Por qué debería utilizar una arquitectura de microservicios

Imagine que tiene una gran aplicación y muchos clientes que hacen buen uso de las muchas funcionalidades y capacidades de esta. Dispone de un gran catálogo de productos, con una enorme tienda muy rica en prestaciones... Le va bien, pero... tiene problemas. Su aplicación se bloquea con demasiada frecuencia. Sus desarrolladores siempre están trabajando en ello cuando falla y son muy rápidos en arreglar el site, pero esto conlleva tiempo y energía. Al menos se cae una vez al mes y puede estar fuera de servicio durante horas. La pérdida de negocio es importante.

A sus desarrolladores les gustaría arreglar el problema y realizar muchos proyectos. No paran de hablar de nuevas y fantásticas funcionalidades que les gustaría implementar, pero no pueden hacerlo. Están demasiado centrados en corregir los errores y en extinguir ‘incendios’.

Han hablado de fichar a más personal, pero su presupuesto no lo permite. Además, en su empresa contratan constantemente para sustituir a las personas que se van: unos a una empresa tecnológica más grande, otros porque se han cansado de atender demasiadas urgencias nocturnas... Los problemas tecnológicos le agobian. También a su equipo. No ve ninguna salida. Usted y su empresa están atrapados.

Ha caído en la misma trampa de muchas empresas de software —y muchos departamentos de TI de empresas que no son de software—, que han creado aplicaciones grandes y monolíticas que parecen gestionarlo todo. Unas aplicaciones que se han vuelto tan grandes y tan complicadas que ahora son difíciles de manejar. Ninguna persona puede entender todo lo que ocurre en la aplicación.

Las cosas se rompen y tardan una eternidad en arreglarse. Intenta añadir funcionalidades nuevas o mejoradas, pero los cambios están tan conectados que no se pueden aplicar con rapidez y, cuando se terminan, hay miles de errores. Su ritmo de desarrollo es lento, cada vez más. Intenta incorporar más desarrolladores, pero no parece que estos hagan que las cosas vayan más rápido. Y la curva de aprendizaje es muy elevada para los nuevos desarrolladores. Está atascado en el fango. No obstante, esto es evitable: puede rediseñar su aplicación para que escale con su empresa, no contra ella.

La aplicación en crecimiento

Empezó bien con una aplicación sencilla, escrita y gestionada por una sola persona o un pequeño equipo de desarrollo o dos. Su aplicación se parece a la figura 1, bonita y sencilla.

Figura 1. Una aplicación sencilla pero que crece.

Pero el tiempo pasa, la aplicación crece. Su aplicación es un éxito y el tráfico aumenta de forma espectacular. Se añaden nuevas funciones y capacidades, y se contratan más desarrolladores para trabajar en la aplicación. Pronto, se parece a la Figura 2.

Figura 2. Una aplicación compleja y estancada. 

Ahora tiene problemas. Nadie sabe qué partes de la aplicación le pertenecen. El equipo 1 hace un cambio y eso afecta al equipo 3. Las tensiones son altas, la productividad es baja. Los errores se cuelan en la aplicación y su sitio web comienza a fallar, aparentemente al azar. Y cuando hay un fallo, sus equipos luchan por averiguar qué es lo que falla, porque ninguna persona puede entender todo lo que está pasando en la aplicación. Este es un ejemplo perfecto de desorden.

Sus equipos de desarrollo independientes no son realmente independientes, porque los cambios que hace un equipo tienen un gran impacto en lo que están trabajando los otros equipos. No se puede trabajar en proyectos independientes, porque todos los proyectos están entrelazados. La innovación se ve ahogada, al igual que su negocio.

El valor de los microservicios

Ahora eche un vistazo a la Figura 3.

Figura 3. Una aplicación de microservicios.

Aquí, cada servicio es independiente y está aislado de todos los demás. Cada servicio es más pequeño, pero hay más. Cada uno tiene una interfaz bien definida entre ellos, y cada uno representa una pieza de lógica de negocio bien definida.

Y lo que es más importante, cada servicio tiene un único propietario. Un equipo de desarrollo es responsable de todos los aspectos de cada servicio individual. La aplicación es más limpia, lo que hace que la propiedad y las responsabilidades sean más claras.

