Header Ads Widget

Ticker

6/recent/ticker-posts

Sugerencias para microservicios de tamaño adecuado

 

Ajustar el tamaño de su API es una de las consideraciones más importantes en las que puede participar a nivel de producto. Asegurarse de que su API haga lo que debería hacer parece un proceso obvio, pero aclarar los parámetros exactos y establecer esas expectativas para sus usuarios puede ser bastante complicado.

Hoy, vamos a profundizar en lo que significa el tamaño correcto para el desarrollador de API promedio. Primero, discutiremos microservicios y monolitos , así como algunos conceptos erróneos con respecto a esos dos paradigmas. Luego, veremos algunos pasos sencillos que cualquier desarrollador de API puede seguir para dimensionar correctamente su servicio, considerando la lógica empresarial específica para impulsar los procesos de dimensionamiento correcto.

Aclaraciones y términos
Antes de explorar este tema, debemos definir algunos términos que se utilizan con frecuencia en este contexto. El concepto central de "dimensionamiento correcto" sugiere que existen "mejores prácticas" y, como tal, la adopción de un lenguaje y comprensión comunes será fundamental para dimensionar correctamente.

Primero, ¿qué significa el tamaño correcto? El concepto de dimensionamiento correcto depende de la idea de que una API debe ser lo suficientemente grande para hacer lo que se supone que debe hacer, pero no tanto como para que se vuelva difícil de manejar o ineficaz. Por supuesto, esto puede ser subjetivo y, como tal, puede ser un tema un tanto nebuloso. No existe un tamaño correcto perfecto porque el tamaño correcto para una API dependerá en gran medida del propósito de la API.

Una buena forma de pensar en esto es imaginar una afirmación como "Quiero comprar un automóvil". ¿Cuál es el auto perfecto en esta situación? Para un conductor de la ciudad, las necesidades serán muy diferentes de, digamos, un conductor rural que vive cuesta arriba en una pendiente empinada. Por esta razón, antes de comenzar a intentar adjuntar una estimación del "tamaño correcto" en una API, debe averiguar cuál es realmente el alcance de su servicio.

A continuación, debemos definir dos términos prevalentes que surgen en este tipo de conversaciones. Primero, analicemos qué es un “monolito”. A menudo escuchará el tamaño correcto en el contexto de “no ser un monolito”, pero la realidad es que la idea de un monolito no es mala en sí misma, es solo un enfoque muy particular para un conjunto de circunstancias muy particular. El monolito es el concepto de una "mega API" singular, en la que todo es manejado por un solo servicio o pila de servicios que se ejecutan en un código grande y complejo. Uno de los inconvenientes de tal paradigma, y ​​esta es la razón principal por la que las personas evitan los monolitos en el espacio moderno, es que el mantenimiento de dicho sistema da como resultado una pérdida de servicio que hace que la API sea cada vez más compleja con funciones adicionales, lo que hace que sea más difícil de implementar cambios o adaptarse a nuevos entornos empresariales.

Los microservicios a menudo se posicionan como una antítesis del estado de ánimo monolítico. Si las complejas interacciones de una base de código crean una pila de servicios, ¿por qué no simplemente separar esos servicios? Romper el monolito en múltiples partes más pequeñas significa que cada API individual puede llevar a cabo una función discreta específica (o un conjunto de funciones) de manera más efectiva y aislada, trabajando con otras unidades discretas cuando surja la necesidad. Esta funcionalidad y extensibilidad independientes otorga a los microservicios la capacidad de pivotar y ser ágiles, pero tiene sus propios costos (que discutiremos en breve).

Pasos para el tamaño correcto
Ahora que hemos discutido el tamaño correcto en términos generales, veamos cómo manejamos el tamaño real de lo que está construido para ver si la API tiene el tamaño correcto o no. Hay un millón de técnicas para hacer esto que han sido defendidas por muchos desarrolladores, líderes de opinión y expertos, pero generalmente todas se dividen en algunas categorías específicas.

1. Audite el propósito de su API
Comprender cuál es el objetivo final de su API lo ayudará a determinar qué enfoque tomar. Por ejemplo, las funciones discretas más pequeñas que operan de forma independiente en lugar de como parte de una suite se prestan a los microservicios. Por el contrario, algo que usa todo y depende de un flujo completo que utiliza una pila de servicios es más apropiado para un monolito. El dimensionamiento correcto no es solo el dimensionamiento adecuado para el uso de recursos o para lo que puede soportar en este momento; también tiene el tamaño adecuado para el propósito fundamental y la forma de la aplicación, ahora y en el futuro.

