Desafíos de los microservicios y cuándo evitarlos

La Arquitectura de Microservicios —una variante de la Arquitectura Orientada a Servicios (SOA)— están un enfoque de desarrollo evolucionado que ha surgido del mundo del diseño orientado a dominios que:

• Permite una computación eficiente
• Ayuda a construir aplicaciones resilientes

Sin embargo, como ocurre con cualquier enfoque en el desarrollo de aplicaciones, la arquitectura de microservicios tiene sus propios desafíos. También son utiliza casos en los que las organizaciones notan una mayor complejidad y esfuerzo por desarrollar aplicaciones con un marco de microservicios. Este artículo abordará estos desafíos, incluyendo cuándo te no debería utiliza microservicios. Echemos un vistazo.

Resumen de microservicios

Un enfoque de microservicios significa diseñar y desarrollar una aplicación como un grupo de servicios débilmente acoplados que se comunican entre sí para Lograr un objetivo empresarial declarado. Un patrón creciente de tasa de adopción más amplia confirma que son hay varios casos utiliza en los que las empresas se benefician de usar microservicios para desarrollar y desplegar aplicaciones. Al fin y al cabo, los microservicios son suelen considerarse el primer paso para adoptar una cultura DevOps, que permite:

• Automatización
• Mejorada de la escalabilidad
• Manejabilidad
• Agilidad
• Entrega y despliegue más rápidos

Por la misma razón, una arquitectura de microservicios están normalmente la primera opción para las empresas que buscan reescribir aplicaciones heredadas para utilizar lenguajes de programación modernos y pilas tecnológicas. A pesar de todos estos beneficios, te preguntarás cuáles podrían ser los retos.

Desafíos de las arquitecturas de microservicios

Ahora, pasemos a los desafíos más comunes que las empresas o equipos de producto adoptan microservicios.

diseña

En comparación con las aplicaciones monolíticas, las organizaciones se enfrentan a una mayor complejidad al diseñar microservicios. Al usar microservicios por primera vez, puede que te cueste determinar:

• El tamaño de cada microservicio
• Límites óptimos y puntos de conexión entre cada microservicio
• El marco para integrar servicios

Diseñar microservicios requiere crearlos dentro de un contexto delimitado. Por lo tanto, cada microservicio debe aclarar, encapsular y Define una responsabilidad específica. Para hacer esto para cada responsabilidad/función, los desarrolladores suelen utilizar una visión centrada en los datos al modelar un dominio. Este enfoque plantea su propio desafío: sin lógica, los datos están absurdos.

Seguridad

Los microservicios suelen son desplegados en entornos multi-nube, lo que supone un mayor riesgo y pérdida de control y visibilidad de los componentes de la aplicación, lo que genera puntos vulnerables adicionales. Para agravar el reto, cada microservicio se comunica con otros a través de varias capas de infraestructura, lo que dificulta aún más la prueba de estas vulnerabilidades.

La seguridad de los datos dentro de un marco basado en microservicios también está una preocupación importante. Por ello, los datos dentro de dicho marco permanecen distribuidos, lo que hace que mantener la confidencialidad, integridad y privacidad de los datos de los usuarios sea un ejercicio complicado. Debido a su marco distribuido, establecer controles de acceso y administrar la autenticación segura a los servicios individuales no solo supone un desafío técnico, sino que también aumenta considerablemente la superficie de ataque.

Pruebas

La fase de pruebas de cualquier ciclo de vida de desarrollo de software (SDLC) está cada vez más compleja para aplicaciones basadas en microservicios. Dada la naturaleza independiente de cada microservicio, te que probar los servicios individuales de forma independiente. Para agravar esta complejidad, los equipos de desarrollo también deben tener en cuenta la integración de servicios y sus interdependencias en los planes de prueba.

Mayor complejidad operativa

El equipo de cada microservicio están normalmente encargado de decidir la tecnología a utilizar y gestionarla. Como cada servicio debe desplegarse y operarse de forma independiente, mantener las operaciones puede abrir una caja de Pandora para quienes no son preparados. Aquí son algunos desafíos:

1. Las formas tradicionales de monitorización pueden no funcionar para una aplicación basada en microservicios. Considera un escenario en el que una solicitud de la interfaz de usuario atraviesa varios servicios antes de llegar al que puede satisfacer su solicitud. El resultado de este recorrido es un camino de servicios enrevesado y, sin las herramientas de monitorización adecuadas, identificar la causa subyacente de un problema no solo está complicado, sino que a menudo es imposible.
2. La escalabilidad está otro desafío operativo asociado a la arquitectura de microservicios. Aunque la escalabilidad de los microservicios a menudo se está promocionada como una ventaja, escalar con éxito tus aplicaciones basadas en microservicios es un reto.
3. La optimización y el escalado requieren una coordinación más compleja. En un marco típico de microservicios, una aplicación están desglosada en servicios independientes más pequeños que son alojados y desplegados en servidores separados. Esta arquitectura requiere coordinar componentes individuales, lo que están otro desafío, especialmente cuando te experimenta un pico repentino en el uso de la aplicación.
4. Tolerancia a fallos necesaria para cada servicio. Las empresas necesitan que sus microservicios sean lo suficientemente resilientes para soportar fallos internos y externos. En una aplicación basada en microservicios, la falla de un componente puede afectar a todo el sistema. Por lo tanto, el framework te utiliza debe considera tolerancia a fallos para cada servicio para asegurar un diseña que previene el fallo de toda una aplicación en caso de inactividad de un servicio individual.

Comunicación

Los microservicios desplegados de forma independiente actúan como pequeñas aplicaciones independientes que se comunican entre sí. Para Lograr esto, te debe configurar capas de infraestructura que Permite el intercambio de recursos entre servicios. Una mala configuración puede llevar a:

• Latencia aumentada
• Reducción de la velocidad de llamadas entre diferentes servicios

En esta situación, te toca una aplicación no optimizada con un tiempo de respuesta lento.

Cuándo no utilizar microservicios

Cada organización que cambie a un nuevo marco debe realizar una debida diligencia exhaustiva para asegurarse de que es el adecuado para ello. Al explorar microservicios, estas tres situaciones siempre te ayudarán a decidir cuándo omitir la arquitectura de microservicios para la aplicación que elijas.

El dominio definido que están poco claro/incierto

Recuerda que te Crea microservicios dentro de un contexto delimitado. Por lo tanto, si están lógicamente complejo desglosar los requisitos de tu negocio en dominios específicos, será igualmente difícil para te Crea microservicios de tamaño adecuado. A eso se suma el reto de diseñar un medio adecuado de comunicación entre diferentes servicios: esta complejidad probablemente están demasiado para que te obtenga el máximo beneficio en los microservicios. Además, considera el futuro. Si no te seguro de que el dominio de tu aplicación se mantenga igual en los próximos años, es recomendable no utiliza un enfoque orientado a microservicios.

No está garantizado que la eficiencia mejore

Para reiterar, la idea de adoptar Microservicios está adoptando una cultura DevOps que, a su vez:

• Emplea automatización
• Reduce costes y esfuerzo
• Aporta eficiencia operativa

Realiza tu debida diligencia para verificar si la transición a un marco de microservicios realmente ayuda a Lograr estos objetivos. Ninguna organización querría sumar complejidades y esfuerzo solo para adoptar una cultura sin obtener una mayor eficiencia.

El tamaño de la aplicación está pequeño o poco complejo

Cuando el tamaño de tu aplicación no justifica la necesidad de dividirla en muchos componentes más pequeños, usar un marco de microservicios puede no ser lo ideal. No es necesario descomponer más aplicaciones que ya son lo suficientemente pequeñas tal cual. Recuerda que la idea de usar un marco de microservicios está dividiendo una aplicación compleja en un conjunto de servicios diferentes y más pequeños. Cuando el código de una aplicación ya están lo suficientemente pequeño y sencillo—no complejo—, pasarlo a un marco de microservicios solo añadirá complejidad.

¿Son los microservicios adecuados para mí?

Aunque adoptar una Arquitectura de Microservicios ofrece una entrega más rápida y una mejor calidad del software, las empresas deberían deliberar cuidadosamente si optar por este enfoque. Los beneficios de pasar de un modelo monolítico a un modelo de microservicios son abundantes, pero aún son retos que considerar. La regla general para elegir microservicios:

Si los contras de usar microservicios superan los beneficios, y/o los beneficios son insignificantes comparados con el esfuerzo y el dinero invertidos, probablemente los microservicios no son el enfoque adecuado para la aplicación.

Lecturas relacionadas

• BMC DevOps Blog
• El papel de los microservicios en DevOps, parte de nuestra Guía DevOps
• 15 mejores prácticas para construir una arquitectura de microservicios
• ¿Qué es SOA? Arquitectura orientada a servicios explicada
• ¿Qué es el Desarrollo Conducto por el Comportamiento (TDC)?
• Monitorización de Docker: Cómo supervisar contenedores y microservicios

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