Los Contenedores: Preguntas y Respuestas

 ¿Para qué nacieron las Computadoras? Para resolver problemas. Sí. Ya son legendarias las aventuras de Alan Turing, su equipo de trabajo y todos los esfuerzos por parte del gobierno británico para descifrar o más bien decriptar los mensajes generados con la máquina "Enigma" de los nacionales socialistas alemanes (nazis).

También las computadoras se han aplicado para analizar datos, ordenarlos (por eso en España se les dice "ordenadores") clasificarlos, realizar operaciones matemática e iterando algoritmos (que deriva del nombre del matemático árabe Abu Abdallah Muḥammad Ibn Mūsā Al-Jwarizmī).

Son precisamente esos algoritmos lo que hace que un grupo de personas, los Programadores, puedan "ecribir" Programas de Cómputo y que estos al ejecutarse en el Hardware, realmente le den sentido a las Computadoras.

Durante mucho tiempo, sin importar el lenguaje de cómputo, se seguían los lineamientos y cánones de la Programación en Cascada.

La Programación en Cascada

Más comúnmente conocida como el modelo de desarrollo de software en cascada, es una metodología secuencial que se ha utilizado tradicionalmente en la ingeniería de software. Este modelo se caracteriza por una serie de fases claramente definidas y ordenadas, donde cada fase debe completarse antes de pasar a la siguiente. Aquí te detallo sus características principales y cómo se desarrolla:

Secuencialidad: El proceso sigue una secuencia lineal desde el inicio del proyecto hasta su conclusión, sin retroceder a fases anteriores.

Estructura Fija: Las fases del proyecto son fijas y se completan una tras otra en orden específico: Requisitos, Diseño, Implementación, Verificación, y Mantenimiento.

Documentación Completa: Cada fase produce documentos que sirven como entrada para la siguiente fase. Esto significa que antes de escribir código, se realiza una extensa documentación de los requisitos y el diseño.

Revisiones y Aprobaciones: Al final de cada fase, el trabajo realizado se revisa y debe ser aprobado antes de pasar a la siguiente etapa.

Las Fases del Modelo en Cascada incluyen:

• Análisis de Requisitos: Se identifican las necesidades del sistema y se documentan de manera detallada. Es la base para el diseño del sistema.
• Diseño del Sistema y del Software: Basándose en los requisitos, se elabora una arquitectura de cómo el software funcionará internamente y en interacción con otros sistemas o con el usuario.
• Implementación y Codificación: Los diseñadores comienzan a escribir el código del software según las especificaciones del diseño.
• Pruebas: El software se prueba para identificar y corregir errores. Se verifica que cumpla con los requisitos especificados.
• Despliegue: Una vez que el software ha sido probado y se considera listo, se instala o se libera para su uso.
• Mantenimiento: Después del lanzamiento, el software entra en una fase de mantenimiento para corregir errores no identificados previamente o para realizar actualizaciones.

¿Cuáles son las Ventajas y Desventajas de este modelo de programación?:

Ventajas:

• Predecible: Las etapas y resultados están claramente definidos, lo que facilita la planificación y el presupuesto.
• Estructura: La metodología en cascada es fácil de entender y seguir, especialmente para proyectos simples y pequeños.

Desventajas:

• Rigidez: La dificultad para volver a fases anteriores puede resultar en problemas si los requisitos cambian durante el desarrollo.
• Retrasos en la Prueba: Las pruebas se realizan al final del ciclo de vida, lo que puede resultar en la detección tardía de errores fundamentales.
• Dificultad con Requisitos Complejos o Cambiantes: No es ideal para proyectos donde los requisitos no están bien definidos desde el principio o son propensos a cambiar.

Aunque el modelo en cascada ha sido criticado por su rigidez y por no adaptarse bien a los proyectos donde los requisitos son inciertos o cambiantes, sigue siendo una metodología valiosa para ciertos tipos de proyectos con requisitos bien definidos y donde los cambios son mínimos o nulos.

Precisamente por su rigidez y como resultado de un cada vez más cambiante ambiente de operación para cualquier programa de cómputo, así como también la necesidad de incluir más dinámicos, flexibles y versátiles ambientes de ejecución, es por lo que se buscó un enfoque diferente y obviamente un modelo de programación que pudiese cumplir con todos estos nuevos requisitos. Es entonces que nace el Modelo de Programación basado en Microservicios.

La Programación Basado en Microservicios

El modelo de programación basado en microservicios representa un enfoque arquitectónico para el desarrollo de aplicaciones. En lugar de construir una aplicación monolítica grande (o inmensa en ocasiones), el enfoque de microservicios descompone o más bien parte la aplicación en componentes más pequeños y manejables, conocidos como microservicios. Estos microservicios son independientes entre sí, cada uno ejecutando un proceso único y gestionando una parte específica de la funcionalidad de la aplicación.

A continuación enumeramos cuáles son las características principales, cómo funcionan, y las ventajas y desventajas de este modelo basado en microservicios.

Características Principales:

Desacoplamiento: Cada microservicio es independiente y responsable de una función específica dentro de la aplicación. Esto permite que se desarrollen, desplieguen, y escalen de manera independiente.

Especialización: Los microservicios se centran en una sola tarea o proceso, siguiendo el principio de responsabilidad única. Esto facilita la comprensión, el desarrollo y el mantenimiento del código.

Comunicación a través de API: Los microservicios interactúan entre sí mediante interfaces de programación de aplicaciones (APIs), generalmente sobre protocolos HTTP/HTTPS con patrones de comunicación REST o GraphQL.

Tecnología Diversa: Cada microservicio puede ser desarrollado utilizando el lenguaje de programación, base de datos, o tecnología de almacenamiento más adecuado para su función específica.

Funcionamiento:

• Una aplicación basada en microservicios se compone de varios servicios pequeños que se comunican a través de la red.
• Cada servicio tiene su propia base de datos y lógica de negocio, lo que permite su desarrollo y escalabilidad de manera independiente.
• Los servicios se despliegan típicamente en contenedores, lo que facilita su replicación y gestión a través de plataformas de orquestación como Kubernetes.

Ventajas:

• Flexibilidad Tecnológica: Permite el uso de diferentes tecnologías y lenguajes de programación según las necesidades específicas del servicio.
• Escalabilidad: Los servicios pueden escalarse independientemente, mejorando el uso de recursos y la capacidad de respuesta ante cargas variables.
• Resiliencia: El fallo en un microservicio no necesariamente causa un fallo en toda la aplicación, lo que mejora la disponibilidad y confiabilidad del sistema.
• Facilita la Integración Continua y la Entrega Continua (CI/CD): La independencia de los servicios facilita la actualización, el testing y el despliegue rápido y frecuente de nuevas características.

Desventajas:

• Complejidad de Gestión: El manejo de múltiples servicios y su intercomunicación puede resultar en una complejidad operativa significativa.
• Consistencia de Datos: Mantener la consistencia a través de los servicios puede ser desafiante, especialmente en transacciones que abarcan múltiples servicios.
• Latencia: La comunicación entre servicios a través de la red puede introducir latencia.
• Sobrecarga de Desarrollo: El diseño e implementación inicial pueden requerir más trabajo comparado con una aplicación monolítica debido a la planificación de la interacción entre servicios.

El enfoque de microservicios es particularmente adecuado para aplicaciones empresariales grandes y complejas, donde la capacidad de escalar y actualizar componentes de manera independiente puede ofrecer ventajas significativas en términos de agilidad y mantenibilidad.

Queremos aquí hacer una pausa, pues como veremos más delante en esta entrada, Microservicios es un Modelo de Programación, pero los Contenedores son una manera de llevar a la práctica este modelo de programación y no por ello presentar las mismas desventajas.

¿Qué son los Contenedores?

Los contenedores son una tecnología de virtualización a nivel de sistema operativo que permite empaquetar y distribuir aplicaciones y sus dependencias de manera ligera y portátil. Cada contenedor encapsula una aplicación, junto con todas sus bibliotecas y archivos necesarios para ejecutarse, en un entorno aislado y autocontenido.

Aquí hay algunas características clave de los contenedores:

Aislamiento: Cada contenedor ejecuta su propia instancia del sistema operativo, lo que proporciona un alto grado de aislamiento y seguridad. Los contenedores comparten los recursos del sistema subyacente, como el kernel del sistema operativo, pero tienen sus propios espacios de nombres para procesos, red, almacenamiento, etc.

Portabilidad: Los contenedores son portátiles y se pueden ejecutar en cualquier entorno que admita el motor de contenedores utilizado. Esto significa que una aplicación empaquetada en un contenedor funcionará de la misma manera, independientemente de si se ejecuta en un entorno de desarrollo, pruebas o producción.

Eficiencia: Los contenedores son ligeros y rápidos de crear y destruir. Comparados con las máquinas virtuales tradicionales, que incluyen un sistema operativo completo, los contenedores comparten el núcleo del sistema operativo subyacente, lo que reduce la sobrecarga y el consumo de recursos.

Escalabilidad: Los contenedores facilitan la implementación de aplicaciones en entornos de infraestructura escalables y distribuidos. Pueden escalarse horizontalmente de manera rápida y eficiente para satisfacer las demandas cambiantes de la carga de trabajo.

