Una de las tendencias de diseño de las que se ha puesto de moda hablar recientemente son los microservicios. Para el que lo quiera entender de un plumazo, los microservicios son lo mismo que Service Oriented Architecture (SOA) pero cambiando los componentes Java Enterprise Edition (JEE) y los Enterprise Software Bus (ESB) por llamadas HTTP entre componentes escritos (posiblemente) en diferentes lenguajes y ejecutándose en diferentes máquinas.
Ejemplo:
El desarrollo de una pagina que tenga, el diseño, back-end y base de datos, esto es una aplicación monolitica.Una posibilidad es intercambiar ficheros de un lado para otro mediante FTP de toda la vida, lo cual sigue siendo muy válido para el intercambio de lotes, pero también habrá servicios de información y notificación en tiempo real que requerirán enlaces entre los servicios web de la tienda y los servicios web de los proveedores.
Existe una teoría atribuida a Melvyn Conway en 1967 y ampliamente comprobada que afirma que el sistema que producirá una organización es isomorfo a la estructura de comunicación de las personas que lo desarrollaron. En las aplicaciones web y cliente servidor suele haber tres equipos: el de interfaz de usuario, el de middleware y el de bases de datos. Se dividen así por una cuestión de reparto de las competencias profesionales, pero desde el punto de vista del desarrollo de las funcionalidades que ve el usuario no existe ninguna razón por la cual haya que tener ingenieros de front, de back y y administradores de base de datos.
La arquitectura basada en microservicios propone que tanto el interfaz como las aplicaciones de usuario sean clientes de una colección de servicios que operan cada uno sobre un dominio.
Un gateway para los microservicios es necesario porque una página puede necesitar decenas de ellos y sería ineficiente realizar una llamada HTTP a cada microservicio desde el navegador. Además, el gateway puede lanzar en paralelo las peticiones a cada microservicio en lugar de ejecutar una única subrutina para obtener todos los datos necesarios para pintar una página web. Netflix utiliza este tipo de arquitectura basándose en RxJava
Desventajas:
Úna aplicación monolítica se instala con un programa especializado o se despliegua como un archivo WAR en un contenedor de servlets. Pero los microservicios pueden estar distribuidos en diferentes servidores y estar escritos en diferentes lenguajes. El uso de herramientas de generación de máquinas virtuales como Vagrant y de despliegue continuo como Jenkins es una necesidad imperiosa en las arquitecturas microservicios.
Los microservicios tampoco solucionan el problema del versionado. Lo que proponen es hacer resilientes los clientes a fallos en los microservicios proveedores, lo cual es más fácil de decir que de hacer.
Pero quizá el problema más grave es el mantenimiento de la consistencia de datos replicados entre los dominios de diferentes servicios. En la mayoría de las arquitecturas basadas en microservicios los datos son sólo eventualmente consistentes, lo que significa que es posible que dos clientes que se ejecutan en paralelo reciban resultados diferentes. El mayor error de diseño que yo he encontrado hasta ahora en las aplicaciones basadas en servicios es montar la replicación de forma explícita y carecer de un buen mecanismo de consolidación de datos. Conviene recordar que evitar la redundancia y la inconsistencia de datos fueron las dos razones principales para diseñar en un principio aplicaciones monolíticas transaccionales.
No hay comentarios.:
Publicar un comentario