kentoh - Fotolia
Seis pasos clave para desplegar microservicios en producción
Para tener éxito con los microservicios, las organizaciones de TI deben replantearse la forma en que diseñan y despliegan las aplicaciones, y no todos los cambios necesarios son técnicos.
Aunque una arquitectura de microservicios distribuidos no es adecuada para todas las empresas o tipos de aplicaciones, funciona bien en muchas situaciones.
Los microservicios promueven un diseño de aplicación modular y facilitan la flexibilidad. Proporcionan a las organizaciones la libertad de elegir los lenguajes de desarrollo, los marcos de trabajo, las construcciones de código, los procesos de integración y la infraestructura de tiempo de ejecución. Sin embargo, esta libertad deja a los desarrolladores y a los equipos de DevOps con una serie de opciones desalentadoras.
No existe un plan de acción prescriptivo o universal para desplegar microservicios en un entorno de producción. Sin embargo, los principales proveedores de servicios en línea, como Google, Amazon y Netflix, que operan con arquitecturas distribuidas a hiperescala, demuestran que todos los equipos de DevOps deben abordar ciertos principios y cuestiones para prepararse para un despliegue de microservicios. Aquí están seis de esas lecciones clave aprendidas.
1. Utilizar servicios en la nube para la infraestructura de producción
En pocas palabras, una arquitectura de microservicios es aquella en la que las aplicaciones están formadas por componentes discretos e independientemente escalables. Los servicios en la nube, que encapsulan los recursos de infraestructura o las aplicaciones empresariales como servicios bajo demanda, permiten los microservicios: hacen que sea más rentable y conveniente desagregar y ejecutar las funciones de las aplicaciones como componentes separados. En lugar de utilizar la infraestructura de TI tradicional, construya y despliegue microservicios en la nube.
Aunque la decisión de operar en la nube sigue ofreciendo a las organizaciones de TI una serie de opciones para un entorno de ejecución de microservicios, no hay que dividir los microservicios en instancias VM discretas, ya que los contenedores y las funciones sin servidor se adaptan mejor a las implementaciones de microservicios. Las instancias de VM podrían seguir siendo necesarias, porque los usuarios de contenedores suelen desplegar instancias de computación para construir un clúster en lugar de utilizar una herramienta de contenedores como servicio totalmente gestionada. Sin embargo, es mejor gestionar estas instancias a través de un servicio kubernetes en la nube, como Azure Kubernetes Service, AWS Elastic Kubernetes Service o Google Kubernetes Engine.
Dada la novedad de los despliegues de microservicios, nunca juzgue la viabilidad, el costo y el rendimiento de los servicios en la nube basándose en su historial con aplicaciones y servidores heredados. Del mismo modo, no asuma compensaciones de costo-rendimiento en el almacenamiento: investigue las diferencias financieras y de rendimiento entre las unidades de estado sólido y las unidades de disco duro, y podría determinar que las SSD merecen el costo incremental.
2. Diseñar para el fracaso
Una arquitectura de microservicios está desacoplada y distribuida, con componentes de aplicación individuales que tienen muchas dependencias. Sin embargo, esta desagregación permite que los componentes funcionen, reciban actualizaciones y escalen de forma independiente sin depender básicamente de la disponibilidad o capacidad de respuesta de otros microservicios. La infraestructura de microservicios no depende críticamente de un solo servidor: sin independencia mutua, un diseño de microservicios se convierte en un sistema monolítico enrevesado.
Las organizaciones deben diseñar y desplegar microservicios para adaptarse a los fallos. Por ejemplo, los microservicios deben tratar a los servidores, o nodos contenedores, como entidades sin estado que pueden detenerse, reiniciarse, autoescalarse y parcharse de forma independiente. Las aplicaciones deben tolerar los fallos de los componentes de los microservicios y recuperarse con elegancia de los fallos a nivel de componente. Las herramientas de ingeniería del caos, como Gremlin y Chaos Monkey de Netflix, prueban la resiliencia de una infraestructura de microservicios.
3. Descentralizar la gestión de datos
Los centros de datos empresariales suelen consolidar las bases de datos y los volúmenes de almacenamiento en unos pocos sistemas para mejorar la eficiencia operativa, reducir los costos de las licencias y simplificar la gestión de las aplicaciones, las políticas y la seguridad. Este enfoque monolítico es un anatema para el diseño de microservicios, ya que las características de las bases de datos no se adaptan a todas las situaciones. Si varios equipos de aplicaciones de microservicios comparten la misma base de datos, esto se convierte en un problema cuando alguien necesita actualizar la estructura de la base de datos de la que dependen otros microservicios.
Los desarrolladores de software necesitan la libertad de elegir la mejor base de datos para el trabajo. Esto es fácil de garantizar con las plataformas en la nube, como AWS o Microsoft Azure, que ofrecen un sinfín de opciones de bases de datos. Los desarrolladores también necesitan la flexibilidad para cambiar y actualizar el esquema y los procedimientos de la base de datos sin el temor de que puedan romper el código funcional existente.
4. Distribuir la gobernanza
Las organizaciones de TI de las empresas operan tradicionalmente en silos funcionales –equipos separados de almacenamiento, redes, bases de datos, desarrollo, operaciones y servidores– en los que cada silo se encarga de una parte del ciclo de vida global de la aplicación. En este modelo tradicional, los equipos de desarrollo se convierten en parte de un proyecto poco manejable para implementar una aplicación o servicio de TI. Los equipos suelen comunicarse a través de los procesos existentes, como los tiquets de la mesa de ayuda o las solicitudes de funciones, que son lentos y a menudo muy restrictivos. Esto inhibe la creatividad y el rápido desarrollo de nuevas ideas.
Los microservicios cambian esta estructura. Los equipos de microservicios interfuncionales con una cultura DevOps y prácticas de desarrollo ágiles sustituyen a los silos de TI. Los equipos se organizan en torno al producto –el microservicio o la aplicación basada en microservicios– en lugar de una función laboral concreta, con un gestor responsable de su desarrollo y entrega.
Para diseñar y desplegar con éxito los microservicios, hay que crear una cultura con un mínimo de procesos restrictivos equilibrados con la responsabilidad de reconocer y solucionar los problemas cuando se producen. Optimice la velocidad, más que la eficiencia. El equipo de infraestructura debe ser pequeño, ya que el proveedor de servicios en la nube se encarga de la mayoría de las tareas operativas. Los equipos centrados en el producto promueven la agilidad, la comunicación estrecha y la coordinación. Esta estructura de equipo también facilita el proceso de creación de las interfaces API necesarias que permiten la automatización de procesos y la integración de microservicios.
5. Automatizar el despliegue de la infraestructura, adoptar procesos CI/CD
Como se ha mencionado anteriormente, los microservicios prosperan en un entorno ágil de DevOps, que requiere procesos rápidos y sin fricciones. Para eliminar la sobrecarga y la fricción, automatice los procesos para que las acciones de un miembro del equipo en particular desencadenen las respuestas necesarias: la actualización de un módulo de código genera construcciones y pruebas de software, por ejemplo. La automatización de procesos fomenta el desarrollo rápido de código y un diseño evolutivo, y ambos son atributos críticos de los microservicios.
Netflix ofrece otras dos recomendaciones tácticas basadas en su experiencia con los microservicios:
- Mantener el código en un nivel de madurez similar. La infraestructura inmutable implica la creación de un nuevo microservicio cuando una empresa necesita añadir características o corregir errores en uno existente. La técnica mantiene el antiguo microservicio operativo mientras los desarrolladores prueban, parchan y depuran el nuevo. Cuando está listo para su despliegue, los administradores de la infraestructura cambian el antiguo contenedor de microservicios por el nuevo.
- Utilice compilaciones separadas para cada microservicio. Varios microservicios pueden compartir archivos, como bibliotecas y funciones de código, pero pueden requerir versiones diferentes. Dado que la filosofía de los microservicios se centra en minimizar las dependencias, construya cada servicio de forma independiente para asegurarse de que extrae la versión correcta de un archivo de componente de una memoria de clase de almacenamiento. Las construcciones independientes también facilitan la eliminación de versiones obsoletas de la base de código.
6. Supervisar, registrar y solucionar problemas desde el principio
La construcción de aplicaciones a partir de un conjunto de microservicios al estilo Legos complica considerablemente la forma de supervisar y solucionar los problemas de los sistemas y su rendimiento. Varios microservicios suelen desencadenar una cascada de eventos que conducen a un fallo de la aplicación. Para minimizar los fallos –que no son un tal vez, sino una realidad– incorpore la supervisión y la resolución de problemas en el diseño de los microservicios.