Orquestación: Para gestionar y coordinar un gran número de contenedores en entornos de producción, se utilizan herramientas de orquestación de contenedores como Kubernetes, Docker Swarm o Amazon ECS. Estas herramientas permiten automatizar tareas como el despliegue, la escalabilidad, la monitorización y la recuperación ante fallos de los contenedores.

Cierto es que a la fecha en la que esta entrada fue creada, los contenedores ya no son unos completos desconocidos y el crecimiento de adopción de éstos ha sido descomunal, pero sí vale la pena (sobre todo para quienes son novatos en este tema) revisar

¿Qué SÍ son y qué NO son los Contenedores?

Qué SÍ son los contenedores:

• Sí son entornos aislados: Los contenedores encapsulan una aplicación y todas sus dependencias en un entorno aislado del resto del sistema, lo que garantiza que funcionen de manera consistente y sin conflictos con otras aplicaciones.
• Sí ofrecen portabilidad: Los contenedores son portátiles y pueden ejecutarse en cualquier entorno que admita el motor de contenedores utilizado, lo que facilita el desarrollo, la prueba y la implementación de aplicaciones en diferentes entornos de forma consistente.
• Sí son eficientes: Los contenedores son ligeros y rápidos de crear y destruir, lo que los hace ideales para implementaciones rápidas y escalables de aplicaciones.
• Sí son escalables: Los contenedores pueden escalarse horizontalmente fácilmente para satisfacer las demandas cambiantes de la carga de trabajo, lo que los hace ideales para aplicaciones en la nube y en entornos distribuidos.

Qué NO son los contenedores:

• No son máquinas virtuales: A diferencia de las máquinas virtuales, los contenedores no incluyen un sistema operativo completo. En su lugar, comparten el kernel del sistema operativo subyacente y solo encapsulan las bibliotecas y dependencias necesarias para ejecutar la aplicación.
• No son un reemplazo de la virtualización tradicional: Aunque los contenedores ofrecen muchas ventajas en términos de eficiencia y portabilidad, no reemplazan por completo la virtualización tradicional. Ambas tecnologías pueden coexistir y ofrecer beneficios complementarios en entornos de desarrollo y producción.
• No son una solución de seguridad completa: Aunque los contenedores ofrecen un cierto grado de aislamiento y seguridad, no son una solución de seguridad completa por sí solos. Se deben implementar medidas adicionales, como políticas de acceso y control de seguridad, para proteger los contenedores y las aplicaciones que contienen.

MUY IMPORTANTE

Los contenedores son una herramienta poderosa para empaquetar y distribuir aplicaciones de manera eficiente y portátil, pero es importante comprender sus características y limitaciones para aprovechar al máximo su potencial.

¿Qué empresas son actualmente los más importantes e influyentes exponentes de los Contenedores?

Hay varias empresas que han sido influyentes en el desarrollo y la adopción de contenedores. Algunas de las más destacadas incluyen:

Docker, Inc.: Docker es la empresa que popularizó la tecnología de contenedores al crear la plataforma Docker. Su enfoque en la facilidad de uso y la portabilidad ayudó a impulsar la adopción masiva de contenedores en la industria de la tecnología.

Google: Google ha desempeñado un papel fundamental en el desarrollo de la tecnología de contenedores. Contribuyeron al desarrollo de Kubernetes, un sistema de orquestación de contenedores de código abierto, que se ha convertido en el estándar de facto para administrar contenedores a escala.

Red Hat: Red Hat ha sido un líder en la adopción de contenedores en el mundo empresarial. Contribuyeron al desarrollo de herramientas como Kubernetes y OpenShift, una plataforma de contenedores empresariales basada en Kubernetes.

Amazon Web Services (AWS): AWS ofrece una amplia gama de servicios de contenedores, incluyendo Amazon ECS (Elastic Container Service) y Amazon EKS (Elastic Kubernetes Service). Su infraestructura de nube escalable ha facilitado la adopción de contenedores en empresas de todos los tamaños.

Microsoft: Microsoft ha integrado el soporte para contenedores en su plataforma en la nube Azure, así como en su sistema operativo Windows Server. Han contribuido al desarrollo de herramientas como Docker Desktop for Windows y Azure Kubernetes Service (AKS).

VMware: VMware ha expandido su oferta para incluir soluciones de contenedores a través de productos como VMware Tanzu y vSphere Integrated Containers. Su experiencia en virtualización ha ayudado a las empresas a integrar contenedores en sus infraestructuras existentes.

CoreOS (ahora parte de Red Hat): CoreOS fue una empresa pionera en el desarrollo de sistemas operativos optimizados para contenedores. Su sistema operativo CoreOS Container Linux y su plataforma de orquestación de contenedores Tectonic contribuyeron al avance de la tecnología de contenedores en la industria.

Estas son solo algunas de las empresas que han desempeñado un papel importante en el desarrollo y la adopción de contenedores. Hay muchas otras organizaciones y líderes en la comunidad de código abierto que también han contribuido al éxito de esta tecnología.

¿Qué liboros y/o guías básicas hay ya disponibles para el entendimiento y aprendizaje de los Contenedores?

Aquí compartimos una lista de libros y guías básicas que pueden ser útiles para entender y aprender sobre contenedores:

"Docker Deep Dive" por Nigel Poulton: Este libro proporciona una introducción completa a Docker, desde los conceptos básicos hasta las características avanzadas. Es ideal tanto para principiantes como para usuarios experimentados.

"Kubernetes Up & Running" por Kelsey Hightower, Brendan Burns y Joe Beda: Este libro es una guía completa para comenzar con Kubernetes, la plataforma de orquestación de contenedores más popular. Cubre todo, desde los fundamentos hasta la implementación y la administración en producción.

"Docker in Action" por Jeff Nickoloff: Este libro cubre los conceptos básicos de Docker y cómo se puede utilizar para empaquetar, distribuir y ejecutar aplicaciones de manera eficiente. Proporciona ejemplos prácticos y consejos para trabajar con Docker en entornos reales.

"Containerization with Docker" por Russ McKendrick: Este libro es una guía práctica para comenzar con Docker, cubriendo temas como la instalación, la creación de imágenes de contenedores y la administración de contenedores en producción.

"The Kubernetes Book" por Nigel Poulton: Este libro es una guía detallada para comprender y trabajar con Kubernetes. Cubre desde los conceptos básicos hasta las prácticas recomendadas para implementar y administrar aplicaciones en Kubernetes.

"Learn Docker - Fundamentals of Docker 19.x" por Gabriel N. Schenker: Este libro es una introducción práctica a Docker, diseñada para aquellos que están comenzando con la tecnología de contenedores. Cubre los fundamentos y proporciona ejemplos paso a paso para comenzar a trabajar con Docker.

Documentación oficial de Docker y Kubernetes: Ambas comunidades ofrecen una amplia documentación en línea que cubre todos los aspectos de sus respectivas tecnologías. Estas guías son una excelente fuente de información para aprender sobre contenedores.

¿Qué debe de incluír un programa de estudios para una capacitación y formación completa en los Contenedores?

¿Desea ir más allá de lo que ofrecen los libros y la documentación? Entonces al parecer es necesario tomar un curso. ¿Qué debe de incluír un programa de estudios para una capacitación y formación completa en los Contenedores?

Un programa de estudios completo para la capacitación y formación en contenedores debe incluir una variedad de temas que cubran desde los fundamentos básicos hasta los aspectos más avanzados de la tecnología. Aquí hay una propuesta de los temas que podrían incluirse en dicho programa:

Introducción a los contenedores:

• Definición de contenedores y su importancia en el desarrollo de software moderno.
• Diferencias entre contenedores y máquinas virtuales.
• Historia y evolución de la tecnología de contenedores.

Conceptos básicos de Docker:

• Instalación y configuración de Docker en diferentes sistemas operativos.
• Creación y gestión de contenedores Docker.
• Uso de imágenes de Docker y registro de Docker Hub.
• Redes y almacenamiento en Docker.

Orquestación de contenedores con Kubernetes:

• Introducción a Kubernetes y su arquitectura.
• Instalación y configuración de un clúster de Kubernetes.
• Despliegue y escalado de aplicaciones en Kubernetes.
• Gestión de recursos y monitoreo en Kubernetes.

Desarrollo de aplicaciones basadas en contenedores:

• Desarrollo de aplicaciones utilizando Docker y Docker Compose.
• Uso de Docker en entornos de desarrollo local y en la nube.
• Integración de contenedores en pipelines de integración continua/despliegue continuo (CI/CD).

Seguridad y buenas prácticas en contenedores:

• Principios de seguridad en contenedores.
• Mejores prácticas para la creación de imágenes seguras.
• Configuración de políticas de acceso y control de seguridad en Kubernetes.

Optimización y rendimiento de contenedores:

• Estrategias para optimizar el tamaño y el rendimiento de las imágenes de Docker.
• Configuración de recursos y límites en contenedores.
• Estrategias de almacenamiento y gestión de datos en contenedores.

Casos de uso y estudios de casos:

