Mirando al pasado hace unos cinco años, puede ver cuánto ha cambiado desde entonces la actitud hacia la arquitectura de los microservicios. Al principio fueron extremadamente populares. Tras el éxito de Netflix, Amazon y Gilt.com, los desarrolladores decidieron que el desarrollo de facto de microservicios no es diferente del desarrollo de aplicaciones. Ahora todos entendieron que los microservicios son un nuevo estilo arquitectónico que es efectivo para resolver ciertos problemas, tiene sus pros y sus contras.
Para comprender qué son los microservicios y en qué casos deben usarse, recurrimos a Jaime Buelta, autor de Hands-On Docker para Microservicios con Python. Habló sobre las ventajas de esta arquitectura y también compartió recomendaciones para desarrolladores que planean cambiar de monolitos.

Beneficios y riesgos.
Una aplicación monolítica tradicional combina todas sus capacidades en un solo módulo conectado. En el caso de los microservicios, lo contrario es cierto. La aplicación se divide en servicios independientes más pequeños que se pueden implementar, actualizar y reemplazar de forma independiente. Cada microservicio se crea para un propósito comercial y puede interactuar con otros microservicios utilizando mecanismos simples.
Buelta explica: “La arquitectura de microservicios es una forma de estructurar un sistema en el que varios servicios independientes se comunican entre sí de una determinada manera (generalmente esto se hace usando servicios web RESTful). Una característica clave es que cada microservicio es capaz de actualizarse y desplegarse independientemente de los demás ".
La arquitectura de microservicios define no solo cómo crea su aplicación, sino también cómo está organizado su equipo.
“Un equipo independiente puede ser totalmente responsable del microservicio. Esto permite que las organizaciones crezcan sin unir a los desarrolladores ”, explica Buelt.
Una de las principales ventajas de los microservicios es que le permiten introducir innovaciones sin ningún impacto especial en el sistema en su conjunto. Con la ayuda de microservicios, puede realizar escalas horizontales, tener límites claros de módulos, usar una variedad de tecnologías y llevar a cabo un desarrollo paralelo.
Cuando se le preguntó sobre los riesgos asociados con los microservicios, Buelta respondió: “La principal dificultad para implementar la arquitectura (especialmente cuando se pasa de un monolito) es crear un diseño en el que los servicios sean realmente independientes. Si esto no se puede lograr, las comunicaciones entre servicios se volverán más difíciles, lo que generará costos adicionales. Los microservicios necesitan profesionales que den forma a la dirección del desarrollo a largo plazo. Recomiendo a las organizaciones que quieran cambiar a dicha arquitectura que designen a alguien responsable del "panorama general". Necesitamos analizar los microservicios más ampliamente ”, dijo Jaime.
Transición de monolito a microservicios
Martin Fowler, un conocido autor y consultor de software, aconseja adherirse al principio de "primero es un monolito". Esto se debe al hecho de que usar una arquitectura de microservicio desde el comienzo del desarrollo es arriesgado, ya que en la mayoría de los casos es adecuado solo para sistemas complejos y grandes equipos de desarrollo.
“El criterio principal que debería alentarlo a cambiar a una nueva arquitectura es el tamaño de su equipo. Los grupos pequeños no deberían hacer esto. En tales condiciones, los desarrolladores ya entienden todo lo que sucede con la aplicación y siempre pueden hacer una pregunta aclaratoria a un colega. El monolito funciona perfectamente en estas situaciones y, por lo tanto, casi todos los sistemas comienzan con él ”, dijo Jaime. Esto confirma la "regla de las dos pizzas" de Amazon, según la cual el equipo responsable de un microservicio puede ser alimentado con dos pizzas; de lo contrario, es demasiado grande.
“A medida que la empresa crece y los equipos de desarrollo aumentan, puede ser necesaria una mejor coordinación. Los programadores a menudo comienzan a interferir entre sí. Comprender el propósito de un código en particular se está volviendo más difícil. En tales casos, la transición a microservicios tiene sentido: esto ayudará a compartir responsabilidades y aportar claridad a la imagen general del sistema. Cada equipo puede establecer sus propios objetivos y trabajar principalmente de forma independiente, proporcionando una interfaz externa clara. Sin embargo, para que esa transición tenga sentido, debe haber muchos desarrolladores ”, agrega Buelt.
Recomendaciones para migrar a microservicios
Respondiendo a una pregunta sobre qué recomendaciones prácticas pueden usar los desarrolladores al cambiar a microservicios, Buelta dijo: "La clave para una arquitectura exitosa de microservicios es que cada servicio debe ser lo más independiente posible".
Surge la pregunta: "¿Cómo puede hacer que los servicios sean independientes?" La mejor manera de descubrir la interdependencia de un sistema es pensar en nuevas posibilidades: “Si desea agregar una nueva función, ¿puede implementarse cambiando solo un servicio? ¿Qué tipos de funciones requerirán la coordinación de varios microservicios? ¿Se usarán con frecuencia o raramente? Es imposible crear el diseño perfecto, pero al menos puede usarlo para tomar las decisiones correctas e informadas ", explica Buelt.
Jaime aconseja cambiar a la arquitectura correctamente para que no tenga que rehacer todo más tarde. “Una vez que se complete la transición, cambiar los límites de los microservicios será más difícil. Vale la pena dedicar más tiempo a la fase inicial del proyecto ", agrega.
Pasar de un patrón de diseño a otro es un paso serio. Preguntamos qué problemas enfrentaron Jaime y su equipo durante la migración a microservicios, a lo que respondió:
“De hecho, las principales dificultades están relacionadas con las personas. Estos problemas generalmente se subestiman, pero cambiar a microservicios en realidad cambia la forma en que trabajan los desarrolladores. ¡La tarea no es fácil! Él agrega: “Personalmente, me he encontrado con problemas similares. Por ejemplo, tuve que entrenar y dar consejos a los desarrolladores. Es especialmente importante explicar por qué ciertos cambios son necesarios. Esto ayuda a las personas a comprender las razones para presentar todas las innovaciones que pueden no gustarles.
Al pasar de una arquitectura monolítica, pueden surgir muchas dificultades al implementar una aplicación que se lanzó previamente como un solo módulo. Requiere un análisis más exhaustivo para garantizar la compatibilidad con versiones anteriores y minimizar los riesgos. Hacer frente a esta tarea a veces es muy difícil ".
Razones para elegir Docker, Kubernetes y Python como su pila de tecnología
Le preguntamos a Buelt qué tecnología prefiere para implementar microservicios. En cuanto a la elección del idioma, la respuesta fue simple: “Python es la mejor opción para mí. ¡Este es mi lenguaje de programación favorito! .. Este lenguaje es muy adecuado para microservicios. Es conveniente de leer y fácil de usar. Además, Python tiene una amplia funcionalidad para el desarrollo web y un ecosistema dinámico de módulos de terceros para cualquier necesidad. Estas necesidades incluyen la conexión a otros sistemas, como bases de datos, API externas, etc. "
Docker a menudo se promociona como una de las herramientas más importantes para microservicios. Buelta explicó por qué:
“Docker le permite encapsular y copiar la aplicación en convenientes paquetes estandarizados. Esto reduce la incertidumbre y la complejidad del medio ambiente. También simplifica enormemente la transición del desarrollo a la producción de aplicaciones. Además de eso, se reduce el tiempo que lleva usar el equipo. Puede colocar varios contenedores en diferentes entornos (incluso en diferentes sistemas operativos) en una caja física o máquina virtual ".
Sobre Kubernetes:
“Kubernetes le permite implementar múltiples contenedores Docker de manera coordinada. Esto hace que los desarrolladores piensen de forma agrupada, recordando el entorno de producción. También le permite definir un clúster utilizando código para que las nuevas implementaciones o cambios de configuración se definan en los archivos. Todo esto hace posibles métodos como GitOps (escribí sobre ellos en mi libro), manteniendo la configuración completa en el sistema de control de versiones. Cada cambio se realiza de forma específica y reversible, ya que es una combinación de git regular. Gracias a esto, es muy fácil restaurar o duplicar la infraestructura ".
“Tienes que pasar tiempo aprendiendo Docker y Kubernetes, pero vale la pena. Ambas herramientas son muy poderosas. Además, lo alientan a trabajar de tal manera que evite problemas durante la producción ”, dice Buelt.
Microservicios multilingües
Al desarrollar microservicios, puede utilizar una variedad de tecnologías, ya que idealmente un equipo independiente es responsable de cada una de ellas. Buelta compartió su opinión sobre microservicios multilingües: “¡Los microservicios multilingües son geniales! Esta es una de las principales ventajas de la arquitectura. Un ejemplo típico de un microservicio multilingüe es la transferencia de código heredado escrito en un idioma a uno nuevo. Un microservicio puede reemplazar a cualquier otro que proporcione la misma interfaz externa. Sin embargo, su código será completamente diferente. Por ejemplo, cambié de viejas aplicaciones PHP, reemplazándolas por análogos escritos en Python ". Jaime agregó: "Trabajar con dos o más plataformas al mismo tiempo ayudará a comprenderlas mejor y comprender en qué casos es mejor usarlas".
Si bien la capacidad de utilizar microservicios multilingües es una gran ventaja arquitectónica, también puede aumentar los costos de transacción. Buelta aconseja: “Necesitamos saber la medida. No tiene sentido utilizar una nueva herramienta cada vez y privar al equipo de la oportunidad de compartir conocimientos entre sí. Las cifras específicas pueden depender del tamaño de la empresa, pero, por regla general, no tiene sentido usar más de dos o tres idiomas diferentes sin una buena razón. No tiene que inflar la pila de tecnología, entonces los desarrolladores podrán compartir conocimientos y comenzar a usar las herramientas disponibles de manera más efectiva.
Sobre el autor
Jaime Buelta es un programador profesional y desarrollador de Python que, a lo largo de los años de su carrera, ha encontrado muchas tecnologías diferentes. Ha desarrollado software para varios campos e industrias, incluyendo aeroespacial, redes y comunicaciones, así como sistemas industriales SCADA, servicios de videojuegos en línea y servicios financieros.
Como parte de varias compañías, se ocupó de áreas funcionales como marketing, gestión, ventas y diseño de juegos. Jaime es un ávido defensor de la automatización y quiere que las computadoras hagan todo el trabajo duro, permitiendo que las personas se concentren en cosas más importantes. Actualmente vive en Dublín y habla regularmente en las conferencias de PyCon en Irlanda.