También hay una pregunta más general sobre cuánto es demasiado. Al crear una API, puede ser tentador simplemente incluir todas las funciones posibles que imagina que serían necesarias en el flujo de trabajo típico de la API. Sin embargo, el caso de uso real de las API es como un conjunto de servicios colectivos; en consecuencia, busque metodologías de código abierto y predeterminadas tanto como sea posible.

2. Audite sus recursos
¿Tiene la capacidad de tener varios equipos, enfoques, etc.? Si es así, un microservicio puede ser apropiado. Sin embargo, desarrollar un microservicio puede ser económico en recursos; sin embargo, crear una colección de microservicios puede ser costoso y llevar mucho tiempo. En tal caso, donde no hay suficientes recursos para tal realidad de paradigma de desarrollo, un monolito puede ser apropiado, especialmente si se combina con una reducción en el alcance. En última instancia, sus recursos definirán su alcance y capacidad de ejecución y, en última instancia, será una de las facetas más importantes a considerar para el dimensionamiento correcto.

3. Audite sus planes
Gran parte de la resistencia al paradigma monolítico no proviene de la aplicación adecuada del paradigma, sino de las dificultades que surgen al convertir algo que debería haber sido una colección de microservicios desde el principio en microservicios durante toda la vida útil del servicio. Auditar adecuadamente no solo cuál es su API, sino lo que podría ser en el futuro, puede ayudarlo a elegir el paradigma correcto desde el principio y luego ajustar su alcance en consecuencia.

4. Adoptar un documento de alcance
Una de las mejores cosas que puede adoptar al principio del desarrollo de una API es un documento de alcance. Cada API es esencialmente un proyecto, y en el mundo de la gestión de proyectos, un documento de alcance establece los límites de ese proyecto. Además de garantizar que el desarrollo no resulte en una cobertura e implementación progresivas, los documentos del alcance del proyecto pueden establecer expectativas para los hitos de desarrollo tempranos, fechas límite para funciones o características, costos de recursos esperados e incluso pasos discretos que se deben tomar para construir y mejorar el servicio. como un todo.

Una vez que se establece el alcance de un servicio, también es útil establecer y gestionar las expectativas . Al comunicar la forma y función de una API, no prometa la luna, prometa lo que realmente funcionará con los recursos disponibles. Con demasiada frecuencia, las API se salen de su alcance porque intentan ser todo para todos los usuarios. Si establece sus expectativas desde el principio y gestiona las expectativas de los usuarios desarrolladores, este punto de presión en particular puede evitarse.

5. Practique el asalto de eventos
Un método que ha sido particularmente útil para planificar implementaciones técnicas es la idea de la tormenta de eventos. Nacido del diseño impulsado por dominios, la tormenta de eventos es una metodología en la que los servicios están diseñados por dominios de función y necesidades comerciales. Es un método global de establecimiento de límites. En esencia, todas las partes interesadas del proyecto se reunirán y se alinearán detrás de una comprensión de la necesidad comercial, la implementación del dominio y, a veces, la solución técnica. De esta manera, los desarrolladores de API pueden tratar su API como un proyecto con una banda estrecha y definida de funciones y expectativas que satisfacen todas las necesidades primarias del grupo principal de partes interesadas.

6. Establezca una mirada de retroalimentación con los usuarios desarrolladores
Por último, establecer una línea de comunicación coherente entre el usuario y el desarrollador es una herramienta vital para prevenir el deslizamiento de funciones. Los desarrolladores de API deben esforzarse por lograr un equilibrio entre las cosas que deben construirse y las características que sería bueno construir. Este punto de equilibrio requiere una línea de comunicación sólida . Los usuarios pueden ayudar a introducir en el sistema lo que les gustaría ver, y los desarrolladores pueden ayudar a comunicar los plazos, las limitaciones de recursos y los planes a largo plazo de manera eficaz. Esta comunicación constante ayudará a establecer el tono de su organización y limitará lo que realmente se puede hacer dentro de los límites de la solicitud del usuario y el cumplimiento del servicio .

