Microservicios, dockers, kubernetes, contenedores… Dentro de la transformación digital todos estos elementos están cobrando una inusitada importancia. Pero, ¿saben las empresas para qué sirven? ¿Los emplean? ¿Qué beneficios pueden sacar? Intenteramos resolver las dudas en este artículo.
Empezaremos analizando qué es cada cosa. En realidad todo se basa en la arquitectura de microservicios, un elemento que está cobrando especial relevancia en los últimos tiempos. Esta arquitectura no existiría sin los contenedores y orquestadores. La gran ventaja que ofrece una arquitectura de microservicios es su agilidad. Y es que, antes de su aparición, todo se basaba en arquitecturas monolíticas y las distintas partes que conformaban un programa de software estaban acopladas y esto genera el problema de que, por ejemplo, todos esos programas no son escalables y es muy difícil añadir funcionalidades nuevas. Una arquitectura de microservicios permite que los servicios acoplados libremente se puedan desarrollar, implementar y mantener de forma independiente. Cada uno de estos servicios es responsable de tareas discretas y puede comunicarse con otros servicios a través de APIs simples para resolver un problema comercial complejo más grande.
En una arquitectura de microservicios, como su propio nombre indica, los servicios son pequeños. La gran ventaja de ello es que gracias a ese tamaño pueden ser construidos por uno o más equipos pequeños desde el principio y puede ser separados por límites de servicio que facilitan la ampliación del esfuerzo de desarrollo si es necesario. Además, una vez que esos microservicios se han desarrollado se pueden implementar de forma independiente entre sí y, por lo tanto, es fácil identificarlos lo que posibilita que puedan ser escalados independientemente de la aplicación completa.
Otra ventaja añadida es que los microservicios también ofrecen un mejor aislamiento de fallos, por lo que en el caso de que se produzca un error en un servicio, la aplicación completa no tiene por qué dejar de funcionar. Una vez que el error se ha solucionado, se puede implementar solo para el servicio respectivo en lugar de volver a implementar una aplicación completa. Además, en una arquitectura de microservicios se puede elegir el lenguaje de programación o la base de datos que se adapte mejor a la funcionalidad requerida (servicio) en lugar de tener que tomar una más estandarizada.
Las aplicaciones creadas como un conjunto de componentes modulares independientes son más fáciles de probar, mantener y comprender. Gracias a ello se incrementa la agilidad, se mejoran los flujos de trabajo y se disminuye la cantidad de tiempo que se necesita para mejorar la producción. Los microservicios son en general una gran opción para situaciones en las que los desarrolladores no pueden predecir completamente a qué dispositivos accederá la aplicación en el futuro. Además, permiten cambios rápidos y controlados en el software sin ralentizar la aplicación en su conjunto, por lo que puede ser más repetitivo en el desarrollo de funciones y nuevos productos. Desde Red Hat, dan algunas claves de las ventajas que ofrecen los microservicios:
– Aplicaciones listas para comercializarse más rápidamente: Debido a la reducción de los ciclos de desarrollo, una arquitectura de microservicios permite que la implementación y las actualizaciones se realicen más rápidamente.
– Gran capacidad de expansión: A medida que crece la demanda de ciertos servicios, es posible realizar implementaciones en distintos servidores e infraestructuras para satisfacer sus necesidades.
– Capacidad de recuperación: Si estos servicios independientes están bien diseñados, no pueden afectar a los demás. Esto significa que si una parte falla, no afecta a toda la aplicación, a diferencia del modelo de aplicaciones monolíticas.
– Facilidad de implementación: Debido a que las aplicaciones basadas en microservicios son más modulares y más pequeñas que las aplicaciones monolíticas tradicionales, ya no es necesario preocuparse por su implementación. Se requiere más coordinación, pero las ventajas son enormes.
– Accesibilidad: Dado que las aplicaciones más grandes se desglosan en piezas más pequeñas, los desarrolladores pueden comprender, actualizar y mejorar más fácilmente esas piezas; de esta manera, se obtienen ciclos de desarrollo más rápidos, especialmente cuando se combinan con metodologías de desarrollo ágiles.
– Aplicaciones más abiertas: Debido al uso de API políglotas, los desarrolladores tienen la libertad de elegir los mejores lenguajes y tecnologías para la función que se necesita.
Contenedores, Kubernetes y docker…
Para que se pueda desarrollar un arquitectura de microservicios el papel que juegan los contenedores y los orquestadores es fundamental. ¿Y cuál es cual? Docker son los contenedores, el que tiene la información necesaria para desarrollar una aplicación y kubernetes es el orquestador, algo así como el director de orquesta que coordina a todos los contenedores. Docker lidera el mercado de contenedores pero, por supuesto tiene alternativas. En el caso de kubernetes, se ha convertido en el estándar de facto para gestionar los contenedores, ya sean Docker u otros. Pero, ¿distinguen las empresas entre todas esas tecnologías? Para, Francisco José Verdugo, Senior Partner Solution Engineer de VMware, “cada vez hay más conocimiento en la mayoría de las empresas acerca de contenedores y la mayoría saben que Dockers es un runtime (sistema operativo) para contenedores y que Kubernetes es un gestor de contenedores. En general los desarrolladores tienen una estrategia al respecto que pueden ir desde el “ahora no es el momento” pasando por “en X tiempo comenzaremos” y llegando al “ya estamos desarrollando aplicaciones nativas cloud”.
Juanjo García, director de la unidad de negocio de Cloud de Microsoft en España, afirma que “la conversación en torno al uso de Kubernetes o Docker suele limitarse a decidir si usar uno u otro. Es necesario tener en cuenta que una diferencia fundamental entre ambos es que Kubernetes se diseñó para ejecutarse en un clúster, mientras que Docker se ejecuta en un nodo único. No se trata de elegir entre uno u otro, ya que son básicamente tecnologías distintas que funcionan bien de forma conjunta para compilar, entregar y escalar aplicaciones en contenedores”.
La tecnología de contenedores Docker se lanzó en 2013 como un motor Docker de código abierto . Aprovechó los conceptos informáticos existentes en torno a los contenedores y, específicamente, en el mundo de Linux, las primitivas conocidas como cgroups y namespaces. La tecnología de Docker es única porque se centra en los requisitos de los desarrolladores y operadores de sistemas para separar las dependencias de las aplicaciones de la infraestructura.
Y es que Docker es una tecnología de código abierto -y un formato de archivo de contenedor-, que permite automatizar la implementación de aplicaciones como contenedores portables que pueden ejecutarse en la nube o en entornos locales. Tal y como señala García, “Docker ha crecido hasta convertirse en el formato de contenedor predeterminado en los últimos años. Su entorno de ejecución, Docker Engine, permite compilar y ejecutar contenedores en cualquier equipo de desarrollo y, después, almacenar o compartir imágenes de contenedor mediante un registro de contenedor, como Docker Hub o Azure Container Registry”.
La tecnología de contenedores Docker se lanzó en 2013 como un motor Docker de código abierto
Pero, ¿qué es un contenedor? En general es una unidad estándar de software que empaqueta el código y todas sus dependencias para que la aplicación se ejecute de forma rápida y confiable de un entorno informático a otro. Una imagen de contenedor de Docker es un paquete de software ligero, independiente y ejecutable que incluye todo lo necesario para ejecutar una aplicación: código, tiempo de ejecución, herramientas del sistema, bibliotecas del sistema y configuraciones.
Las imágenes de contenedor se convierten en contenedores en tiempo de ejecución y, en el caso de los contenedores de Docker, las imágenes se convierten en contenedores cuando se ejecutan en Docker Engine. Está disponible para aplicaciones basadas en Linux y Windows con la gran ventaja de que el software en contenedores siempre se ejecutará de la misma manera, independientemente de la infraestructura. Los contenedores aíslan el software de su entorno y garantizan que funcione de manera uniforme a pesar de las diferencias, por ejemplo, entre el desarrollo y la puesta en escena.
Lo cierto es que la tecnología de contenedores está experimentando un crecimiento exponencial. Ven en ella una agilidad que de otra forma sería imposible implementar. Y gracias a ellos, pueden conseguir sus objetivos de forma mucho más rápida. Para Ramón Gordillo, Principal Solution Architect de Red Hat, “la orientación de las compañías respecto a los contenedores debería basarse en apoyarse en estas tecnologías y en otras para ser catalizadores de un cambio cultural centrado en sus clientes. En este sentido, Red Hat tiene un programa de adopción tecnológica cimentada en modelos ágiles y apoyado en las tecnologías de contenedores que ayuda a conseguir los mejores beneficios de la tecnología. En mi opinión, las empresas españolas son conscientes de que la tecnología de contenedores ha llegado para quedarse, y tenemos muchos ejemplos de empresas españolas que los están usando en la actualidad. Todas estas organizaciones son conscientes de que la tecnología de contenedores Linux conlleva un cambio en el plano operativo, pero, además, para aprovecharla al máximo, también en los procesos y la cultura de la organización. Además de adoptar la nueva tecnología, las empresas están inmersas en la adopción de métodos de desarrollo ágil y una cultura DevOps”.
Oracle es otra de las empresas que están haciendo un mayor hincapié en el mundo de los contenedores. Borja Gómez, Business Development Manager Cloud Innovation en Oracle cree que “más que pensar en un tipo de empresa, debemos pensar en qué desarrollos vamos a hacer. ¿Es un desarrollo nuevo o tengo un software funcionando y necesito realizar alguna modificación? ¿tengo que implementar cambios constantemente, o solo un par de releases al año? ¿necesito elasticidad debido a un número de usuarios/peticiones que fluctúa? ¿tengo distintos equipos de desarrollo? ¿cuento con expertos in house o puedo contar con partners especializados? Todas estas preguntas nos acercan más a la respuesta, aunque no es única. Lo que sí puedo decir es que quizá la pregunta correcta sería ¿cómo hago para introducir de forma exitosa los contenedores en mi empresa?”.
¿Y kubernetes?
Como hemos dicho al principio, kubernetes es el orquestador. Es quien es capaz de coordinar a los contenedores. Se trata de una plataforma que fue desarrollada por primera vez por un equipo de Google y que posteriormente fue donada a la Cloud Native Computing Foundation (CNCF). No es la única opción para la gestión de contenedores, pero se ha convertido rápidamente en el estándar de facto. También conocida como k8s, automatiza las operaciones de contenedores de Linux. Además, elimina muchos de los procesos manuales involucrados en la implementación y el escalado de aplicaciones en contenedores pudiendo agrupar grupos de hosts que ejecutan contenedores de Linux, y Kubernetes ayuda a administrar esos clústeres de manera fácil y eficiente. Su principal ventaja parece clara: alivia la carga de configurar, implementar, administrar y monitorear incluso las aplicaciones en contenedores de mayor escala. También ayuda a los profesionales de TI a administrar los ciclos de vida de los contenedores y los ciclos de vida de las aplicaciones relacionadas, y problemas que incluyen la alta disponibilidad y el equilibrio de carga.
A medida que las aplicaciones crecen para abarcar varios contenedores implementados en diferentes servidores, administrarlas se hace también cada vez más complejo. ¿Cómo se coordinan y programan varios contenedores? ¿Cómo se comunican entre sí los distintos contenedores de su aplicación? ¿Cómo se escalan distintas instancias de contenedor? Aquí es donde Kubernetes puede resultar útil. El director de la unidad de negocio Cloud de Microsoft afirma que “si nos centramos en Kubernetes, formalmente hablamos de un software de orquestación de código abierto que ofrece una API para controlar la forma y el lugar en que se ejecutarán los contenedores. Permite ejecutar contenedores y cargas de trabajo de Docker y dar solución a algunas de las complejidades de funcionamiento al escalar diferentes contenedores implementados en varios servidores. Kubernetes simplifica la organización de un clúster de máquinas virtuales y programar los contenedores para que se ejecuten en esas máquinas según los recursos de proceso disponibles y los requisitos de recursos de cada contenedor. Gracias a esto es posible escalar los contenedores y pods -unidad operativa básica de Kubernetes, producto de la agrupación de contenedores-, hasta el estado deseado y administrar su ciclo de vida para mantener las aplicaciones en funcionamiento aprovechando la escalabilidad y flexibilidad que confiere la nube”.
Pasar desde aplicaciones monolíticas
Como hemos visto el uso de contenedores tiene numerosas ventajas si las comparamos con las aplicaciones monolíticas tradicionales. El problema es que muchas aplicaciones empresariales ya están desarrolladas en esos entornos. Así que ¿cómo pasan las empresas de un entorno de aplicaciones monolíticas a otro de contenedores? El portavoz de Red Hat asegura que “la mayoría de las empresas están abordando los entornos de contenedores para aplicaciones nuevas y orientadas a servicios, donde no tienen la herencia ni las limitaciones de las arquitecturas y los procesos tradicionales. Poco a poco los monolitos antiguos están siendo reducidos funcionalmente allí donde es posible, conservando la parte que no se puede o no es rentable deconstruir en los sistemas tradicionales”. Por su parte, Borja Gómez de Oracle afirma que “todo en tecnología tiene un punto de moda, y los contenedores empezaron siendo algo “cool” para los desarrolladores y que todos querían probar, pero el éxito en este caso viene determinado por dar respuesta también a las necesidades de negocio: menor time-to-market, más facilidad en las fases de test/certificación, facilidad para tener equipos de desarrollo independientes o deslocalizados, despliegue más modular que permite obtener todos los beneficios del cloud como la escalabilidad y el pago por uso… Los contenedores son una de las bases en las que se sustentan las arquitecturas Cloud-Native, y es lo que buscan las empresas a día de hoy”.
Pero el hecho de tener aplicaciones monolíticas no quiere decir que sea imposible pasar a un entorno de contenedores. El objetivo de migrar desde un entorno monolítico a otro de contenedores es proporcionar un entorno más ágil y escalable para las funciones individuales del sitio, en el que las funciones se pueden administrar y actualizar con mayor facilidad que si fuesen parte de la plataforma monolítica. Ejecutar en un entorno de este tipo genera mejoras más rápidas en cada función migrada, lo que proporciona valor a los usuarios durante el proceso. En este sentido, Francisco Verdugo cree que es posible “estableciendo una estrategia que implica la conversión de esas aplicaciones antiguas y monolíticas a otras basadas en microservicios que serán más fáciles de mantener, más ágiles y que, a largo plazo, permitirán reducir costes y ser escaladas de forma ilimitada”.
Para el portavoz de Red Hat, lo que hay que tener en cuenta es que “las importantes mejoras de los contenedores no se centran en el rendimiento, si bien algunas veces lo consiguen con modelos elásticos más versátiles y de menor consumo. Los microservicios permiten una mayor autonomía e independencia de los equipos que los desarrollan, derivando en una mayor agilidad y disminución del “time-to-market” de las aplicaciones. Las aplicaciones monolíticas pueden ejecutarse sobre contenedores, pero esas mejoras de agilidad no pueden obtenerse de la misma forma por la interdependencia de los equipos y los desarrollos. Los contenedores han sido clave en el desarrollo de los microservicios, porque han llevado la misma independencia y autonomía a los entornos de ejecución. Sin ellos, los microservicios tendrían la mitad del camino recorrido, pero les faltaría esa agilidad operativa que los contenedores proporcionan”.
Seguridad
Al trabajar en entornos de infraestructura compartida, algunos especialistas destacan los problemas de seguridad que se pueden dar en un entorno de contenedores, lo que provocaría interrupciones del sistema. Lo cierto es que la seguridad puede ser uno de los elementos discordantes en todas las ventajas que conlleva el uso de contenedores. Desde Trend Micro afirman que la seguridad de contenedores es un proceso de implementación de políticas y herramientas de seguridad para garantizar que todo lo relativo a su contenedor funciona como debería. Esto incluye la protección de la infraestructura, la cadena de suministro de software o el tiempo de ejecución.
En este sentido, el proceso de protección de contenedores es un proceso continuo. Se debería integrar en su proceso de desarrollo, de forma automatizada para eliminar los puntos de contacto manuales y extendida en el mantenimiento y la operación de la infraestructura subyacente. Esto implica la protección de sus imágenes de contenedor en la canalización de desarrollo, de la plataforma del host en tiempo de ejecución y las capas de aplicación. La implementación de la seguridad como parte del ciclo de vida de entrega continua implica la reducción del riesgo y de las vulnerabilidades de su empresa en la siempre cambiante superficie de ataque.
Cuando se trata de proteger los contenedores, las principales inquietudes giran en torno a:
La seguridad del host del contenedor
El tráfico de red del contenedor
La seguridad de su aplicación en el contenedor
El comportamiento malicioso en su aplicación
La protección de su pila de administración de contenedores
Las capas principales de su aplicación
La integridad de la canalización de desarrollo
Ramón Gordillo, de Red Hat considera que “los contenedores son igual o más seguros que las infraestructuras tradicionales, y permiten un aislamiento similar o mayor que el de ellas. Algunos comentarios críticos acerca de la seguridad se centran en que, al igual que en otros aspectos, han aparecido nuevas capacidades relativas a la seguridad que se aplican en estos modelos nativos cloud y que muchas veces no se comprenden bien. Junto a las metodologías ágiles y los modelos devops, ha surgido recientemente el DevSecOps que permite incluir la seguridad dentro de esos modelos ágiles. Desde Red Hat se apuesta claramente por los entornos seguros a todos los niveles, y en el mundo de contenedores se ha incorporado recientemente la tecnología que proviene de la adquisición de la compañía StackRox, que es un referente en el ámbito de seguridad en contenedores”.
Los contenedores son igual o más seguros que las infraestructuras tradicionales
Pero lo cierto es que la parte a la parte de la seguridad todavía le queda camino por recorrer, ya que como asegura Francisco Verdugo de VMware, “la seguridad es el gran desconocido en el mundo del desarrollo de aplicaciones. Por eso se antoja imprescindible la figura del DevSecOps como responsable de la gobernanza de la seguridad en escenarios de Kubernetes, puestos que tienen sus propios desafíos que no suelen ser los mismos que en un escenario “tradicional”.