• Aplicaciones de contenedores en diferentes industrias y sectores.
• Estudios de casos de empresas que han adoptado contenedores con éxito.
• Prácticas recomendadas y lecciones aprendidas de implementaciones reales.

Este es solo un ejemplo de los temas que podrían incluirse en un programa de estudios completo sobre contenedores. Es importante adaptar el contenido según las necesidades y el nivel de conocimiento de los estudiantes, así como incorporar ejercicios prácticos y proyectos para reforzar los conceptos aprendidos.

¿Qué alternativas existen en línea, para el aprendizaje, formación y capacitación en Contenedores?

Plataformas de cursos en línea:

• Udemy: Ofrece una amplia variedad de cursos sobre Docker, Kubernetes y contenedores en general, impartidos por instructores expertos.
• Coursera: Tiene cursos y especializaciones en contenedores ofrecidos por universidades y empresas líderes en tecnología.
• LinkedIn Learning: Ofrece una amplia gama de cursos y tutoriales sobre Docker, Kubernetes y desarrollo de contenedores.
• Pluralsight: Tiene cursos especializados en contenedores y orquestación de contenedores, diseñados para profesionales de la tecnología.
• edX: Ofrece cursos en línea gratuitos y de pago sobre contenedores, impartidos por universidades y organizaciones académicas.

Recursos gratuitos y de código abierto:

• Documentación oficial de Docker y Kubernetes: Ambas comunidades ofrecen una amplia documentación en línea que cubre todos los aspectos de sus respectivas tecnologías.
• Tutoriales y guías en blogs y sitios web: Hay muchos blogs y sitios web que ofrecen tutoriales y guías gratuitas sobre Docker, Kubernetes y contenedores en general.
• GitHub: Hay numerosos repositorios en GitHub con ejemplos de código, proyectos y recursos de aprendizaje relacionados con contenedores.

Cursos especializados y certificaciones:

• Certificaciones oficiales de Docker y Kubernetes: Tanto Docker como Kubernetes ofrecen programas de certificación oficial que pueden ayudar a validar tus habilidades en contenedores.
• Cursos especializados en plataformas de capacitación en línea: Algunas plataformas ofrecen cursos específicos para la preparación de certificaciones en Docker y Kubernetes.

Comunidades y grupos de usuarios:

• Participar en comunidades en línea, como foros, grupos de usuarios y canales de Slack relacionados con Docker y Kubernetes, puede ser una forma útil de aprender y compartir conocimientos con otros profesionales de contenedores.

¿Qué ambientes de ejecución (en máquinas físicas o virtuales) existen y cuáles son las mas recomendables para comenzar a aprender a programar y ejecutar contenedores?

Para comenzar a aprender a programar y ejecutar contenedores, es útil familiarizarse con los ambientes de ejecución que permiten manejar estas tecnologías eficientemente. La buena noticia es que podemos iniciar con herramientas relativamente sencillas que no requieren de infraestructuras complejas ni de grandes recursos de hardware. Aquí algunos de los entornos más populares y accesibles:

1. Docker

Docker es la plataforma de contenedores más popular y un excelente punto de partida para aprender sobre contenedores. Permite crear, desplegar y manejar contenedores de manera sencilla y eficiente. Docker puede ejecutarse tanto en máquinas físicas como virtuales y es compatible con múltiples sistemas operativos, incluyendo Linux, macOS y Windows. Para quienes inician, Docker ofrece una curva de aprendizaje amigable y una gran cantidad de documentación y recursos de aprendizaje.

2. Kubernetes

Aunque Kubernetes es más un sistema de orquestación de contenedores que un ambiente de ejecución per se, aprender a usarlo después de Docker es un paso natural. Kubernetes te permite manejar aplicaciones contenerizadas a gran escala. Es más complejo que Docker en términos de curva de aprendizaje, pero también es muy poderoso y ampliamente utilizado en la industria. Minikube es una herramienta que te permite ejecutar Kubernetes localmente en tu máquina (física o virtual), simplificando el proceso de aprendizaje y experimentación con Kubernetes.

3. Play with Docker (PWD)

Play with Docker es una herramienta en línea que proporciona un entorno Docker gratuito, accesible directamente desde tu navegador. Es una opción excelente para experimentar con Docker sin necesidad de instalar nada en tu máquina. Aunque no sustituye la experiencia de trabajar con Docker localmente, es una forma rápida de empezar a aprender y experimentar con contenedores.

4. Katacoda

Katacoda es una plataforma de aprendizaje interactivo que ofrece escenarios gratuitos y tutoriales en vivo para tecnologías como Docker y Kubernetes. Katacoda ejecuta contenedores y ambientes de orquestación directamente en tu navegador, lo que permite aprender y experimentar sin configuraciones complejas.

Recomendaciones para Principiantes

Para los principiantes, empezar con Docker en una máquina local es altamente recomendable. Esto se debe a que Docker simplifica muchos de los conceptos fundamentales de los contenedores y tiene una comunidad de soporte extensa. Una vez que te sientas cómodo con Docker, avanzar hacia Kubernetes utilizando Minikube o incluso Katacoda para experimentar sin necesidad de un entorno de hardware dedicado puede ser el siguiente paso lógico.

¿Qué Sistemas Operativos son más recomendables para ejecutar Contenedores?

Los contenedores son una tecnología que se ejecuta en sistemas operativos basados en Linux, por lo que cualquier distribución Linux es adecuada para ejecutar contenedores. Sin embargo, algunos sistemas operativos han sido diseñados específicamente con contenedores en mente y ofrecen características adicionales para administrar y desplegar contenedores de manera más eficiente. Aquí hay algunas opciones recomendadas:

Ubuntu: Es una de las distribuciones Linux más populares y ampliamente utilizadas para ejecutar contenedores. Es fácil de instalar, tiene una amplia base de usuarios y cuenta con una gran cantidad de documentación y soporte disponible.

Fedora CoreOS: Es una distribución de Linux optimizada para ejecutar contenedores en entornos de producción. Está diseñada para ser segura, estable y fácil de administrar, con actualizaciones automáticas y soporte nativo para Kubernetes.

Red Hat Enterprise Linux (RHEL): Es una distribución de Linux empresarial con soporte comercial proporcionado por Red Hat. Ofrece características avanzadas de seguridad y administración, así como soporte a largo plazo para entornos críticos.

CentOS: Es una distribución de Linux de código abierto basada en el código fuente de RHEL. Es una opción popular para entornos de servidor debido a su estabilidad y compatibilidad con aplicaciones empresariales.

Debian: Es una distribución de Linux conocida por su estabilidad y seguridad. Es una opción sólida para ejecutar contenedores, especialmente si prefieres un enfoque más conservador y de código abierto.

Arch Linux: Es una distribución de Linux para usuarios avanzados que prefieren construir su sistema desde cero. Si estás dispuesto a configurar tu sistema manualmente, Arch Linux puede ser una opción interesante para ejecutar contenedores.

¿Qué Lenguaje de Programación puedo utilizar para programar contenedores?

La belleza de los contenedores es que permiten empaquetar y ejecutar aplicaciones de manera consistente a través de diferentes entornos, independientemente del lenguaje de programación en que estas estén escritas. Esto significa que podemos utilizar prácticamente cualquier lenguaje de programación para desarrollar tu aplicación antes de contenerizarla. La elección del lenguaje dependerá de preferencias personales, requisitos del proyecto y el ecosistema del lenguaje. Algunos de los lenguajes de programación más comunes utilizados para desarrollar aplicaciones en contenedores incluyen:

Python: Gracias a su simplicidad y legibilidad, junto con una vasta biblioteca de módulos de terceros, Python es un favorito para el desarrollo de aplicaciones web, automatización, análisis de datos, aprendizaje automático, y más.

JavaScript (Node.js): Permite ejecutar JavaScript en el lado del servidor, lo que lo hace ideal para construir aplicaciones web escalables y en tiempo real. La popularidad de JavaScript y el ecosistema NPM ofrecen una gran flexibilidad para el desarrollo de aplicaciones modernas.

Go (Golang): Conocido por su simplicidad, eficiencia y soporte nativo para la concurrencia. Es ampliamente utilizado en el ecosistema de contenedores y microservicios, especialmente porque herramientas como Docker y Kubernetes están escritas en Go.

Java: Sigue siendo popular en entornos empresariales debido a su robustez, escalabilidad y vasto ecosistema. Las aplicaciones Java pueden ser fácilmente contenerizadas y desplegadas en cualquier entorno.

Ruby: En particular el framework Ruby on Rails, es una excelente opción para el desarrollo rápido de aplicaciones web. Aunque ha disminuido en popularidad frente a otros lenguajes más nuevos, sigue siendo una opción sólida para muchos proyectos.

