¿Qué son los microservicios?

Los microservicios, también conocidos como arquitectura de microservicios, se refieren a un método de desarrollo de software que estructura una aplicación como un conjunto combinado de servicios. Esencialmente, este conjunto de aplicaciones se implementa como una aplicación completa por derecho propio y todos estos servicios funcionan juntos para formar la aplicación completa. Todos los microservicios siguen estos patrones: están organizados en torno a las capacidades comerciales, están poco acoplados, se implementan de forma independiente y se pueden probar. Debido a que están poco acoplados, los microservicios se pueden construir, implementar y escalar de forma independiente.

Cada servicio se comunica con otros servicios a través de interfaces de programación de aplicaciones (APIs) estandarizadas, lo que permite que los servicios se escriban en diferentes lenguajes o en diferentes tecnologías. Esto difiere completamente de los sistemas construidos como estructuras monolíticas donde los servicios estaban inseparablemente interconectados y solo se podían escalar juntos.

Como cada servicio tiene una funcionalidad limitada, generalmente singular, es mucho más pequeño tanto en tamaño como en complejidad. El término microservicio proviene de este diseño de funcionalidad discreta.

Al descomponer la aplicación en servicios discretos que implementan funciones comerciales específicas, los microservicios brindan a los desarrolladores modernos una forma de diseñar aplicaciones flexibles y altamente escalables.

¿Por qué los microservicios?

Los microservicios han ganado popularidad debido a que sus características modulares conducen a la flexibilidad, escalabilidad y esfuerzo de desarrollo reducido. Su flexibilidad de implementación y el aumento de las opciones de implementación nativas de la nube sin servidor y su función como servicio (como AWS Lambda y Microsoft Azure Cloud Functions) crearon el entorno perfecto para que los microservicios prosperen en el panorama de TI actual. Estas plataformas en la nube permiten que los microservicios y las funciones se escalen de la inactividad a un gran volumen y viceversa, mientras que los clientes pagan solo por la capacidad informática que utilizan.

A medida que las empresas buscan continuamente ser más ágiles, reducir los obstáculos y mejorar los tiempos de entrega de las aplicaciones, la arquitectura de microservicios sigue aumentando en popularidad.

En el pasado, las empresas desarrollaron aplicaciones empresariales especializadas que tenían tres componentes principales:

• Una interfaz orientada al cliente, generalmente páginas HTML que se ejecutan en la máquina de un usuario
• Una base de datos, normalmente muchas tablas en un sistema de gestión de base de datos relacional
• Una aplicación del lado del servidor que manejó todas las solicitudes, como la recuperación de datos, las solicitudes HTTP y el llenado de navegadores HTML.

Para el usuario, todo parecía pasar por un único punto de contacto. El desarrollo, las pruebas y la implementación utilizaron una canalización de implementación y se podía escalar horizontalmente ejecutando varias instancias.

Sin embargo, eran bastante costosos de desarrollar, cualquier cambio requería un rediseño completo del sistema, reconstrucción y redistribución, era difícil mantener una estructura modular limpia a medida que la organización crecía y cambiaba, y la ampliación requería que la aplicación completa se volviera a probar y escalar y redesplegado para cualquier cambio sin importar cuán pequeña sea la revisión. Todos estos problemas dieron lugar a un sistema costoso y no ágil que el panorama tecnológico que cambia rápidamente superó rápidamente.

Una forma de pensar en estos sistemas monolíticos tradicionales es como casas de muñecas listas para usar. Si bien puede editar la estructura o el diseño, no es fácil y está limitado en el tamaño total a menos que compre otra casa de muñecas y la adjunte a la casa de muñecas heredada.

Con los microservicios, no es necesario volver a implementar toda la aplicación, solo los servicios que lo necesitan. En lugar de una entidad estructural singular, como una casa de muñecas, piense en los microservicios como una pila de piezas de Lego. Técnicamente, son todos independientes, pero cuando se juntan, forman una aplicación estructural completa. Si desea agregar un compartimento o terminar algo, puede eliminarlo, agregarlo, ampliarlo y editarlo fácilmente para adaptarlo a las necesidades cambiantes de manera rápida y eficiente sin tener que cerrar toda la aplicación.

Beneficios de una arquitectura de microservicios

