¿Cuándo debería utilizar la arquitectura de microservicios? Escuche historias del mundo de los servomotores.

Imagine que está ensamblando un brazo robótico complejo, en el que cada articulación es impulsada por un servomotor independiente. Dedos, muñecas, codos, hombros: ¿qué pasaría si todos los motores estuvieran gestionados por un controlador central? Un pequeño fallo en la punta de un dedo puede paralizar todo un brazo. Pero ¿y si cada articulación tuviera su propio sistema de control? Los problemas al alcance de la mano sólo se quedan al alcance de la mano.

Este es el pensamiento central de la arquitectura de microservicios. No se trata de una palabra técnica que surge de la nada, sino de una forma de resolver problemas, como dotar a cada parte clave de un sistema mecánico de un "cerebro" independiente y coordinado.

Ese problemático sistema de "grandes"

Hace unos años participé en un proyecto de renovación de una línea de producción automatizada. El sistema original era un gigante: procesamiento de pedidos, programación de materiales, control de maquinaria, inspección de calidad... todo ello en un solo programa. Al principio funcionó sin problemas, hasta que un día fue necesario actualizar cierto módulo de identificación de materiales. ¿El resultado? Para implementar la actualización, fue necesario apagar todo el sistema durante seis horas.

La línea de producción se detuvo, los clientes estaban ansiosos y el equipo se quedó despierto hasta tarde. En ese momento me di cuenta de repente: cuando el sistema se convierte en un ovillo de hilo retorcido, cualquier pequeño ajuste puede convertirse en un desastre.

La aparición de los microservicios viene precisamente a desatar este ovillo de hilo. No se trata de desarmar las cosas y terminar con ellas, sino de permitir que cada parte crezca de forma independiente, se repare de forma independiente y respire de forma independiente.

Microservicios: piense como módulos mecánicos

¿Cuándo debería considerar esta arquitectura?

• Cuando prevé cambios que suceden con frecuencia: Si su lógica empresarial necesita ajustes frecuentes, como el diseño mecánico (optimizar la velocidad de respuesta del mecanismo de dirección hoy y agregar tipos de sensores mañana), los microservicios hacen que cada cambio esté localizado y no afectará a todo el cuerpo.
• Cuando las cargas de diferentes módulos varían mucho: Imagine que el sistema de vigilancia procesa miles de imágenes por segundo, mientras que solo se accede al módulo de gestión de usuarios unas pocas veces al día. Agruparlos es como usar la misma fuente de alimentación para accionar un servomotor de alta potencia y una pequeña luz indicadora: ineficiente y un desperdicio de recursos.
• Cuando los equipos necesitan desarrollarse en paralelo:existirkpotenciaEn la práctica, descubrimos que cuando diferentes grupos desarrollan al mismo tiempo el control de hardware, el procesamiento de datos, la interfaz de usuario, etc., los microservicios pueden reducir las esperas y los conflictos, al igual que en el ensamblaje mecánico, cada grupo procesa diferentes piezas al mismo tiempo y finalmente se conecta sin problemas.
• Cuando necesitas flexibilidad, no perfección: La arquitectura tradicional persigue “nunca el tiempo de inactividad”, pero en realidad los fallos son inevitables. Los microservicios admiten que las piezas pueden fallar, pero garantizan que el conjunto aún pueda funcionar, al igual que una articulación de un brazo robótico se bloquea temporalmente y las piezas restantes aún pueden completar las operaciones básicas.

Preguntas y respuestas en algunos escenarios reales.

P: ¿Los microservicios harán que el sistema sea más complejo?

Es como mantener un robot ensamblado a partir de múltiples servos independientes. Mirando cada servo individualmente, el cableado es claro y las funciones son claras; pero para un controlador "multiuso" grande, el cableado interno puede estar enredado. Los microservicios aumentan la cantidad de componentes que se implementan y monitorean, pero la lógica interna de cada componente es más simple y más enfocada.

P: ¿Cuándo no son adecuados los microservicios?

Si su sistema es como un simple destornillador eléctrico de mano (con una única función, cambios mínimos y un número estable de usuarios), dividirlo deliberadamente en microservicios agregará gastos generales innecesarios. Las elecciones arquitectónicas siempre responden a necesidades reales, no a tendencias técnicas.

P: ¿Cómo determinar la granularidad dividida?

En el diseño mecánico, a menudo dividimos los módulos según límites funcionales: parte motriz, parte sensora y parte de control. Lo mismo ocurre con el software. Una función se considera un microservicio si puede describirse, probarse, implementarse de forma independiente e interactuar con otras partes a través de interfaces claras. No lo desmontes demasiado, ya que no convertirías cada engranaje en su propio módulo, lo que haría que el montaje fuera una pesadilla.

De la idea a la implementación: algunas reflexiones no lineales

Elegir microservicios no es una decisión de la noche a la mañana. Es un poco como modificar un equipo mecánico antiguo: primero dibuje todos los diagramas de módulos funcionales, encuentre las piezas con el acoplamiento más estrecho y los cambios más frecuentes, y comience a dividir el piloto desde aquí. No es necesario reconstruir todo el sistema de una vez; eso sería como intentar reemplazar todos los motores mientras la máquina está en funcionamiento, y es demasiado arriesgado.

existirkpotenciaEn nuestra práctica técnica, a menudo dejamos que aparezcan nuevas funciones primero en forma de microservicios y verificamos gradualmente su estabilidad y valor. Partes del antiguo sistema pueden permanecer intactas y comunicarse con los nuevos servicios a través de una capa de adaptación. Esta evolución gradual reduce la presión del equipo y hace que la deuda técnica sea controlable.

Descubrirá que los mayores cambios provocados por los microservicios no son solo técnicos. Impulsa al equipo a pensar en límites de responsabilidad más claros, fomenta equipos pequeños y finos y cultiva un énfasis en los "contratos" entre sistemas; estos beneficios blandos a veces son más valiosos que las mejoras en el desempeño.

escrito en

Volvamos a la metáfora del brazo robótico del principio. Le damos a cada articulación un control independiente, no para crear separación, sino para hacer que el movimiento general sea más flexible y robusto. Cuando la punta de un dedo necesita una actualización del sensor, solo necesitamos pausar esa punta, no todo el brazo.

Lo mismo ocurre con la arquitectura de microservicios. Persigue un mayor nivel de sinergia y resiliencia de una manera aparentemente descentralizada. Si su proyecto enfrenta iteraciones lentas, proliferación de fallas y congestión del equipo, es posible que desee detenerse y pensar: ¿es hora de equipar cada "articulación" del sistema con su propio "pequeño cerebro"?

En el mundo de la tecnología, a veces dejar que cada parte crezca de forma independiente puede hacer que el conjunto se mueva más estable y llegue más lejos. Al igual que un buen diseño mecánico, no persigue un control maestro universal, sino que permite que cada servomotor funcione al máximo en la posición correcta.

Establecido en 2005,kpotenciase ha dedicado a un fabricante profesional de unidades de movimiento compacto, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en tecnología de accionamiento modular, Kpower integra motores de alto rendimiento, reductores de precisión y sistemas de control multiprotocolo para proporcionar soluciones de sistemas de accionamiento inteligentes eficientes y personalizadas. Kpower ha brindado soluciones de sistemas de accionamiento profesionales a más de 500 clientes empresariales en todo el mundo con productos que cubren diversos campos, como sistemas domésticos inteligentes, electrónica automática, robótica, agricultura de precisión, drones y automatización industrial.