Los Microservicios Vs Servicios Monolíticos es el tema de debate más candente en el mundo de las TI, donde los microservicios han estado a la par que los servicios monolíticos. Las recientes evoluciones y transformaciones han allanado el camino hacia el mundo de los microservicios, independientemente de las tecnologías o los dominios.

La presión para salir más rápido al mercado ha empujado a las TI a utilizar el enfoque de los microservicios, que es más rápido de desarrollar, probar e implementar. Los equipos a menudo sacrifican la calidad por encima del tiempo de entrega, lo que da lugar a un código rápido y sucio que conduce a un mal diseño y a una enorme deuda técnica.

Así es que el escenario tampoco es más favorable del lado de los microservicios, sólo unas cuantas organizaciones y equipos han entendido estos problemas y están trabajando para solucionarlos junto con el uso de los beneficios del enfoque de microservicios.

La mayoría de las organizaciones y equipos terminan utilizando la misma base de datos, sistemas no distribuidos que se suman a la complejidad y la dependencia de los microservicios entre sí.

Con el desarrollo sobre el modelo ágil, los requerimientos de nuevas funcionalidades y características, las nuevas APIs se conectan sobre los servicios prexistentes para servir al propósito sin seguir el diseño adecuado. Esto hace que el diseño sea más bien un trabajo basado en parches.

La arquitectura y el diseño en papel puede haber evolucionado rápidamente hacia los principios teóricos de los de los microservicios, pero el proceso de pensamiento de los desarrolladores tarda más tiempo, ya que pasaron mucho tiempo de su vida diseñando y desarrollando aplicaciones monolíticas. Esto hace que la primera versión de los servicios sea una obra maestra, pero que con el tiempo se vea empañada por las correcciones de errores y «workarounds» que se añaden para lograr que las soluciones sean altamente disponibles y evolutivas.

Además, las organizaciones medianas y pequeñas tienden a utilizar los mismos equipos de trabajo para la mayoría de los servicios, esto hace que los equipos añadan más cohesión entre los servicios a lo largo del tiempo dado que es el mismo grupo de gente trabajando en todos los servicios. Además, se presenta el reto de planificar y gestionar la implementación de las APIs, ya que ahora dependen unas de otras.

El tiempo de prueba de una aplicación de microservicios es mucho mayor que el de una aplicación monolítica, debido a la complejidad y variedad de pruebas necesarias en todas las API. Esto a menudo lleva a los proyectos/equipos a reducir el ciclo de pruebas y a lanzar una versión de la aplicación que no ha sido probada completamente.

Cuantos más microservicios haya, más implementaciones, gestión de código, configuraciones, hospedajes – a menudo hay errores de configuración, falta de comunicación entre los equipos y mayor vulnerabilidad a los ataques.

Encontrar un problema en el mundo de los microservicios es como encontrar una aguja en un pajar – con el enfoque de los microservicios es importante seguir estrictamente los principios de SRE (Service Reliability Enginneering) para tener los SLIs (Service Level Indicators) y SLOs (Service Level Objectives) en su lugar y ser capaz de encontrar un problema rápidamente entre los servicios.

Y no hay que olvidar la deuda técnica – a menudo se pasa por alto y se olvida debido a la ventaja de «tiempo de comercialización más rápido» de las APIs.

En resumen, los microservicios nos han permitido evolucionar nuestros programas y aplicaciones para seguir el ritmo del mercado, pero es importante comprender y solucionar los problemas que se plantean para hacer frente a estas aplicaciones y mantenerlas.

Es importante ayudar a los ingenieros de código y calidad a ser capaces de evolucionar rápidamente y cambiar de mentalidad, tener más cohesión entre el desarrollo y las operaciones y menos entre los servicios. Así mismo, dedicar más tiempo a identificar y arreglar la confiabilidad de la plataforma atendiendo a las deudas técnicas aún con los plazos ajustados de la mayoría de los proyectos.

Autor: Prateek Srivastava
Lead Solutions Architect / Engineering Manager
Atículo Original:  https://www.linkedin.com/pulse/micro-service-prateek-srivastava/