Hay una serie de beneficios significativos para las empresas que buscan adoptar microservicios e integrarlos en sus ofertas, que se explorarán con mayor detalle a continuación.

Introducción más rápida al mercado

Poder agregar y eliminar funciones rápidamente significa que el negocio puede volverse increíblemente ágil. La adición de nuevas funcionalidades se puede hacer a la velocidad, manteniendo el ritmo de crecimiento del negocio. A diferencia del software monolítico tradicional, los cambios en el código en una parte del sistema no afectarán a otros módulos, por lo que no es necesario realizar pruebas adicionales, cerrar toda la aplicación o tener que volver a implementar todo.

Mayor funcionalidad y menores costos operativos

Debido a que los módulos en los microservicios están todos separados, existe un riesgo mucho menor de posibles errores o errores que provoquen que falle toda la aplicación. A diferencia de los sistemas de software tradicionales, donde un cambio en una parte de la funcionalidad puede causar una falla o error en otra parte, el aislamiento y el acoplamiento flexible permiten la implementación de actualizaciones y mejoras compartimentadas. Los microservicios también permiten el uso de opciones de implementación de funciones como servicio nativas de la nube, que pueden reducir significativamente los costos operativos.

Aplicaciones fácilmente escalables

Las decisiones de escalado para microservicios se toman a nivel granular, lo que permite tomar las decisiones más eficientes para la optimización del sistema. Al adoptar microservicios, cuando llega el momento de escalar, las organizaciones pueden tomar las mejores decisiones para ellas, justo en el momento.

Integración continua

Los microservicios se desarrollan utilizando flujos de desarrollo e implementación continuos individuales. Estos flujos se pueden mantener para que no haya interrupciones en otro servicio cuando un equipo implementa un cambio basado en los comentarios de los clientes, lo que significa una mayor satisfacción del usuario final.

Equipos de desarrolladores dedicados

A diferencia de los sistemas monolíticos, que no pueden soportar múltiples equipos de desarrollo, los microservicios tienen la capacidad de soportar equipos dedicados a ciertas partes específicas del sistema. Debido a que los módulos de software no interactúan entre sí, no hay riesgo de errores o superposición de trabajo entre equipos, por lo que los equipos de microservicios pueden tener desarrolladores de software especializados, así como equipos que trabajan en diferentes períodos de tiempo o ubicaciones geográficas.

Todos estos beneficios se suman a quizás el más significativo: la agilidad empresarial. Se pueden realizar cambios pequeños y simples rápidamente, lo que permite la experimentación de procesos. La capacidad de dar un gran salto en los negocios, o al menos fracasar rápidamente y reaccionar en tiempo real, se vuelve posible con los microservicios. Además, los estudios han encontrado que a los pocos meses de implementar la arquitectura de microservicios, un tercio de las organizaciones comienzan a lograr ventajas. Eso significa que los plazos para el desarrollo se reducen y, con menos errores en el código y mayores capacidades, el impacto positivo en las operaciones comerciales se puede sentir casi de inmediato.

Características de los microservicios

• Débilmente acoplado.
• Componentes desplegables de forma independiente.
• Despliegue automatizado.
• Control de datos e idioma descentralizado.
• Altamente sostenible.
• Fácilmente comprobable.
• Organizado en torno a las necesidades y capacidades de una empresa u organización.
• Cada servicio tiende a ser propiedad de un pequeño equipo.

Desafíos con los microservicios

Si bien los microservicios resuelven una serie de problemas, aún existen algunas dificultades y problemas que se pueden encontrar con la arquitectura, así como con la adopción inicial.

Gestión de datos descentralizada

A diferencia de los sistemas monolíticos, los microservicios generalmente no dependen de una base de datos que actúe como fuente única de veracidad de sus datos para la empresa. Los datos del cliente pueden estar en un lugar, mientras que los datos del proveedor están en otro. Tal vez la información de inventario se almacena con el portal de ventas en línea, pero el sistema de pedidos se mantiene en una base de datos separada. Esto puede crear problemas con la calidad y la consistencia de sus datos, a menos que haga un punto específico de planificación para esto.

Cultura Corporativa y Desafíos de Organización Interna

