Los bueno y lo malo de los Microservicios

repostaje_ferrari-5B1-5D

“Los microservicios son pequeñas aplicaciones responsables de hacer una cosa bien en la búsqueda de un objetivo común”

Como todo en tecnología, tiene su lado bueno y su lado ‘malo’. A continuación hablaré sobre ambos frentes en base a nuestra experiencia.

El lado bueno:

Bueno, la arquitectura de microservicios está enfocada para despliegues en la nube, pero considérese una nube privada, pública o híbrida. Sus principios base ayudan a aumentar la eficiencia del proceso de desarrollo y obtener más valor para el negocio enfocado en la innovación:

  1. Independencia de servicios: Cada servicio contiene su propia lógica de negocio y se implementa por separado. Esto hace posible agregar gradualmente nuevas características. Por otro lado, cada microservicio puede estar desarrollado en distintos lenguajes de programación. Lo más importante en este punto es hacer que sean lo necesariamente atómicos para que se puedan reutilizar por otros procesos.
  2. Centrarse en los requerimientos del negocio: El proceso de desarrollo se vuelve más flexible. Cada servicio es una aplicación independiente con su propia lógica de negocio, interface, persistencia y funcionalidad para conectarse con otros servicios. Esto es de gran utilidad puesto que cada desarrollador es responsable de crear un servicio altamente eficiente y correcto; además que no tiene excusas para no hacerlo puesto que es responsable de todo.
  3. Fácil de agregar nuevas funcionalidades: Los equipos de desarrollo tratan con aplicaciones más pequeñas y arquitecturas más simples. Por lo tanto, es fácil introducir cambios o agregar otro microservicio. En general, el enfoque de microservicios es adecuado para desarrollar aplicaciones tanto para clientes como para uso interno.
  4. Tolerante a fallos: Aunque las aplicaciones basadas en este enfoque constan de varios microservicios pequeños que pueden fallar, estas unidades están acopladas de forma flexible y pueden restaurarse automáticamente cuándo están desplegadas en cluster.

El lado malo:

Como toda arquitectura, la arquitectura basada en microservicios tiene sus retos y algunas veces sus complicaciones.

  1. Interfaces implícitas: Cuando dividimos un sistema monolito en varios componentes que colaboran entre sí, necesitamos habilitar la comunicación entre todos. Las aplicaciones de microservicios utilizan interfaces para este propósito, mejor conocido como APIs. Para que esta comunicación funcione sin problemas, los mensajes deben tener un formato y una semántica que todas las interfaces puedan leer.
  2. Trabajo operativo se incrementa: El uso de una arquitectura de microservicios puede aumentar la sobrecarga operativa. Con este enfoque, su implementación puede requerir significativamente más recursos. Como resultado, es posible que necesite más tiempo y esfuerzo para crear la infraestructura.
  3. DevOps es requerido: Dado que el modelo de microservicios permite el uso de varias herramientas y soluciones para implementar diferentes servicios del mismo sistema, es posible que deba usar diferentes bases de datos para diferentes servicios. Es posible que su desarrollador de bases de datos tenga que ser reemplazado por un desarrollador con experiencia en la implementación, ejecución y optimización de bases de datos NoSQL (un desarrollador con habilidades DevOps).
  4. Complejidad operacional: Es más difícil controlar una arquitectura de microservicios, ya que consta de varias instancias y servicios que deben administrarse en producción. Para solucionar esto, debe proporcionar un alto nivel de automatización.

Finalmente, la adopción de este modelo de diseño será un constante proceso de aprendizaje y mejora continua. Los microservicios serán buenos en la medida que se diseñen correctamente los mismos, pero lo más importante será diseñar una arquitectura que sea tolerante a fallos y que se recupere automáticamente.