Antes de entender Contenedores, entendamos Microservicios

Una característica que tienen las Tecnologías de la Información (antes Sistemas, Informática, etc.) es su siempre MUY rápida evolución, por sobre todo desde los últimos años de década de los noventa del Siglo XX, y qué decir de lo que llevamos de este Siglo XXI.

Ya en esta tercera década del Siglo XXI, vemos como más que nunca es tan sencillo que una empresa o una persona publique una idea, un concepto y en menos de una semana todos (directa o indirectamente involucrados con las Tecnologías de la Información) hablan del tema.

¿A qué viene todo esto? La palabra o más bien las palabras que ahora están en boca de todos son: "Contenedores" y "Microservicios". Todos ahora las pronuncian y (sin afán de criticar o hacer escarnio de nada o nadie) cada vez es más grande la confusión acerca de estas palabras, aplicadas obviamente a las Tecnologías de la Información.

Como lo dice el título de esta aportación al Blog Tecnológico TechData México, antes de entender Contenedores, entendamos Microservicios. Comencemos pues.

¿Qué son los Microservicios?

Los microservicios son un enfoque arquitectónico para la creación de aplicaciones. Como marco arquitectónico, los microservicios se distribuyen y se acoplan libremente, por lo que los cambios de un equipo no dañarán toda la aplicación. El beneficio del uso de microservicios es que los equipos de desarrollo pueden construir rápidamente nuevos componentes de aplicaciones para satisfacer las cambiantes necesidades comerciales.

El párrafo anterior es para nosotros la mejor definición de qué son, cuales son sus alcances y se vislumbra ya sus beneficios. Desde ya podemos decir que esto se enfoca y tiene sentido, para aquellas empresas que se dedican en cuerpo y alma al Desarrollo, o las áreas de Desarrollo dentro de organizaciones, instituciones y empresas.

Una forma de crear aplicaciones, optimizadas para DevOps y CI/CD

Lo que diferencia a una arquitectura de microservicios de los enfoques monolíticos más tradicionales es cómo divide una aplicación en sus funciones principales. Cada función se llama servicio y se puede construir e implementar de forma independiente, lo que significa que los servicios individuales pueden funcionar (y fallar) sin afectar negativamente a los demás. Esto nos ayuda a adoptar el lado tecnológico de DevOps y hacer que la iteración y entrega constante (constant iteration and delivery o CI/CD) sean más fluidas y alcanzables.

Piense en su última visita a un minorista en línea. Es posible que haya utilizado la barra de búsqueda del sitio para buscar productos. Esa búsqueda representa un servicio. Quizás también haya visto recomendaciones para productos relacionados, recomendaciones extraídas de una base de datos de preferencias de compradores. Eso también es un servicio. ¿Agregaste un artículo a un carrito en línea? Lo has adivinado, otro servicio.

Por lo tanto, un microservicio es una función central de una aplicación y se ejecuta independientemente de otros servicios, pero una arquitectura de microservicios es algo más que el simple acoplamiento de las funciones centrales de una aplicación: se trata de reestructurar los equipos de desarrollo y la comunicación entre servicios de una manera que prepare para fallas inevitables, escalabilidad futura e integración de nuevas características.

¿Cómo se logra esto? Adaptando los conceptos básicos de una Arquitectura Orientada a Servicios (SOA) para implementar microservicios.

Esto suena familiar...

Si desglosar las aplicaciones en sus funciones principales y evitar las trampas de los monolitos suena familiar, es porque el estilo arquitectónico de microservicios es similar a la Arquitectura Orientada a Servicios (SOA). Un estilo de diseño de software ya bien establecido.

En los primeros días del desarrollo de la aplicación, incluso los cambios mínimos en una aplicación existente requerían una actualización de la versión mayorista con su propio ciclo de aseguramiento o garantía de calidad (QA), lo que podría ralentizar a muchos sub-equipos. Este enfoque a menudo se denomina "monolítico" porque el código fuente de toda la aplicación se creó en una sola unidad de implementación (como .war o .ear). Si las actualizaciones de una parte de una aplicación causaron errores, todo se tuvo que desconectar, reducir y corregir. Si bien este enfoque aún es viable para aplicaciones pequeñas, las empresas en crecimiento no pueden permitirse el tiempo de inactividad.

Ingrese a la arquitectura orientada a servicios, que estructura las aplicaciones en servicios discretos y reutilizables que se comunican a través de un bus de servicios empresariales (ESB). En esta arquitectura, los servicios individuales, cada uno organizado en torno a un proceso comercial específico, se adhieren a un protocolo de comunicación (como SOAP, ActiveMQ o Apache Thrift) para compartir a través del ESB. En conjunto, este conjunto de servicios, integrado a través de un ESB, comprende una aplicación.

Por un lado, esto permite que los servicios se construyan, prueben y modifiquen simultáneamente, no más ciclos de desarrollo monolíticos. Por otro lado, sin embargo, el ESB representa un único punto de falla para todo el sistema, por lo que, en cierto modo, el esfuerzo por eliminar el monolito solo creó uno nuevo: el ESB, que podría potencialmente obstaculizar a toda la organización.

De SOA a microservicios

