Seguramente habrán escuchado sobre micro-servicios, o de alguna software que sigue el patrón de una arquitectura de micros-servicios. Micro-Servicios es un tema que actualmente se encuentra en boca de todos y probablemente escuchemos cada vez más hablar de ello.
Objetivo
El objetivo de esta publicación es tocar las posibles utilizaciones y alcance una arquitectura de microservicios. Sus beneficios como también que puntos debemos tener en cuenta para poder llevarla adelante.
Audiencia
Este documento está dirigido a personas que conocen pero no saben que realmente es, como también a personas que no conozcan el tema, o bien profesionales que desarrollan tareas de consultoría de desarrollo o que simplemente están interesados en leer e investigar sobre la tecnología alcanzada por esta publicación.
Desarrollo
Cuando hablamos de una arquitectura de microservicios tenemos que pensar en una aplicación construida sobre una serie de pequeños servicios. Estos tienen la característica de ejecutarse de forma autónoma y también pueden comunicarse entre sí. Uno de los mecanismos comunes de comunicación es por medio de peticiones http hacia sus APIs.
Al referirnos a pequeños servicios podemos decir que cada uno corresponde a un área de negocio de la aplicación como por ejemplo: Clientes, Ventas, Stock, etc. Básicamente el objetivo es tener una cantidad mínima de servicio que manejan cosas comunes para todos como acceso a base de datos o bien servicios de terceros.
Cada servicio es independiente y debe poder ser desplegado sin tener ningún impacto sobre los otros. Otra característica muy interesante es que pueden escribirse en cualquier tecnología y cómo estos se comunican por medio de las APIs pueden hablar sin inconvenientes.
No hay especificaciones de qué tamaño deben tener los micro-servicios, tampoco, cómo debemos dividirlo para una aplicación. Jon Evans publicó que la mejor característica de un microservicio es que puede ser re-escrito nuevamente en 2 semanas.
Arquitectura sin MicroServicios
Para poder entender mejor el objetivo de la arquitectura de microservicios vamos a usar el siguiente ejemplo: Pensemos en una aplicación de gestión para una empresa que se dedica a la venta de productos en línea. Los usuarios interesados en los productos podrán ver, comprar los productos y seguir sus pedidos.
Nuestra primera aproximación de nuestra arquitectura seria algo asi sin la utilización de microservicios:
Nuestros usuarios entraran a la aplicación, una aplicación web, y podrán visualizar los productos, seleccionarlos, agregarlos a un carrito y finalmente cerrar su compra junto a su forma de pago y datos de envío. Todo nuestro codigo se ejecutara en el servidor el cual puede conectarse a una base de datos u otro servicio de terceros. En nuestro caso podría ser un servicio de pago especial.
Nuestra aplicación pueda estar separado por módulos con diferentes lógicas de aplicación, pero, esta tiene como resultado siempre el mismo compilado ejecutable. Supongamos que debemos hacer un cambio en el módulo de envíos y debemos implementarlo en producción. Ante esta situación no tenemos opción de tener que implementar todos los módulos aunque la gran mayoría no hayan cambiado.
Otra situación es, que pasa si nuestro sitio tiene comienza a tener mucha demanda. Necesitaremos escalar para poder brindar servicio a todos los usuarios nuevos. En esta arquitectura debería crear nuevas instancias de mi aplicación y usar algún tipo de balanceador de carga para que los usuarios vayan dirigiéndose a cada instancia dependiendo de la carga. Pero, si en realidad es solo el modulo de ventas está sobrecargado, igualmente, deberemos crear instancias totales de nuestra aplicación.
No debemos olvidar que en el punto anterior la aplicación es fácil de gestionar porque posee un solo ejecutable para actualizar todas las instancias de nuestra aplicación de una forma manual o automática.
Arquitectura MicroServicios
En lugar de tener todo en un solo servicio o ejecutable, cada componente puede auto-ejecutarse y los servicios que lo componente pueden comunicarse entre si sin ningún problema.
Los usuarios pueden interactuar con ellos por medio de la aplicación, que tranquilamente también puede ser un micro-servicio, comunicándose con los servicios de clientes por ejemplo.
Al usar este tipo de arquitectura tenemos los siguientes beneficios:
- Como la lógica de negocio está bien separada o sectorizada es muy simple de comprender.
- Cada microservicio es autónomo y puede desplegarse sin afectar a otro. Si el módulo de clientes necesita actualizarse no afectará por ejemplo al módulo de proveedores o no será necesario implementarlo nuevamente.
- Mejor escalamiento debido a que no es necesario replicar toda la aplicación, si no, balancear o replicar los módulos que están teniendo más carga.
- Podemos tener varios equipos de desarrollo autónomos encargándose cada uno de un módulo o micro-servicio tanto en el desarrollo como en la gestión del mismo.
Si bien este tipo de arquitectura tiene muchos beneficios… no todo es color de rosa. Como toda arquitectura tiene sus pros y sus contras.
Una falsa creencia es que sin microservicios no podemos tener despliegue continuo o entrega continua, esto no es cierto. Grandes empresas como Facebook, Twitter u otras poseen este tipo de capacidad sin la utilización de una arquitectura de microservicios en su totalidad.
Los micro-servicios agregan complejidad en nuestra gestión. Si tenemos mucha cantidad de servicios debemos tomarnos el tiempo de crear una buena estrategia gestión. Deben estar bien monitoreados, debemos saber exactamente cual esta fallando, gestionar sus fallos, velar por la consistencia de datos y tener una buenas estrategias de pruebas.
Martin Fowler dice : “hay muchas formas de gestionar todo esto, pero necesitamos esfuerzo extra, y nadie que conozco en desarrollo software parece tener muchísimo tiempo libre.”
Si nuestra aplicación es muy simple tal vez no sea necesario usar micro-servicios. Pero si nuestra aplicación crece y comienza a volverse compleja vale la pena invertir esfuerzo en llevarla a este tipo de arquitectura. Grandes empresas, clientes nuestros, se han encontrado con que gestionar la aplicación en un solo componente con el tiempo es cada vez mas complejo y han empezado a separar sus aplicaciones en microservicios o bien, los proyectos nuevos, desarrollarlos con una arquitectura de micro-servicios.
Conclusión
La arquitectura de micro-servicios no es simplemente una moda. Para una empresa que hoy no posee esta arquitectura es aconsejable que vayan hacia ella poco a poco, manteniendo las aplicaciones actuales e ir separando las partes críticas en micro-servicios mediante algunas estrategias como Branch By Abstration. Esta estrategia hablaremos en algún post junto a Visual Studio On-Line. En azure podemos usar docker para llevarla adelante. En próximo post estaremos viendo como usar docket en azure.