En resumen, su aplicación ha escalado. No se ha ampliado en el sentido del número de clientes a los que puede dar soporte, sino en el número de desarrolladores independientes, proyectos e iniciativas que mantiene para dar soporte a su negocio en crecimiento. Sus equipos de desarrollo no se pisan unos a otros y son más productivos porque hay menos desorden. Están más contentos y es más probable que permanezcan en la empresa durante más tiempo.

Además, se puede aumentar el número de equipos de desarrollo, y por tanto el número de desarrolladores, simplemente reequilibrando las responsabilidades de propiedad. Un mayor número de desarrolladores es más productivo, y usted puede progresar mejor en esos proyectos empresariales tan importantes que son críticos para su negocio en crecimiento.

Y si se produce un problema, al analizar la interacción entre los servicios se puede determinar mucho más fácilmente dónde se origina el problema y qué equipo debe solucionarlo. Además, cada equipo tiene un conjunto de responsabilidades mucho más reducido y, por tanto, un mayor conocimiento sobre el funcionamiento de los servicios de los que son responsables, por lo que pueden solucionar los problemas con mucha más rapidez y eficacia. Y como conocen mejor las áreas de las que son responsables, es menos probable que introduzcan errores en el sistema.

Los microservicios le ayudan a escalar

Las arquitecturas de microservicios le ayudan a escalar en muchas dimensiones:

Tráfico y clientes

Los microservicios le permiten dar soporte a más clientes con más tráfico y más datos.

Número de desarrolladores y equipos de desarrollo

Los microservicios le permiten añadir más equipos de desarrollo y, por tanto, más desarrolladores a su aplicación. Los desarrolladores son más productivos, porque no se pisan los unos a los otros tanto como en un proceso de desarrollo monolítico.

Complejidad y capacidades

Los equipos tienen menos "superficie" de aplicación en la que pensar, lo que les permite trabajar en problemas más complejos dentro de su dominio. Con más equipos trabajando en más dominios de problemas, son posibles proyectos más complejos.

Arquitectura de servicios orientada a un solo equipo (STOSA)

No basta con pasar su aplicación a una arquitectura basada en microservicios. Todavía es posible tener una arquitectura basada en microservicios, pero hacer que sus equipos de desarrollo trabajen en proyectos que abarcan servicios y crean interacciones complejas entre sus equipos. En resumen: todavía puede estar metido en el fango del desarrollo, incluso si pasa a una arquitectura basada en microservicios.

Para evitar estos problemas, debe tener un modelo de propiedad y responsabilidad de servicios limpio. Todos y cada uno de los servicios necesitan un propietario único, claro y bien definido que sea totalmente responsable del servicio, y el trabajo debe gestionarse y delegarse a nivel de servicio. Sugiero un modelo como la Arquitectura de Servicios Orientada a un Solo Equipo (STOSA). Este modelo, del que hablo en mi libro Architecting for Scale, proporciona la claridad que permite a su aplicación —y a sus equipos de desarrollo— escalar para adaptarse a sus necesidades empresariales.

El coste de los microservicios

Las arquitecturas de microservicios tienen un coste. Mientras que los servicios individuales son más fáciles de entender y gestionar, una aplicación de microservicios en su conjunto tiene muchas más partes móviles y se convierte en un monstruo más complejo. Esto puede añadir complejidad a la aplicación y llevar a los problemas que esta conlleva en otros aspectos, cuestiones que no deben ser ignoradas.

Además, muchas empresas atascadas en el fango (como se muestra en la figura 2) comenzarán un proyecto para migrar a una arquitectura de microservicios (como se muestra en la figura 3). Sin embargo, a menudo encontrarán que la transición es más difícil y más cara de lo que esperaban o preveían. Y así, a mitad de camino de la migración, abandonan el esfuerzo. La migración es parcial y a menudo se encuentra en peor estado que cuando empezó.

Antes de emprender una migración a una arquitectura de microservicios, es preciso que entienda bien los costes, los beneficios y los retos que le esperan. Debe tener las expectativas adecuadas para que la transición —y su aplicación en el futuro— sea un éxito.