Paso 2: organiza tu equipo de forma correcta

Hasta ahora, podía parecer que la compilación de microservicios era, sobre todo, una cuestión técnica. Hay que dividir una base de código en varios servicios, implementar los patrones correctos para fallar de forma limpia y recuperarte de las incidencias en la red, lidiar con la coherencia de los datos, supervisar la carga de servicio, etc. Habrá muchos conceptos nuevos que comprender, pero una cosa que no se debe ignorar es que deberás reestructurar la forma en que se organizan tus equipos.

La ley de Conway existe y se puede observar en cualquier tipo de equipo. Si un equipo de software está organizado con un equipo de backend, uno de frontend y otro de operaciones que trabajan de manera independiente, terminarán entregando monolitos de frontend y backend separados que se presentarán al equipo de operaciones para que los entreguen en la producción. Este tipo de estructura no es una buena opción para los microservicios, ya que cada servicio se tratará como su propio producto que debe enviarse independientemente de los demás.

En su lugar, debes crear equipos de DevOps que tengan todas las competencias necesarias para desarrollar y mantener los servicios de los que están a cargo. Organizar tus equipos de esta manera presenta grandes ventajas. En primer lugar, todos tus desarrolladores comprenderán mejor el impacto de tu código en la producción; esto ayudará a producir una mejor publicación y a reducir el riesgo de ver incidencias publicadas que llegan a los clientes. En segundo lugar, las implementaciones resultarán más naturales para cada equipo, ya que trabajarán juntos en las mejoras en el código, así como en la automatización de la canalización de implementaciones.

Paso 3: divide el monolito para compilar una arquitectura de microservicios

Cuando hayas determinado los límites de tus servicios y hayas descubierto cómo puedes reestructurar tus equipos, puedes empezar a dividir el monolito para crear microservicios. Estos son los puntos clave que tener en cuenta en ese momento.

Simplifica la comunicación entre servicios con una API basada en REST

Si aún no estás usando una API basada en REST, ahora sería un buen momento para adoptarla. Como explica Martin Fowler, te interesará tener “endpoints inteligentes y canales simples”. Esto quiere decir que el protocolo de comunicación entre tus servicios debe ser lo más sencillo posible y que solo se encargue de transmitir los datos sin transformarlos. La magia se produce en los mismos endpoints: reciben una solicitud, la procesan y emiten una respuesta.

Las arquitecturas de microservicios se esfuerzan por mantener las cosas lo más sencillas posible para evitar dependencias estrechas entre componentes. En algunos casos, es posible que acabes utilizando una arquitectura orientada a eventos con comunicaciones asincrónicas basadas en mensajes. Pero, una vez más, debes echar un vistazo a los servicios básicos de cola de mensajes como RabbitMQ y evitar añadir complejidad a los mensajes transmitidos a través de la red.

Divide los datos en contextos delimitados o dominios de datos

Las aplicaciones monolíticas utilizan una sola base de datos para todas las funciones empresariales de la aplicación. Cuando un monolito se divide en microservicios, es posible que esta base de datos única ya no sea práctica. De hecho, una base de datos centralizada puede convertirse en un cuello de botella para el escalado del tráfico. Si un servicio en particular accede a la base de datos con una carga elevada, puede interrumpir el acceso a la base de datos por parte de otros servicios. Además, una base de datos única puede convertirse en un cuello de botella de colaboración para varios equipos que intentan modificar el esquema al mismo tiempo. Esto puede requerir que la base de datos se divida o que se agreguen herramientas de almacenamiento de datos adicionales para respaldar las necesidades de los datos de los microservicios.

La refactorización de un esquema de base de datos monolítico puede ser una operación delicada. Es importante determinar con claridad qué conjuntos de datos necesita cada servicio y las superposiciones. Esta planificación de esquemas se puede realizar mediante contextos delimitados, que son un patrón de diseño por dominio. Un contexto delimitado define un sistema autónomo, que incluye lo que puede entrar al sistema o salir de él.

En este sistema, cuando un usuario accede a un pedido, puedes ver la información del cliente en la tabla, y la misma tabla puede servir también para rellenar la factura gestionada por el sistema de facturación. Esto parece lógico y sencillo pero, con los microservicios, querrás que los servicios se desacoplen para que sea posible acceder a las facturas, aunque el sistema de pedidos se haya caído. Además, esto permite optimizar o perfeccionar la tabla de facturas independientemente de las demás. De esta forma, cada servicio puede terminar teniendo su propio almacén de datos para mantener los datos que necesita.

También presenta nuevos problemas, ya que acabarás con algunos datos duplicados en diferentes bases de datos. Los contextos delimitados pueden determinar la mejor estrategia para gestionar datos duplicados o compartidos. Puedes adoptar una arquitectura orientada a eventos para ayudar a sincronizar datos en varios servicios. Por ejemplo, es posible que tus servicios de facturación y seguimiento de entregas estén escuchando eventos emitidos por los servicios de cuentas cuando un cliente actualiza su información personal. Tras recibir el evento, estos servicios actualizarán su almacén de datos de forma pertinente. Esta arquitectura orientada a eventos facilita la lógica del servicio de la cuenta, ya que no tiene que conocer los demás servicios dependientes. Simplemente le dice al sistema lo que ha hecho y otros servicios escuchan y actúan en consecuencia.