.NET (C#): Con la evolución de .NET Core, las aplicaciones .NET pueden ejecutarse en Linux y contenerizarse fácilmente. Esto hace que C# sea una opción atractiva para el desarrollo de aplicaciones web, servicios, y aplicaciones de escritorio.

Rust: Está ganando popularidad debido a su enfoque en la seguridad y el rendimiento. Es una buena opción para sistemas y aplicaciones donde la eficiencia y la seguridad son críticas.

¿Cuáles son los pasos a seguir para armar un laboratorio casero para aprender a programar y probar contenedores?

1. Definamos Objetivos

Antes de comenzar, es importante saber qué se quiere lograr. Esto puede incluir aprender un lenguaje de programación específico, entender cómo funcionan los contenedores o desarrollar una aplicación concreta.

2. Eligir y Preparar el Hardware

Casi cualquier computadora moderna puede ser adecuada para trabajar con contenedores. Sin embargo, asegurémonos de tener suficiente memoria RAM (8 GB es un buen punto de partida, aunque 16 GB es ideal) y espacio en disco para las imágenes de los contenedores y los contenedores mismos.

3. Instalar un Sistema Operativo Compatible

Los sistemas operativos basados en Linux son ampliamente considerados como los más adecuados para el trabajo con contenedores, aunque Windows y macOS también soportan herramientas de contenedorización como Docker. Si está instalado Linux como Sistema Operativo por defecto, podemos instalarlo en una máquina virtual o usar una dual boot setup.

4. Instalar Docker o una Plataforma de Contenedores Similar

Docker es la plataforma de contenedorización más popular. Su instalación es sencilla y está bien documentada en su sitio web oficial. Otras opciones incluyen Podman, que es un daemon-less y se presenta como una alternativa a Docker.

• Para Linux: Encontraremos instrucciones específicas para la distribución en la documentación oficial de Docker.
• Para Windows y macOS: Docker Desktop es la opción recomendada. Hay que asegurarse de cumplir con los requisitos del sistema.

5. Aprender los Fundamentos de Docker y la Contenedorización

Antes de empezar a programar, es crucial entender los conceptos básicos de Docker y cómo funcionan los contenedores. Esto incluye imágenes de contenedores, contenedores, Dockerfiles, volúmenes, redes y el registro de Docker. Hay muchos cursos y tutoriales gratuitos disponibles en línea.

6. Eligir un Editor de Código o IDE

Es mejor utilizar un editor de código o un entorno de desarrollo integrado (IDE) que sea cómodo. Visual Studio Code, por ejemplo, es una opción popular y gratuita que soporta una amplia gama de lenguajes de programación y tiene extensiones para trabajar con Docker.

7. Comenzar con Proyectos Simples

Practicar creando imágenes de contenedores para aplicaciones sencillas en el lenguaje de programación de nuestra elección. Un proyecto típico de iniciación puede ser contenerizar una aplicación web básica o una API.

8. Experimentar con Orquestación de Contenedores

Una vez que estemos cómodo trabajando con contenedores individuales, consideremos aprender sobre orquestación de contenedores usando herramientas como Docker Compose en un inicio, seguido de Kubernetes para escenarios más complejos.

9. Participa en la Comunidad

Unirse a comunidades en línea, como foros de Docker, GitHub, o Stack Overflow, puede proporcionar soporte, nuevos conocimientos y oportunidades para resolver problemas reales de otros usuarios.

10. Mantén la Curiosidad y Continúa Aprendiendo

El campo de la contenedorización y la infraestructura como código está en constante evolución. Hay que mantenerse actualizado con las últimas tendencias, herramientas y mejores prácticas.

Si buscamos soluciones más enfocadas en ambientes de producción o en simulación de ambientes de producción, herramientas como Minikube (para Kubernetes) o Rancher Desktop pueden ser alternativas interesantes. Estas herramientas permiten gestionar clústeres de Kubernetes en una máquina local y están más orientadas hacia pruebas de orquestación y manejo a escala de contenedores.

Hablando concretamente de Minikube, es una herramienta que facilita la ejecución de Kubernetes localmente en la computadora de escritorio o la laptop. Está diseñada para desarrolladores o entusiastas de Kubernetes que desean experimentar o desarrollar con Kubernetes sin necesidad de desplegar un clúster de Kubernetes completo en la nube o en un entorno de servidor dedicado.

Características Principales de Minikube:

• Sencillez: Minikube inicia un clúster de Kubernetes de un solo nodo dentro de una máquina virtual (VM) en la máquina de escritorio o la laptop, lo que hace que sea fácil de instalar y ejecutar.
• Compatibilidad: Funciona en sistemas operativos Linux, Windows y macOS.
• Flexibilidad: Soporta diversas herramientas de virtualización, incluyendo VirtualBox, KVM, HyperKit, y más. También puede ejecutarse directamente en contenedores Docker si preferimos evitar usar una VM.
• Desarrollo Local: Proporciona un entorno ideal para aprender Kubernetes y experimentar con contenedores sin incurrir en costos de infraestructura de nube.
• Herramientas de Desarrollo: Minikube incluye características útiles para el desarrollo, como un Dashboard de Kubernetes, soporte para carga de configuración y volúmenes persistentes, y la capacidad de emular redes y condiciones de entorno específicas.

Cómo Funciona Minikube:

Al ejecutar Minikube, este crea y configura una máquina virtual que corre una distribución ligera de Linux. Dentro de esta VM, se inicia un clúster de Kubernetes de un solo nodo, permitiéndote desplegar y gestionar contenedores usando Kubernetes en tu máquina local.

Usos de Minikube:

• Aprendizaje de Kubernetes: Por ser un clúster de Kubernetes real, aunque sea de un solo nodo, Minikube es una excelente herramienta para aprender cómo funciona Kubernetes y cómo se despliegan y gestionan las aplicaciones en él.
• Desarrollo de Aplicaciones: Los desarrolladores pueden usar Minikube para desarrollar y probar aplicaciones en un entorno de Kubernetes local antes de desplegarlas en un entorno de producción o en la nube.
• Pruebas de Integración y Funcionalidad: Permite a los equipos de desarrollo probar nuevas características, configuraciones, y más, en un entorno controlado y fácilmente reproducible.

Inicio con Minikube:

Para empezar con Minikube, necesitamos instalarlo en nuestra máquina. La documentación oficial de Minikube proporciona instrucciones detalladas de instalación y uso para diferentes sistemas operativos. Una vez instalado, podemos iniciar tu clúster de Kubernetes con el comando minikube start y comenzar a experimentar con Kubernetes de manera local.

Conclusión

Aún queda mucho material que podríamos compartir en esta entrada, pero recomendamos más bien comenzar con todo lo que hemos incluido aquí y que sea su experiencia en particular la que dicte cuáles serían los siguientes pasos.

¿Está Usted listo para comenzar con los contenedores?

Podman. la nueva estrella en ascenso en un nuevo panorama de contenedores

Ya hace un tiempo que tomamos el tema de los Contenedores. ¿Qué contenedores? Esos métodos centrados en las aplicaciones para ofrecer aplicaciones escalables de alto rendimiento, en cualquier infraestructura que se elija. Son los más adecuados para ofrecer microservicios, al proporcionar entornos virtuales portátiles y aislados para que las aplicaciones se ejecuten sin interferencia de otras aplicaciones en ejecución.

¿Microservicios? Nos referimos a las aplicaciones ligeras escritas utilizando varios lenguajes de programación modernos, con sus propias dependencias, bibliotecas y requisitos ambientales específicos. Para garantizar que una aplicación tenga todo lo que necesita para ejecutarse correctamente, se empaqueta junto con sus Dependencias.

Por mucho tiempo Doker se consolidó como una plataforma de contenedorización de código abierto. Ha permitido a los desarrolladores empaquetar aplicaciones en contenedores. Digamos pues que Doker era la plataforma "de facto" para quien quisiera ejecutar contenedores.

Algo que caracteriza al Código Abierto, así como a todas y cada una de las comunidades y tecnologías que se basan en ésta, es el hecho de que nada ni nadie tiene la exclusiva sobre cualquiera de las mencionadas. Es por eso que ahora tenemos una alternativa más para ejecutar Contenedores. ¿Su nombre? Podman.

Podman (Pod Manager) es definido como -"...un motor de contenedores sin daemons (daemonless) para administrar y ejecutar contenedores apegado a la Open Container Initiative (OCI) en su sistema Linux. Los contenedores se pueden ejecutar como raíz o en modo sin raíz. En pocas palabras: alias docker=podman.

Es una estrella en ascenso en un nuevo panorama de contenedores que de repente tiene muchos más jugadores. Aprenda qué es Podman y cómo se compara con Docker para la compatibilidad con Kubernetes y más.

Podman es un proyecto de Red Hat que es de código abierto y de descarga gratuita. Es un recién llegado a la escena de la contenerización, con la versión 1.0 lanzada en 2019. Desde entonces, Podman ha hecho grandes avances, y su ascenso se ha visto agravado por el declive gradual de Docker, el proyecto que en muchos sentidos creó el mundo de los contenedores como lo sabemos hoy.

Podman y Kubernetes

Si está un poco familiarizado con el desarrollo basado en contenedores, conocerá el nombre Kubernetes. A medida que las aplicaciones en contenedores se volvieron más complejas, los desarrolladores necesitaron herramientas que pudieran coordinar los contenedores que interactuaban entre sí mientras se ejecutaban en diferentes máquinas virtuales, o incluso en diferentes máquinas físicas. Esta herramienta se denomina plataforma de orquestación de contenedores y Kubernetes es, con diferencia, el ejemplo más destacado. Kubernetes puede funcionar con cualquier contenedor que cumpla con la especificación de imagen de Open Container Initiative (OCI), lo que hacen los contenedores de Podman.

Una de las características importantes de Kubernetes es el concepto de pod, una agrupación efímera de uno o más contenedores que es la unidad informática más pequeña que puede administrar Kubernetes. Podman también se centra en la idea de una cápsula, como su nombre lo indica. Un pod de Podman también incluye uno o más contenedores, que se agrupan en un solo espacio de nombres, red y contexto de seguridad. Esta similitud hace que Podman y Kubernetes encajen de forma natural y, desde el principio, uno de los objetivos de Red Hat era que los usuarios de Podman organizaran contenedores con Kubernetes.

Podman contra Docker

El otro gran nombre del mundo de los contenedores que seguramente habrá escuchado es Docker. Docker no fue el primer motor de contenedores, pero en muchos sentidos ha llegado a definir la creación de contenedores. Gran parte del funcionamiento de Docker es el estándar de facto para el desarrollo basado en contenedores, lo suficiente como para que muchas personas utilicen "Docker" como abreviatura de contenedores.

Si bien Docker y Podman ocupan un espacio similar en el ecosistema de contenedores, no son lo mismo y tienen diferentes filosofías y enfoques sobre cómo funcionan. Por ejemplo, Docker es una plataforma todo en uno con herramientas para tareas específicas, mientras que Podman colabora con otros proyectos para ciertos fines; por ejemplo, se basa en Buildah para crear imágenes de contenedores.

También hay diferencias arquitectónicas: Docker no tiene un concepto nativo de pods, por ejemplo. Otra diferencia importante es que Docker se basa en un programa daemon en segundo plano que se ejecuta continuamente para crear imágenes y ejecutar contenedores, mientras que Podman lanza contenedores y pods como procesos secundarios independientes. Este aspecto del diseño de Docker tiene implicaciones importantes para la seguridad, que analizaremos en breve.

Comandos de Docker en Podman

Por diseño y necesidad, Podman y Docker son compatibles en general. Parte de esa compatibilidad se puede atribuir a la adhesión a estándares abiertos. Debido a que ambos motores funcionan con contenedores que cumplen con el estándar OCI, puede crear un contenedor con Docker y modificarlo en Podman, o viceversa, y luego implementar cualquiera de los contenedores en Kubernetes.

Cuando se lanzó Podman en 2019, Docker era tan dominante que su interfaz de línea de comandos se había convertido en parte de las rutinas de programación y la memoria muscular de muchos desarrolladores. Para hacer que un cambio potencial a Podman sea más fluido, los creadores de Podman se aseguraron de que sus comandos y sintaxis reflejaran la de Docker tanto como fuera posible. Fueron tan lejos como para hacer posible establecer un alias que redirigir los comandos de Docker a Podman.

Mejor seguridad con contenedores "sin raíz" (rootless)

Con Podman y Docker trabajando de manera tan similar en tantas formas, ¿por qué elegiría uno sobre el otro? Bueno, una razón importante es la seguridad. ¿Recuerda cómo Docker se basa en un daemon para realizar gran parte de su trabajo continuo? Ese demonio se ejecuta como root, lo que lo convierte en un punto de entrada potencial para los atacantes. Este no es un obstáculo insuperable para la informática segura, pero sí significa que debe pensar un poco en navegar por los problemas de seguridad de Docker.

En algunas situaciones, querrá ejecutar un contenedor con privilegios de root en su máquina host, y Podman le permite hacerlo. Pero si prefiere mantener sus contenedores restringidos de forma segura al espacio del usuario, también puede hacerlo ejecutando lo que se denomina un contenedor sin raíz. Un contenedor sin raíz no tiene más privilegios que el usuario que lo lanzó; dentro del contenedor, ese usuario tiene privilegios de root. También puede usar marcas de línea de comandos para agregar privilegios a sus contenedores de forma granular.

¿Qué hay con el rendimiento?

Un área en la que Docker tiene una ventaja sobre Podman es el rendimiento, al menos según algunos. Si bien hay poca información concreta sobre este tema, no es difícil encontrar desarrolladores frustrados en Hacker News, Stack Overflow y Reddit quejándose del rendimiento de Podman, especialmente cuando se ejecuta sin root. Algunos estudiantes universitarios suecos ejecutaron una suite de referencia en varias plataformas de contenedores diferentes y encontraron que Podman carecía, aunque es cierto que se trataba de una versión anterior a 1.0 de Podman. Si bien no hay mucha información técnica sobre este tema, anecdóticamente, Podman se ve criticado por su desempeño.

¿Podman reemplazará a Docker?

De la discusión hasta ahora, puede que no parezca que se está trabajando en un gran cambio de ambiente para reemplazar Docker con Podman. Pero se avecina un cambio importante que desplazará a Docker de uno de sus nichos de toda la vida: el mismo Kubernetes.

Kubernetes y Docker han sido durante años los gigantes gemelos del mundo de los contenedores. Pero su convivencia siempre fue algo incómoda. El auge de Kubernetes se produjo después de que Docker estuviera bien establecido en su nicho; de hecho, se podría decir que Kubernetes se hizo popular en parte porque Docker no estaba a la altura de la tarea de administrar todos los contenedores que debían coordinarse en una gran aplicación distribuida. .

Docker (la compañía) desarrolló su propia plataforma de orquestación de contenedores en 2015, denominada Swarm, que fue diseñada para aprovechar las fortalezas de Docker. Swarm se lanzó con gran fanfarria, pero nunca alcanzó a Kubernetes. Si bien Swarm todavía tiene devotos, Kubernetes se ha convertido en el estándar de facto para la orquestación de contenedores, al igual que Docker se convirtió en el estándar de facto para otros aspectos del ecosistema de contenedores.

Además, Docker nunca jugó bien con Kubernetes en términos de tiempo de ejecución de contenedores, el componente de bajo nivel del motor de contenedores que, entre otras tareas, funciona con el kernel del Sistema Operativo (SO) subyacente y monta imágenes de contenedores individuales. Tanto Docker como Kubernetes se ajustan a la especificación de imagen OCI, que Kubernetes usa para coordinar imágenes creadas en contenedores. Pero Kubernetes también se basa en tiempos de ejecución de contenedores compatibles con una API de complemento estandarizada llamada Interfaz de tiempo de ejecución de contenedores (Container Runtime Interface o CRI), que Docker nunca ha llegado a implementar.

Durante mucho tiempo, la popularidad de Docker obligó a Kubernetes a usar Dockershim, una capa compatible con CRI que era un intermediario entre Kubernetes y el demonio de Docker. Sin embargo, esto siempre fue una especie de truco y, a principios de este año, Kubernetes desechó el soporte para Dockershim. (Podman, por el contrario, utiliza el tiempo de ejecución CRI-O compatible de Cloud Native Computing Foundation).

Esto es parte de una historia más amplia sobre Docker que intenta y no logra convertirse en una empresa empresarial. En resumen, Docker nunca pudo separarse por completo de Kubernetes. Mientras tanto, Kubernetes ya no necesita Docker en la medida en que lo hacía antes.

No está claro si Podman reemplazará a Docker, pero definitivamente será uno de los contendientes. Ayuda que Podman no sea un producto insignia que busca ser monetizado, sino más bien una única oferta de tecnología de código abierto de una empresa mucho más grande. Podemos esperar que Podman y Kubernetes permanezcan entrelazados durante algún tiempo.

¿Qué motor de contenedor debería usar?

Con suerte, esta discusión le dará una idea de los factores que lo ayudarán a elegir entre estos dos motores de contenedores. Podman se basa en una arquitectura más segura, mientras que Docker tiene una historia más profunda. Podman es nativo de Kubernetes, mientras que Docker también funciona con Docker Swarm. Docker incluye toda la funcionalidad que necesita para muchas tareas relacionadas con contenedores. Podman es modular y te permite experimentar con diferentes herramientas para diferentes propósitos.

Dicho esto, la pregunta "Podman vs. Docker" es, en cierto modo, una elección falsa. Ambas plataformas crean imágenes que se ajustan a las especificaciones de OCI, y ambas funcionan con muchos de los mismos comandos, por lo que puede moverse sin problemas entre las dos. Por ejemplo, puede querer usar Docker para el desarrollo local y luego usar Podman para implementar los contenedores que creó dentro de Kubernetes.

Una característica que distingue a Docker es que viene con soporte pago. Pero incluso esto tiene un lado negativo: mientras Docker (la empresa) intenta monetizar su oferta principal, ha comenzado a cobrar por el entorno de desarrollo de Docker Desktop. Red Hat, por otro lado, parece contento con dejar libre a Podman (como en la cerveza) por ahora.

Al final, la ventaja principal que vemos a priori es que existen ya dos grandes alternativas para los ambientes de ejecución de nuestros contenedores. Esto al final genera competencia y esta es el mejor catalizador para que cualquiera de estas alternativas mejore cada vez más.

¿Cuál es para Usted la mejor altenetiva?

Cloud Paks de IBM. Microservicios en Multi Nube Híbrida

Parte esencial de la Tercera Plataforma. Tecnología fundamental dentro de las doce tecnologías con impacto a corto plazo de la Transformación Digital y uno de los cimientos fundamentales para la Cuarta Revolución Industrial, el Cómputo en La Nube ha sido pues de lo más revolucionario que se tiene ahora en lo referente a las Tecnologías de la Información.

Cómo recordamos y con mucho afecto esos días en los que el Cómputo, los Sistemas, la Informática se llevaba a cabo programando sobre un hardware, para poder obtener un Sistema de Cómputo que pudiese subsanar las necesidades de administración, contabilidad, producción, etc. en una empresa u organización.

El "boom" que vino de la mano de la Segunda Plataforma, o la Arquitectura Cliente-Servidor, hizo que sin darnos cuenta y sin previo aviso, fuésemos responsables de programas de cómputo monolíticos, enormes,  con millones de líneas de código y que cada que fuese necesario realizar un cambio, una actualización, arreglar un desperfecto (por más pequeño que este fuera), requeríamos abrir una ventana de mantenimiento y la operación podía durar un par de meses.

Los negocios, la gestión de empresas y/o entidades de gobierno y todas esas actividades para las que se había creado o comprado una aplicación, evolucionaron por su cuenta y ahora los cambios suceden con una frecuencia inusitada e inverosímil para aquellos tiempos en los que muchas aplicaciones se habían creado. Ahora los usuarios (no decenas ni cientos, sino miles o millones) no estaban detrás de una Terminal "tonta" (en una estación de trabajo fija). Tampoco estaban en Computadoras Personales de Escritorio (Desktops). Mínimo los usuarios están detrás de una Computadora con Monitor Abatible (LapTop), una Tableta con tecnología "touch" y servicio de red inalámbrica o con un Dispositivo Personal Móvil en su mano, y éstos pueden estar en su casa, en un ciber-café, en la calle, en un vehículo de transporte público o inclusive en la Estación Espacial Internacional. Sí. Literalmente donde quieran y utilizando el dispositivo que en ese momento pueden o quieren utilizar. Todo un reto.

Las Redes de Cómputo son ese aparato circulatorio por el cual los datos fluyen en todos los sentidos. Los riesgos de seguridad se han multiplicado y literalmente, los usuarios no pueden esperar más de tres segundos por su información. Para desgracia de muchos negocios, existen muchas opciones para los usuarios quienes no dudarán en abandonar una opción e inmediatamente tomar otra distinta que les ofrezca lo que necesitan, cuando lo necesitan, en donde quiera que estén y sin esperar tres segundos.

¿Se imaginan estar en la época de los Mainframe (Primera Plataforma), o incluso de la Arquitectura Cliente-Servidor (Segunda Plataforma), con los tiempos y procedimientos para crear, actualizar, reparar aplicaciones en estos tiempos tan vertiginosos con usuarios tan exigentes y voraces?

La Nube (pública, híbrida o privada) representó un considerable ahorro para los Costos de Capital (CapEx) y un uso más eficiente en lo que se refiere al Costo Operativo (OpEx). Pero aún así el seguir "montando" inmensas aplicaciones monolíticas (aunque fuese en modalidad Multi-Capa) seguía siendo un enorme reto.

¿Y qué pasó entonces? Nació la Arquitectura de Microservicios (en inglés, Micro Services Architecture, MSA).

Ésta es una aproximación para el Desarrollo de Software que consiste en construir una aplicación como un conjunto de pequeños servicios, los cuales se ejecutan en su propio proceso y se comunican con mecanismos ligeros (normalmente una API de recursos HTTP).

En esta Arquitectura, cada servicio se encarga de implementar una funcionalidad completa del negocio. Cada servicio es instalado, configurado y aprovisionado de forma independiente y puede estar programado en distintos lenguajes, usando diferentes tecnologías de almacenamiento de datos.

¿Cuáles son las características principales de los Microservicios?

• Los componentes son servicios: Los servicios son componentes separados que se comunican mediante mecanismos como los servicios web o los RPC en lugar de usar llamadas a funciones en memoria como hacen las bibliotecas.
  
  
• Organización en torno a las funcionalidades del negocio: El sistema se divide en distintos servicios donde cada uno está organizado en torno a una capacidad del negocio. Es muy importante limitar la responsabilidad de cada servicio. Cada servicio implementa toda la funcionalidad del negocio que agrupa desde la interfaz de usuario, la persistencia en el almacenamiento y cualquiera de las colaboraciones externas.
  
  
• Productos, no proyectos: En esta arquitectura normalmente se sigue la idea de que un equipo debe estar a cargo de un componente (servicio) durante todo el ciclo de vida del mismo, desde la etapa de diseño y construcción, la fase de producción y hasta la de mantenimiento. Esta mentalidad se acopla bien con la vinculación a una capacidad del negocio. En lugar de ver el software como un conjunto de funcionalidades terminadas se ve como una relación continua, donde la pregunta es cómo puede el software ayudar a sus usuarios a mejorar la funcionalidad del negocio que implementa. Esto es facilitado por el bajo nivel de granularidad que ofrecen los microservicios.
  
  
• Extremos inteligentes, tuberías bobas: Las aplicaciones creadas desde microservicios pretenden ser tan disociadas y cohesivas como sea posible, ellas poseen su propia lógica de dominio y actúan como filtros en el clásico sentido UNIX: recibe una solicitud, aplica la lógica apropiada y produce una respuesta. Estos pasos son coreografiados usando protocolos simples (típicamente HTTP con REST o mensajería liviana como RabbitMQ o ZeroMQ) en lugar de protocolos complejos como WS-BPEL.
  
  
• Tener gobernabilidad descentralizada: Con el sistema con múltiples servicios colaborativos, podemos decidir utilizar diferentes lenguajes de programación y tecnologías dentro de cada servicio. De esta forma podemos elegir la herramienta adecuada para cada tipo de trabajo en lugar de tener una estandarizada. Por ejemplo si una parte del sistema necesita mejorar su rendimiento es posible usar una tecnología, quizás más complicada, que permita alcanzar el nivel de rendimiento requerido.
  
  
• Gestión de datos descentralizada: Los microservicios prefieren dejar a cada servicio que gestione su propia base de datos, sean estos diferentes instancias de la misma tecnología de base de datos o sistemas de base de datos completamente diferentes.
  
  
• Diseño tolerante a fallos: Las aplicaciones necesitan ser diseñadas de modo que puedan tolerar las fallas de los distintos servicios. Cualquier llamada de servicio puede fallar y el cliente tiene que ser capaz de responder a esto con la mayor facilidad y eficacia posible, evitando los muy habituales fallos en cascada de las arquitecturas distribuidas.
  
  
• Automatización de la infraestructura: La mayoría de los productos y sistemas desarrollados con el enfoque de microservicios han sido construidos por equipo que usan entrega continua y su precursor la integración continua. Para conseguir esto es necesario:
  • Automatizar todo el proceso, desde el chequeo del código, pruebas, despliegue.
  • Control de versiones y gestión de configuración.
  • Arquitectura (hardware-software-sistema operativo) adecuada. Tiene que permitir realizar cambios sin que afecten al resto del sistema.
  
  
• Diseño evolutivo: Cuando se divide el sistema en servicios hay que tener en cuenta que cada uno tiene que poder ser reemplazado o actualizado de forma independiente.

Todo esto se lee y suena fantástico. ¿Pero cómo es posible lograr todo esto de manera concreta, completa y cabal? La respuesta a esta pregunta de llaman Contenedores de Cómputo.

Los Contenedores son elementos que contienen (valga la redundancia) están centrados en las aplicaciones, para que estas sean escalables de alto rendimiento, pudiéndose ejecutar en cualquier infraestructura que se elija. Los Contenedores son los más adecuados para ofrecer microservicios, al proporcionar entornos virtuales portátiles y aislados para que las aplicaciones se ejecuten sin interferencia de otras aplicaciones en ejecución.

Un contenedor 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 en la plataforma de ejecución para contenedores 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.

Aquí ya comenzamos a tocar un tema dentro de esto que es los Contenedores, y aquí vale la pena hacer una aclaración: Los Contenedores NO SON Máquinas Virtuales, y aunque suene a todo un "cliché" o un pleonasmo, las Máquinas Virtuales NO SON tampoco Contenedores. Lo que es más, es posible ejecutar Contenedores DENTRO de Máquinas Virtuales, pero nunca una Máquina Virtual podrá ejecutarse en un ambiente de ejecución para Contenedores, pues la máquina virtual necesita de un Hipervisor.

Vale la pena entonces también hacer un paréntesis para mencionar que, los Micro Servicios (y por ende los Contenedores), nada tienen que ver con la Arquitectura Orientada a Servicios o Service Oriented Architecture (SOA). Un ejemplo de implementación de esta Arquitectura son los Web Services.

La Arquitectura Orientada a Servicios es un estilo de arquitectura de TI que se apoya en la orientación a servicios y se deriva de la Web 2.0 en lo concerniente a relación Negocio a Negocio. La orientación a servicios es una forma de pensar en servicios, su construcción y sus resultados. Aquí un servicio es una representación lógica de una actividad de negocio que tiene un resultado de negocio específico (ejemplo: comprobar el crédito de un cliente, obtener datos de clima, consolidar reportes de perforación).

El estilo de arquitectura SOA se caracteriza por:

• Estar basado en el diseño de servicios que reflejan las actividades del negocio en el mundo real, estas actividades forman parte de los procesos de negocio de la compañía.
• Representar los servicios utilizando descripciones de negocio para asignarles un contexto de negocio.
• Tener requerimientos de infraestructura específicos y únicos para este tipo de arquitectura, en general se recomienda el uso de estándares abiertos para la interoperabilidad y transparencia en la ubicación de servicios.
• Estar implementada de acuerdo con las condiciones específicas de la arquitectura de TI en cada compañía.
• Requerir un gobierno fuerte sobre las representación e implementación de servicios.
• Requerir un conjunto de pruebas que determinen que es un buen servicio.

El desarrollo e implementación de una arquitectura SOA se rige por los principios descritos en el manifiesto SOA. Por otra parte la aplicación de la orientación a servicios se divide en 2 grandes etapas:

• Análisis orientado a servicios (Modelado de servicios)
• Diseño orientado a servicios

Volviendo ahora al tema, para hacer más simple el entendimiento de el concepto de lo que es el Contenedor, imagine por un momento que Usted necesita ejecutar, en su computadora de escritorio un par de aplicaciones. Estas aplicaciones NO es posible instalarlas sobre el mismo Sistema Operativo que actualmente se ejecuta en su equipo de cómputo, pues ambas tienen en común "bibliotecas" (libraries) y recursos informáticos que no pueden compartir. Una evita que la otra se ejecute en el mismo ambiente de ejecución (valgan las redundancias).

¿Qué hacer entonces? Si esto nos lo hubiesen preguntado hace dos años, la respuesta sería: -"...instala VMware WorkStation Player o Virtual Box sobre tu Sistema Operativo, crea dos máquinas virtuales y sobre los respectivos Sistemas Operativos, instala en cada una su aplicación correspondiente."- Hoy y si esta aplicación viene "contenerizada", no necesitas hipervisor alguno. Mientras que el "Kernel" del Sistema Operativo sea compatible a ambas aplicaciones, usando un ambiente de ejecución de contenedores (como el ya mencionado Doker), no es necesaria ninguna Máquina Virtual. Ambas aplicaciones pueden convivir en el mismo Hardware.

Queda entonces claro que, para poder ejecutar contenedores es necesario:

• Un Sistema Operativo (Linux) en el que se pueda instalar el ambiente de ejecución de contenedores
• Un ambiente de ejecución de contenedores (Doker)
• Los contenedores

Sí. Así de sencillo. Huelga decir que estos contenedores pudiesen trabajar completamente independientes uno del otro o trabajar en conjunto para conformar una Aplicación. También podemos inferir de todo esto, que con tan solo un modesto equipo de cómputo (pudiese ser incluso a nivel de escritorio) es posible comenzar con nuestra aventura con los Contenedores.

Todo esto ha estado funcionando tan bien y ha tenido tanto sentido para las empresas y organizaciones, que se disparó una tremenda proliferación de aplicaciones contenerizadas. Esto comenzó entonces a presentar sendos retos para la administración de los Contenedores.

Sólo para comenzar, éstos ya no se instalaban en equipos pequeños, sino que ahora se tenían Clusters de Servidores que proveen todo lo necesario en cuanto a ambiente de ejecución se requiere. Dichos Clusters en su mayoría son basados en plataformas de Virtualización y esto también fue lo que hizo que cada vez se tuviesen ambientes más y más complejos para controlar los Contenedores. Fue entonces que se hizo necesaria una herramienta que permitiese orquestar, administrar de manera centralizada y automatizar la operación de los Contenedores. Nace Kubernetes.

Kubernetes (referido en inglés comúnmente como “K8s”) es una herramienta de Código Abierto creada para la automatización del despliegue, escalabilidad y administración de aplicaciones en contenedores,​ que fue originalmente diseñado por Google y donado a la Cloud Native Computing Foundation (parte de la Linux Foundation). Soporta diferentes entornos para la ejecución de contenedores, incluido Docker.

Ahora los Desarrolladores y el personal de Operación de las empresas y organizaciones, encontraron un muy valioso aliado para poner bajo control desde pequeñas y hasta inmensas cantidades de contenedores.

No vamos a ahondar en el tema de Kubernetes, pues merece un tratamiento aparte. Lo que sí vale la pena mencionar es que aunque es posible ejecutar Contenedores contando tan sólo con Doker (la plataforma o ambiente de ejecución), Kubernetes ha demostrado ser indispensable.

Para muchas áreas de Tecnologías dela Información de empresas y organizaciones, ya en la práctica, poder armar todo lo referente al ambiente de ejecución, automatización, orquestación, administración, etc. para los Contenedores, no resultó tan fácil como se escuchaba o leía. ¿Qué hacer para aprovechar todas las bondades de los Contenedores y no tener que lidiar con todo lo que implica poner a punto toda esa estructura necesaria). Llegó al rescate Red Hat® OpenShift®.

