¿Qué compone una plataforma de contenedores?

Recién terminada la DockerCon y el anuncio de Docker Enterprise 3.0, una plataforma de contenedores “end-to-end” y “dev-to-cloud”, voy compartir algunas ideas sobre lo que queremos decir cuando se habla de una “plataforma de contenedores completa”. Elección y flexibilidad Una solución completa tiene que satisfacer las necesidades de diferentes tipos de aplicaciones y usuarios, no sólo proyectos nativos en la …

Recién terminada la DockerCon y el anuncio de Docker Enterprise 3.0, una plataforma de contenedores “end-to-end” y “dev-to-cloud”, voy compartir algunas ideas sobre lo que queremos decir cuando se habla de una “plataforma de contenedores completa”.

Elección y flexibilidad

Una solución completa tiene que satisfacer las necesidades de diferentes tipos de aplicaciones y usuarios, no sólo proyectos nativos en la nube, sino también aplicaciones heredadas y abandonadas tanto en Linux como en Windows. A un alto nivel, uno de los objetivos de la modernización – la razón principal por la que las organizaciones están adoptando plataformas de contenedores – es deshacernos de la “deuda técnica”. Las organizaciones quieren tener la libertad de crear sus aplicaciones basándose en el stack “correcto” y ejecutándolas en el lugar “correcto”, aunque lo que es “correcto” puede variar de una aplicación a otra. Por tanto, la plataforma de contenedores que ejecuta esas aplicaciones debe ser flexible y abierta para satisfacer esas necesidades, en lugar de vincular de forma rígida a los equipos de aplicaciones a un único sistema operativo o modelo de virtualización y nube.

Innovación a alta velocidad

Para ofrecer innovación a alta velocidad, los desarrolladores son un componente clave para la plataforma de contenedores. Esto significa que la plataforma de contenedores debe extenderse a lo largo del entorno, de modo que los desarrolladores estén construyendo y probando sobre las mismas API que se utilizarán en los entornos de producción.

La plataforma de elección debe tener herramientas que se integren en el flujo de trabajo preferido de los desarrolladores, en lugar de forzarles a utilizar una herramienta nueva o diferente, o un flujo de trabajo completamente nuevo que sólo funcione para un patrón de implementación.

La plataforma de elección debe tener herramientas que se integren en el flujo de trabajo preferido de los desarrolladores, en lugar de forzarles a utilizar una herramienta nueva o diferente, o un flujo de trabajo completamente nuevo que sólo funcione para un patrón de implementación. Los desarrolladores son contratados por su capacidad creativa para resolver problemas con el código, lo que significa que adoptar una plataforma que requiere que sus equipos abandonen su intuición y conocimientos previos en favor de otras herramientas que sólo funcionan con una metodología prescriptiva, no sólo ralentiza la innovación, sino que también aumenta el riesgo de que los desarrolladores abandonen los procesos aprobados por IT para llevar a cabo el trabajo.

El número de expertos en Kubernetes es realmente escaso, por lo que si la plataforma de elección requiere que los administradores y operadores conozcan Kubernetes desde el primer día, además de aprender los entresijos de la plataforma de contenedores en sí misma, es fácil extenderse en más de 12 meses en formación, servicios, PoC y errores antes de que la plataforma de contenedores esté lista para su primera carga de trabajo “real”.

Además, Kubernetes es un orquestador de confianza y compatible con la el Docker Engine. La plataforma de contenedores debe estar construida sobre estos componentes fundamentales porque esto le dará una mayor flexibilidad en el futuro. Docker Enterprise y las principales nubes públicas utilizan Kubernetes y Docker engine porque son “opensource” y con un largo recorrido entre las tecnologías de contenedores.

Los equipos de operaciones también están interesados en la estabilidad de la plataforma. Las plataformas de contenedores reciben actualizaciones frecuentes, pero eso no significa que se le deba exigir que elimine y reemplace su plataforma de contenedores cada dos años, y junto con ello todas las habilidades, scripts y otras herramientas que sus equipos de operaciones construyeron alrededor de la plataforma con el paso del tiempo. Cuando se añadió Kubernetes en Docker Enterprise 2.0, fue una actualización importante, pero hicieron esa actualización lo más simple posible, incluyendo continuar proporcionando y desarrollando Docker Swarm.

Seguridad intrínseca

Por último, pero no por ello menos importante, la seguridad debe estar integrada en todas las capas de la plataforma. Con el avance hacia versiones de software más actuales, eficientes y rápidas, la seguridad tiene que ser parte tanto de la experiencia del desarrollador como de la del operador. Pero la seguridad no puede ser restrictiva u obstructiva, ya que nadie querría usar la plataforma. Debería tener pasarelas que ayuden a los desarrolladores a empezar rápidamente con buenos cimientos y buenas prácticas conocidas, en lugar de descubrir más tarde que algo está “roto” o funciona incorrectamente. La plataforma debería darle visibilidad a cada aplicación que envíe: Windows o Linux, Edge o centros de datos. Por tanto, la seguridad debe ser un componente fundamental de la plataforma de contenedores y eso incluye también la seguridad de sus aplicaciones en ejecución.

Conclusión

Como hemos podido ver en el artículo, es importante conocer los componentes de la plataforma de contenedores, ya que en gran medida van a influir en los equipos de desarrollo y producción, así como en las apps y servicios que se vayan a ir desplegando.

Por otro lado, es importante tener una buena base, que se conseguirá a base de formación certificada por profesionales. Uno de los grandes problemas a los que estamos sometidos actualmente es a la poca calidad de la formación que se encuentra por la red, que genera vicios y malas prácticas, que se van trasladando desde el desarrollo hasta los entornos de producción, lo que supone un grave problema de seguridad.