Una de las buzzwords del momento es, sin duda, microservicios. De hecho, ya hace tiempo que saltó de los círculos de hyper-cool early adopters al mundo marketiniano, y la cantidad de empresas que intentan venderte algo relacionado con microservicios no para de crecer. Cuando llega este punto, merece la pena pararse un rato a pensar sobre lo que realmente nos aporta una arquitectura basada en microservicios antes de lanzarnos a seguir la moda y utilizarla para desarrollar nuestro próximo proyecto.
El gran Paco Martínez Soria en La ciudad no es para mí de 1966
OJO: Este post está escrito más desde el análisis que desde la experiencia. No he implementado y mantenido un sistema grande basado en microservicios, entre otras cosas porque su propuesta no me ha seducido lo suficente. Digo esto porque me encantaría recibir vuestras opiniones y discutir un rato sobre el tema.
Qué son los microservicios
Suele ser habitual que estos términos de moda se acaben «adaptando» a lo que cada uno quiera vender, por lo que antes de empezar a analizarlos se hace necesario establecer un punto de partida. En mi caso, me gusta bastante la definición de Martin Fowler de una arquitectura basada en microservicios.
Un microservicio es un componente que puede ser desplegado, evolucionado y actualizado de forma independiente. Este componente encapsula la lógica necesaria para cubrir una funcionalidad completa, entendiendo por completa que incluye todas las capas necesarias para implementarla, desde el API hasta el acceso a la base de datos. En general, estas funcionalidades serán bastante pequeñas (de ahí lo de micro), y nuestra arquitectura se basará en tener un montón de componentes como éste comunicándose unos con otros mediante algún protocolo ligero. Lo más habitual es que la comunicación se realice mediante peticiones y respuestas HTTP, o algún bus de mensajes simple.
Visto así, se parece bastante a lo que proponía SOA hace diez años, y lo cierto es que la idea es practicamente la misma, pero cambiando tecnologías (más JSON y menos SOAP) y el tamaño de los servicios.
En ambos casos lo importante es particionar el sistema en componentes que se puedan desplegar de formam independiente, pero en lugar de hacerlo basándose en capas (tiers, no layers), hacerlo basándose en particiones verticales que incluyen todas las capas para implementar una funcionalidad:
Esta es una visión muy simplista de toda la arquitectura, pero nos sirve para empezar a ver pros y contras.
Lo que nos dan los microservicios
Una de las ventajas que más se citan a la hora de vender los microservicios es la escalabilidad. Personalmente, no creo que sea la ventaja principal, pero en los últimos años escalabilidad se ha convertido en una palabra muy buena para vender cosas, y a todo el mundo le gusta pensar que su sistema es muy especial y necesita escalar a millones de peticiones por segundo.
En el caso de los microservicios, al poder distribuir nuestra aplicación en distintos procesos, es posible desplegarlos en máquinas diferentes, consiguiendo una escalabilidad horizontal bastante decente.
Cada microservicio podemos desarrollarlo sobre una plataforma diferente, con un lenguaje diferente, y con las dependencias (por ejemplo, bases de datos) que creamos convenientes. Eso, además de al propio proceso de desarrollo, ayuda a la escalabilidad, porque podemos aprovechar las características de cada plataforma y exprimirlas al máximo en función del rol de cada microservicio.
La independencia a la hora de desarrollarlos es lo que constituye la principal ventaja de los microservicios, al menos desde mi punto de vista.
Por una parte, nos permite, como decíamos antes, elegir la tecnología más apropiada para implementar cada uno, por lo que (se supone) los costes de desarrollo serán menores y el resultado final será mejor.
Además, nos obliga a definir claramente las responsabilidades de cada servicio y el API que expondrá hacia el mundo exterior. Esto ayuda a conseguir una buena cohesión dentro de cada componente manteniendo un bajo acoplamiento en todo el sistema.
Al tratarse de componentes pequeños (recuerda, son microservicios), deberían ser relativamente simples, por lo que es sencillo entenderlos para modificarlos y mantenerlos. Incluso podríamos reescribirlos sin demasiado esfuerzo si fuese necesario.
Por último, es una arquitectura que facilita especialmente el desarrollo en paralelo. Son componentes independientes, por lo que una vez definidas la interfaces entre ellos, podemos tener distintos equipos trabajando en cada microservicio.
Lo que nos cuestan los microservicios
Acabamos de ver suficientes ventajas como para que los microservicios sean una arquitectura a considerar en tu próximo proyecto, pero antes de hacerlo hay que tener en cuenta algunos pequeños detalles.
Todo esto de utilizar servicios autónomos que podemos desarrollar por separado está muy bien pero como ya hemos dicho alguna vez, desarrollar es sólo el principio, y vamos a necesitar tener una estrategia para el despliegue, versionado, actualización, monitorización, etc.
Eso no es una tarea trivial, y más si tenemos en cuenta que una de las ventajas que veíamos antes es que podemos desarrollar cada microservicio con la plataforma y tecnología que más nos guste, por lo que podemos acabar teniendo que gestionar un buen número de elementos distintos a la hora de desplegar y mantener funcionando nuestro sistema.
Para paliar estos problemas tenemos herramientas de automatización de despliegue, máquinas virtuales, contenedores y un montón de nuevas tecnologías que nos pueden ayudar (junto con un equipo de DevOps, otra buzzword que lleva unos años de moda), pero la realidad es que si en lugar de tener que desplegar 34 servicios cada uno con un runtime diferente, tuviésemos una única aplicación monolítica, probablemente no necesitaríamos todo eso y nuestra vida sería más sencilla (al menos en ese sentido).
Este aumento de la complejidad estructural del sistema se refleja en otras áreas. Establecer una buena política de versionado es fundamental y aun así podemos encontrarnos con situaciones un poco incómodas. Cada microservicio puede ser muy simple, fácil de comprender y ser «obviamente» correcto, pero la interrelación entre ellos es mucho más complicada y testear que el funcionamiento es el adecuado entre distintas versiones de los servicios no es fácil.
Es algo similar a lo que ocurre al testear otros sistemas: los componentes son sencillos pero la interacción es compleja, por lo que necesitas aumentar la cantidad de pruebas de integración, que suelen ser las más complicadas de escribir y más costosas de ejecutar.
Independientemente de que despleguemos en máquinas diferentes o no, cada microservicio se ejecuta en su propio proceso, por lo que nuestro sistema será un sistema distribuido. No sé si alguna vez os habéis parado a pensarlo, pero los sistemas distribuidos son complicados.
Por ejemplo, está el pequeño detalle de la transaccionalidad. Cualquier operación que requiera coordinar varios microservicios para completarse está realizando una especie de transacción distribuida entre ellos, y eso no es nada sencillo de gestionar. Aquí empiezas a entrar en un mundo de consistencia eventual entre el estado de distintos microservicios y de acciones compensatorias que, sinceramente, si te lo puedes ahorrar, mejor.
Operaciones que podrían ser dentro de un mismo proceso pasan a requerir una conexión con un proceso externo y además suelen hacerse de forma asíncrona para mantener la escalabilidad del sistema, pero ello implica una pérdida de rendimiento a la hora de atender peticiones indiduales, aparte de que hay momentos en que tratar con esa asincronía puede ser complicado.
Conclusión
Después de analizar lo que me ofrecen y lo que me cuestan los microservicios, mi conclusión es que, a día de hoy, los microservicios no son para mí. Y probablemente para ti tampoco.
Están muy bien si estás trabajando en un proyecto muy grande donde le puedes sacar partido a la capacidad de que varios equipos desarrollen en paralelo muchos microservicios.
Si tienes unos requisitos de escalabilidad enormes, o sea, si eres Netflix, o Twitter, o Facebook, una arquitectura de este tipo puede ser apropiada por las facilidades que ofrece para escalar horizontalmente.
La realidad es que muchos de nosotros no trabajamos en equipos tan grandes ni tenemos unos requisitos de escalabilidad tan elevados como para que compense el precio que hay pagar por usar una arquitectura de moda.
Reconozco que hay una parte que sí me gusta mucho de esta filosofía: lo mucho que favorece la cohesión al encapsular la funcionalidad en componentes bastante independientes. El buscar un particionado más vertical que horizontal me gusta, pero también es cierto que puedes aspirar a ello sin necesidad de utilizar microservicios. No hace falta desplegar en procesos separados para organizar una aplicación alrededor de funcionalidades, y si tienes suficiente disciplina puedes conseguir buenos resultados con alternativas mucho más simples.
Bastante clarificador, cuánto daño hacen las «modas»…
Como a ti, o eso he querido entender, a mí también me gusta la idea que hay detrás, pero me parece un poco, como decirlo, «excesivo» para lo que son nuestros proyectos en el día a día, y un gran punto al que no solemos darle mucha importancia al principio, el tema de las transacciones…
Esto de los microservicios me recuerda al debate «núcleo monolítico vs microkernel».
Stallman comenzó GNU con un «microkernel» y terminó adoptando un núcleo monolítico (Linux) por las enormes dificultades que supone depurar un «microkernel». Sospecho que en este caso va a suceder algo muy parecido. Los desarrolladores tendrán grandes dificultades para identificar el flujo de la información y terminarán por abandonar la arquitectura basada en microservicios.
Quizás estaria bien diseñar la arquitectura de la aplicación para que en en el caso que se necesite en algún momento una arquitectura así pues se podría crear los microservicios con solo trocearla facilmente la aplicación y desmontarla como los legos para cerar otra pieza en lugar de liarlo todo desde el comienzo sin saber si tu aplicacion aprovechará los beneficios de montarlo como microservicios.
Como siempre me gusta leer este tipo de articulos que te hace reflexionar sobre «modas» gracias por publicar estos artículo! sigue así ;-).
Buenas:
Me interesa mucho todo lo positivo que has comentado sobre micro servicios. De hecho me parece que, dado el mundo de modernidad y vanguardia que supone en sí mismo el software, es bastante patético que la parte negativa sea que «no es nada sencillo de gestionar».
Creo que deberíais reflexionar todos sobre la necesidad de salir de la zona de confort y dejar de dar esta pésima imagen de nuestra profesión.
Gracias por los comentarios, en general coincido bastante con vosotros.
Jesús, sobre lo de dejar la aplicación preparada para trocearla, yo diría que es viable (hasta cierto punto). El mero hecho de tenerla preparada, aunque nunca llegues a dividirla, creo que ya aporta bastante ventajas de cara al diseño (alta cohesión, dependencias entre componentes limitadas, interfaces claros, etc.).
Ricardog, no veo que tiene de vanguardista aumentar innecesariamente la complejidad de una solución.
En teoría la teoría y la practica son lo mismo, en la practica no xD, creo que los pros y los contras verdaderos los veremos unos años después cuando los desarrolladores nuevos entren y digan ¿ Qué rayos es esto ? , aun así la idea de los microservicios es buena, igual todo con medida, evite el exceso, si a google y a facebook les funciona por que no tomar algo de ellos y utilizarlo, ¿ Para que reinventar la ruda ?, el problema es cuanto puedo/debo reutilizar
Yo ahora mismo estoy sufriendo la moda, y aun hay algo que añadir: Los microservicios tienen sus pros y sus contras, pero lo que la gente está haciendo ahora con la excusa de los microservicios, eso sí tiene delito.
Como bien dices, definición de los microservicios de M. F. implica que los microservicios son autosuficientes e independientes, así que incluyen todas las capas.
Pero la gente lo está usando para cortar capas, un «microservicio» de persistencia por aquí, un «microservicio» para este proceso de agregación por allá… pero como son servicios separados y se comunican usando REST, entonces los llamamos microservicios y ya son guays, modernos y «mejores por definición».
Luego cogen y aplican las teorias de microservicios y eso de que tienen que ser independientes y autosuficientes a esas distintas capas, así que bienvenido el copy/paste a la enesima potencia, ya que «no se puede compartir nada entre servicios, han de ser independientes» etc. etc.
En fin, la gente lo esta usando como en su día se uso CORBA, y se van obtener los mismos resultados… incluso peores.
Y estoy de acuerdo contigo «no es nada fácil de gestionar» no tiene nada que ver con zonas de confort, modernidad ni florituras. Tiene que ver con que las aplicaciones han de ser faciles de mantener y actualizar y complicarse la vida innecesariamente no es ser moderno, es ser otra cosa no mencionable en público :).
Es un tema que me intersa mucho, a parte del artículo de MF también me he leído el libro de Sam Newman (que recomiendo independientemente de si quieres o no implementar microservicios) en él se habla de todos los retos y complicaciones en las que te metes al montar la arquitectura.
Se aconseja partir de un enfoque monolítico y extraer servicios. Uniendo el concepto de fronteras de DDD con los microservicios.
Yo he hecho algunas pruebas de gaseosa usando RabbitMQ como comunicador entres servicios e incluso a pequeña escala se vuelve muy complejo de mantener y al final no puedes hacer deployments separados porque los conceptos se acoplan y no puedes separar bien los microservicios, que además son mucho más complicados de refactorizar para mover modelos o funciones de un servicio a otro.
Sí que es muy interesante ir separando los proyectos en features que en un momento dado si el uso lo requiere y está justificado poder extraerlo, lo que yo veo más complicado es separar la BD.
Como muchas otras cosas es ridículo pensar que algo por ser nuevo y que a otros les funcione, es lo que hay que usar. Rigor y pragmatismo que somos profesionales.
Excelente post y como siempre didáctico y directo. Gracias.
@Antonio, yo creo que parte del problema ahora mismo es la indefinición del concepto y que en muchos casos se está aplicando mal. IMHO, microservicios no implica dividir la BDD, que en sistemas que no sean de jueguete o totalmente independientes de partida, no se puede/debe separar.
Con esa misma excusa la gente esta «separando» las BDD en islas independientes, desnormalizando, pasando las reglas de consistencia a la lógica de la aplicación… barbaridades, si me preguntas a mí. Con la pura excusa de que es más moderno y guay, escalable blah sin pararse realmente a pensar.
La idea de los microservicios es, por ejemplo, poder tener un ciclo de vida independiente de servicios que realmente lo tengan, poder tener una escalabilidad diferente sin que sea un todo o nada. Así pués, si tenemos un sistema de informes que no se usa más que de pascuas a ramos y tenemos un sistema de consulta online que sufre mucha carga, podemos autoescalar el sistema de consulta online sin estar obligados a escalarlo todo, y podemos aplicar parches más rápidamente sin tener que alinearnos con la parte de informes, que a lo mejor necesita más CPU, por decir algo, pero menos memoria, y cuyos cambios a lo mejor pueden esperar a los siguientes informes mensuales/anuales.
Pero dividir por el placer de usar la tijera y decir que estamos haciendo servicios «micro» es de tontos. Si los «microservicios» son mantenidos a la vez, están tan relacionados que casi nunca actualizarás uno sin tocar el otro, los usuarios y requisitos son básicamente los mismos… simplemente son ganas de complicarse y poderse colgar la medallita de «usar microservicios», a costa de aumentar la complejidad, el «overhead», el uso de recursos…
Pero bueno, ya conocemos como es esto, el hype le da mil vueltas al espíritu crítico, que no vende libros, ni conferencias ni te hace quedar tan molón :X
Muy de acuerdo contigo.
Aquí os dejo un enlace con una historia sobre microservicios desde la experiencia y contextualizando equipo, proyecto, etc.
A mi me parece muy interesante:
https://rclayton.silvrback.com/failing-at-microservices?utm_content=buffer93afc&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer
Buenas noches Juanma,
Antes de nada, felicidades por el artículo. Otro más para los que nos gusta el debate sobre arquitecturas, modas, tendencias, etc, en el mundo del software.
Sobre el tema del artículo, dejando aparte la tendencia de muchos de nosotros a implementar las últimas modas en nuestros proyectos web por simple postureo, existe otro amplio campo en el que los «micro-servicios» creo que juegan un papel bastante importante y tienen bastante sentido, y creo que en el artículo no se ha mencionado:
la integración entre sistemas.
Imaginemos que nuestra infraestructura se componen de múltiples «input system» los cuales emiten (y potencialmente reciben) información la cual debe ser procesada, analizada y tratada antes de enviarla a un sistema central de control, con el fin de tener disponible toda esta información de manera clara y útil para otros sistemas o personas que nada o poco tienen que ver con esos «input system». Pensemos además que quizás este sistema central de control esta fuera de nuestra intranet (porque queremos que tanto los trabajadores de nuestra empresa, como los trabajadores externos puedan comunicarse con este sistema), y que queremos filtrar de manera adecuada la información interna que sale de nuestra red.
En este caso cada punto de entrada al sistema central puede ser «de su padre y de su madre». Se podrían dar casos en que nos llega información a través de: una web en SharePoint, un sistema de carpetas compartido, una web, un Rest API, una aplicación de escritorio, un directorio activo, etc. Y toda esta información debe ser procesada y llevada al sistema central para visualizarla de forma homogénea. Aquí tiene mucho sentido tener «micro-aplicaciones» encargadas de gestionar y analizar esa información de entrada. Además, efectivamente esta información debe ser coherente en el espacio y el tiempo, por tanto es necesario un sistema de comunicación entre sistema central y los «input/output systems» y entre ellos mismos (llamase RabbitMQ, Apache Kafka, whatever…).
Por otra parte, cada sistema de entrada tiene unos requisitos de usuario muy distintos y muy dispares, por lo que se pueden atacar de forma más focalizada si tenemos micro-servicios enfocados a cada parte, sin que nuestros cambios afecten a los demás input systems.
También si el día de mañana se decide eliminar funcionalidad o mergear varios input system y dejar otros, los microservicios nos permiten hacer esta union sin afectar a otros stakeholders que nada tienen que ver con ese cambio de funcionalidad.
Y a todo lo anterior le podemos añadir lo ya comentado en el post sobre mejoras en escalabilidad de procesamiento al poder ir levantando instancias de nuestros microservicios según se vaya demandando más capacidad.
No obstante, por supuesto que hay problemas en este tipo de arquitecturas, y el que comentas Juanma sobre el versionado y despliegue de cada micro-servicio es uno de ellos y bastante importante además, ya que muy probablemente la manera de desplegar de cada micro-servicio, aparte de ser completamente distinta, probablemente implique «down times» muy diferentes tanto en tiempo como en forma. Para ello nada mejor que dedicar varios sprints a desarrollar la parte de DevOps lo mejor posible y, por qué no, si la pasta te lo permite, tener a una persona dedicada al mantenimiento de toda esa infraestructura nunca esta demás :D
Se esta perdiendo de vista el hecho de que con microservicios puedes escalar partes de una aplicación de una manera muy granular, y que hay muchas faclidades derivadas de las tecnologias de nube, todo el tema de contenedores y del costo de infraestructura en la nube es un gran facilitador. Fácilmente una aplicación puede construirse de forma tradicional y exponer solo como microservicios las partes que más requieran escalabilidad, logrando tener una muy Buena mejora en servicio y reduciendo a su vez los costos de producción. Normalmente por un par de Servicios de alta demanda se termina escalando toda la aplicación incurriendo en costos innecesarios. Otro tema importante es que para temas críticos hoy en día se pueden encontrar herramientas especializadas que no necesariamente correran el mismo fwk que el resto de la aplicación. El enfoque de microservicios tambien permite desacoplamiento tecnologico en Servicios donde la major solución puede estar en otro framework o lenguaje.
Hola Luis,
En un escenario como el que planteas, utilizar servicios/aplicaciones diferentes me parece lo más natural y una opción perfectamente válida. Que sean micro o macro es una cuestión diferente pero, en mi opinión, irrelevante.
En el caso que describes, la necesidad de escalar, desplegar, mantener y evolucionar por separado cada componente es algo inherente al sistema, no es algo heredado de la arquitectura usada.
Para mí esa es la diferencia clave: si la arquitectura se ajusta a la complejidad esencial del sistema, está bien elegida; si la arquitectura introduce complejidad accidental, la arquitectura sobra.
Gran artículo Juanma (no podía ser de otra forma viniendo de ti), sobre todo en la parte del artículo que detallas las ventas (esta va con indirectas) ;)
Me voy a centrar más en las desventajas, porque con las ventajas, entre otras muchas más, estoy de acuerdo.
1- Despliegue, Versionado y actualización: Es verdad que pasas de tener 1 despliegue en caso de una aplicación monolítica a tener muchos despliegues en caso de micro-servicios, pero cuando despliegas no lo haces de todos los micro-servicios a la vez, solo despliegas la pieza que necesitas evolucionar o corregir. Esto a la hora de la verdad, se convierte más en una ventaja que en una desventaja ya que no corres los riesgos que implica desplegar toda tu aplicación para corregir o evolucionar solo una funcionalidad.
El versionado es otra ventaja que va muy ligado a lo anterior. ¿Cuántas veces no hemos querido evolucionar algo o re-factorizar algo que implica una refactorización de varias tiers? En estos casos o re-factorizamos todo lo que toca o nos arriesgamos a mantener dentro de una misma aplicación funcionalidades que hacen lo mismo de distintas maneras (ummmm).
En el caso de las actualización, podría sumar los dos párrafos anteriores y quedaría nuevamente convencido de que la separación es una buena solución :)
Monitorización: Lo he separado porque es un error común a la hora de plantear una arquitectura de Micro-servicios, saltarnos el API Manager o API Gateway. Si se busca arquitectura de Micro-servicios en internet y vemos las imágenes, nos encontramos con muchas que explican la exposición directa de cada Micro-servicio y esto es un error.
Esto pasa porque hacia fuera, esta pieza es invisible a los ojos (como todo lo bueno, según nos contó «El Principito» una vez). Aquí puedes gestionar todas las peticiones a tu arquitectura, registro, subscripciones, policy injections, logs, versionado, analytics, etc.
WSO2, Mule de MuleSoft o el propio API Manager de Azure nos hace este trabajo muy simple. Incluso, si queremos que cada micro-servicio tenga su propio log (no lo veo necesario) y nos ponemos serios con la arquitectura, toda esta gestión la puede hacer un micro-servicio, por lo que simplificamos el análisis y la resolución de problemas. Visual Studio Application Insights es un ejemplo de esto.
DevOps, es un elemento clave en todo esto. Hasta hace poco no era extraño ver a un IT diciendo «Es culpa del software» o a un desarrollador diciendo «No me puedo conectar a la BD, esto es cosa de IT». Aquí esto se acabó :) Somos un equipo! Yo pude estar en uno que después de algún tiempo intentándolo, finalmente se logró y el resultado es espectacular.
Sobre la interrelación entre servicios, ¿qué decir? Nadie duda hoy en día que el Cloud es una solución para muchas empresas por lo que representa en ahorros de costes. En Azure por ejemplo, interactuamos con bases de datos SQL o NoSQL, Redys, Storages, Notificaciones, Visual Studio Application Insights, etc. ¿Tan complicado nos ha resultado? ¿Nos hemos preocupado por transaccionalidad más allá de la capa que nos ocupa? Azure está montado sobre una arquitectura de micro-servicios e interactuamos con ellos sin apenas darnos cuenta.
Estoy de acuerdo que vender esta arquitectura por su escalabilidad, es un malísimo enfoque. Además, tu puedes escalar perfectamente una aplicación monolítica. Para mi, además de las ventajas que se han descrito aquí, la principal ventaja que veo en esta arquitectura es que puedo exponer una lógica de negocio y convertirlo en un negocio independiente, sin escribir 1 sola línea de código. La rapidez para este tipo de decisiones en un mundo que a día de hoy expone 100 soluciones para un mismo problema, es prioridad para cualquier negocio.
Saludos (Al final excepto por el título, no has sido tan duro con la arquitectura) ;)
y ahora que leo algunos comentarios, muy buen punto el de @JuanKRuiz
Aunque es verdad que puedes escalar sin problemas una aplicación monolítica, el coste en Cloud no será igual al escalado en una arquitectura de micro-servicios. En el primer caso, se escala «toda» la aplicación, en el segundo, se escala solo el micro-servicio que demanda mayor uso y lo haces incluso, pudiendo decidir que no te interesa escalar más.
Un ejemplo que me viene de cerca: En una pasarela de pago, ¿qué es lo que más te interesa? Pues que se pueda pagar ¿Verdad? Sin embargo una pasarela de pago tiene reporting, registros, etc. Yo puedo decidir que mi micro-servicio de pago escale siempre (hasta el infinito y más allá). Esa es la vida de mi negocio, lo que me da dinero.
Sin embargo, ¿te interesa escalar de igual forma la parte de reporting? Si quieres regular costes la respuesta es «No», escalo hasta X usuarios, la media por ejemplo, de ahí en adelante si da time-out, ya podrán obtener sus reportes en otro momento.. Quizás suena drástico e incluso se pueden incluir otras variables en la ecuación, pero si tienes una carga de pagos y una carga de reporting y no quieres que se te vaya la ganancia en pagar el escalado del reporting, te toca tomar una decisión
Con Micro-servicios tenemos mayor control de cada parte de la aplicación, podemos decidir en caso de necesitar ahorrar, dónde puedo y dónde no…
;)
Saludos…
Muchas gracias por tus comentarios, Omar. Me han resultado muy útiles.
Lo cierto es que como arquitectura ya digo que me parece atractiva y creo que tienes razón en que parte de lo que yo veo como desventajas pueden convertirse en ventajas.
Al final, como siempre, todo depende del contexto que tengas. Por el tipo de aplicaciones que desarrollo actualmente, no me aporta mucho poder desplegar versiones de forma independiente, o escalar partes concretas de la aplicación, por eso digo que los microservicios no son para mí.
Sobre la facilidad para gestionar 300 servicios en la nube, lo veo como un arma de doble filo. Está muy bien que sea fácil montar un Redis, un mongo, un sql server, un app insights y 40 cosas más, pero no sé si quiero que mi aplicación dependa de todas esas cosas. Bueno, sí lo sé, prefiero que no lo haga a menos que sea imprescindible.
En cuanto a la parte de «convertir parte de la lógica en un negocio independiente», yo diría que lo complicado de un negocio no suele ser exponer la lógica sino todo lo que va alrededor (comercialización, marketing, fuerza comercial, canal de distribución, modelo de negocio). Comparado con eso, encapsular detrás de un API la lógica que tenías en una dll no me parece tan complejo. Si haces algo parecido a lo que comentaba @Jesús al principio, dejando la aplicacion «preparada» para partirla pero sin partirla, dar ese paso es fácil, y mientras te has ahorrado el resto de costes asociados a los servicios.
;)
Estoy de acuerdo en que hay que contextualizar. Miraba el comentario que escribí en el post pasado donde dije «siempre utilizaría micro-servicios» y lo reconozco, me dejé llevar… :D
Sobre las dependencias ¿Seguro que ya no dependes de otras aunque sean desarrolladas por ti? ¿Por qué no nos creamos nuestra propia BD en vez de usar SQL Server, Oracle, MySQL o Postgre? ¿Hacemos caché en nuestra aplicación monolítica para mejorar los tiempos de respuesta? ¿Tenemos implementado un sistema de Logs? para mi, las dependencias son las mismas e incluso, puede que más difícil de gestionar…
El otro punto ya te digo, me gustaría verlo como lo vez tú o como lo ve @Jesús… pero de verdad, a mi al menos eso que llamáis «fácil» me parece complicado.
Suponiendo que el resto de actores hace su trabajo: tienes marketing, tienes fuerza comercial y canal de distribución. No se trata de exponer una parte de tu código y listo. ¿Cómo gestionas las credenciales para las aplicaciones que quieran consumir tu API? ¿Cómo controlas que alguien se haya apoderado de un juego de credenciales y te quiera echar abajo tu API? ¿Cobrarás por petición o por volumen de peticiones? ¿Quién se encarga de controlar esto? ¿Cómo expones tu documentación? Mucho trabajo que hacer veo yo, incluso planteándose incluir un API Manager de terceros…
Saludos..
Sobre dependencias, no digo que no haya que usarlas, pero si puedo, prefiero minimizarlas, y si puedo controlarlas yo, mucho mejor. Si uso NHibernate (por poner un ejemplo de ORM), puedo copiarme la DLL y usarla infinitamente. Si uso Azure Service Expert Management Support Center For Insight Analytics y mañana lo descontinúan, tengo un problema más grave.
Tienes razón en lo que dices sobre la complejidad técnica para exponer algo como un servicio. Pero creo que, precisamente, ese tipo de argumentos sirven también para evitar convertir algo en servicio hasta que no sea imprescindible. Por lo de YAGNI y cosas de esas ;-)
Tu tranqui, los microservicios déjamelos pa’ mi :) que le inyecto unos WebForms y a generar microservicios a cholón.
Quitando mis tonterias, la verdad que si que, a primera vista parecen una sobrearquitectura, pero qué no es una sobrearquitectura hoy en dia… Personalmente, el tema de los microservicios siempre me ha hecho gracia, pero no me acababa de convencee el overhead de interacción via servicios web, no porque lo vea dificil sino porque es una inversión de tiempo espeluznante para conseguir algo potable y que es muy poco práctico a nivel de mantenimiento, incluso con las mejores prácticas aplicadas. Como he leido en algunas partes, la diferencia entre microservicios y monolitos es el tamaño de la mierda y su dispersión.
Pero con el tema de los microservicios, descubrí akka.cluster…. ¡¡¡¡¡Y TE HACES PAJAS# SÓLO DE VER LO QUE SE PUEDE HACER!!!!!. Como ejemplo, el siguiente enlace: Cluster.WebCrawler. Lo siento si te lo haces encima, ¡pero esto es digno de ver! I <3 Akka!!!
Muchas Gracias Juan María Hernández. Valiosísimo tu post. Estoy a puertas de implementar un proyecto con M.S. El punto de la transaccionalidad se nos paso a todos. Toca ajustar las tuercas. Sin ser un evangelizador de M.S ya me olía todita la complejidad que expones, así que no estaba loco :s
Yo viví en carne propia dos apps monolíticas elevadas a la 1000. Uno era un producto de ibm y otro un desarrollo en un lugar muy muy lejano. Ambas tenían un workspace de mas de 1gb, sin maven, tecnologia antiquisima, errores extraños, demoraba mas de 20 minutos el arranque, la app se chupaba toda la ra, de mi pc, el eclipse se colgaba y los developers se ahorcaban. No podias meter nada nuevo porque el mounstruo monolitico no lo permitia. Era el mismisimo infierno T_T.
Por experiencia propia , entre una app monolitica y una basada en microservices sin caer en delitos como dijo GreenEyed, me quedo con los microservices.
Lo que si es delito es el comentario de «salir de la zona de confort».
Aquí una interesante historia de como una monolitica se vuelve un mountruo:
http://microservices.io/patterns/monolithic.html
Saludos.
Supongo que se da por supuesto pero a veces parece como que es una eleccion de todo o nada siendo que el tamaño y ambito de cada desplegable/proyecto puede ser ajustado segun varios criterios:
* Agrupar las funcionalidades de un conjunto de usuarios mas o menos homogeneo
* Separar las partes que cambian mas frecuentemente y que cambian juntas
* Ver el balance entre tener demasiadas dependencias estaticas con un grafo de dependencias complejo y tenerlas en tiempo de ejecucion (lo que rompe la transitividad de dependencias)
* Estudiar como afecta al coste mantener la correccion en un caso u en otro (herramientas de analisis estaticos, tipos, tests unitarios o de integracion, etc)
* Etc
O sea que no tiene que ser todo grande o pequeño siempre y tal vez deberiamos estar preparados para desarrollar y desplegar aplicaciones de varios tamaños.
El uso de un sistema basado en microservicios así como cualquier otra arquitectura esta relacionado directamente en las necesidades del negocio (pensemos en DDD). Pienso que es un error decir que es favorable si se trabaja en equipos grandes o proyectos grandes, llevo trabajando dos años con este tipo de arquitecturas y he llegado a desarrollar y administrar hasta mas de 20 microservicios todos correspondientes a la misma solución. No me confundan (No soy un fanático religioso de x tecnología o x arquitectura o x tendencia) pero esta arquitectura permite tener una gran libertad de diseño y de costos al momentos de implementar una soluciona a la vez que permite un acoplamiento mas fácil con otros sistemas no distribuidos o monolíticos. De nuevo aclaro, es una arquitectura para x necesidad de negocio, así como todas las tecnologías que utilizamos.
Creo que su artículo presenta un punto de vista peculiar e interesante sobre como el mercado o la moda rigen en sobremanera las arquitecturas de los sistemas o peor los destinos tecnológicos. Se me ocurren ahora mismo par de tecnologías que no han resuelto ningún problema que no estuviera resuelto antes y de hecho traen otros problemas que ya estaban resueltos, pero se han impuesto exactamente por la moda. Sin embargo, otras que lucen más robustas, resultan ser menos populares.
Donde si NO coincido es cuando asocia los temas de gestión de configuración (despliegue, versiones, actualizaciones, …), a las arquitecturas micro servicios + tamaño de los equipos. Según mi punto de vista, independientemente del tamaño equipo o la arquitectura la gestión de configuración es imprescindible.
Una cosa es que algunas tecnologías promuevan ambas cosas (micro servicios + gestión de configuración) y otra es que por método o principio deba SIEMPRE tenerse en cuenta.
¿Dónde está dicho que una aplicación monolítica no deba versionarse correctamente o que un desarrollador individual no deba mantener su pipeline para la construcción y/o despliegue continuo para sus aplicaciones?
Hola Igr,
Tal vez no me haya explicado bien. No creo que desplegar, versionar o monitorizar sean características exclusivas de arquitecturas basadas en microservicios o de equipos grandes, de hecho he escrito sobre ello, por ejemplo al hablar de servidores de integración continua o de todo lo que hay que hacer además de desarrollar.
A lo que me refiero en el post es que todas esas cosas tienen un coste que no es despreciable, y en el caso de una arquitectura basada en microservicios, el coste se multiplica porque en tienes que desplegar, versionar y monitorizar más procesos separados que en el caso de una aplicación monolítica.
El comentario sobre el tamaño de los equipos es porque una de las ventajas que le veo a los microservicios es que permiten dividir mejor el trabajo en distintos equipos y, obviamente, a eso le sacas más partido cuando mayor sea tu equipo. Por supuesto, si tu equipo tiene 2 personas, también es bueno poder dividir el trabajo, pero suele ser más fácil que cuando tiene 300.
Buenas:
Como comentan esto ahorita es el «trending topic» del desarrollo, a lo que veo para poder desarrollar una buena arquitectura de microservicios se necesita conocer cosas como:
Principios GRASP, Principios SOLID, DDD , Teorema de CAP, TDD, Message Brokers (RabbitMQ ,MSMQ, JMS), Herramientas de Monitoreo como New Relic (por mencionar alguna) y ni hablar de CI (Continous Integration) y Continous Deployment, para que tu proyecto no sea un infierno, la verdad yo no me arriesgaría a invertir tanta bilis en ello, aparte para ser sinceros muy pocas empresas necesitan tanta «Escalabilidad», habrá sus excepciones. y como no mencionan el manejo de transacciones se dificulta de una gran manera ya que cada servicio maneja sus propias transacciones. por lo que veo no es tan trivial implementar algo así en nuevos proyectos, al menos que se quiera correr el riesgo $$$$
Hace un tiempo leí un comentario muy acertado, un equipo de desarrollo bueno nunca necesito una buena arquitectura para hacer buen software, y no me quiero extender en la explicación y consecuencias de esto.
Microservicios es la manera adecuada de abordar un problema perse, asi como se puede decir que separar un problema en partes más pequeñas es una buena practica siempre. Hay quienes diran, es que mi problema es muy pequeño y no necesito separarlo, y me ahorro la complegidad de los llamados y definición de las las partes, etc, :(, xD.
Si desde el principio adoptas este patron no habra problema si te encuentras con la eventalidad que no necesitabas separar, pero si pasa lo contrario, como al final siempre me ha pasaddo…
Queria aportar esto, ya que de lo demás suficiente se ha hablado.
Microservicios esta orientado a cierta tipo de aplicaciones que no tengan muchos interface pero si un buen comsumo de recursos en realidad creo seria un poco complicado implementar microservicios pero si es una app pequeña y enfocada a solo alguna cosa estaria bien
Pingback: Seis ventajas de los microservicios – DaniCCardenas
Yo llevo trabajando en con microservicios los últimos 5 años…. y me encantan!
Tienen sus complicaciones, un buen equipo de DevOps es clave
Si bien la escalabilidad horizontal es la reina de las ventajas, también hay otras: la posibilidad de desarrollar en paralelo sin código compartido entre equipos y que es una arquitectura que fuerza a que los componentes sean muy cohesionados y poco acoplados.
He comenzado ahora a leer posts de microservicios en castellano, y este es uno de los mejores análisis de pros y contras que he encontrado.
Saludos y enhorabuena!
Max
maxaldunate@gmail.com
Tu opinion es la de asno,que no come carne y opina sobre su gusto.No rebuses mas