OpenShift® es una familia de productos de software de contenedorización desarrollados por Red Hat®. Su producto estrella es OpenShift® Container Platform, una plataforma local como servicio construido alrededor de contenedores Docker orquestados y administrados por Kubernetes sobre la base de Red Hat® Enterprise Linux. 

La familia de productos OpenShift® proporciona la ten necesaria plataforma a través de diferentes entornos: OKD (Origin Community Distribution) que sirve como el upstream impulsado por la comunidad (similar a la forma en que Fedora está upstream de Red Hat® Enterprise Linux). OpenShift® Online, la plataforma que se ofrece como software como servicio y OpenShift® Dedicated, la plataforma que se ofrece como servicio gestionado.

Hasta el momento hemos mencionado que los Contenedores son ideales para crear un ambiente de Plataforma como un Servicio, sobre nuestra Infraestructura como un Servicio, en nuestros Centros de Datos Definidos por Software. Digamos que ahora tenemos nuestra Nube Privada ejecutando nuestros Contenedores.

¿Y qué sucede cuando queremos incorporar Servicios de Infraestructura en Nubes Públicas? Cierto. La evolución a entornos de ejecución fuera de la empresa, da soporte y es esencial para esa necesidad de proveer a nuestros Usuarios de sus aplicaciones que se puedan ejecutar donde sea, cuando sea, a través del dispositivo que sea.

