Monta un microservicio en un patinete y ¡Dale al play!
Si el título del post te ha generado la suficiente curiosidad como para estar leyendo estas líneas… ¡primer objetivo cumplido! El segundo es que leas hasta la última que además viene con sorpresa. 😉
En uno de nuestros anteriores posts, ahondábamos en la diferencia entre ejecutar proyectos o desarrollar productos (el “tú cueces o enriqueces”) y la diferencia de mentalidad que marcan ambos enfoques.
En esta ocasión le meteremos un poco de thinking al desarrollo de productos complejos y a uno de los enfoques más extendidos: los microservicios. ¿Cuáles son las ventajas de la arquitectura de microservicios y qué debes tener en cuenta a la hora de trabajar con un nuevo microservicio? Te lo contamos.
¿Qué son los microservicios?
De manera contraria a arquitecturas monolíticas donde la solución reside en una sola aplicación, el paradigma de una arquitectura de microservicios se basa en dividir la solución en “pequeños servicios” cada uno de los cuales se encarga de resolver una funcionalidad concreta. Cada uno de estos servicios se ejecuta, se desarrolla y se gestiona de manera autónoma, siendo clave la gestión de la comunicación entre ellos.
¿Qué beneficios tiene una arquitectura de microservicios desde el punto de vista de negocio?
Desde el punto de vista de negocio, la arquitectura de microservicios tiene grandes beneficios como pueden ser:
- Facilita la diversificación de las fuentes de ingresos. Podemos fijarnos en Google Maps y la cantidad de servicios monetizables que ha podido construir en torno a su aplicación de mapas.
- Es más fácil de escalar y customizar. Y no hablamos solo desde el punto de vista de la tecnología. Afrontar un evento como puede ser un Black Friday exige un nivel de escalabilidad y de configuración que difícilmente se puede alcanzar con una arquitectura monolítica.
- Facilita la migración progresiva desde un sistema legacy evitando un big bang en caso de migrar entre dos sistemas monolíticos. Si alguna vez habéis migrado entre Magento 1 y Magento 2 o entre dos soluciones comerciales diferentes de ecommerce, sabéis de lo que hablamos.
- Facilita la extracción de métricas por áreas, funcionalidades, unidades de negocio… Es más fácil medir el número de usos, patrones de comportamientos, la monetización de cada microservicio… lo cual permite tomar decisiones en base a datos y no a suposiciones o al cada vez más denostado “criterio de experto”.
¿Qué ventajas tiene una arquitectura de microservicios desde el punto de vista de la tecnología y la gestión?
Desde el punto de vista tecnológico y de gestión, una orientación a microservicios tiene múltiples beneficios entre los que cabe destacar:
- Modularización: frente a un enfoque monolítico que escala hasta cierto punto.
- Implementar de manera más natural metodologías ágiles de gestión, como puede ser Scrum: como resultado de una modularización es más fácil ordenar los equipos en squads o Scrum Teams y trabajar de una manera más ágil.
- Enfocar el desarrollo de cada microservicio con un enfoque de producto, lo cual acaba redundando en una mayor calidad de lo implementado, pudiendo satisfacer de mejor manera las necesidades de negocio.
- Desarrollar flujos avanzados a partir de la combinación de diferentes microservicios: la orientación a microservicios permite la combinación de productos para crear un valor añadido diferente. Aunque son servicios diferentes, Glovo usa Google Maps para que en todo momento el usuario sepa dónde está su rider. Google Maps fue creado mucho antes que Glovo, pero ha permitido que el desarrollo de esta funcionalidad sea más sencilla y con más valor para el usuario.
- Crear flujos de DevOps totalmente automatizados, autónomos y atomizados: una aplicación monólitca requiere el despliegue completo de la aplicación, mientras que una orientación a microservicios permite despliegues independientes.
Los microservicios, los patinetes y la música
Pero recapitulemos… si habéis llegado hasta aquí guiados por la curiosidad del título, os seguiréis preguntando: ¿Qué demonios tiene que ver un patinete, un microservicio y una canción? Y no es que un skate y un microservicio tengan en común el año de su invención. El monopatín surgió en los años 60 y el término microservicio fue usado por primera vez por Peter Rodgers en el 2005 en una conferencia del Web Services Edge. No tienen en común para nada su creador, su concepción… y dudamos mucho que Tony Hawk haya diseñado, definido o desarrollado alguna vez un microservicio. Aunque la verdad que el Tony Hawk es probablemente el videojuego con mejor banda sonora de la historia.
La relación entre un patinete y un microservicio es… ¡Spotify!
Spotify: cómo desarrollar productos haciendo patinetes
Spotify es una de las empresas que han sido referentes por su filosofía en el desarrollo de productos y su clara orientación a microservicios. Su whitepaper sobre su framework de agile se ha vuelto referencia en los últimos años. Y una de las maneras en las que Spotify explica la forma con la que afrontan el desarrollo de un producto es que siempre empiezan “haciendo patinetes”. ¿Cómo os quedáis?
El racional detrás de todo esto es que si quieres construir algo perfecto, llevará mucho tiempo de análisis, diseño, construcción…tiempo en el que no estás aportando ningún valor para tus usuarios, ni estás pudiendo medir ni sacar ningún aprendizaje del uso que los usuarios hacen de tu producto o tu nueva funcionalidad. Y quién mejor va a poder definir qué necesita tu aplicación que tus usuarios (aunque Steve Jobs no estaría muy de acuerdo con esto…).
En lugar de este enfoque, Spotify promueve la filosofía de centrarse en algo que se pueda implementar de manera rápida y que provea la oportunidad de tener un feedback real. Al inicio de cada nueva iniciativa se hacen la misma pregunta: “¿cuál es nuestro patinete?”
Producto mínimo viable (MVP) vs. Minimum Loveable Product (MLP)
Esta filosofía va muy ligada a la de tener un producto mínimo viable (o MVP en sus siglas en inglés de Minimum Viable Product). El problema es que un MVP muchas veces no satisface las necesidades de manera completa. En ocasiones el MVP se convierte en una “muletilla” usada en gestión cuando no se va a llegar a cubrir el 100% de la funcionalidad. Un MVP muchas veces es el nuevo “esto lo abordaremos en la fase 2”. Y por eso también desde Spotify han potenciado el uso de lo que se conoce como Minimum Loveable Product o MLP (concepto inicialmente planteado por Brian de Haaff en 2013, y que luego amplió Laurence McCahill a finales de 2014 en una charla del UX Café de Londres)
El concepto de MLP surge para evitar que el objetivo de sacar algo rápido y medir el uso para mejorar, impida desarrollar algo que los usuarios puedan “amar” (la verdad que el término anglosajón loveable suena mejor que su equivalente en español). Es decir, no podemos dejar de un lado la calidad de lo que entregamos a nuestros usuarios.
Como siempre sucede en términos de gestión, es necesario llegar a una solución de compromiso entre velocidad y calidad. Pero siempre tenemos que tener en cuenta que lo que se ponga en manos de un usuario debería ser algo de lo que el equipo involucrado se sienta orgulloso. Podrá ser mejorado con nuevas funcionalidades, pero está bien diseñado, bien definido y bien desarrollado. Es loveable.
¿Qué tengo que recordar a la hora de trabajar sobre un nuevo microservicio?
A la hora de definir, diseñar e implementar un nuevo microservicio os recomendamos interiorizar estos pasos:
- Preguntaros siempre “¿cuál es nuestro patinete?”.
- Aseguraos de que es “un patinete super chulo” y del que os podáis sentir orgullosos. No debemos comprometer la calidad a cambio de la velocidad.
- Tened siempre presente las métricas que queréis obtener para recabar el feedback necesario que os ayude a mejorar el producto.
- Poneros la banda sonora del Tony Hawk y dadle caña!
