Close

Microservicios y arquitectura de microservicios

Descubre los pros y los contras de los microservicios y en qué se diferencian de los monolitos.

¿Qué son los microservicios?

El término “microservicios” es un término moderno utilizado para describir un patrón tradicional de “separación de intereses” dentro de un proyecto distribuido y conectado en red. La de los microservicios es una idea que sigue una antigua filosofía fundamental de Unix “de herramientas pequeñas e impecables”. Ambos conceptos se basan en otro patrón informático fundamental de “composición”, es decir, que los sistemas complejos equivalen a la suma de entidades componibles de nivel inferior.

Artículos de microservicios

[CONTINUACIÓN]

La composición se produce a través de todas las capas de un proyecto de software. En el nivel inferior, el “nivel de unidad”, las funciones individuales de código independiente interactúan entre sí a través de una interfaz compartida para crear colecciones o “bibliotecas” de código. En el nivel del shell del sistema operativo, los comandos de shell se pueden componer para crear una canalización de funciones superiores. Los microservicios están a un nivel de composición entre servicios web. Un microservicio es un servicio web responsable de una parte de la lógica del dominio. Los microservicios interactúan entre sí a través de protocolos de red simples como REST para realizar acciones, pero no tienen conocimiento de cómo funcionan otros servicios de forma interna. Esta armoniosa interacción entre microservicios es una arquitectura de microservicios.

La arquitectura de microservicios (MSA, por sus siglas en inglés) ha estado recibiendo mucha atención, ya que los equipos de software están buscando nuevas formas de mejorar su flujo de trabajo de publicación. Amazon, Netflix y eBay se encuentran entre las empresas que adoptan abiertamente esta forma de crear software y han contribuido con la comunidad publicando su propia experiencia y desarrollando herramientas que pueden ayudar a otros a adoptar esta práctica.

El principio rector de los microservicios es crear una aplicación dividiendo sus componentes empresariales en pequeños servicios que se puedan implementar y que funcionen de forma independiente los unos de los otros.

Diagrama donde se muestra cómo un cubo grande se puede dividir en varios cubos más pequeños.

Entonces, los desarrolladores se pueden organizar en equipos más pequeños especificándose en diferentes servicios, con diferentes pilas e implementaciones desacopladas. Esta separación de intereses y la función independiente desacoplada permiten optimizar las prácticas de desarrollo de software ágil, como la entrega continua y la integración continua.

Arquitectura orientada a servicios (SOA) frente a microservicios

La arquitectura orientada a servicios y los microservicios son dos tipos de arquitecturas de servicio web de orden superior. Se pueden concebir los microservicios como una versión ligera de SOA. La diferencia entre ambos tipos de arquitectura es la clasificación burocrática de los tipos de servicios. La SOA se divide en cuatro tipos de servicios básicos: empresas, grandes empresas, aplicaciones e infraestructura. Estos tipos definen la responsabilidad específica de dominios relacionada con los servicios subyacentes. En comparación, los microservicios solo se dividen en dos tipos: funcionales e infraestructurales.

Ambas arquitecturas comparten el mismo conjunto de estándares en diferentes capas de una empresa. La existencia de las MSA se reduce al éxito de la pauta SOA. Por lo tanto, el patrón MSA es un subconjunto de SOA. Aquí el foco principal está en la autonomía de tiempo de ejecución de cada servicio.

Aplicación monolítica frente a microservicios

Diagrama donde se muestra la diferencia entre los monolitos y los microservicios en la entrega continua.

Los microservicios desacoplan los principales intereses específicos de dominios empresariales en bases de código independientes. La arquitectura de aplicación monolítica se puede concebir como la antítesis de los microservicios. Un monolito es una base de código que aúna todos los intereses empresariales. Los monolitos pueden resultar prácticos desde el principio de un proyecto para aliviar la sobrecarga cognitiva de la gestión de código, así como la implementación. De esta forma, es posible publicar a la vez todo lo presente en el monolito.