Leyes, normatividades, regulaciones pusieron un freno a la migración total desde La Nube Privada (o los ambientes On Premise) hacia La Nube Pública. Por lo que las empresas y organizaciones optaron por un mitad-y-mitad naciendo con esto La Nube Híbrida. En esta modalidad se aprovecha lo mejor de La Nube Privada y La Nube Pública, dando como resultado un ambiente de ejecución homogéneo (o idealmente homogéneo) en donde los Usuarios "ni se enteran" de a dónde se están ejecutando sus Servicios. Ellos simplemente disfrutan de estos.

El nuevo reto entonces era elegir en qué proveedor de Nube Pública ejecutar nuestros Contenedores. Pues en un principio y aunque los ambientes de ejecución de Contenedores no requieren de bastos recursos informáticos, sí es indispensable el armar toda la estructura (física y/o virtual) que de sustento dicho ambiente de ejecución.

Aquí es entonces a donde entra el concepto de los Cloud Paks de IBM. Son software con tecnología de Inteligencia Artificial para La Nube (o Multi Nube) Híbrida , que nos permite implementar por completo flujos de trabajo inteligentes la empresa u organización, para acelerar el camino a la transformación digital en lo que a Contenedores se refiere.

IBM Cloud Paks aprovecha el poder de IBM Watson® para aplicar Inteligencia Artificial a su negocio, predecir y dar forma a resultados futuros, automatizar procesos complejos, optimizar el tiempo de administradores de T.I. y crear ambientes más ágiles y seguros.

Basados en Red Hat® OpenShift®, es posible desarrollar o instalar aplicaciones contenerizadas una vez, e implementarlas en cualquier lugar de cualquier Nube Pública o Privada. Además, puede integrar la seguridad y automatizar las operaciones con visibilidad de gestión. IBM Cloud Paks tiene una base común de componentes empresariales que aceleran el desarrollo, brindan una integración perfecta y ayudan a mejorar la colaboración y la eficiencia.

Los flancos en los que tenemos por el momento los Cloud Paks son:

• Datos
• Automatización del Negocio
• Operaciones con Inteligencia Artificial provista por Watson
• Integración
• Automatización de la Red
• Seguridad

En entregas posteriores abordaremos cada uno de estos Cloud Paks. Por el momento baste decir que si dentro de los requerimientos de su empresa u organización ya se está trabajando y/o se requiere implementar a corto plazo la contenerización de sus aplicaciones, Cloud Paks de IBM son la mejor alternativa Multi Nube.

¿Su empresa u organización ya está trabajando con Contenedores?

El Proyecto Monterey de VMware marca un cambio importante en la infraestructura moderna

Es increíble todo lo que han evolucionado las otrora denominadas "Sistemas", "Cómputo" e "Informática" ahora conocidas como Tecnologías de la Información. Lo que sí es evidente es que durante los últimos cinco años, VMware ha experimentado una transformación significativa.

Primero, se alejó de ofrecer su propia Nube Pública para apostar por la estrategia multi-nube integrando a los proveedores de Nube Pública ya existentes. Hoy en día, VMware Cloud Foundation, el componente central del Centro de Datos Definido por Software que se ejecuta en La Nube (en principio Privada), es la plataforma de Nube Híbrida preferida con el respaldo oficial de los principales proveedores de Infraestructura como un Servicio en Nube Pública o Hiperescaladores.

El siguiente paso importante, se produjo en forma de Proyecto Pacífico comenzando en el año 2019, uniendo contenedores y máquinas virtuales. Aquí VMware Cloud Foundation y vSphere integran Kubernetes para permitir que los clientes administren cargas de trabajo tradicionales (en Máquinas Virtuales) y modernas (en Contenedores) sin problemas.

En el marco del VMworld 2020, VMware ha anunciado Proyecto Monterey, una nueva tecnología que cambia fundamentalmente la arquitectura del Hipervisor.

Con Proyecto Pacífico y Proyecto Monterey, VMware responde a la dinámica cambiante del mercado y al panorama cambiante de la infraestructura empresarial.

Cuando VMware fue testigo del aumento de los Contenedores en la empresa, se movió rápidamente al adquirir Heptio, Bitnami y Pivotal Labs. Estas inversiones permitieron a VMware responder inmediatamente a la oportunidad de Contenerización. Con esto, vSphere se convirtió en un plano de control integrado para administrar máquinas virtuales, Contenedores y Clústeres de Kubernetes. Los activos existentes de Pivotal para Plataforma como un Servicio (PaaS), se rebautizaron como Tanzu para ejecutar aplicaciones modernas basadas en contenedores y microservicios. 

Si bien los clientes continúan ejecutando cargas de trabajo heredadas como lo son las Máquinas Virtuales sobre vSphere, ahora pueden administrar Clústeres de Kubernetes desde el mismo conjunto de herramientas y APIs que ya conocidas. Proyecto Pacífico convirtió a VMware en un actor importante en el ecosistema nativo de la nube liderado por Kubernetes.

Proyecto Pacífico tiene que ver con reinventar y rediseñar vSphere, el componente básico del software de las ofertas de VMware. Con Proyecto Monterey, VMware está cambiando su enfoque a la capa de hardware para ofrecer la próxima generación de infraestructura de centro de datos.

¿Los procesadores x86 son ahora el eslabón más débil o más fuerte de la infraestructura moderna?

El movimiento hacia los Centros de Datos Definidos por Software (SDDC) ha ejercido una enorme presión sobre el omnipresente procesador x86. Las tendencias emergentes como la Contenerización y el Aprendizaje Automático comienzan a llevar los procesadores x86 a sus límites. Hay que tener en cuenta que la tendencia a corto plazo con la Arquitectura de Micro-Servicios, la tendencia será el ejecutar decenas de miles de contenedores en una flota de servidores físicos o virtuales.

Además de procesar la lógica empresarial, actualmente el Procesador es responsable de gestionar el tráfico de red Este-Oeste del plano de datos, así como el tráfico Norte-Sur que atraviesa el centro de datos. También interactúa con la capa de almacenamiento que gestiona el rendimiento de Entrada/Salida.

El cambio a Hipervisor, Redes Definidas por Software y Almacenamiento Definido por Software ha sobrecargado al Procesador x86. Para darnos una idea, el Procesador invierte al menos el 30% de su capacidad de procesamiento para administrar tareas que no pertenecen a una aplicación o carga de trabajo.

Dado que la mayoría de las aplicaciones tienen como objetivo la arquitectura de Procesadores x86, existe un intento de trasladar la gestión de red y almacenamiento a Circuitos Integrados y Tarjetas de Sistema en un Chip (SoC) especialmente diseñadas. Este enfoque permite delegar la administración del plano de control, desde el Procesador hacia hardware especializado conocido como SmartNICs que está conectado físicamente (comúnmente vía slots PCIe) al mismo servidor físico.

En el mundo de la Infraestructura como Servicio en Nube Pública, las SmartNICs de Azure las Unidades de procesamiento de datos Fungible F1, Intel FPGA PAC N3000, las Unidad de Procesamiento de Datos (PDUs) NVIDIA y las Tarjeta de Servicios Sistribuidos (DSCs) Pensando, son ejemplos de la tendencia en la que los aceleradores de red y almacenamiento se mueven del software a una capa de hardware dedicada.

Incorporación del hipervisor ESXi en SmartNICs

Normalmente, las SmartNICs o las Data Processing Unit (DPU) tienen circuitos integrados especialmente diseñados para acelerar la red y el almacenamiento. Liberan al Procesador de las tareas mundanas que compiten con las cargas de trabajo que se ejecutan el plano de datos.

Con Proyecto Monterey, VMware está trasladando el hipervisor ESXi a las SmartNICs. Esto es importante porque las SmartNICs ahora tiene circuitos integrados especializados que se asignan a las capas de virtualización de almacenamiento, red y computación que normalmente se ejecutan sobre los Procesadores x86. Además de ESXi, VMware también está trasladando el núcleo de vSAN y NSX: sus componentes de virtualización de red y almacenamiento a SmartNIC.

Dado que las SmartNICs tiene Procesadores de uso general basadas en Arquitectura ARM, proporciona suficiente potencia informática para los controladores integrados especializados. Por lo tanto, una SmartNIC tiene varios Procesadores ARM junto con el Circuito Integrado para Aplicaciones Específicas (Application Specific Integrated Circuit - ASIC) o las Matrices de Compuertas Lógicas Programables en Campo (Field Programmable Gate Arrays - FPGA) responsables de las tareas de Cómputo, Red, Almacenamiento, Seguridad y Administración.

Es posible que un Servodor Físico con el hipervisor instalado (Host) que ejecute Proyecto Monterey, aún necesite ejecutar ESXi en la forma tradicional. La combinación de ESXi basado en hardware y ESXi tradicional ofrece el rendimiento óptimo de las máquinas virtuales. Ambas instancias de ESXi se pueden administrar como una unidad lógica. El ciclo de vida de las máquinas virtuales es administrado por el ESXi x86 que se ejecuta dentro del host. Dado que la SmartNIC con ESXi embebido administra al ESXi sobre plataforma x86, esto mejorará la administración del ciclo de vida de las VM invitadas.

Las SmartNICs ESXi puede administrar cualquier Sistema Operativo para Arquitectura x86 basado en Linux o Microsoft Windows que se ejecute en el Host. El hipervisor también puede arrancar vía una tarjeta de red con Preboot Execution Environment (PXE) con una imagen ISO, lo que ofrece capacidades completas a los hosts. Dado que la SmartNIC administra la red y el almacenamiento, el Sistema Operativo "bare metal" (nativo o a metal desnudo) experimenta un rendimiento optimizado.

Una de las otras ventajas de trasladar el hipervisor ESXi a la SmartNIC, es la seguridad mejorada. SmartNIC ESXi refuerza la seguridad de la red a través de un modelo de seguridad Airgap. 

"Air gap", "air wall", o "red desconectada" es una medida de seguridad de red empleada para garantizar que una red informática segura, esté físicamente aislada de las redes no seguras como la Internet pública o una red de área local no segura.

ESXi incorporado en la SmartNIC elimina la complejidad de colocar cargas de trabajo en hosts con aceleradores específicos como GPU (Graphic Processor Units), ASIC (Application Specific Integrated Circuits) y FPGA (Field Programable Gate Arrays). Estos activos subyacentes pueden virtualizarse por completo y exponerse a aplicaciones sin preocuparse por hacer coincidir las cargas de trabajo con hosts especializados.

Proyecto Monterey: convertir el centro de datos empresarial en una infraestructura de hiperescala

Con el Proyecto Monterey, VMware ofrece la misma tecnología de infraestructura escalable y multi-inquilino utilizada por los hiperescaladores (proveedores de Infraestructura como un Servicio en Nube Pública) a los clientes empresariales.

A modo de ejemplo, Amazon confía en AWS Nitro para descargar las funciones del hipervisor, red y almacenamiento en hardware especializado. 

En muchos sentidos, Project Monterey hace con los centros de datos empresariales lo que AWS Nitro hizo con Amazon EC2.

VMware se está asociando con proveedores de SmartNIC como NVIDIA (GPUs), Pensando e Intel (ASICs y FPGAs). También está colaborando con Dell Technologies, HPE y Lenovo para ofrecer una solución integrada de extremo a extremo a las empresas.

La evolución del software de aplicación liderada por Contenedores y Kubernetes, así como la evolución de la infraestructura impulsada por aceleradores de hardware especializados, marcan el comienzo de una nueva era. Con Proyecto Pacífico (Contenedores) y Proyecto Monterey (Aceleradores de Hardware Especializados), VMware está bien posicionado para aprovechar estas dos tendencias.