Si has leído algún artículo mío sobre microservicios te debes estar preguntando si después de cinco años — ahora que hay un microservicio para todo — he cambiado de ideas. Verás que no necesariamente, y que sigo pensando que los diferentes estilos y las diferentes arquitecturas de desarrollo de software tienen sentido según las diferentes necesidades del proyecto, producto, servicio, u organización.
Por cierto, ¡te recomiendo leer el artículo de Sergio sobre microservicios!
Sin embargo, y por amor a la democracia, he ido por red en busca de “detractores de microservicios”, o reflexiones filosóficas sobre por qué no siempre son la mejor práctica. He encontrado algunas reflexiones interesantes que quiero compartir contigo hoy.
¿Cuál es el problema?
Ahora que todos estamos MUY entusiasmados con Docker y Kubernetes, me ha llamado la atención las reflexiones de David Heinemeier Hansson y Kelsey Hightower, sobre si “los microservicios han venido a simplificar la vida de los programadores, o a crear sistemas más complejos que los llamados monolíticos por los entusiastas de microservicios?”
El problema es que los microservicios nos llevaron a pensar que tener nuestra APP divida en muchas otras APPs más pequeñas, simplificaría todo el proceso. — ¿Lo ha simplificado?
Procesos
Además, para que funcione “correctamente” todo el proceso, es necesario aplicar microservicios con responsabilidad y con la “disciplina tan característica de los equipos” de IT ;). Esto lleva inmediatamente a la conclusión que los microservicios pueden enfrentar los mismos problemas de enfoque, y diseño que las arquitecturas “monolíticas”, por los mismos temas de siempre: “un commit a la vez, cincuenta veces…” — Kelsey lo llama el “monolítico distribuido” -, “deadlines ajustados”, o la falta de preparación para esta “nueva” arquitectura.
Por tanto, los problemas que se están intentando solucionar con los microservicios no acaban de ser realistas, y es muy fácil “navegar” en procesos “de código mal escrito a infraestructuras mal desarrolladas”.
Código Heredado
Otro de los problemas con los microservicios también surge cuando se quiere simplemente añadir, o usar código heredadoen arquitecturas de microservicios, y esperar que todo funcione correctamente, mientras el monstruo microserviciotambién está creciendo rápidamente a…¿monolítico? Esto pasa incluso en sistemas o arquitecturas modulares, o basadas en componentes.
Docker, Kubernetes & SaaS
Como bien sabes, un entorno de microservicios también tiene que saber lidiar con temas relacionados con la latencia, la seguridad y todo el tema de métricas, análisis de datos y de sistemas, pues los datos pueden acabar distribuidos en diferentes entornos y sistemas (Docker, Kubernetes — con más gastos, más inversión, nuevos empleados -, SaaS, etc..).
¿Cual es la solución?
Cómo desarrollador, he considerado que TDD a pesar de su potencial tiene un u otro problema,y también estoy de acuerdo con David cuando dice que los microservicios como arquitectura pueden ser la solución “perfecta para perdonar nuestros pecados”, pero me parece aún más interesante su propuesta de contrargumento que dice que si los “sistemas integrados son buenos”, entonces los “desarrolladores integrados” también.
¿Desarrolladores integrados?
Sí, se trata de desarrolladores capaces de pensar toda la aplicación, y de desarrollar todas las características de la aplicación. El objetivo es tener un proceso y equipos sanos en el que la “especialización y la compartimentación”características de los microservicios no pasen factura posteriormente. Con este enfoque, tienes a desarrolladores preparados para cualquier situación.
Compresión conceptual
Además, si crees que tu aplicación es demasiado compleja para el cerebro de tus desarrolladores, David también propone una solución, o varias: “trabajar en compresión conceptual, buena escritura de código, un entorno productivo, usar patrones”.
Obviamente que este enfoque requiere más trabajo, pero los resultados pueden ser positivos y, según David, “trabajar en un sistema integrado conjuntamente con programadores integrados” proporciona “posibilidades ilimitadas” y si existen límites, estos “no son arbitrarios” — ¿qué te parece?. El objetivo es fusionar frontend y backend en la misma mente, y aprovechar los fundamentos de la web, que parecen seguir siendo los mismos, a pesar de la evolución técnica que experimentamos cada día.
Conclusión
Entonces, ¿las aplicaciones monolíticas son el futuro? Me cuesta pensar que lo sean, sobretodo por cómo está evolucionando el trabajo, y por la adopción de ciertas tecnologías.
Pero creo que pensar en desarrollar aplicaciones usando microservicios sin tener un equipo grande detrás — es muy probable que no seas el próximo Google -, donde se defina correctamente quien “es el owner de qué”, el caos es una cuestión de tiempo.
Si no, piensa en aquella APP que empezaste desarrollando gracias a múltiples microservicios (con múltiples lenguajes, proveedores, frameworks, enfoques, documentaciones) que se hizo demasiado compleja, con problemas de rendimiento, pobre experiencia digital, y que no has podido enviar a la store.
Por todo eso, creo que es importante unirnos a la reflexión de David y Kelsey, y preguntarnos si los “microservicios son realmente una buena práctica” para nuestra organización, si no somos un banco que tiene una aplicación monolítica y necesita desarrollar una aplicación para el móvil.
Porque al final del día, como desarrolladores, estamos llamados a resolver problemas, no a hacer de las modas un problema más del proceso. ¿No es cierto?
Puedes leer más sobre este debate , y participar en el artículo “Monoliths are the future” de Kelsey Hightower”.
¿Qué experiencia has tenido con los microservicios?
Fuentes:
