Los microservicios se han barajado en los últimos años, pero ¿cuáles son las ventajas y desventajas reales de implementarlos y ejecutarlos? Al igual que cualquier arquitectura de servicio, existen pros y contras, beneficios y compensaciones. Entonces, ¿cómo se comparan los microservicios con otras arquitecturas de aplicaciones como monolitos, arquitectura orientada a servicios (SOA) y funcional?
Este es un analisis no demasiado profundo pero sirve para arrojar algo de luz sobre por qué el desarrollador y la comunidad DevOps están presionando contra la arquitectura de que microservicios es la solución para todo en 2018.
¿Qué es un microservicio?
Está más allá del alcance de este artículo proporcionar una definición exhaustiva de un microservicio. Dicho esto, permítanme seguir adelante y dar un intento de definición simple: "Los microservicios son componentes individuales y distintos de un programa de software que existen para cumplir la función más pequeña posible de una aplicación sin dejar de ser independientes y útiles para el negocio. Desde un punto de vista práctico , cada servicio es un código pequeño, altamente definido y discreto que es responsable de una tarea (por ejemplo, la autorización del usuario final) ".
El lado bueno
Los microservicios, cuando se implementan correctamente, pueden mejorar enormemente la confiabilidad y la escalabilidad del software. Uno de los aspectos más convincentes de los microservicios, cuando se los compara con los monolitos, por ejemplo, es que un error o error en un servicio no debería afectar la capacidad de otros servicios para seguir trabajando según lo previsto. Tenga en cuenta que lo excluí diciendo que no debería, pero más sobre eso más adelante.Los microservicios tienen una serie de ventajas, como:
- Capaz de escalar de forma independiente
- Tolerante a fallos
- Se puede intercambiar o reescribir fácilmente
- Marco y lenguaje agnóstico
- Adherirse al principio KISS
Lo que esto significa desde un punto de vista práctico es que una aplicación debería:
- Escale fácilmente y de una manera altamente eficiente.
- No tener un único punto de falla.
- Ser retirado, refactorizado o reescrito sin comprometer la integridad de toda la aplicación.
- Estar escrito en muchos idiomas y marcos para adaptarse a los requisitos de cada servicio.
- Sé simple y discreto.
- Satisface fácilmente los requisitos para los entornos modernos de PaaS(plataforma como servicio) y SaaS (software como servicio).
Si es lo suficientemente bueno para Netflix, entonces seguramente debe ser lo suficientemente bueno para nosotros. Pues, a lo mejor no. Como veremos, la mentalidad de "por qué no nosotros" debe dejarse de lado. Todo depende de la realidad empresarial y del contexto de desarrollo.
El lado malo
El hecho de que algo sea una tendencia en la industria no significa necesariamente que sea una solución viable para cada caso de uso. Una de las principales desventajas es toda la publicidad que rodea a los microservicios. Algunas de las dificultades más superficiales con microservicios incluyen:- Más complejidad, gracias a la experiencia requerida para mantener una aplicación basada en micro servicio con todas sus partes móviles.
- Si la aplicación no necesita escalar o no está basada en la nube, la arquitectura basada en microservicios puede no proporcionar ningún beneficio significativo.
- No hay opciones nuevas, porque los microservicios necesitan conectarse a los sistemas existentes (y posiblemente monolíticos).
- Las unidades de funcionalidad más pequeñas que se comunican mediante API necesitan métodos de prueba más robustos, así como la aceptación de todo el equipo de ingeniería.
- La necesidad de una mayor gestión y comunicación del equipo para garantizar que todos, no solo ciertos ingenieros, comprendan cada servicio y el sistema en su conjunto.
- Mayor complejidad en entornos de infraestructura con la inclusión de gateways, contenerizacion y equipos.
El lado feo
El hecho de que Netflix o alguna startup de Silicon Valley haya adoptado microservicios no significa que sea el estilo arquitectónico correcto para todas las aplicaciones. La arquitectura de la aplicación debe basarse no solo en lo que está en boga en este momento, sino también en la eficacia y extensibilidad. Cuando se trata de eso, los puntos dolorosos verdaderamente intrínsecos que los microservicios vienen de la mano son:- Tratar con los gastos generales de desarrollo, despliegue y gestión operativa de los sistemas distribuidos puede ser costoso y requiere una inversión inicial elevada.
- Elegir un equipo tecnológico diferente para diferentes componentes conduce a un diseño y arquitectura de aplicación no uniforme.
- Documentación interminable en forma de esquemas actualizados y documentos de interfaz para cada aplicación de componente individual.
- Los costos de mantenimiento, costos operacionales y monitoreo en entornos de producción son mucho más altos, y este último también adolece de una escasez de herramientas disponibles.
- Las pruebas de automatización se vuelven difíciles cuando cada componente de microservicio se ejecuta en un entorno de tiempo de ejecución diferente.
- Mayor consumo de recursos y memoria de todos los componentes de funcionamiento independiente que necesitan sus propios contenedores de tiempo de ejecución con más memoria y CPU.
- Los microservicios, cuando se implementan incorrectamente, pueden hacer que las aplicaciones mal escritas sean aún más disfuncionales, es decir los malos habitos del equipo de desarrollo se extrapolan con mas componentes.