¿Es malo el paradigma monolítico?
Como parte de esta cuestión de dimensionamiento correcto, existe una discusión subyacente sobre si el monolito, como concepto, es malo o no. Con demasiada frecuencia, el consejo es evitar los monolitos porque son monolitos; la realidad, sin embargo, es que pintar monolitos como universalmente malos pasa por alto una gran cantidad de contexto y advertencias.

Sí, de hecho, una API no debería ser un monolito a menos que sea absolutamente necesario. Además, una API solo debe ser tan monolítica como sea necesario para funcionar para esa expectativa principal. Los monolitos no son intrínsecamente malos; la mayoría de las veces, es la adopción incorrecta del paradigma del monolito.

La idea de que todas las cosas deberían ser microservicios pasa por alto los muy buenos casos de uso para el desarrollo de API monolíticas , especialmente cuando esa API debería ser por diseño una pila de funciones no aisladas. Los modelos monolíticos son apropiados cuando un solo equipo puede posiblemente poseer la totalidad de la pila de API, siempre que el tamaño de esa API monolítica no sea en sí mismo un bloqueador. Cuando un solo equipo posee una sola API y esa API es un conjunto apilado de funciones dependientes, un monolito puede ser la opción más adecuada. Este modelo también es apropiado cuando se requiere un cierto nivel de seguridad o interioridad; Los microservicios crean más oportunidades para la exposición, la interceptación de datos, etc., por lo que, en algunos casos mínimos, un monolito tendría sentido como un único nexo seguro.

Cabe señalar que la principal preocupación en torno a los monolitos, que son inflexibles y evitan la adaptación, es solo una preocupación si tal giro es una posibilidad. Por ejemplo, si la construcción de una API de propósito único que solo hace una cosa en un entorno seguro es el caso en cuestión, un monolito puede, de hecho, beneficiarse de esta naturaleza más restringida.

Cuándo aprovechar los microservicios
Entonces, ¿Cuándo deberían adoptarse los microservicios? Los microservicios como patrón de diseño reflejan la idea de dividir los servicios en múltiples partes más pequeñas, todas las cuales pueden llevar a cabo su función principal de forma independiente y, al mismo tiempo, permitir la interconexión y el tránsito con otras API para funciones superiores. El principal beneficio de este enfoque es que el microservicio es escalable y puede expandirse o contraerse de forma independiente, además de la mayor colección de servicios, lo que ofrece una mayor agilidad.

La respuesta de cuándo aprovechar los microservicios viene con esa misma naturaleza. Como se supone que cada microservicio es independiente, una calificación importante para la adopción es que cada función debe existir de forma independiente y funcionar como un nodo en la red más amplia. La segmentación de función y forma debe ser aprovechable; de lo contrario, está dividiendo algo que depende en gran medida de sus funciones internas en un monolito en pedazos.

Hay inconvenientes en los microservicios que deben mencionarse. Dado que está creando muchas pequeñas API, necesita más recursos para administrar esos proyectos discretos y un ciclo de desarrollo total más largo. Para ser claros, es cierto que los microservicios pueden permitir un desarrollo más rápido y una entrega más rápida, pero esta ganancia generalmente se encuentra cuando se realiza un microservicio o una pequeña cantidad en total. Mover un monolito a una colección de potencialmente decenas o cientos de microservicios puede resultar más costoso en algunas situaciones. Si esto no es algo que pueda admitir, entonces su mejor opción para el tamaño correcto puede ser adoptar un modelo monolítico, pero mantenga el alcance muy pequeño. La demanda de recursos también puede ser una preocupación: el registro, el almacenamiento en caché, el rendimiento, etc. pueden volverse problemáticos a escala de microservicio cuando se acaba de crear una API y, como tal,

Conclusiones
Los consejos de este artículo no deben usarse como un conjunto de reglas estrictas y rápidas, sino como un marco que puede ayudarlo a guiarlo en la dirección correcta. En última instancia, el tamaño adecuado de los microservicios dependerá en gran medida de lo que desee que haga, se vea y admita el microservicio. Por ejemplo, un servicio monolítico con un conjunto de características de amplio alcance será apropiado para casos comerciales específicos donde los microservicios que proporcionan un dominio mínimo de funciones no lo serían.

¿Qué opinas de estos consejos? ¿Hay más consejos que creas que valen la pena para ayudar a las API de tamaño adecuado? ¡Háznoslo saber a continuación!

Publicar un comentario

0 Comentarios