También puedes conservar toda la información del cliente en el servicio de la cuenta y mantener únicamente una referencia de clave externa en tu servicio de facturación y entrega. Luego, los servicios interactúan con el servicio de la cuenta para obtener los datos pertinentes del cliente cuando fuera necesario, en lugar de duplicar los registros existentes. No hay soluciones universales para estos problemas y tendrás que analizar cada caso concreto para determinar cuál es el mejor enfoque.

Compila tu arquitectura de microservicios en caso de fallos

Ya hemos visto las grandes ventajas que pueden ofrecerte los microservicios sobre una arquitectura monolítica. Son de tamaño más pequeño y están especializados, de modo que son fáciles de entender. Están desacoplados, lo que significa que puedes refactorizar un servicio sin temer estropear los demás componentes del sistema, o bien ralentizar el desarrollo de los otros equipos. Asimismo, ofrecen más flexibilidad a tus desarrolladores, ya que pueden elegir diferentes tecnologías si es necesario sin verse limitados por las necesidades de los otros servicios.

En resumen, contar con una arquitectura de microservicios facilita el desarrollo y el mantenimiento de cada capacidad empresarial. Pero las cosas se vuelven más complicadas cuando nos fijamos en todos los servicios en conjunto y en cómo deben interactuar para realizar acciones. Tu sistema ahora está distribuido y cuenta con varios puntos de error, por lo que debes hacerte cargo de todo eso. Debes tener en cuenta no solo los casos en los que un servicio no responde, sino también la capacidad de lidiar con respuestas de red más lentas. A veces, recuperarse de un error también puede resultar complicado, ya que debes asegurarte de que los servicios que vuelvan a estar disponibles no se inunden de mensajes pendientes.

Cuando empieces a extraer capacidades de tus sistemas monolíticos, asegúrate de que tus diseños están preparados para evitar los errores desde el principio.

Haz hincapié en la supervisión para facilitar las pruebas de microservicios

Las pruebas son otro inconveniente de los microservicios en comparación con un sistema monolítico. Una aplicación compilada como una sola base de código no necesita mucho para tener un entorno de pruebas en marcha. En la mayoría de los casos, tendrás que iniciar un servidor de backend acoplado con una base de datos para poder ejecutar tu conjunto de pruebas.

En el mundo de los microservicios, las cosas no son tan fáciles. Cuando se trata de pruebas unitarias, seguirá siendo bastante similar al enfoque monolítico y no deberías tener más dificultades a ese nivel. Sin embargo, en lo que respecta a la integración y las pruebas del sistema, las cosas se ponen mucho más difíciles. Es posible que tengas que iniciar varios servicios a la vez y poner en marcha diferentes almacenes de datos, y que tu configuración deba incluir colas de mensajes que no necesitabas con el monolito. En este caso, resulta mucho más costoso realizar pruebas funcionales y el cada vez mayor número de elementos móviles complica mucho la predicción de los diferentes tipos de errores que se pueden producir.

La supervisión permite identificar pronto las incidencias y reaccionar en consecuencia. Tienes que entender los puntos de referencia de tus diferentes servicios y saber reaccionar no solo cuando dejen de estar operativos, sino también cuando se comporten de manera inesperada. Una ventaja de adoptar una arquitectura de microservicios es que tu sistema debe ser resistente a errores parciales, por lo que, si empiezas a ver anomalías en el servicio de seguimiento de entregas de nuestra aplicación Pizzup, no será tan malo como si se tratara de un sistema monolítico. Nuestra aplicación debe diseñarse para que todos los demás servicios respondan correctamente y dejar que nuestros clientes pidan pizza mientras restauramos el seguimiento en vivo.

Adopta la entrega continua para reducir la fricción de las implementaciones

La publicación manual de un sistema monolítico en la producción es una tarea tediosa y arriesgada, pero no imposible. Por supuesto, no recomendamos este enfoque y animamos a todos los equipos de software a adoptar la entrega continua para todo tipo de desarrollo; sin embargo, al comienzo de un proyecto, podrías encargarte tú mismo de las primeras implementaciones a través de la línea de comandos.

Este enfoque no resulta sostenible cuando se tiene un número cada vez mayor de servicios que se deben implementar varias veces al día. Por lo tanto, como parte de la transición a los microservicios, es muy importante que adoptes la entrega continua para reducir el riesgo de fallos de publicación, así como asegurarte de que tu equipo se centra en la compilación y ejecución de la aplicación, en lugar de quedarse atascado en la implementación. Poner en práctica la entrega continua también significará que tu servicio ha aprobado las pruebas de aceptación antes de la producción. Por supuesto, se producirán errores, pero, con el tiempo, crearás un sólido conjunto de pruebas que aumentará la seguridad de tu equipo con respecto a la calidad de las publicaciones.