Português - Brasil
English
EspañolTres lecciones que aprendí del hype de los microservicios
¿Realmente necesitas microservicios?
Monolith First
La primera fecha fue el 3 de junio de 2015, cuando Martin Fowler escribió el artículo “MonolithFirst”, en el que aconsejaba iniciar siempre una nueva solución con un monolito, organizarlo en módulos y dividirlo en microservicios solo cuando se convirtiera en un problema. Esto reduce el costo de desarrollo y el tiempo de las liberaciones y, al final, tenemos una solución más simple, ya que no necesitamos lidiar con los desafíos de una arquitectura distribuida.
Don´t start with a monolith
La segunda fecha fue poco menos de una semana después: el 9 de junio de 2015, Stefan Tilkov contraargumentó, en su artículo “Don’t start with a monolith”, que es muy difícil mantener los módulos tan bien aislados unos de otros como lo requiere una arquitectura de microservicios. Cuando empiezas con una arquitectura de microservicios, te ves obligado, de forma natural, a desarrollar servicios bien desacoplados.
It all depends
La tercera fecha fue a mediados de 2016–2017, cuando recibí la solicitud de un proyecto que era básicamente un blog de contenido que el cliente quería que se desarrollara con arquitectura de microservicios.
Tiempo después, hice una consultoría para una empresa del sector industrial, en la que evalué la arquitectura de software de un sistema que controlaba UNA máquina y que se había construido con 28 microservicios.
También vi soluciones que podían resolverse fácilmente con un worker trabajando en background y escalado horizontal convertirse en 23 complejos desplegables.
3 lecciones
En particular, me gusta mucho la definición de microservicios de Amazon:
La mayoría de las veces que los desarrolladores discutimos temas de nuestra área, tenemos la costumbre de ver solo la parte técnica. En serio, es ESPECTACULAR ver una estructura de microservicios funcionando perfectamente. Ese montón de componentes comunicándose con solicitudes para aquí y para allá, mensajería, procesos asíncronos. ¡Es buenísimo! ¡Admítelo!
Pero ¿notaron un detalle muy importante en la definición de Amazon? La adopción de una arquitectura de microservicios no empieza en la parte técnica, sino en la estructura ORGANIZACIONAL del desarrollo de software. Un microservicio es un software INDEPENDIENTE que pertenece a UN EQUIPO.
En primer lugar, la Ley de Conway.
Esto nos lleva a la primera gran lección, la Ley de Conway:
- Las organizaciones que diseñan sistemas están obligadas a producir diseños que son copias de las estructuras de comunicación de esas organizaciones.
Interesante, ¿no? E incluso podemos considerar invertirla:
- Las organizaciones que diseñan sistemas están obligadas a estructurar comunicaciones que son copias de los diseños de esos sistemas.
En un sentido o en el otro, al final, la organización de tu empresa y la estructura de tu software deben estar en sintonía para que la comunicación, el desarrollo y la estrategia se construyan de manera adecuada y eficiente.
En segundo lugar, el Scale Cube.
La segunda lección tiene que ver con el principal argumento técnico que escucho para adoptar microservicios: escalar el software. Y me gusta responder a ese argumento con el Scale Cube, que nos presenta 3 maneras de escalar software:
X****Axis
En el eje X tenemos la replicación horizontal. ¿Tu sistema está preparado para escalar horizontalmente? Si creo nuevas instancias e incluyo un Load Balancer adelante, ¿seguirá funcionando? ¿Qué componentes adicionales hay que construir para que esto funcione? Un gran ejemplo de este escenario es Stack Overflow: son 1.3 mil millones de page views por mes con un monolito con escalado horizontal.
Y****Axis
En el eje Y tenemos la descomposición funcional, es decir, macro/microservicios. En este punto empezamos a pensar en la escala no solo del software, sino también en la escala organizacional. La complejidad de implementación aumenta, ya que se necesitan cambios técnicos y organizacionales. Es necesario un entendimiento muy claro de los equipos, sectores y procesos de tu empresa para que todo funcione correctamente.
Z****Axis
En el eje Z vamos a separar cosas similares, es decir, tendremos el sistema ejecutándose con un subconjunto de información. Es una solución más común de lo que imaginamos. Las empresas que implementan su sistema por cliente, por ejemplo, escalan de esta manera.
El Scale Cube nos presenta caminos que pueden usarse por separado o combinados para construir una estrategia sólida de escalado de la aplicación. Pero cualquiera que sea la estrategia, empieza por el negocio.
En tercer lugar, Domain Driven Design.
En tercer lugar, pero no menos importante, me gustaría hablar sobre Domain Driven Design. El término fue acuñado por Eric Evans en 2003.
Implementé mi primer sistema con DDD entre finales de 2014 y principios de 2015. En aquella época, estructuré el sistema con todas las piezas que consideraba importantes: Entities, Repositories, Domain and Applications Services…
La experiencia fue excelente, pero tardé en entender que DDD no se trataba tanto de construir software, sino de entender el negocio. La parte técnica o táctica es muy interesante, pero la parte estratégica es verdaderamente fascinante. ¿Cómo puede entender el negocio marcar tanta diferencia en la construcción de sistemas? Y créeme, LA MARCA.
Para mí, hoy no tiene sentido construir sistemas lejos del negocio. No hay forma de levantar requisitos arquitectónicos de un software sin entender el negocio. Ni siquiera puedo escribir un buen código sin entender el problema que realmente necesita resolver.
Domain Driven Design cambió mi forma de diseñar sistemas. Empecé a diseñar sistemas en una época en la que todo comenzaba por el diseño de la base de datos. Pensábamos primero en los datos para después encajar las funcionalidades en ellos. Hoy empiezo por los PROCESOS. Los datos son consecuencia de los procesos. Con procesos bien diseñados, es más fácil diseñar módulos, microservicios, arquitectura e infraestructura. Y DDD cuenta con diversas herramientas que ayudan en esa construcción, incluida la parte estratégica, los dominios y los procesos del negocio.
Empieza simple, evoluciona según la complejidad
Desarrollar sistemas distribuidos o microservicios aumenta la complejidad. Cuando tienes una estructura organizacional y un sistema gigantescos, tiene sentido dividir esa complejidad en piezas pequeñas que avanzan de forma independiente. Eso realmente acelera el conjunto. Pero cuando tienes un sistema de pequeño o mediano tamaño, en la mayoría de los casos no tiene sentido traer esa complejidad. Evalúa siempre el tamaño de tu organización y las estrategias que se ajustan a tu momento actual.
Con solo empezar a pensar en una arquitectura distribuida, me vienen a la mente:
- ¿Qué servicios voy a necesitar construir? Normalmente empiezo con el de identidad, pero ¿y después?
- ¿Qué componentes adicionales, como el de caching distribuido, voy a necesitar?
- ¿Qué patrones de comunicación voy a usar y cómo tratar la idempotencia y la resiliencia? No solo cómo voy a escalar horizontalmente CADA servicio, sino cómo voy a garantizar su elasticidad.
- ¿El negocio está preparado para volver asíncronos sus procesos? No hay microservicios sin mensajería.
- ¿El negocio está preparado para no tener consistencia de los datos todo el tiempo? Teorema CAP (Consistency, Availability, Partition Tolerance)
- ¿Cómo vamos a implementar transacciones distribuidas? (SAGA/SEC Patterns)
- ¿Qué herramientas voy a necesitar para monitorear todo esto?
- etc., etc…
Me encanta ver discusiones entre posturas opuestas. Es esencial seguir a personas que están dispuestas a debatir. Creo que siempre existen puntos de vista diferentes y, para mí, eso es pensar de manera estratégica. Aprendo mucho en esos momentos porque simplemente necesito pensar y formar mi propia opinión. Mirar el problema que se discute desde ópticas diferentes, analizar y decir un buen y viejo “DEPENDE”.
Bueno, ¿y cuál es mi opinión? ¿Debes usar microservicios o no? Acabo de responder, ¿verdad? ¡DEPENDE!
Es importante analizar caso por caso y evaluar si la solución se ajusta al problema. No es cierto que, si funciona en Netflix, Uber o Twitter, también va a funcionar en tu negocio. Tú no eres uno de ellos. Los problemas son diferentes y necesitan soluciones diferentes.
Rodrigo Hülsenbeck
