[vc_row][vc_column][vc_column_text]
La idea central detrás de los microservicios es que algún tipo de aplicaciones se conviertan en fáciles de construir y mantener cuando esta se descompone en pequeñas partes que puedan trabajar juntas. Cada componente se encuentra desarrollado y actualizado por separado, y la aplicación es la suma de estos componentes. Esto es en contraste de las aplicaciones «monolíticas» que son todas desarrolladas en una pieza.
Una aplicación construida como un conjunto de componentes modulares es fácil de entender, fácil de probar, y más importante fácil de darle mantenimiento durante el ciclo de vida de la aplicación. Esto permite a las organizaciones tener una mayor agilidad y mejorar los tiempos de llevar mejoras a producción. Esta opción ha probado ser superior, especialmente para grandes aplicaciones empresariales que son desarrolladas por equipos que se encuentran en distribuidos.
También presenta otros beneficios:
- Independencia del desarrollador: Pequeños equipos trabajando en paralelo y pueden iterar más rápido que grandes equipos.
- Aislamiento y resilencia: Si un componente muere, el resto de la aplicación puede continuar funcionando.
- Escalabilidad: Pequeños componentes toman menos recursos y pueden ser escalados al conocer la demanda de recursos de dicho componente.
- Automatización del ciclo de vida: Componentes individuales son fáciles de incluir en el proceso de entrega continua, mientras que procesos de despliegue no son posibles con aplicaciones monolíticas.
- Relación con el negocio: La arquitectura de microservicios se divide a lo largo de los límites del dominio, lo que aumenta la independencia y la comprensión de toda la organización.
La definición común de microservicios generalmente se basa en cada microservicio que proporciona un punto final de un API, a menudo, pero no siempre, una API REST sin estado a la que se puede acceder a través de HTTP(S) al igual que una página web estándar. Este método para acceder a los microservicios los hace más fáciles de usar para los desarrolladores, ya que solo requieren herramientas y métodos con los que muchos desarrolladores ya están familiarizados.
[/vc_column_text][/vc_column][vc_column][vc_single_image image=»1722″ img_size=»full» alignment=»center»][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
¿Es este un nuevo concepto?
La idea de separar las aplicaciones en partes más pequeñas no es nada nuevo; hay otros paradigmas de programación que abordan este mismo concepto, como la arquitectura orientada a servicios (SOA). Sin embargo, los avances tecnológicos recientes, junto con una creciente expectativa de «experiencias digitales» integradas, han dado lugar a una nueva generación de herramientas y técnicas de desarrollo utilizadas para satisfacer las necesidades de las aplicaciones empresariales modernas.
Los microservicios dependen no solo de la tecnología que se está configurando para respaldar estos conceptos, sino también de una organización que tenga la cultura, el conocimiento y las estructuras establecidas para que los equipos de desarrollo puedan adoptar este modelo. Los microservicios forman parte de un cambio más amplio en los departamentos de TI hacia una cultura DevOps, en la que los equipos de desarollo y operaciones trabajan estrechamente para respaldar una aplicación a lo largo de su ciclo de vida y pasan por un ciclo de publicación rápido o incluso continuo en lugar de un ciclo tradicional largo.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
¿Por que es importante el código abierto para los microservicios?
Cuando diseña sus aplicaciones desde cero para que sean modulares y en base a componentes, le permite utilizar componentes de inserción en muchos lugares donde en el pasado puede haber requerido soluciones patentadas, ya sea por la licencia de los componentes o los requisitos especializados. Muchos componentes de aplicaciones pueden ser herramientas de código abierto disponibles en el mercado, y existen innumerables proyectos de código abierto que implementan requisitos transversales de arquitecturas de microservicios como autenticación, descubrimiento de servicios, registro y supervisión, equilibrio de carga, escalado y muchos más.
Un enfoque de microservicios también puede facilitar que los desarrolladores de aplicaciones ofrezcan interfaces alternativas a sus aplicaciones. Cuando todo es una API, las comunicaciones entre los componentes de la aplicación se estandarizan. Todo lo que tiene que hacer un componente para hacer uso de su aplicación y sus datos es poder autenticarse y comunicarse a través de esas API estándar. Esto permite que tanto los que están dentro como, cuando corresponda, los que estén fuera de su organización, desarrollen fácilmente nuevas formas de utilizar los datos y servicios de su aplicación.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
¿Donde entran las tecnologías de contenedores?
El concepto moderno de contenedores ligeros del sistema operativo se introdujo a principios de la década del 2000 como parte del proyecto FreeBSD. Docker proporcionó una experiencia de usuario mejorada para crear y compartir imágenes de contenedores y, como resultado, vio una gran adopción a partir del 2013. Los contenedores son una opción natural para microservicios, que coinciden con el deseo de componentes livianos y ágiles que puedan administrase fácilmente y reemplazarse dinámicamente. A diferencia de las maquinas virtuales, los contenedores están diseñados para reducirse a las piezas viables mínimas necesarias para ejecutar cualquier cosa para los que este diseñado el contenedor, en lugar de empaquetar múltiples funciones en la misma máquina virtual o física. La facilidad de desarrollo que proporciona Docker y herramientas similares ayuda a que sea posible un rápido desarrollo y prueba de servicios.
Por supuesto, los contenedores son solo una herramienta, y la arquitectura de microservicios es solo un concepto. Es completamente posible construir una aplicación que podría describirse como seguir un enfoque de microservicios sin usar contenedores, del mismo modo que sería posible construir una aplicación mucho más tradicional dentro de un contenedor, lo que puede tener sentido cuando se quiere aprovechar las capacidades de orquestación de contenedores sin volver a escribir una aplicación grande y monolítica.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
¿Cómo se organizan los microservicios?
Para ejecutar realmente una aplicación basada en microservicios, debe ser capaz de supervisar, administrar y escalar las diferentes partes constituyentes. Hay una serie de herramientas diferentes que pueden permitirle lograr esto. Para contenedores, las herramientas de código abierto como Kubernetes probablemente serán parte de su solución. Alternativamente, para piezas que no son contenedores de una aplicación, se pueden usar otras herramientas para orquestar componentes: por ejemplo, en una nube OpenStack, puede usar Heat para administrar los componentes de la aplicación.
Otra opción es utilizar una herramienta de Platform as a Service (PaaS), que permite a los desarrolladores centrarse en escribir código al abstraer parte de la tecnología de orquestación subyacente y permitirles seleccionar fácilmente componentes de código abierto listos para usar para ciertas partes de una aplicación, como un motor de almacenamiento de base de datos, un servicio de registro, un servidor de integración continua, un servidor web u otras piezas del rompecabezas. Algunos sistemas PaaS como OpenShift usan directamente proyectos iniciales como Docker y Kubernetes para administrar componentes de aplicaciones, mientras que otros intentan implementar las herramientas de administración por sí mismos.
[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
¿Qué pasa con las aplicaciones existentes?
Si bien la utilización de microservicios puede ser un componente importante de la estrategia de TI de una organización en el futuro, sin duda hay muchas aplicaciones que no cumplen con este modelo, ni es probable que esas aplicaciones se remodelen de la noche a la mañana para cumplir con este nuevo paradigma. Existe un costo cultural y técnico para pasar a una arquitectura de microservicios, pero, afortunadamente, los microservicios y las aplicaciones tradicionales pueden funcionar juntas en los mismos entornos, siempre que la organización tenga una sólida estrategia de TI bimodal.
Bi-modal de TI, según Gartner, es la capacidad de entregar tanto aplicaciones de TI tradicionales con un enfoque en estabilidad y tiempo de actividad, y aplicaciones más nuevas, más ágiles, pero posiblemente menos probadas a través de nuevos métodos que involucran cosas como la capacidad de los desarrolladores para máquinas de provisión y ciclos cortos de desarrollo.
Muchas, sino la mayoría, de las organizaciones necesitarán adaptarse para trabajar con ambos enfoques durante muchos años.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_column_text]
¿Donde puede aprender más?
OpenSource.com tiene muchos recursos para los interesados en aprender más sobre las diferentes herramientas y patrones de diseños que son parte de las aplicaciones orientada a microservicios. A continuación algunas recomendaciones que puede revisar:
- Containers, microservices, and orchestrating the whole symphony, by Uri Cohen
- Google shares gRPC as alternative to REST for microservices, by Luis Ibañez
- NGINX: the secret heart of the modern web, by Jason Hibbets
- Smart API integrations with Python and Zato, by Dariusz Suchojad
- Senior software engineer Petazzoni on the breathtaking growth of Docker, by Richard Morrell.
Este artículo esta basado en Microservices: Open Source, Containers, and Orchestration[/vc_column_text][/vc_column][/vc_row]