
Microservicios: ventajas y contras de la arquitectura descentralizada
16 agosto 2018

Probablemente has oído hablar de microservicios antes. Seguramente estás harto de oír hablar de ellos. Tal vez no estés seguro de entender totalmente el concepto. Si ese es el caso, el artículo de Rebel Thinking de esta semana es para ti.
La versión reducida, la arquitectura de microservicios es un método de desarrollo de aplicaciones o sistemas de software, compuesto por servicios más pequeños que proporcionan una funcionalidad de negocio completa. En otras palabras, cada microservicio desempeña una función específica y puede conectarse con otros microservicios. Es una alternativa a las soluciones monolíticas más tradicionales, donde todos los elementos funcionales están unidos en un programa o aplicación.
Los microservicios nacen de la necesidad de implementar y realizar cambios en el software de forma rápida y sencilla. Ahora que los desarrolladores están abandonando las arquitecturas monolíticas en favor de sistemas de microservicios, cada vez más populares, aumentan las organizaciones que están empezando a dar prioridad al desarrollo de productos compuestos de piezas intercambiables, actualizables y escalables, donde todas encajan como un rompecabezas. Las organizaciones que están adaptando gradualmente una mentalidad centrada en el ser humano, donde se necesita un flujo fluido de información, y donde pueden sentirse aún más atraídas por los microservicios.
Como se puede ver en la imagen de arriba, cada microservicio tiene su propia base de datos, lo que significa que el sistema se distribuye y también mejora el rendimiento del producto. Sin embargo, hay que tener en cuenta que el usuario nunca apreciará completamente la diferencia entre ambas soluciones ya que, a nivel de la interfaz, es difícil notar la diferencia.
¿Cómo se comunican los microservicios entre sí?
Los microservicios se comunican entre sí a través de APIs – un conjunto de comandos, funciones y protocolos predefinidos. Los desarrolladores pueden aprovechar las bibliotecas de la API y, en la mayoría de los casos, tienen permiso para añadir nuevas bibliotecas y compartirlas con la comunidad. Las APIs son el lenguaje común utilizado para permitir la comunicación entre microservicios y otras formas de arquitectura.
Hay muchas nuevas tecnologías que se aprovechan del aumento de la cultura del microservicio – Docker, un «contenedor de software», es quizás el ejemplo más relevante. Con Docker, y plataformas similares como Nomad y Kubernetes, podemos sustituir los modelos tradicionales de servidores web por contenedores de software virtualizados más pequeños y mucho más adaptables. Gracias a las soluciones de software «middleware» fáciles de configurar, podemos asegurar que el flujo de información entre sistemas es preciso y reducir el riesgo de perder la pista de cualquier dato.
Echemos un vistazo a algunos de los pros y contras de los microservicios. Esto nos ayudará a explicar cómo nosotros, en Good Rebels, determinamos qué forma de arquitectura es la adecuada para un equipo u organización.
Pros y contras de los microservicios
No hay una manera fácil de identificar qué forma de arquitectura funcionará mejor para un equipo – es importante evaluar todos los pros y contras que vienen con las arquitecturas monolíticas y microservicios, así como los puntos débiles comunes. En Good Rebels, estamos acostumbrados a trabajar tanto en proyectos ágiles como en proyectos más tradicionales – y como tal no creemos que ninguna forma de arquitectura sea intrínsecamente «mejor» – todo depende del proyecto en sí. Es bastante común comenzar con la arquitectura monolítica y luego expandirse gradualmente, de manera secuencial y controlada, añadiendo más servicios a medida que se avanza. De esta manera, se puede reducir costos y mantenerse en una posición competitiva.
Por supuesto, hay que tener en cuenta el alcance inicial del trabajo. Nuestra recomendación, si se desea reducir costes y limitar el tiempo necesario para completar el proyecto, es empezar con un modelo monolítico de bajo coste y prestar mucha atención a la evolución del proyecto para que si es necesario añadir algo, se pueda hacer de forma natural y sólo cuando sea necesario.
Si el objetivo es poner en marcha microservicios, primero habría que familiarizarse con las ventajas y desventajas de esta forma de arquitectura:
Ventajas:
- Versátil – los microservicios permiten el uso de diferentes tecnologías y lenguajes.
- Fácil de integrar y escalar con aplicaciones de terceros.
- Los microservicios pueden desplegarse según sea necesario, por lo que funcionan bien dentro de metodologías ágiles.
- Las soluciones desarrolladas con arquitectura de microservicio permiten la mejora rápida y continua de cada funcionalidad.
- El mantenimiento es más simple y barato – con los microservicios se puede hacer mejoras de un módulo a la vez, dejando que el resto funcione normalmente.
- El desarrollador puede aprovechar las funcionalidades que ya han sido desarrolladas por terceros – no necesita reinventar la rueda, simplemente utilizar lo que ya existe y funciona.
- Un proyecto modular basado en microservicios evoluciona de forma más natural, es una forma fácil de gestionar diferentes desarrollos, utilizando los recursos disponibles, al mismo tiempo.
Contras:
- Debido a que los componentes están distribuidos, las pruebas globales son más complicadas.
- Es necesario controlar el número de microservicios que se gestionan, ya que cuantos más microservicios existan en una solución, más difícil será gestionarlos e integrarlos.
- Los microservicios requieren desarrolladores experimentados con un nivel muy alto de experiencia.
- Se requiere un control exhaustivo de la versión.
- La arquitectura de microservicios puede ser costosa de implementar debido a los costos de licenciamiento de aplicaciones de terceros.
Puede parecer que los pros superan a los contras, sin embargo hay ciertos problemas inherentes a las soluciones basadas en microservicios (costo, eficiencia, tiempos de respuesta, etc.). Lo más importante a tener en cuenta es qué solución se adapta mejor a las necesidades del proyecto específico y qué soluciones nos ayudarán a conseguir nuestros objetivos.
Mono vs. Micro
Además, para determinar qué tipo de arquitectura se adapta mejor a las necesidades de un proyecto específico, necesitamos responder a las siguientes preguntas:
- ¿Cuál es el tamaño del equipo? Un equipo más grande puede ser más adecuado para microservicios.
- ¿Actualmente dependemos de un servicio monolítico?
- ¿Hay alguien en el equipo con la experiencia necesaria para facilitar la arquitectura de microservicios?
- ¿Estamos construyendo para una sola audiencia? Los microservicios son más útiles cuando se está construyendo para una base de consumidores más diversa.
Con un sistema grande y evolutivo (pensemos en Google, Netflix, Amazon, Uber…etc.), los microservicios son claramente la mejor opción. Pero, siendo realistas, ¿nuestro proyecto se puede comparar con una organización tan grande como Google?
También necesitamos considerar el futuro de los microservicios – ¿cómo evolucionarán y cómo se beneficiarán los desarrolladores de soluciones de software? El pago instantáneo a través de aplicaciones de mensajería, por ejemplo, es posible gracias a aplicaciones integradas y más centralizadas que permiten a los usuarios realizar pedidos o hacer reservas sin tener que salir de la propia aplicación.
Los microservicios son como departamentos dentro de una empresa; cada departamento tiene su propio papel, su propio conjunto específico de habilidades. Siguiendo esta misma analogía, los APIs son como aquellos empleados con experiencia en un número de áreas diferentes – son responsables de ayudar en la implementación de protocolos o tareas específicas a través de diferentes departamentos. La empresa puede, siempre que sea necesario, hacer uso de estos colaboradores cualificados para lograr un resultado específico. Los microservicios dependen de la cultura organizacional, al igual que aquellos que desean implementar un sistema de microservicios. Para determinar si la arquitectura de microservicios es adecuada para un proyecto, primero se debe evaluar las necesidades, los recursos y la cultura de la organización.