¿Cual es la diferencia? Los microservicios pueden comunicarse entre sí, generalmente sin estado, por lo que las aplicaciones creadas de esta manera pueden ser más tolerantes a fallas y menos dependientes de un único ESB. Esto también permite a los equipos de desarrolladores elegir sus propias herramientas, ya que los microservicios pueden comunicarse a través de Interfaces de Programación de Aplicaciones (API) independientes del lenguaje.

Dada la historia de SOA, los microservicios no son una idea tan nueva. Sin embargo, los microservicios se han vuelto más viables gracias a los avances en las tecnologías de contenedorización. Con los contenedores de Linux, ahora puede ejecutar varias partes de una aplicación de forma independiente, en el mismo hardware, con un control mucho mayor sobre sus piezas individuales y sus ciclos de vida. Junto con los equipos de API y DevOps, los microservicios en contenedores son la base de las aplicaciones nativas de la nube.

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

Los microservicios dan un impulso a sus equipos y rutinas a través del desarrollo distribuido. También puede desarrollar múltiples microservicios al mismo tiempo. Esto significa que más desarrolladores trabajan en la misma aplicación, al mismo tiempo, lo que resulta en menos tiempo dedicado al desarrollo.

Listo para el mercado más rápido.- Dado que los ciclos de desarrollo se acortan, una arquitectura de microservicios admite una implementación y actualizaciones más ágiles.

Altamente escalable: a medida que crece la demanda de ciertos servicios, puede implementar en múltiples servidores e infraestructuras para satisfacer sus necesidades.

Resistente.- Estos servicios independientes, cuando se construyen adecuadamente, no se impactan entre sí. Esto significa que si una pieza falla, la aplicación completa no se cae, a diferencia del modelo de aplicación monolítica.

Fácil de implementar.- Debido a que sus aplicaciones basadas en microservicios son más modulares y más pequeñas que las aplicaciones monolíticas tradicionales, las preocupaciones que vinieron con esas implementaciones se niegan. Esto requiere más coordinación, con lo que una capa de malla de servicios puede ayudar, pero los beneficios pueden ser enormes.

Accesible.- Debido a que la aplicación más grande se divide en partes más pequeñas, los desarrolladores pueden comprender, actualizar y mejorar más fácilmente esas partes, lo que resulta en ciclos de desarrollo más rápidos, especialmente cuando se combinan con metodologías de desarrollo ágiles.

Más abierto.- Debido al uso de API políglotas, los desarrolladores tienen la libertad de elegir el mejor lenguaje y tecnología para la función necesaria.

¿Y los desafíos?

Si su organización está pensando en cambiar a una arquitectura de microservicios, espere cambiar la forma en que las personas trabajan, no solo las aplicaciones. Los cambios organizativos y culturales se identifican como desafíos en parte porque cada equipo tendrá su propia cadencia de implementación y será responsable de un servicio único con su propio conjunto de clientes. Es posible que esas no sean las preocupaciones típicas del desarrollador, pero serán esenciales para una arquitectura exitosa de microservicios.

Más allá de la cultura y el proceso, la complejidad y la eficiencia son dos desafíos principales de una arquitectura basada en microservicios. John Frizelle, arquitecto de plataforma para Red Hat Mobile, expuso estas ocho categorías de desafío en su charla de 2017 en Red Hat Summit:

Construcción: Debe dedicar tiempo a identificar dependencias entre sus servicios. Tenga en cuenta que completar una compilación puede desencadenar varias otras compilaciones, debido a esas dependencias. También debe tener en cuenta los efectos que los microservicios tienen en sus datos.

Pruebas: Las pruebas de integración, así como las pruebas de extremo a extremo, pueden volverse más difíciles y más importantes que nunca. Tenga en cuenta que una falla en una parte de la arquitectura podría causar que falle un par de saltos, dependiendo de cómo haya diseñado sus servicios para apoyarse mutuamente.

Control de versiones: cuando actualice a nuevas versiones, tenga en cuenta que puede romper la compatibilidad con versiones anteriores. Puede construir una lógica condicional para manejar esto, pero eso se vuelve difícil de manejar y desagradable, rápido. Alternativamente, podría soportar múltiples versiones en vivo para diferentes clientes, pero eso puede ser más complejo en mantenimiento y administración.

Implementación: Sí, esto también es un desafío, al menos en la configuración inicial. Para facilitar la implementación, primero debe invertir en mucha automatización ya que la complejidad de los microservicios se vuelve abrumadora para la implementación humana. Piense cómo va a implementar los servicios y en qué orden.

Registro: con sistemas distribuidos, necesita registros centralizados para unir todo. De lo contrario, la escala es imposible de gestionar.
Monitoreo: es fundamental tener una vista centralizada del sistema para identificar las fuentes de problemas.

Depuración: la depuración remota a través de su entorno de desarrollo integrado local (IDE) no es una opción y no funcionará en docenas o cientos de servicios. Lamentablemente, no hay una respuesta única sobre cómo depurar en este momento.

Conectividad: considere el descubrimiento de servicios, ya sea centralizado o integrado.

Cierto que los Microservicios, al igual que SOA y otros conceptos dentro de las Tecnologías de la Información, pueden aplicarse a su empresa, organización y/o institución de distintas y diversas maneras. Pero en este caso en particular, lo cual abordaremos con más detalle en una entrada posterior, puede ser abordado con los Contenedores.

¿Está Usted listo para los Contenedores?