[18/11/2021] Su aplicación es grande. Tiene muchos clientes que aprovechan la variedad de funciones y capacidades. Cuenta con un catálogo extenso de productos y su tienda ofrece muchas funcionalidades. Le va bien.
Excepto que está teniendo problemas.
Su aplicación se bloquea con demasiada frecuencia. Sus desarrolladores siempre están al tanto cuando falla, y son muy rápidos en arreglar su sitio, pero requiere tiempo y energía. Se cae al menos una vez al mes, y puede estar fuera de servicio durante horas. Imagínese el negocio perdido.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
A sus desarrolladores les gustaría solucionar el problema; les gustaría hacer muchas cosas. No dejan de hablar de estas fantásticas funciones nuevas que les gustaría implementar, pero simplemente no pueden hacerlo. Están demasiado concentrados en corregir errores y apagar incendios.
Ha pensado en contratar a más personas, pero su presupuesto no lo permite. Además, contrata constantemente para reemplazar a las personas que se van. Judy se fue a una empresa de tecnología más grande. Joe se fue porque se cansó de manejar demasiadas emergencias nocturnas.
Los problemas tecnológicos lo agobian y agobian a su equipo. No ve ninguna salida. Usted y su empresa están atrapados.
Ha caído en la trampa en la que han caído muchas empresas de software y departamentos de TI de empresas que no son de software. Han creado aplicaciones grandes y monolíticas que parecen controlarlo todo. Pero estas se han vuelto tan extensas y complicadas que resultan difíciles de manejar. Nadie puede llegar a entender todo lo que ocurre en la aplicación.
Las cosas se rompen y tardan una eternidad en arreglarse. Usted intenta añadir capacidades nuevas o mejoradas, pero los cambios están tan entrelazados que no puede hacerlos rápidamente, y cuando se completan, terminan llenos de errores. Su ritmo de desarrollo es lento y cada vez más. Intenta agregar más desarrolladores, pero esa no parece ser la solución para que las cosas vayan más rápido. La curva de aprendizaje para los nuevos desarrolladores es increíblemente empinada.
Está atrapado en el barro.
El barro no es inevitable. Puede rediseñar su aplicación para que escale con su empresa, no en contra de ella.
La aplicación en crecimiento
Todo comenzó bien con una aplicación simple, escrita y administrada por una sola persona o un pequeño equipo de desarrollo. Su aplicación se parece a la Figura 1, agradable y simple.
Figura 1. Una aplicación simple, pero en crecimiento.
Pasa el tiempo y la aplicación crece. Es un éxito y el tráfico aumenta drásticamente. Agrega nuevas funciones y capacidades, y contrata a más desarrolladores para que trabajen en la aplicación. Pronto, se empieza a parecer a la Figura 2.
Figura 2. Una aplicación compleja y estancada.
Ahora tiene problemas. Nadie sabe de qué partes de la aplicación está a cargo. El equipo 1 hace un cambio y afecta al equipo 3. Las tensiones incrementan y la productividad disminuye. Los errores se cuelan dentro de la aplicación y el sitio comienza a fallar, aparentemente al azar. Cuando se produce una falla, los equipos luchan por descubrir qué está mal, porque ninguna persona puede entender realmente todo lo que sucede en la aplicación. Este es un excelente ejemplo de barro.
Sus equipos de desarrollo independientes no son realmente independientes, porque los cambios que realiza un equipo tienen un gran impacto en lo que están trabajando los otros equipos. No puede trabajar en proyectos independientes, porque todos los proyectos están entrelazados. La innovación está reprimida, 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. Los servicios son más pequeños, pero hay más cantidad. Cada uno tiene una interfaz que lo diferencia de los otros y representa una parte de la lógica empresarial bien definida.
Y lo más importante es que cada servicio tiene un único propietario. Todos los aspectos de un servicio individual son responsabilidad de un solo equipo de desarrollo.
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 en el sentido de la cantidad de clientes a los que puede dar soporte, sino que ha escalado en el sentido de la cantidad de desarrolladores, proyectos e iniciativas independientes que mantiene para respaldar su negocio en crecimiento.
Sus equipos de desarrollo no se pisotean unos a otros y son más productivos porque hay menos estorbos. Están más contentos y es probable que permanezcan más tiempo en la empresa.
Además, puede aumentar el número de equipos de desarrollo, y por lo tanto el número de desarrolladores, simplemente reequilibrando las responsabilidades de propiedad. Un mayor número de desarrolladores significa más productividad, y de esta manera puede progresar en esos proyectos empresariales importantes que son críticos para su negocio en crecimiento.
Si ocurre un problema, al analizar la interacción entre los servicios se puede determinar mucho más fácilmente dónde se origina y qué equipo debe solucionarlo. Además, cada equipo tiene un conjunto de responsabilidades más pequeño y, por tanto, un mayor conocimiento sobre cómo funcionan los servicios de los que son responsables, así que pueden solucionar problemas mucho más rápida y eficazmente. Y debido a que comprenden mejor las áreas bajo su responsabilidad, 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 brindar soporte a más clientes con más tráfico y datos.
- Número de desarrolladores y equipos de desarrollo. Los microservicios le permiten agregar más equipos de desarrollo y, por lo tanto, más desarrolladores a su aplicación. Los desarrolladores son más productivos porque no se pisan tanto los unos a los otros como en un proceso de desarrollo monolítico.
- Complejidad y capacidades. Los equipos tienen menos "área de superficie” de aplicación en la que pensar, lo que les permite trabajar en problemas más complejos dentro de su dominio. Si se tiene a más equipos trabajando en un número mayor de dominios de problemas, es posible abordar proyectos más complejos.
Arquitectura de servicios orientada a un solo equipo (STOSA)
No basta con trasladar su aplicación a una arquitectura basada en microservicios. 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 pocas palabras: puede encontrarse atascado en el barro del desarrollo, incluso si se traslada a una arquitectura basada en microservicios.
Para evitar estos problemas es importante tener un modelo limpio de responsabilidad y propiedad de servicios. Cada uno de los servicios necesita un propietario único, claro y bien definido que asuma la responsabilidad completa, 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 escalar su aplicación y sus equipos de desarrollo para satisfacer las necesidades del negocio.
El costo de los microservicios
Las arquitecturas de microservicios tienen un costo. Si bien los servicios individuales son más fáciles de entender y gestionar, una aplicación de microservicios en conjunto tiene muchas más partes móviles y eso la vuelve más compleja por sí misma. Esta complejidad en la aplicación puede traer problemas en otros aspectos, y esto no debe ser ignorado.
Además, muchas empresas atascadas en el barro (como se muestra en la Figura 2) comienzan un proyecto para migrar a una arquitectura de microservicios (como se muestra en la Figura 3). Sin embargo, a menudo encuentran que la transición es más difícil y cara de lo que esperaban o anticipaban. Y así, a mitad del proceso, abandonan el esfuerzo. Han migrado parcialmente y, muchas veces esto las deja en una situación peor que cuando comenzaron.
Antes de emprender la migración hacia una arquitectura de microservicios, asegúrese de comprender los costos, beneficios y desafíos futuros. Es fundamental establecer las expectativas adecuadas para que la transición -y su aplicación en el futuro- sea un éxito.
Basado en el artículo de Lee Atchison (InfoWorld) y editado por CIO Perú
Lee Atchison es un reconocido líder de opinión en cloud computing y modernización de aplicaciones. Con más de tres décadas de experiencia en desarrollo, arquitectura, escalado y modernización de productos, Lee ha trabajado en Amazon, Amazon Web Services (AWS), New Relic y otras organizaciones de aplicaciones modernas. Es ampliamente citado en muchas publicaciones y ha sido un orador destacado en todo el mundo. El libro más reciente de Lee se llama Architecting for Scale (O'Reilly Media).
Puede ver también: