En los últimos dos años, todos están hablando de Microservicios y quieren aplicarlos en cualquier lugar.
Es la misma historia con los contenedores y docker (y antes lo fue con el Enfoque en la Nube e incluso antes con SOA, BPM, EDA…).
Cualquier cosa que tenga suficiente ruido de la comunidad, resulta en que todos los clientes (y «todo tipo» de clientes) intentan aplicar la «nueva moda» sin importar qué. Debido a eso, todos los Integradores de Sistemas intentan buscar un lugar donde encaje (o incluso si no encaja…) para aplicar esta «nueva cosa» porque es «lo que tenemos que hacer ahora». Es como el negocio de la moda. ¿Qué está de moda hoy? ¿Eso? Ok, hagámoslo.
No me malinterpreten, esta publicación no va a estar en contra de los microservicios porque me encanta el concepto y me encantan las ventajas que trae consigo y lo bueno que es ir hacia este tipo de modelo.
Pero, me gustaría hablar sobre algunos aspectos específicos que no estaban en la charla común y la experiencia con este tipo de tecnología. Este patrón, modelo o paradigma, es genial y es un éxito comprobado.
Puedes ver cualquier charla de Adrian Cockcroft sobre su experiencia en Netflix para estar seguro de que esto no es solo una palabra de moda (#NoSoloUnaPalabraDeModa) pero, ¿es capaz de usarse en todos los casos?
Cuando usualmente vemos una charla sobre microservicios, siempre es la misma historia: microservicios vs aplicación monolítica, especialmente aplicaciones web siguiendo algún tipo de patrón cliente-servidor o incluso un patrón MVC o algo similar. Y para ese tipo de aplicaciones es genial, simple y claro.
Pero, ¿qué pasa con las Aplicaciones Empresariales donde en las últimas décadas seguimos un Enfoque SOA: ¿Es aplicable aquí?
Por supuesto, hay muchas diferencias entre el Enfoque de Microservicios (el puro, el que Martin Fowler usó en su artículo) y el Paradigma SOA. No comparten los mismos principios, pero al final están más cerca que los concursantes habituales que ves en todas las charlas (aplicación web monolítica vs microservicios).
Los microservicios hablan de romper el monolito y eso es fácil para una aplicación web, pero ¿qué pasa con una Arquitectura SOA? En este caso, ni siquiera es posible seguir ese camino.
Si alguna vez has trabajado en Integración Empresarial, has visto algunos silos y es obligatorio no tocarlos y mantenerlos de esa manera. Es algo que no está abierto a discusión.
Existen diferentes razones para esa decisión: Podría ser porque son tan antiguos que nadie sabe sobre ellos, sobre cómo hacen lo que hacen, o podría ser porque son tan críticos que nadie va a seguir ese camino o solo porque no hay un caso de negocio para justificar reemplazar este tipo de silos.
Entonces, ¿qué pasa ahora? ¿Podemos seguir el camino de los Microservicios o deberíamos quedarnos con el enfoque SOA? Los microservicios no solo se tratan de romper los silos, pero es algo muy importante, así que no, no podemos seguir el camino de los Microservicios para Integraciones Empresariales, pero podemos reunir todas las otras ventajas que incluyen los Microservicios e intentar aplicarlas a nuestra capa de integración (ahora, no estaríamos hablando de Arquitectura SOA porque la mayoría de estas ventajas están en contra de algunos de los principios de SOA).
La Ola de Microservicios también se trata de Ágil y DevOps, de ser más rápido, de estar automatizado, de ser mejor, de reducir tu tiempo de comercialización. Se trata de la nube (no en el término de nube pública, sino en el término de no estar atado a tu infraestructura). Se trata de todas esas cosas también.
Entonces, los Microservicios se tratan de tantas cosas que podríamos aplicar incluso si no pudiéramos ir al 100% sobre esto. Hay varios nombres para este enfoque como Arquitectura Basada en Servicios, pero me gusta mucho más el enfoque de micro-servicios (con guion en el medio, hablando de servicios que son micro) porque creo que explica mejor el enfoque.
Así que, nos gustaría hacer servicios más pequeños para ser más flexibles, para poder aplicar todas estas cosas de DevOps, y allí podemos aplicar todas las otras cosas relacionadas con la Ola de Microservicios.
Y eso no es algo nuevo, eso no es algo que esté comenzando ahora o en los últimos años.
Es algo que he visto desde el principio en mi carrera (hace una década) cuando comencé a trabajar con TIBCO AMX BusinessWorks que te da la oportunidad de decidir tú mismo el alcance de tus servicios y dependiendo de las necesidades podrías crear «Aplicaciones Empresariales» o podrías optar por «Servicios Empresariales» o «Servicios Pequeños» que trabajaban juntos para hacer el trabajo.
Y ese camino ha sido seguido no solo por TIBCO sino por algunas otras compañías también, con la evolución del concepto ESB para adaptarse a la nueva era, que eran más como PaaS donde te permitían ejecutar tus servicios en un mundo «algo» containerizado.
Por ejemplo, la Plataforma TIBCO AMX (desde 2006) podías desarrollar tus servicios y aplicaciones usando varios tipos de lenguajes y opciones como el Editor Gráfico para Mediaciones o Java, C/C++, .NET, Spring y así sucesivamente usando el estándar SCA y ejecutándose en una plataforma elástica basada en OSGI donde puedes gestionarlos a todos de la misma manera (suena similar, ¿verdad? 🙂 )
¿Qué pasa con la reutilización? El paradigma SOA tiene estándares muy altos para asegurar la reutilización de los servicios y el registro y repositorio empresarial… y el microservicio está (al principio) en contra de la reutilización, deberías duplicar en lugar de reutilizar para poder ser autónomo y más libre. Pero, los últimos avances en Microservicios incluyen una capa de Orquestación, cosas como Conductor que están siguiendo el camino de la reutilización y la orquestación. Así que, podemos encontrar un lugar intermedio, cuando necesitas reutilizar si es posible pero no detener tu agilidad para asegurar el 100% de reutilización de las oportunidades disponibles. El tiempo de comercialización es el factor crítico aquí para todos ahora, y todos los «principios» tienen que adaptarse a eso.
¿Qué pasa con DevOps y la Nube? No hay problema, aquí podrías incluir las mismas técnicas para este caso como lo estabas haciendo anteriormente. Infraestructura como Código, Contenedores, Integración y Despliegue Continuo, etc.
¿Qué pasa con los estándares ágiles REST/JSON y demás? Tampoco hay problemas aquí.
En resumen, puedes adoptar e implementar la mayoría de los sabores y componentes del movimiento de Microservicios, pero también necesitas comprometerte con otros, y no vas a usar «Microservicios puros», vas a usar otra cosa, y eso no es malo. Siempre tienes que adaptar cualquier paradigma a tu caso de uso específico.