Puede ser difícil lograr que las empresas acepten y se adapten a los nuevos sistemas de software. A menudo, la gerencia puede mostrarse renuente a ceder el control, o un departamento estará a la defensiva de sus silos. Cualquiera que sea el motivo del rechazo de los equipos que tienen que aceptar nuevos sistemas, la conclusión es que, a veces, a las personas simplemente no les gusta el cambio.

Para que los microservicios sean adoptados en toda la organización, es fundamental reconocer que la introducción de nuevos sistemas y procesos puede ser disruptiva, pero también es importante recordar que los beneficios valen la pena. Al comenzar la transición a los microservicios, es mejor involucrar a los equipos afectados al planificar la arquitectura. Tenga un plan para evaluar las soluciones que están disponibles y asegúrese de elegir la que mejor se adapte a los requisitos del negocio.

Los microservicios pueden generar complejidad en su arquitectura

Si bien los servicios individuales que componen los microservicios pueden ser pequeños y simples por sí mismos, cuando se combinan, la aplicación general puede terminar teniendo muchas partes móviles que pueden volverse difíciles de administrar. Con cientos o miles de interconexiones, los microservicios pueden aumentar rápidamente en complejidad.

Se recomienda que al implementar microservicios, se dedique una cantidad significativa de previsión y planificación al diseño y la implementación básica. Se pueden evitar muchas complejidades con un buen diseño de arquitectura básica que permita el crecimiento y el cambio en el futuro.

Ejemplos de casos de uso de arquitectura de microservicios

Adopte opciones de implementación nativas de la nube: aproveche la función sin servidor y la función como servicio para lograr operaciones más eficientes y escalables.

Migre la funcionalidad de las aplicaciones heredadas: descomponga los servicios de grandes aplicaciones monolíticas para que se puedan mantener y escalar de forma independiente.

Aproveche la arquitectura de aplicaciones moderna: adopte patrones de aplicaciones de microservicios poco acoplados y basados en eventos, con la capacidad de aprovechar diferentes lenguajes de programación según las necesidades del caso de uso. Por ejemplo, busque funciones computacionalmente pesadas, Node.js para aplicaciones web rápidas, etc.

¿Qué es DevOps y por qué frecuentemente se asocia con los microservicios?

DevOps se puede explicar como una ideología centrada en herramientas. Esencialmente, es un conjunto de prácticas que combina herramientas y tecnología para simplificar el trabajo que deben realizar los desarrolladores. Junto con las herramientas mejoradas, la cooperación entre los equipos de operaciones y desarrollo ayuda a impulsar los proyectos para que se completen de manera más rápida y eficiente.

Por ejemplo, supongamos que está creando una aplicación que permite a los usuarios consultar los saldos de sus cuentas. En el pasado, el ciclo de desarrollo de la aplicación tenía desarrolladores que creaban la aplicación y luego se la entregaban al equipo de operaciones sin responsabilidad por el resultado final. El trabajo del equipo de operaciones era hacer que la aplicación funcionara. En un entorno DevOps más cohesivo, ambas partes trabajan juntas. Un desarrollador posee el ciclo de vida de la aplicación de principio a fin, lo que significa estar de guardia durante el lanzamiento. La comunicación constante entre los dos grupos es necesaria para asegurarse de que todo sea exitoso y obtener todos los beneficios de DevOps, como la velocidad de comercialización, un ciclo de desarrollo más fácil y una mayor responsabilidad.

El nuevo modelo de flujo de trabajo de DevOps crea un cambio cultural importante. El solo uso de nuevas herramientas no hace que un plan de DevOps sea exitoso. En todo caso, las nuevas herramientas podrían inhibir el éxito si le hacen creer sólidamente que todo se implementará adecuadamente.

Debido a la naturaleza de los microservicios, a menudo es necesario contar con procesos sólidos de DevOps para la implementación. El mayor uso de herramientas y prácticas compartidas más sólidas evita que los equipos se sientan abrumados por todas las pequeñas partes móviles. Reduce la interrupción o la carga de este cambio mientras continúa recibiendo los beneficios.

El futuro: microservicios basados en eventos, computación sin servidor y FaaS

Cuando las personas comienzan a experimentar con microservicios, a menudo utilizan de forma predeterminada técnicas familiares, por ejemplo, RESTful API. REST opera en un tipo de comunicación de solicitud-respuesta. El problema con este enfoque sincronizado es que deberá esperar una respuesta; los servicios se vuelven dependientes unos de otros. Si un servicio se ejecuta más lento o no responde, significa que el servicio que lo llamó se ejecutará más lento o fallará. Este acoplamiento puede significar perder algunos de los beneficios de una arquitectura de microservicios, creando una estructura más interdependiente similar a un estilo de arquitectura orientada a servicios (SOA).

Si diseña sus servicios utilizando beyond-REST o un modelo basado en eventos, puede asegurarse de que algunas partes de su aplicación continúen funcionando, mientras que otras partes podrían no estar involucradas, en lugar de que toda la aplicación deje de responder. Tome Netflix como ejemplo. En ocasiones, puede notar que el botón "continuar viendo" no aparece. Esto se debe a que un servicio específico no está disponible. Sin embargo, eso no significa que todo Netflix se detenga. Los usuarios aún podrán buscar programas y ver vistas previas, por lo que otros aspectos del servicio de Netflix aún están disponibles, aunque es posible que un servicio no lo esté.

Los desarrolladores que adoptan completamente un enfoque de microservicios se dan cuenta de que la verdadera escalabilidad se habilita con una estructura flexible y una arquitectura basada en eventos. Un servicio puede ser asíncrono, realizar una acción, transmitir un mensaje y continuar con su función principal sin tener que esperar una respuesta de otro servicio.

¿Cómo funcionan los microservicios?

Los microservicios no son una idea nueva. Hace más de tres décadas, Unix desarrolló una SOA que usaba un principio de diseño similar, pero era costosa de implementar y fallaba con demasiada frecuencia como para ser considerada una buena opción para las empresas. Veinte años después, los microservicios llegaron con una consistencia mucho mejor entre los servicios y, desde entonces, la adopción ha sido mucho más exitosa.

En cuanto a cómo funcionan realmente los microservicios, en primer lugar, la funcionalidad del software se divide en módulos pequeños y aislados. Estos módulos tienen tareas independientes definidas. Luego, el sistema funciona vinculando estas pequeñas piezas de software mediante interfaces de programación de aplicaciones (API).

Las API son segmentos de código que hacen que dos programas no relacionados "hablen" entre sí. Un ejemplo de API en acción sería una aplicación o un sitio web que tenga Google Maps incrustado. La API se encuentra entre Google Maps y la aplicación que envía información de un lado a otro, lo que permite a los usuarios ver su mapa en tiempo real, dar instrucciones al conductor y también alertar a su contacto de confianza sobre su ubicación. Si bien Google Maps sigue siendo una entidad separada, la API permite la comunicación de ida y vuelta entre el mapa y la aplicación. Entonces, en lugar de una casa de muñecas prefabricada, donde todo está planificado, es rígido y es difícil de cambiar, usted tendrá esas pequeñas piezas útiles de Lego que se unen usando API como conectores. Las plataformas de tecnología estandarizadas pueden ser constrictivas, pero no todos los problemas son un clavo, ni todas las soluciones un martillo. Los microservicios permiten la herramienta adecuada para el trabajo.

Los microservicios tienen ciertos beneficios, y las empresas que los han adoptado con éxito como modelo de arquitectura han cosechado los beneficios de estructuras de TI comerciales más rápidas y ágiles. Sin embargo, algunas organizaciones han encontrado que el sistema deteriora la productividad y es una carga para operar. La diferencia entre el éxito y el fracaso radica en dos partes: la cultura de la organización y su voluntad de aceptar y utilizar los microservicios, y la planificación y previsión puesta en el mapa de los microservicios.

A menudo, los verdaderos beneficios o costos de un nuevo sistema no se perciben hasta pasados muchos años. La arquitectura monolítica a veces ya se habrá superado o habrá comenzado a decaer dentro de esos años. Hay menos oportunidades para ese deterioro dentro de los microservicios, y reparar un problema es un asunto mucho más simple.

Una solución para una variedad de estos problemas potenciales es comenzar con un monolito. Esto permite que un software base se adhiera a otras cosas a medida que se amplía, creando una especie de casa de muñecas con extensiones de Lego. Si bien este puede no ser el enfoque más elegante, es una forma de proceder para una empresa, especialmente con una base de datos o programa existente en el centro de las operaciones.