Nota publicada originalmente en Linkedin.
Alguien lo tenia que decir. Hablando con clientes, conocidos y amigos, creo que hay un poco de confusión respecto al concepto de containers y al de microservicios.
El container permite correr una app de forma isolada del sistema operativa. Una VM en cambio debe correr siempre un sistema operativo. En un contenedor el kernel y partes de la infraestructura del SO se comparten. Para la máquina virtual, se debe incluir un SO completo.
El #microservicio es la visión funcional de lo que estamos armando, y podriamos hacerlo en containers y también con #VMs. Los microservicios son conceptualmente la división de las aplicaciones en componentes pequeños e independientes entre sí. A diferencia de un enfoque tradicional y monolítico sobre las aplicaciones, en el que todo se crea en una única pieza, los microservicios están separados y funcionan conjuntamente para llevar a cabo las mismas tareas. Dada la historia de #SOA, los microservicios no son realmente tan nuevos como una idea. Sin embargo, los microservicios se han vuelto más viables gracias a los avances en las tecnologías de “contenedorización” (se dice asi???).
Acá es donde veo habitualmente un concepto erróneo. Tomar una aplicación #PHP corriendo en un #LAMP y subirla a #Docker es tan solo un #shift&lift. Tiene ventajas? Si, claro que tiene ventajas. Sacamos varios componentes del medio, dependencias de librerías, y la aplicación es mucho mas portable. Ahora, por hacer eso no convertimos nuestra app a microservicio.
Para que la aplicación sea un microservicio necesitamos transformarla. Mínimo que hable API.
Aquí viene el desafío. Un microservicio requiere mucho mas esfuerzo que resolver la parte técnica. Un equipo desarrollando microservicios necesita mucha mas autonomía para testing, seguridad, operación, etc, que el habitual modelo de silos instaurado en las organizaciones.
Melvyn Conway en 1967 dijo: “Cualquier organización que diseñe un sistema producirá un diseño cuya estructura sea una copia de la estructura de comunicación de la organización.”.
Haciendo foco en esa mención, y apoyado por este gráfico de Martin Fowler es que necesitamos realizar modificaciones organizacionales para construir aplicaciones como microservicios.
Tiene ventajas desarrollar en microservicios? Claro. Los microservicios son versátiles, se pueden portar de una instalación on-premise a cloud en segundos (y viceversa), son fáciles de escalar y de mejorar de forma constante, mejora las tolerancias a fallas. Pero también tienen contras. Por ejemplo, hemos visto que las pruebas integrales son mas complicadas, es necesario evitar la expansión sin control dado que son difíciles de gestionar y controlar, algo que puede ser minimizado recurriendo a procesos automatizados de orquestacion.
Mientras redactaba esta nota me tope con este manual técnico de Manuel Barrios sobre Docker. Para los sysadmin de la vieja escuela, les recomiendo la lectura.https://blog.mymware.com/2019/03/19/docker-desde-cero-p1.html
La idea de la nota no era desalentar el shift&lift, muy por el contrario, larga vida!
Entendiendo bien cada caso puntual tiene muchos beneficios que tienen que ver con mayor eficiencia, disminución de recursos de hardware, reducción de costos de licenciamiento, portabilidad y muchas otras ventajas.
[popup_anything id=”2076″]