En principio, muchos proyectos comienzan como un monolito y, luego, evolucionan hasta convertirse en una arquitectura de microservicios. A medida que se añaden nuevas funciones a un monolito, es posible que empiece a resultar engorroso que muchos desarrolladores trabajen en una sola base de código. Los conflictos de código se vuelven más frecuentes y aumenta el riesgo de que las actualizaciones en una función introduzcan errores en una función no relacionada. Cuando aparecen estos patrones no deseados, puede ser el momento de considerar una migración a los microservicios.

Cómo funciona la arquitectura de microservicios

Pongamos como ejemplo un hipotético proyecto de software de comercio electrónico. Hay algunas funciones empresariales de dominio específico claramente definidas. Los sitios de comercio electrónico cuentan con un sistema de autenticación para que el usuario inicie y cierre sesión. Un carrito de la compra conservará una lista de productos en los que el usuario está interesado. Un sistema de facturación permite a los usuarios pagar sus compras.

En una arquitectura de microservicios, estos dominios empresariales de ejemplo serían servicios independientes. Toma como ejemplo específico el sistema de facturación. Dependiendo del número de empleados de la empresa, puede haber un “equipo de facturación” especializado que se dedique al desarrollo y al control de calidad de este microservicio de facturación. El microservicio de facturación tendría su propio calendario de publicaciones y sus propios manuales de estrategias de implementación. El servicio de facturación proporcionaría una API documentada y versionada para que otros servicios pudieran comunicarse y utilizar su funcionalidad.

Pros y contras de los microservicios

+ Escalado horizontal

Los microservicios, por definición, se distribuyen, y se pueden implementar en clústeres. Esto permite escalar de forma horizontal y dinámica a través de los límites de servicios. Si un microservicio está maximizando su capacidad de carga, se pueden implementar rápidamente nuevas instancias de ese servicio al clúster que lo acompaña para aliviar la presión.

+ Ejecución de equipos independientes

Los equipos de propiedad de microservicios pueden operar independientemente de otros equipos de gestión en la organización. Esto permite acelerar la ejecución y la entrega de nuevas funciones.

+ Enfoque más profundo en la calidad

La separación de intereses empresariales en microservicios independientes garantiza que el equipo encargado de dicho servicio esté enfocado por completo en la calidad de la entrega.

- Costes de infraestructura exponenciales

Cada nuevo microservicio que una organización añade a su implementación de producción viene con su propio coste de conjunto de pruebas, manuales de estrategias de implementación, infraestructura de alojamiento, herramientas de supervisión y mucho más.

- Sobrecarga de organización añadida

Se necesita un nivel adicional de comunicación y colaboración para coordinar las actualizaciones e interfaces entre los equipos de arquitectura de microservicios.

- Complejidad del entorno de desarrollo

Cuando un proyecto se divide en múltiples microservicios, surge el nuevo desafío de reproducir la arquitectura distribuida durante la configuración local de desarrollo.

El futuro de los microservicios

La contenedorización y la implementación de contenedores son un nuevo patrón de infraestructura distribuida. Herramientas como Docker y Kubernetes se utilizan para empaquetar un servicio en un “contenedor” completo que se puede implementar y descartar rápidamente. Estas nuevas herramientas de infraestructura complementan la arquitectura de microservicios. Los microservicios se pueden almacenar en contenedores, así como implementar y gestionar fácilmente mediante un sistema de gestión de contenedores.

La adopción de microservicios debe considerarse un viaje, no el objetivo inmediato de un equipo. Empieza poco a poco para conocer los requisitos técnicos de un sistema distribuido, cómo fallar de forma limpia y cómo escalar componentes individuales. Luego, puedes extraer gradualmente más y más servicios a medida que vas adquiriendo experiencia y conocimientos.

La arquitectura de microservicios aún es bastante reciente, pero es una forma prometedora de desarrollar aplicaciones y, definitivamente, vale la pena revisarla. Sin embargo, recuerda que es posible que aún no encaje del todo en tu equipo.

Claire Maynard
Claire Maynard

Claire es una empleada sénior de marketing de Atlassian que ha trabajado en crecimiento, rendimiento y marketing de productos a lo largo de su trayectoria. En este momento, está al frente de la estrategia de marca, contenido y comercialización de Confluence Cloud. Le gusta dedicar su tiempo libre a surfear, salir a correr o descubrir restaurantes en San Francisco o en ciudades de todo el mundo.