Los microservicios son un tipo de arquitectura que sirve para diseñar aplicaciones. Lo que distingue a la arquitectura de microservicios de los enfoques tradicionales y monolíticos es la forma en que desglosa una aplicación en sus funciones principales. Cada función se denomina servicio y se puede diseñar e implementar de forma independiente. Esto permite que funcionen separados (y también, fallen por separado) sin afectar a los demás.
Acuérdese de la última vez que visitó una tienda en línea. Seguramente usó la barra de búsqueda del sitio para ver los productos. Esa búsqueda es un servicio. Es posible que haya visto recomendaciones sobre productos relacionados; estas recomendaciones provienen de una base de datos sobre las preferencias del comprador. Eso también es un servicio. ¿Añadió algún artículo a un carrito de compras en línea? Así es, eso es otro servicio.
Entonces, un microservicio es la función principal de una aplicación que se ejecuta de forma independiente de los demás servicios. Sin embargo, una arquitectura de microservicios no solo se refiere a las funciones principales de una aplicación que no están conectadas directamente; se trata de reestructurar los equipos de desarrollo y la comunicación entre los servicios para estar preparados para las fallas inevitables, la futura necesidad de expansión y una nueva integración de las funciones.
¿Y esto cómo se logra? Con la adaptación de los componentes básicos de una arquitectura orientada a los servicios (SOA) para implementar microservicios.
En los comienzos del desarrollo de las aplicaciones, incluso los cambios mínimos en una aplicación existente requerían una actualización masiva de las versiones con su propio ciclo de control de calidad (QA) que, posiblemente, retrasaba a muchos subequipos. Este enfoque se denomina comúnmente “monolítico” porque el código fuente para toda la aplicación se crea en una única pieza de implementación (como .war o .ear). Si las actualizaciones de una parte de la aplicación generan errores, se debe desconectar toda la unidad, analizarla y solucionar el error. Si bien este enfoque todavía es viable para las aplicaciones pequeñas, las empresas en crecimiento no pueden permitirse ese tiempo de inactividad.
Consideremos la arquitectura orientada a los servicios, que estructura las aplicaciones en servicios discretos y reutilizables que se comunican a través de un bus de servicios empresariales (ESB). En esa arquitectura, cada uno de los servicios individuales se organiza en torno a un proceso comercial específico, y todos cumplen con un protocolo de comunicación (como SOAP, ActiveMQ o Apache Thrift) para poder compartirse a través del ESB. Este conjunto de servicios, integrado a través del ESB, conforma una aplicación.
Por un lado, esto permite que los servicios se diseñen, se prueben y se optimicen de forma simultánea, sin recurrir a ciclos de desarrollo monolítico. Por otro lado, el ESB representa un punto único de fallas para todo el sistema; entonces, de alguna manera, el intento de eliminar la estructura monolítica solo creó otra estructura similar: el ESB, que podría bloquear a toda la empresa.
BENEFICIOS DE LOS MICROSERVICIOS
A través del desarrollo distribuido, los microservicios potencian a los equipos y las rutinas. También puede desarrollar múltiples microservicios de forma simultánea. Gracias a ello, más desarrolladores pueden trabajar en la misma aplicación simultáneamente para reducir el tiempo invertido en el desarrollo.
DESAFIOS DE LOS MICROSERVICIOS
Diseño: debe invertir tiempo en identificar las dependencias entre los servicios. Y debe estar atento, porque cuando se termina un diseño, puede surgir la necesidad de muchos otros debido a esas dependencias. También debe considerar los efectos de los microservicios en sus datos.
Pruebas: las pruebas de integración, así como las pruebas finales, pueden tornarse más complejas e importantes que nunca. Tenga en cuenta que una falla en una parte de la arquitectura puede producir un verdadero error, y esto depende de la manera en que haya diseñado la arquitectura de sus servicios para que sean compatibles entre sí.
Control de versiones: cuando actualice sus sistemas a las nuevas versiones, tenga en cuenta que corre el riesgo de anular la compatibilidad con las versiones anteriores. Se puede diseñar en función de una lógica condicional para manejar este problema, pero se torna una tarea engorrosa y desagradable. Otra opción es implementar múltiples versiones en vivo para distintos clientes, pero esto puede ser más complejo durante el mantenimiento y la gestión.
Implementación: efectivamente también es un desafío, al menos durante la configuración inicial. Para simplificarla, primero debe invertir mucho en la automatización, ya que la complejidad de los microservicios resulta agobiante para la implementación humana. Tenga en cuenta la manera y el orden en que implementará los servicios.
Registro: con los sistemas distribuidos, se necesitan registros centralizados para integrar todos los elementos. De lo contrario, es imposible controlar la expansión.
Monitoreo: es indispensable tener una vista centralizada del sistema para identificar las causas de los problemas.
Depuración: la depuración remota no es opción y no funcionará en decenas ni cientos de servicios. Desgraciadamente, no hay una única respuesta sobre cómo realizar la depuración en este momento.
Conectividad: considere la detección de servicios, así sea centralizada o integrada.
