Menta

Blog

Cinco ideas sobre la adopción de microservicios y arquitecturas de contenedores

Las plataformas de contenedores democratizan algunas capacidades radicalmente poderosas, y vale la pena tomarlas en serio.

Traducido de: Five Thoughts About Adopting Microservice and Container Architectures por Jonathan Owens https://blog.newrelic.com/technology/five-thoughts-about-adopting-microservices/

Como ingeniero de integridad tecnológica líder (Site Reliability Engineer) para el proyecto Container Fabric de New Relic (nuestra plataforma interna de orquestación de contenedores y tiempo de ejecución), paso mucho tiempo respondiendo preguntas de clientes existentes y potenciales sobre cómo usamos y administramos los contenedores para crear una plataforma compuesta de docenas de microservicios.

Definitivamente nosotros nos consideramos de los primeros adoptantes de contenedores y comenzamos a empaquetar servicios con ellos casi tan pronto como Docker lanzó su primera versión lista para producción en el verano de 2014. Muchos de los clientes con los que he hablado ahora están empezando –o pensando en empezar– tales caminos, y quieren saber todo lo que nosotros sabemos. Quieren saber cómo lo hacemos funcionar y cómo lo diseñamos. Pero parte del proceso, que me gustaría resaltar, es lo que necesitan saber sobre dónde tuvimos que luchar a lo largo del camino.

Con esto en mente, aquí hay 5 conclusiones clave que me gustaría compartir con cualquiera que pondere los contenedores y microservicios:

1. Nunca pares de desarrollar

Toma tu proyecto de adopción seriamente y trátalo como un producto. Dale un nombre, incluso el de una marca interna, y una clara visión del producto. Debe ser administrado y se le debe dotar de vida.

Nuestra versión actual de Container Fabric no es nuestro primer intento de orquestación y entrega interna. Construimos nuestra versión original en 2014 y una vez que llegamos a todo lo que pensamos que necesitábamos, dejamos de desarrollarla. No teníamos una visión completa para una plataforma de implementación, como un producto que nuestros desarrolladores disfrutarían usando, y construimos algo que satisfacía únicamente nuestra necesidad de una capa de abstracción consistente.

Pasaron 2 años antes de que comenzáramos a reinvertir en la plataforma de contenedores. Nuestra primera versión no dejó de ser útil, pero fallamos en captar muchas de las mejoras incrementales que surgieron durante el rápido desarrollo de esta fase en Docker.

Uno de nuestros clientes de más tiempo emprendió un proceso similar de orquestación de contenedores/microservicios por el mismo periodo de tiempo, y están mucho más avanzados de lo que nosotros estamos al día de hoy. Cuando les preguntamos cómo llegaron tan lejos, su respuesta fue dolorosamente simple: “Simplemente nunca dejamos de trabajar en eso.“

2. Constrúyelo paso a paso y empieza con los primeros adoptantes

Cuando estás cambiando a contenedores, adoptar una nueva tecnología (como Kubernetes) no significa que saltes hasta el extremo más profundo y muevas toda tu flota de producción a clusters gigantes de alta disponibilidad. ¿No es más fácil construir cada cosa pieza por pieza?

Cuando comenzamos con Container Fabric, restringimos nuestro despliegue al caso de uso más simple que pudiéramos ofrecer: servicios HTTP sin estado, sin persistencia, sin protocolos no HTTP y con un solo esquema de implementación. Esto redujo la huella de la función de la plataforma a una que sabíamos, podía servir de manera efectiva en un plazo razonable.

Esto era importante porque una plataforma de programación de contenedores no ofrece todo. Todavía necesitábamos monitorear la plataforma, implementar cambios, manejar secretos, configurar el equilibrio de carga automático y capturar registros: todo lo que viene con una plataforma de servicios enriquecida. Restringir el tipo de servicio objetivo hizo más fácil para nosotros razonar sobre los componentes de la plataforma.

Entonces, si estás seguro de que la orquestación de contenedores es lo que tú necesitas, analiza detenidamente qué es lo que la plataforma de contenedores ofrece y piensa en qué le falta. ¿Qué tendrás que construir encima de esta plataforma para apoyar la particularidad de tus servicios y tu infraestructura en su contexto?

También, debes entender la cultura y disponibilidad de tus equipos. ¿Quiénes son los primeros adoptantes en tu compañía? ¿Qué equipos están preparados para cambiar a un nuevo paradigma? ¿Qué equipos están construyendo servicios que encajarían bien con una arquitectura de microservicios? ¿Qué equipos están atrapados con los legados de monolitos y necesitan más tiempo, planeación y experimentación?

3. Un solo tamaño no ajusta para todo

