microservicesLas arquitecturas basadas en microservicios están cambiando la forma en la que, a día de hoy, diseñamos el software, lo que plantea nuevos retos en el desarrollo y la operación.

Estas arquitecturas están añadiendo una fuerte dependencia de la red en la lógica de negocio, incrementando el número de peligros potenciales, que crecen proporcionalmente a las conexiones o enlaces que se crean entre los servicios.

Arquitectura basada en microservicios vs arquitectura monolítica

La arquitectura monolítica ha sido el modelo de desarrollo de software tradicionalmente utilizado. En esta, el software se compone de una aplicación unificada y autocontenida, en la que sus componentes están fuertemente acoplados, de tal forma que, un cambio en una pequeña parte de la aplicación implica la liberación de una nueva versión.

La arquitectura de microservicios es una alternativa a la arquitectura monolítica. Esta, habitualmente, requiere descomponer la aplicación en múltiples unidades débilmente acopladas, con el objetivo de tener servicios independientes con operaciones e interfaces definidas, a través de los cuales interactúan unos con otros para realizar una operación requerida. Gracias a esta arquitectura nos podemos beneficiar, entre otras cosas, de:

• Agilidad
• Innovación
• Escalabilidad
• Fácil mantenimiento

Pero este tipo de arquitectura también pone sobre la mesa nuevos escenarios que conviene seguir muy de cerca.

Los nuevos retos de las arquitecturas de microservicios

A finales de los años 90, James Glosing, diseñador de la máquina virtual Java, recogió una lista de falsas suposiciones que pueden hacer a un sistema distribuido ineficiente, inseguro y más difícil de mantener. Una arquitectura distribuida necesita ser modelada cuidadosamente, y hacerlo sin manejar explícitamente estos problemas es una fuente de fallos. Por lo tanto, es esencial, para una adopción exitosa de la arquitectura de microservicios, desgranar las conjeturas de Glosing:

• La red es robusta y confiable. Un fallo puede estar causado tanto por el software como por el hardware (por ejemplo,un switch), o un problema en el DNS entre otros servicios externos.
• La latencia es cero. Los lenguajes y librerías actuales enmascaran la lógica repetitiva en la invocación de llamadas a funciones de servicios remotos, pero los desarrolladores, a veces, asumen que se invocan como si de un servicio local se tratase. Y esto es totalmente falso, una llamada a través de la red es muchísimo más lenta que una llamada local. Si esta no es apropiadamente tratada se puede bloquear la aplicación por un largo periodo de tiempo. La caída de un servicio es un escenario extremo, que rara vez ocurre. Una situación mucho más común es que un servicio responda con lentitud a causa de la carga.
• El ancho de banda es infinito. Usualmente, la necesidad de una nueva funcionalidad nos lleva a la prematura conclusión de crear un nuevo microservicio para ello. Pero esto tiene un coste para los servicios ya desplegados en términos de capacidad de red.
• La topología no cambia. Una de las razones por las cuales pueden adoptarse arquitecturas de microservicios es la agilidad. Con la que velozmente se podrá construir, liberar y desplegar. Esto implica bajo acoplamiento entre servicios. Un simple escalado horizontal en un servicio puede cambiar flujos de tráfico, e insertar fallos inesperados.
• La red es segura. Usualmente las aplicaciones realizan un intercambio en información en texto plano, exponiendo datos sensibles, en consecuencia la comunicación debe estar securizada.
• Hay un solo administrador del sistema. En un entorno basado en microservicios, cada equipo debe ser responsable de mantener y operar sus propios servicios con independencia del resto.
• El coste de transporte es cero. Es importante tener en cuenta que la transferencia de datos consume recursos y puede incurrir también en costes.
• La red es homogénea. Todo el ecosistema usa el mismo hardware y todos los servicios se comunican a través de un protocolo estándar. Esta idea es completamente estéril en una filosofía de microservicios formada por equipos de trabajo independientes y autónomos.

Si profundizamos en cada uno de estos desafíos, descubriremos que no están relacionados con la lógica de negocio de los microservicios, sino con la forma en que los diferentes sistemas interactúan entre sí. En un ecosistema cloud-native como el Orquestador kubernetes, estos desafíos pueden abordarse mediante la implementación de una service mesh o malla de servicios.

En el próximo artículo expondremos qué es una malla de servicios y cómo nos ayuda a afrontar los nuevos retos.


Sobre el autor

Guillermo Lopez
Guillermo Lopez
Ingeniero en Informática en el departamento de I+D. Dentro de dicho departamento trabaja en el grupo de Cloud Appliances como Ingeniero de Infraestructuras.

Comparte este post


Nuestras Soluciones Relevantes



| Etiquetas: