El despliegue de micro servicios es un tanto distinto del despliegue un monolito. Cada microservicio podría estar escrito en su propio lenguaje y framework. Hay unos cuantos patrones de despliegue de microservicios.
Multiple Service Instance Per Host Pattern
Cuando se usa este patrón se provisionan uno o más host, ya sean físicos o virtuales, y se ejecuta una instancia del servicio en cada uno de ellos. Esta es la estrategia tradicional para el despliegue de aplicaciones.
Hay variantes de este patrón como puede ser ejecutar varias instancias de servicio. En teoría, el uso de recursos es más eficiente dado que comparten el servidor y el sistema operativo. Otro beneficio de este patrón es que simplemente copias el servicio al host y se inicializa.
La principal desventaja es que no hay un aislamiento de los servicios dado que comparten los recursos de la máquina. Esto implica que un servicio pueda llegar a consumir el 100% de los recursos de esa instancia.
Otra desventaja es que el equipo de operaciones debe conocer los detalles específicos de cómo desplegar ese servicio. Esto incrementa la complejidad de desplegar el servicio.
Service Instance per Host Pattern
Con este patrón se ejecuta cada instancia del servicio en propio host. Hay dos especializaciones distintas: por máquina virtual o por concendor.
Service Instance per Virtual Machine Pattern
Se crea una máquina virtual con todo lo necesario para ejecutar el servicio. A partir de esa imagen se pueden crear múltiples instancias de la máquina virtual.
El principal beneficio es que cada máquina corre aislada y tiene una CPU y una memoria propia que no comparte.
Otro beneficio es que la máquina virtual encapsula la implementación del servicio. Una vez que el servicio está empaquetado se convierte en una caja negra para el administrador de máquinas virtuales.
Por el contrario, es que la utilización de los recursos es menos eficiente. Cada máquina virtual tiene el overhead de la máquina virtual incluyendo el sistema operativo.
Otro dificultad es que es difícil reaccionar rápidamente a los cambios bajo demanda. Debido a esto hay que hacer una previsión lo cuál encarece el coste de despliegue.
Otra desventaja es que desplegar una nueva versión del servicio es un proceso lento. Las máquinas virtuales son lentas de instanciar y tardan tiempo en empezar.
Todo este proceso conlleva un tiempo que, aunque es necesario, no se está invirtiendo en el negocio.
Service Instance per Container Pattern
Con esta estrategia cada instancia del servicio se ejecuta en su propio contenedor. Los contenedores son un mecanismo de virtualización al nivel del sistema operativo.
Un contenedor consiste en uno o más procesos ejecutándose en un sandbox. Desde la perspectiva de procesos estos tienen su propio sistema de archivos y puertos. Se puede limitar los recursos de CPU y memoria de un contenedor.
Para llevar a cabo este patrón cada servicio se empaqueta como un contenedor. Esta contenedor es un imagen del sistema de archivo y las librerías que el servicio necesita para su ejecución.
Una vez que se ha empaquetado el servicio como un contenedor se pueden lanzar una o varias instancias tanto en una máquina física como en una máquina virtual. El administrador de recursos, como Kubernetes, administra los host como un pool de recursos. Este decide donde ubicar cada instancia dependiendo de los requerimientos de la misma y los recursos disponibles.
Los beneficios son aislar las instancias unas de otras. Se pueden monitorizar los recursos de cada contenedor. Los contenedores encapsulan el servicio.
Los contenedores, no como las máquinas virtuales, tienen la ventaja de ser una tecnología más ligera. Se pueden construir muy rápido y también empiezan muy rápido ya que no hay un mecanismo de arranque de un sistema operativo. Cuando un contendor empieza lo que ejecuta es el servicio.
Las desventajas es que mientras la infraestructura de contenedores madura rápidamente no está tan madura como la infraestructura de máquinas virtuales. Los contendores no son tan seguros como las máquinas virtuales desde que estos comparten el kernel.
Otro inconveniente es que hay que administrar los contenedores.
Serverless Deployment
Es un concepto en el cual se trata de evitar tener que lidiar con las máquinas virtuales o contenedores.
AWS Lambda es un ejemplo de tecnología serverless. Sólo hay que empaquetar el microservicio, proporcionar unos metadatos y AWS Lambda levanta suficientes instancias del microservicio para manejar las solicitudes.
Como en todo, AWS lambda tiene sus limitaciones aunque no deja de ser atractivo el poder abstraerse de la parte de infraestructura.
No hay comentarios:
Publicar un comentario