Microservicios vs Nanoservicios: Opciones de Marco de Ponderación

Con los años, el desarrollo de software se alejó de las arquitecturas monolíticas tradicionales, abordando sus complejidades con código estrechamente acoplado e interconectado. Esto dio lugar a la adopción de microservicios, enfoques eficientes nativos en la nube que Permite la computación distribuida a través de múltiples servicios más pequeños.

Desde que los microservicios se han vuelto habituales, en los últimos años, los nanoservicios evolucionaron como otro patrón diseñado principalmente para superar las complejidades encontradas en los microservicios. Esencialmente, los nanoservicios dividen aún más los servicios para aportar mayor eficiencia.

Este artículo explica cómo desarrollar componentes más pequeños para construir una aplicación está un enfoque preferido, así que voy a:

• Explica tanto los microservicios como los nanoservicios
• Explora beneficios y desafíos
• Comparte ejemplos y buenas prácticas para ayudar te a determinar el marco adecuado para tus necesidades

Mejora de las prácticas de desarrollo

Debido a su diseño elemental, las aplicaciones monolíticas presentan algunos desafíos serios:

• Son incómodas.
• Utilizan mucho espacio en disco.
• Son difíciles de escalar.

Cuando las aplicaciones monolíticas son maduras, la introducción de las últimas tecnologías o la adopción de frameworks mejorados conlleva muchas complejidades. Estos obstáculos no son limitados a la integración a nivel de código. Las pruebas y el despliegue son además un reto.

Además, un proyecto entero para reescribir toda la aplicación están a menudo lento y muy arriesgado.

(Conoce las complejidades de la modernización de aplicaciones y la refactorización de código.)

Microservicios sobre monolitos

Se construyeron microservicios para:

• Superar los problemas con un enfoque monolítico.
• Proporcionar una solución eficaz para desarrollar aplicaciones distribuidas basadas en la nube.

Un microservicio fragmenta una aplicación en un ensamblaje de múltiples servicios débilmente acoplados. Normalmente, los microservicios son:

• Desarrollado y probado de forma aislada
• Organizados según los procesos que gestionan
• Desplegados de forma independiente.

Cada uno de estos servicios tiene sus propios procesos separados y está diseñado para funcionar de forma independiente sin compartir recursos, con el fin de evitar conflictos.

Nanoservicios

Una ilustración típica muestra cómo un marco central y multinivel de un monolito difiere de una arquitectura de microservicios con servicios distribuidos.

(Comparar la arquitectura de microservicios con la arquitectura monolítica.)

Los microservicios suelen son contenidos dentro de contenedores basados en la nube que se comunican con otros servicios a través de APIs web. Estas APIs actúan como colas de mensajería que responden a eventos entrantes como la interfaz de usuario, la invocación de otros servicios, la aceptación de datos, etc.

Debido a su modelo distribuido, son desarrollados y mantenidos microservicios sin afectar a otros servicios. Esto esencialmente también ayuda a un modelo DevOps al permitir:

• Automatización eficiente
• Alta disponibilidad 

(Ve cómo los microservicios y las APIs difieren pero funcionan juntos.)

Beneficios de los microservicios

El diseño basado en componentes de un marco de microservicios ofrece múltiples beneficios, entre ellos:

• Los microservicios son más fáciles de mantener, escalar y compartir
• Funcionan bien con los recipientes.
• El desarrollo y las pruebas están más rápidos, acortando el ciclo de despliegue y convirtiéndolo en un encaje ideal para prácticas DevOps.
• La naturaleza aislada de los servicios ofrece un despliegue más seguro y una resolución más rápida de errores.
• Los microservicios ofrecen mayor flexibilidad al permitir la reutilización para construir servicios similares.
• No son restricciones sobre las tecnologías específicas a utilizar, lo que permite una mayor productividad en el desarrollo (y quizás innovación).
• Debido a que son de naturaleza interoperable, los microservicios pueden usarse tanto con plataformas de código abierto como cerrado.

¿Qué son los nanoservicios?

La diferencia básica entre ambos marcos están que los nanoservicios son considerados hermanos menores de los microservicios. Los nanoservicios son diseñados para realizar una única función, cuya salida está expuesta a través de un endpoint API específico (comando).

Los nanoservicios son totalmente descubribles entre sí. Cada uno puede conectarse con otros servicios para realizar acciones adicionales y extender funcionalidades.

Por diseño, los nanoservicios son:

• Autocontenido
• Reutilizable
• Menos complejo que los microservicios
• Soportado por archivos de función distintos para cada una

Los nanoservicios son considerados más eficientes que los microservicios, especialmente debido a:

• Facilidad de montaje inicial
• Latencia reducida entre servicios, donde el código de función de cada nanoservicio puede ejecutarse bajo demanda sin la utiliza de contenedores o servidores dedicados para alojar cada servicio individual.

Caso de utiliza real de nanoservicios

La ilustración siguiente destaca un caso de uso interesante de cómo la web de la BBC utiliza miles de nanoservicios para generar páginas web dinámicas. Cada servicio funciona para alimentar un componente específico de la página web, como:

• Generación de un titular
• Obtención de datos meteorológicos
• Actualización de un marcador de partido
• Etcétera.

Una arquitectura de nanoservicios de alto nivel del sitio de la BBC describe cómo múltiples servicios más pequeños funcionan en conjunto para entregar el contenido de una página web:

Beneficios de los nanoservicios

Los nanoservicios son especialmente beneficiosos debido a su facilidad para encapsular funciones específicas. Esto aporta un marco de aplicación con estas ventajas:

• Más enfocado y ligero en comparación con los microservicios
• Varios equipos pueden trabajar en un servicio específico o en varios servicios
• Cada servicio puede tener su propio protocolo de seguridad
• Puede desarrollarse, probarse y desplegarse de forma independiente
• Facilita liberaciones de código más rápidas y frecuentes
• Mayor flexibilidad para enlazar diferentes servicios entre sí y así ampliar la funcionalidad

Desafíos actuales

Aunque los microservicios y nanoservicios son mejoras significativas respecto a un monolito, no están exentos de desafíos.

Ciertos casos utiliza también sugieren que desarrollar una aplicación combinando servicios más pequeños aumenta la complejidad de varias maneras, incluyendo:

• Más esfuerzo dedicado a crear y mantener servicios duplicados
• El requisito de una infraestructura altamente eficiente es complejo de construir y costoso de mantener
• Mayor consumo de recursos, debido a la gran cantidad de servicios te soportar
• Dependencias más estrictas a nivel de servicio pueden resultar en un seguimiento complejo de errores

A primera vista, un mayor aislamiento dentro de los nanoservicios puede parecer tentador. Sin embargo, la utiliza generalizada de nanoservicios podría provocar una gran serie de problemas y mayores complejidades.

Además, para aplicaciones bastante complejas, adoptar un marco de nanoservicios puede en realidad sobreutilizar recursos y escalar esfuerzos manuales, algo que las prácticas DevOps quieren minimizar.

(Prepárate para otros retos comunes de microservicios.)

Elegir microservicios o nanoservicios

Tanto los microservicios como los nanoservicios han evolucionado para aportar eficiencia frente a las arquitecturas tradicionales, distribuyendo códigos de aplicación complejos en múltiples servicios más pequeños dentro de una configuración nativa en la nube.

Teniendo esto en cuenta, las consideraciones importantes para elegir el mejor marco se reducen finalmente a dos componentes clave:

• Experiencia del desarrollador
• Requisitos de funcionalidad de la aplicación

Cuándo utilizar microservicios

En comparación con los nanoservicios, los microservicios son un enfoque de diseño consolidado y conocido que puede operar con una amplia gama de tecnologías.

Son varios casos de uso exitosos de grandes actores de la industria—Netflix y AWS—que ya utilizan la arquitectura de microservicios para ofrecer varios servicios de última generación. Eso significa que los microservicios cuentan con una gran cantidad de recursos y grupos para apoyar la estrategia de microservicios de aprendizaje o madurez.

Los microservicios suelen son adecuados para:

• Un proceso de desarrollo ágil
• Situaciones en las que son los equipos de desarrollo están funcionalmente o geográficamente distribuidos
• Crear un producto mínimo viable (MVP) que te extiende funcionalmente con el tiempo, no todo de golpe

Teniendo esto en cuenta, están igualmente importante señalar que los microservicios no son adecuados para todos los tipos de aplicaciones. Ciertos casos utiliza destacan que, sin una diligencia exhaustiva y una planificación eficiente, la expansión aleatoria de los servicios puede acabar haciendo que el marco sea tan grande y engorroso como una arquitectura monolítica.

(Sigue las mejores prácticas de microservicios desde la planificación hasta el mantenimiento.)

Los nanoservicios son mucho más recientes. Han demostrado utiliza casos de su potencial completo aún son por descubrir. Aunque son más pequeños, flexibles, aislados y funcionalmente enfocados, aún son incógnitas sobre:

• Compatibilidad con tecnología emergente
• Escalado exponencial

Como resultado, son escuelas de pensamiento contradictorias sobre cómo y cuándo utilizar los microservicios.

En primer lugar, la mera naturaleza de los nanoservicios plantea la cuestión de si son protegidos de los vectores de ataque cuando se utilizan extensamente en una aplicación.

Algunos también consideran que los nanoservicios son un anti-patrón debido a su funcionalidad fragmentada. Se está sabido que esto puede causar que la sobrecarga de mantenimiento supere el valor de los beneficios del marco.

Como los nanoservicios son aún en pañales, las organizaciones conservadoras y grandes suelen evitarlos (por ahora), principalmente debido al incierto soporte del marco para la escalabilidad. Para quienes lo adopten, una de las mejores prácticas para usar el marco están:

Evita los nanoservicios si su utiliza complica el sistema que pretende simplificar.

Diseño intencionado

Si elegir nanoservicios en lugar de microservicios, o viceversa, siempre dependerá de los casos de uso. El objetivo final, sin embargo, sigue siendo el mismo: adoptar la arquitectura adecuada que facilite la automatización y desarrolle aplicaciones que son resilientes, escalables y seguras.

Lecturas relacionadas

• BMC DevOps Blog
• Microservicios vs Miniservicios: Elegir el marco adecuado
• Microservicios vs Serverless: ¿Cuál es la diferencia?
• Kubernetes vs Docker Swarm: Comparando herramientas de orquestación de contenedores, parte de nuestra Guía Kubernetes
• Ágiles vs SDLCs en cascada: ¿cuál es la diferencia?
• Las principales tendencias DevOps hoy en día

Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.