Microservicios

¿Qué son los microservicios?

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 descompone 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 o 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.


Esto suena conocido...

Si descomponer una aplicación en sus funciones principales y evitar los riesgos de las arquitecturas monolíticas suena conocido, es porque el estilo de arquitectura de los microservicios es similar a la arquitectura orientada a los servicios (SOA), un estilo de diseño de software que ya está bien establecido.

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, retroescalarla 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, si bien el ESB representa un punto único de fallas para todo el sistema, de alguna manera el esfuerzo de eliminar la estructura monolítica solo creó otra estructura similar: el ESB, que podría bloquear a toda la empresa.


Entonces, ¿cuál es la diferencia entre la arquitectura orientada a los servicios y los microservicios?

Los microservicios pueden comunicarse entre sí, generalmente sin estado, para que las aplicaciones diseñadas de esta manera sean más tolerantes a los errores y menos dependientes de un ESB único. Esto también permite que los equipos de desarrollo elijan sus propias herramientas, ya que los microservicios pueden comunicarse a través de las interfaces de programación de aplicaciones (API) que son imparciales respecto al lenguaje.

Si consideramos la historia de la arquitectura orientada a los servicios (SOA), los microservicios no son realmente una idea innovadora. Sin embargo, se han hecho más viables gracias a los avances en las tecnologías de contenedores. Con los contenedores de Linux, ahora puede ejecutar las partes múltiples de una aplicación de forma independiente, en el mismo hardware, con mucho más control sobre las partes y los ciclos de vida individuales.

Ahora comienza la parte más desafiante de cualquier arquitectura nueva. ¿Quiere diseñar aplicaciones nuevas o transformar las antiguas? Cualquiera que sea su elección, deberá considerar los beneficios y los desafíos del diseño de microservicios.


¿Cuáles son los beneficios de una arquitectura de microservicios?

A través del desarrollo distribuido, los microservicios potencian a sus equipos y sus 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.

Aplicaciones listas para comercializarse más rápidamente

Debido a la reducción de los ciclos de desarrollo, una arquitectura de microservicios permite que la implementación y las actualizaciones se realicen más rápidamente.

Gran escalabilidad

A medida que crece la demanda de ciertos servicios, se puede implementar en distintos servidores e infraestructuras para satisfacer sus necesidades.

Capacidad de recuperación

Si estos servicios independientes están bien diseñados, no pueden afectar a los demás. Esto significa que si una parte falla, no afecta a toda la aplicación, a diferencia del modelo de aplicaciones monolíticas.

Facilidad de implementación

Debido a que las aplicaciones basadas en microservicios son más modulares y más pequeñas que las aplicaciones monolíticas tradicionales, ya no es necesario preocuparse por su implementación. Se requiere más coordinación, pero las ventajas son enormes.

Accesibilidad

Como las aplicaciones más grandes se descomponen en piezas más pequeñas, los desarrolladores pueden comprender, actualizar y mejorar más fácilmente esas piezas, y de esta manera, obtener ciclos de desarrollo más rápidos, especialmente cuando se combinan con metodologías de desarrollo ágiles.

Aplicaciones más abiertas

Debido al uso de API políglotas, los desarrolladores tienen la libertad para elegir los mejores lenguajes y tecnologías para la función que se necesita.


¿Y los desafíos?

Si su empresa piensa pasar a una arquitectura de microservicios, deberá cambiar la manera en que trabajan las personas, no solo las aplicaciones. Los cambios de la empresa y la cultura son desafíos en parte porque cada equipo tendrá su propio ritmo de implementación y será responsable por un servicio único con su propio grupo de clientes. En general los desarrolladores no se preocupan por estos cambios, pero son esenciales para que la arquitectura de microservicios se implemente con éxito.

Más allá de la cultura y los procesos, la complejidad y la eficiencia son dos desafíos importantes para una arquitectura basada en microservicios. John Frizelle, arquitecto de plataformas de Red Hat Mobile, expuso estas ocho categorías de desafíos en la presentación que dio en la Red Hat Summit de 2017:

  1. Diseño: debe invertir tiempo en identificar las dependencias entre los servicios. Y 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.
  2. Pruebas: las pruebas de integración, como las pruebas finales, pueden volverse más complejas y ser más 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 se den soporte entre sí.
  3. Control de versiones: cuando actualice sus sistemas a las nuevas versiones, tenga en cuenta que corre el riesgo de cancelar la compatibilidad con las versiones anteriores. Se puede diseñar 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 eso puede ser más complejo durante el mantenimiento y la gestión.
  4. 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. Reflexione sobre la manera y el orden en que implementará los servicios.
  5. Registro: con los sistemas distribuidos se necesitan registros centralizados para integrar todos los elementos. De lo contrario, es imposible controlar la escalabilidad.
  6. Monitoreo: es indispensable tener una vista centralizada del sistema para identificar las causas de los problemas.
  7. Depuración: la depuración remota no es opción y no funcionará en decenas ni cientos de servicios. Desgraciadamente, no hay una respuesta única sobre cómo realizar la depuración en este momento.
  8. Conectividad: considere la detección de servicios, si es centralizada o integrada.

Con los microservicios puede hacer mucho más