Cuando se trata de contenedores y microservicios, algunos sistemas simplemente no se ajustan al modelo, y es más fácil si reconoces esto desde el principio. La tecnología en nuevos sistemas frecuentemente es tan nueva que el esfuerzo de portar viejos sistemas puede ser más problemático de lo que vale.

Nuestra plataforma continúa sirviendo primordialmente servicios HTTP, pero también estamos comenzando a manejar más servicios de procesamiento de flujo. Seguimos sin hacer almacenamiento o bases de datos persistentes. (El equipo de base de datos maneja esto con Megabase.) A algunas partes de la plataforma de New Relic podría tomarles años moverse a Container Fabric, si alguna vez las movemos. ¡Y está bien! Las plataformas de contenedores no tienen el monopolio de buenas prácticas de implementación.

Las últimas tecnologías y arquitecturas se tratan de iteración rápida y control descentralizado, por lo que si esas cuestiones no son cruciales para las metas de tu negocio, sólo deja que esos viejos sistemas heredados sigan avanzando hasta que tengas una necesidad lógica de negocios para migrarlos.

4. Los cambios de tecnología son cambios organizacionales

Es fácil empezar a usar una tecnología antes de pensar cómo utilizar esa tecnología. Las nuevas arquitecturas típicamente requieren de nuevo conocimiento de arquitectura y nuevas ideas sobre cómo implementar sistemas. Los patrones de microservicios afectan las arquitecturas de ambos, de los software y de las organizaciones que las utilizan.

A medida que los equipos de New Relic movían sus servicios al Container Fabric, la carga de trabajo de sus operaciones solía reducirse. En algunos casos, los equipos se deshicieron de una considerable carga de trabajo, liberándolos para trabajar en otros proyectos que encontraron más gratificantes. Éste es el mejor caso de automatización, el que elimina una carga de trabajo pesada y estamos encantados de verlo. Los equipos que han migrado obtienen más libertad para construir software que encante a nuestros clientes.

Las organizaciones que estén considerando moverse a una arquitectura de contenedores y microservicios deberían preguntarse a sí mismos las siguientes cuestiones:

¿Qué producto provee tu grupo de operaciones a los desarrolladores y qué capa de abstracción conlleva ese producto?

¿Ése es el correcto para tu negocio o los contenedores se ajustan mejor?

¿Los contenedores son mejores, tanto que están deseando cambiar la abstracción y, por lo tanto, el producto completo que tu equipo de operación ofrece, para utilizarlo?

¿Estás listo para crear nuevos puestos para administrar la escala y la confiabilidad de esta nueva abstracción?

Ninguna organización hace un cambio como éste de la noche a la mañana. La travesía desde una nueva arquitectura idealizada hasta el primer despliegue de producción requiere cambiar muchas mentes y crear nuevos procesos, lo que no siempre es divertido.

5. Recuerda, construir software es una experiencia humana

Una plataforma de contenedores rica y compleja necesita cientos de años-persona de experiencia para construir, mantener y escalar. Estas plataformas y arquitecturas requieren que aceptes nuevos contextos y exijas que tu organización acepte concesiones en su diseño a medida que te adaptas en el caso de uso. Adoptar una arquitectura de microservicios en contenedores es una gran labor que probablemente cambie el equilibrio de trabajo a lo largo de todos tus equipos; afectará la forma en la que ocupan el tiempo; puede que hasta cambie la felicidad que experimentan en sus trabajos. A menos que realmente consideres los aspectos humanos de adopción de la plataforma, la migración va a ser mucho más difícil de lo que necesita ser.

Por nuestra estructura organizacional, nos hemos posicionado bien para una migración exitosa. Cada servicio en New Relic es propiedad de un equipo: ellos lo planean, programan, despliegan y operan. Esta estructura ha estado vigente por años y la plataforma Container Fabric hace el trabajo de estos equipos propietarios aún más simple, los que les permite avanzar en la abstracción de las capas y acercarse a los objetivos de negocio.

La promesa de los contenedores, y especialmente de sus plataformas de programación, frecuentemente se lee como “así es como todo el mundo debería desarrollar software; está lleno de magia“. Y frecuentemente eso es cierto: las plataformas de contenedores democratizan algunas capacidades radicalmente poderosas, y vale la pena tomarlas en serio. Pero recuerda que todas resolvieron un problema de productividad en una plataforma de forma tajante. Necesitas racionalizar si esa forma puede también ser la tuya.

¿Tu empresa está lista para construir una plataforma de contenedores rica y compleja?

Contáctanos

Por favor introduce tus datos y nos pondremos en contacto contigo.

Recibirás un resumen semanal.