Los microservicios son un enfoque para el desarrollo de software que ha experimentado un aumento de interés durante la última década más o menos, yendo de la mano con otras tendencias como el desarrollo ágil, nativo de la nube y, más notablemente, el uso de contenedores como vehículo para implementar componentes de software.
La adopción de microservicios ha aumentado en los últimos años. Una encuesta realizada por O’Reilly en 2020 a más de 1.500 organizaciones encontró que solo alrededor de una cuarta parte no usaba microservicios en absoluto. Del 75% que estaban, solo alrededor del 10% los había estado usando durante más de cinco años, lo que significa que la mayoría ha dado el paso con los microservicios durante los últimos años.
Los microservicios no son una tecnología específica, sino un estilo de arquitectura de software y un enfoque para diseñar aplicaciones y servicios. En lugar de crear una aplicación como una entidad monolítica única, el enfoque de microservicios es dividir la funcionalidad requerida en una colección de servicios más pequeños e implementables de forma independiente que se comunican entre sí.
Este enfoque tiene varias ventajas, una de las cuales es una escalabilidad más sencilla, ya que los componentes individuales se pueden escalar de forma independiente entre sí. Solo las partes de la aplicación que podrían estar experimentando una gran demanda, por ejemplo, deben escalarse, generalmente iniciando nuevas instancias de ese componente para equilibrar la carga de trabajo, en lugar de escalar toda la aplicación.
Los microservicios también se prestan a un proceso de desarrollo ágil, porque el tamaño más pequeño de los componentes facilita la mejora continua y permite actualizaciones más rápidas del código. También hace posible que se utilicen diferentes lenguajes de programación para diferentes componentes, ya que algunos lenguajes pueden ser más adecuados para ciertos tipos de tareas. Debido a que los componentes son pequeños, a los desarrolladores les resulta más fácil comprender el código, lo que puede tener un efecto en cadena sobre la confiabilidad.
Otra ventaja es el potencial de reducir el tiempo de inactividad mediante un mejor aislamiento de fallas. Si falla una sola instancia de microservicio, es menos probable que se desactive toda la aplicación o el servicio como resultado.
Posibles desventajas
Si bien el enfoque de microservicios tiene ventajas, también existen algunas desventajas que las organizaciones deben considerar. Por ejemplo, aunque el desarrollo de cada componente de microservicio podría ser más simple, la aplicación o el servicio en su totalidad podría volverse más complejo de administrar.
Esto es especialmente cierto con una implementación de cualquier escala, que puede involucrar docenas o cientos de instancias individuales de diferentes componentes de microservicio. La complejidad proviene no solo de administrar la comunicación entre todas estas instancias separadas, sino de monitorear cada una de ellas para asegurarse de que estén operando dentro de los parámetros esperados y no consuman más recursos de los que normalmente requerirían, lo que puede indicar que hay un problema.
Las pruebas y la depuración también pueden convertirse en un desafío mayor con los microservicios, simplemente porque rastrear el origen de un error puede ser más difícil entre una red de instancias de microservicios, cada una con su propio conjunto de registros. Probar toda la aplicación también puede ser complicado, porque cada microservicio solo se puede probar correctamente una vez que todos los servicios de los que depende también se hayan probado.
En particular, el monitoreo es más importante en una implementación de microservicios, pero la naturaleza distribuida de los componentes lo hace más complejo que las aplicaciones tradicionales, que son en gran parte autónomas. El sistema de monitoreo tiene que operar a nivel de cada instancia de microservicio individual, mientras que al mismo tiempo vigila la red de dependencias entre los diferentes componentes.
La forma en que operan los microservicios también tiene implicaciones para la infraestructura de la organización. Admitir el escalado automático para satisfacer la mayor demanda implica que los recursos para nuevas instancias de microservicio deben poder ser aprovisionados por llamadas a la interfaz de programación de aplicaciones (API), lo que implica un cierto nivel de infraestructura definida por software similar a la nube.
Los datos pueden ser otro problema espinoso al crear una aplicación o servicio basado en una arquitectura de microservicios, o para ser más precisos, dónde almacenar los datos. Esto se debe a que es probable que cada instancia de microservicio tenga su propio almacén de datos, pero algunas aplicaciones pueden requerir la capacidad de acceder a un repositorio compartido. Los diferentes servicios también tendrán diferentes requisitos de almacenamiento de datos, y algunos en la industria dicen que una base de datos NoSQL tiene más sentido, mientras que otros abogan por ceñirse a SQL, si eso es lo que la organización ya ha implementado.
Hay otras opiniones divergentes sobre este tema, y algunos expertos advierten que una sola base de datos (pero no quizás un solo esquema) compartida por múltiples servicios es el mejor enfoque, porque, por un lado, permite a las organizaciones reutilizar los procedimientos que tienen en lugar para la copia de seguridad y restauración de la base de datos. Otros desaconsejan esto, porque crea un punto único potencial de falla que va en contra de la ética de los microservicios.
Planifica con cuidado
Todo esto significa que es posible que la arquitectura de microservicios no se adapte a todas las organizaciones ni a todos los tipos de aplicaciones. Sin embargo, las razones detrás de su creciente adopción son que los microservicios facilitan la implementación de un enfoque más ágil para la implementación de servicios, que muchas organizaciones están buscando ahora.
“Las organizaciones que siguen la ruta de los microservicios tienden a ser más innovadoras que el resto”, dice el analista independiente Clive Longbottom. “Como tal, también tenderán a estar más abiertos a pensar en lo que necesita un cambio a una nueva topología arquitectónica. Históricamente, la mayoría de los cambios han sido evolutivos: las arquitecturas de microservicios exitosas son revolucionarias y requieren un replanteamiento completo de lo que se está haciendo “.
En otras palabras, los microservicios pueden ser más adecuados para una implementación de “campo verde” que se está construyendo desde cero, en lugar de organizaciones que intentan refactorizar o actualizar una aplicación existente.
Como ya se señaló, los contenedores de software estilo Docker son una tecnología que se ha asociado en la mente de muchos con los microservicios, aunque son solo una forma de implementar una implementación distribuida como los microservicios. Otras formas pueden incluir máquinas virtuales ligeras o incluso implementar instancias de microservicio como código no virtualizado que se ejecuta en un entorno de servidor, al igual que las aplicaciones cotidianas. Las funciones de computación sin servidor serían otra forma de implementar microservicios.
Los contenedores son quizás más adecuados que las máquinas virtuales, porque son menos pesados en recursos y es mucho más rápido generar una nueva instancia de contenedor que iniciar una nueva máquina virtual. Los contenedores también son ahora una tecnología relativamente madura, con un amplio ecosistema de herramientas para apoyar la orquestación (como Kubernetes), las comunicaciones (como Istio) y el monitoreo.
Curiosamente, la encuesta de O’Reilly descubrió que una proporción superior a la media de encuestados que informaron haber tenido éxito con los microservicios optaron por instanciarlos mediante contenedores, mientras que una mayor proporción de encuestados que describieron sus esfuerzos de microservicios como infructuosos no utilizaron contenedores.
Esto podría sugerir que los contenedores son una opción menos riesgosa al implementar microservicios, pero nuevamente se trata más de elegir la tecnología adecuada para la aplicación y los requisitos específicos de la organización.
“Si solo miramos un microservicio, es solo un código auxiliar funcional”, dice Longbottom. “El contenedor debe proporcionar el entorno que necesita el microservicio, con orquestación, etc., administrando el aprovisionamiento, el parcheo, la actualización y el movimiento de los microservicios según sea necesario en las plataformas más amplias”.
En otras palabras, la creación de microservicios implica un tipo de complejidad diferente de los estilos de aplicación tradicionales y más monolíticos. Por esta razón, puede considerarse como una tecnología más adecuada para aplicaciones modernas o nativas de la nube de nueva construcción, o para organizaciones que revisan su TI como parte de un proceso de transformación digital.