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?

Pronóstico de Crecimiento en Ingresos para Software y Servicios de Gestión de Contenedores

En las dos más recientes entradas: "Antes de entender Contenedores, entendamos Microservicios" y "Guía esencial de contenedores", explicamos qué son los Contenedores (en el ámbito de las Tecnologías de la Información), por qué se han convertido en un "deber ser" para las áreas de Desarrollo y Operación de las empresas, así como también aportamos una muy breve guía de cómo comenzar esta aventura.

Como bien sabemos, nada en este mundo (incluidas por supuesto las Tecnologías de la Información) funciona, subsiste, persiste o trasciende si no viene con su dosis (directa o indirectamente) de beneficio económico.

Por ello queremos aquí compartir cuál es, en estos meses más recientes, el panorama con respecto a los Contenedores y quiénes son los que están partiendo el pastel.

Entrando de lleno al tema, es un hecho que los ingresos mundiales de gestión de contenedores alcanzarán los $ 944 millones en 2024, frente a una pequeña base de $ 465.8 millones en 2020, según las nuevas cifras de Gartner.

Entre los diversos subsegmentos, la orquestación de contenedores en la nube pública y las ofertas de contenedores sin servidor experimentarán el crecimiento más significativo, dice la firma analista.

Esta es la primera vez que Gartner publica un pronóstico para la gestión de contenedores, en respuesta a la creciente importancia de la tecnología subyacente.

"Ha habido una exageración considerable y un alto nivel de interés en la tecnología de contenedores, pero un menor nivel de despliegues de producción hasta la fecha", dice Michael Warrilow, vicepresidente de investigación de Gartner.

"Los contenedores se han vuelto populares porque proporcionan una herramienta poderosa para abordar varias preocupaciones críticas de los desarrolladores de aplicaciones, incluida la necesidad de una entrega más rápida, agilidad, portabilidad, modernización y gestión del ciclo de vida", afirma.

Gartner predice que para 2022, más del 75% de las organizaciones globales ejecutarán aplicaciones en contenedores en producción, en comparación con menos del 30% actual.

"Como resultado del uso creciente de contenedores, la demanda empresarial para la gestión de contenedores está aumentando", dice Warrilow, quien además agrega que "la gestión de contenedores proporciona software y/o servicios que respaldan la gestión de contenedores, a escala, en entornos de producción".

Según Gartner, la popularidad de las aplicaciones nativas de la nube está detrás del crecimiento de la administración de contenedores.

Warrilow añade que el crecimiento previsto en la adopción empresarial de la gestión de contenedores indica el atractivo intrínseco de la arquitectura nativa de la nube.

"La comprensión de" nativo de la nube "varía, pero tiene importantes beneficios potenciales sobre el diseño tradicional de aplicaciones monolíticas, como la escalabilidad, la elasticidad y la agilidad", afirma y además comenta que "también está fuertemente asociado con el uso de contenedores".

Gartner afirma que las condiciones económicas recesivas frenarán el crecimiento en el mediano plazo.

Varios factores restringirán la adopción entre organizaciones que desarrollan o modernizan aplicaciones personalizadas. A pesar de la necesidad de apoyar la Transformación Digital, las iniciativas se verán limitadas por condiciones económicas recesivas por lo menos a mediano plazo, a medida que las prioridades de la organización cambien a la optimización de costos, aporta la firma analista.

Gartner espera que hasta el 15% de las aplicaciones empresariales se ejecuten en un entorno contenedor para 2024, frente a menos del 5% en 2020, obstaculizado por la acumulación de solicitudes, la deuda técnica y las limitaciones presupuestarias.

"El cuello de botella será la velocidad a la que las aplicaciones se pueden refactorizar y / o reemplazar", comparte Warrilow.

Un dato de suma importancia es lo que Gartner ha encontrado y nos comparte en la frase: -"Los contenedores alimentarán un ecosistema abierto."-

Los ingresos directos por software y servicios de gestión de contenedores seguirán siendo una pequeña parte del ecosistema de contenedores. Los ingresos adicionales provendrán de una variedad de segmentos adyacentes que no están incluidos en el pronóstico de administración de contenedores de Gartner. Esto incluye el desarrollo de aplicaciones, servicios administrados, hardware local e Infraestructura como un Servicio (IaaS) entre otros segmentos.

Por ejemplo, se espera que los ingresos de IaaS asociados con la gestión de contenedores alcancen $ Un Mil Millones antes de 2023. Muchos de los segmentos adyacentes ya se informan en los pronósticos existentes de Gartner

"Aunque los ingresos incrementales directos pueden ser menores de lo que muchos esperan, los contenedores pueden tener un papel diferente que desempeñar", explica Warrilow. "Los contenedores podrían en última instancia alimentar un ecosistema abierto similar a Linux".

En este punto ya pudimos darnos cuenta de qué tan preponderante e importante son ya los Contenedores, no solo para las áreas de Desarrollo y Operaciones de las empresas en general, como también para aquellas que su negocio principal sea precisamente el Desarrollo de Aplicaciones, sino también desde el punto de vista del negocio en general.

Ahora bien. ¿Qué empresas son las que hoy predominan, desde el punto de vista de Productos y Servicios, en lo que respecta a Contenedores Informáricos?

La creciente oportunidad está resultando atractiva para los proveedores de software que buscan demostrar que sus ofertas comerciales basadas en Kubernetes son mejores que el resto. Hasta ahora, Red Hat se destaca como líder del mercado con una cuota de mercado del 44%. La compañía está cosechando el fruto de su estrategia de ventas práctica, donde primero consultan y capacitan a los desarrolladores empresariales y luego monetizan una vez que la empresa despliega contenedores en producción.

"Las funciones de automatización son la clave del crecimiento de los contenedores", dijo Vladimir Galabov, analista principal de IHS Markit. “Los proveedores de servicios en la nube de hiperescala fueron los primeros en adoptar el software de contenedor en sus centros de datos (DC) y ya ejecutan sistemas operativos de contenedor en máquinas virtuales en más de un tercio de sus servidores de múltiples inquilinos. En comparación, las empresas de telecomunicaciones y las empresas ejecutan software de contenedores en solo el 8 por ciento de sus servidores de múltiples inquilinos en la actualidad ”.

El retraso en la implementación se debe a la complejidad de administrar Kubernetes en varios equipos dentro de la organización, así como en varias nubes.

"Esta es la razón por la cual las empresas y las empresas de telecomunicaciones requieren niveles más altos de automatización de administración de contenedores, administración de clúster y características de configuración de políticas que las que estaban disponibles en 2018", dijo Galabov.

Los principales desarrollos de cuota de mercado en el primer trimestre de 2019 incluyen:

Red Hat obtuvo un 44% de participación en los ingresos del mercado de software de contenedores. Su software de contenedor, OpenShift, recientemente superó los 1.100 clientes. Red Hat demostró que la mejor estrategia para vender software de contenedores es un enfoque práctico donde la capacitación y la consultoría son lo primero. La adquisición de CoreOS de CoreOS también ha permitido la adición de nuevas funciones de configuración de políticas, administración y automatización a OpenShift.

Docker fue No. 2 con 23%. El compromiso de la compañía de adoptar Kubernetes en lugar de seguir adelante con su software alternativo de administración de contenedores, Swarm, está dando sus frutos. El proveedor indicó que más de 750 clientes implementaron Docker Enterprise a fines de abril de 2019.

Pivotal y VMware tomaron el puesto número 3 con una participación de ingresos del 6% generada por sus esfuerzos conjuntos de comercialización. Aún en su infancia, el acuerdo de los proveedores ha producido un software de contenedor PKS desarrollado conjuntamente, que ha superado los 140 clientes acumulados.

Rancher Labs y Canonical completaron los cinco primeros con 3% y 2% de acciones, respectivamente. El primero ha duplicado su número de empleados durante el último año para apoyar a sus 250 clientes acumulados.

"Red Hat ha asegurado una posición de liderazgo en el mercado con una adquisición oportuna de CoreOS y una estrategia de ventas práctica diferenciada", dijo Galabov. “El atractivo de este mercado en crecimiento ha llevado a otros proveedores a intensificar su juego, con Docker haciendo las paces con Kubernetes y VMware formando una estrategia de salida al mercado más clara después de adquirir Heptio. Es probable que VMware refleje la estrategia de ventas de Red Hat y aumente su enfoque en las empresas de consultoría y capacitación para permitir de manera más efectiva la implementación de software de contenedores en la producción ".

Aspectos más destacados del mercado de software adicional para el servidor de múltiples inquilinos (multitenant).

Otros desarrollos notables incluyen:

• Los servidores de múltiples inquilinos representaron el 67% del total de servidores enviados en el primer trimestre.
  
• Un total del 48% de las unidades de software de servidor de múltiples inquilinos en el primer trimestre fueron autogestionadas, ya sea de código abierto, con un 38%, o propietarias, con un 10%.
  
• Los contenedores en servidores bare metal representaban el 5% del total de servidores multiinquilinos.
  
• VMware fue el número 1 en participación de mercado de ingresos de software de virtualización de servidores del primer trimestre con 47%, seguido de Microsoft con 14% y Red Hat con 11%.

En conclusión, tanto los Contenedores de Software, como todos los productos y servicios que ya están ofertándose y consumiendo el día de hoy, están transformando todo lo tocante a Desarrollo y Operaciones (DevOps), además de que representa una excelente oportunidad de negocio.

Antes de entender Contenedores, entendamos Microservicios

Una característica que tienen las Tecnologías de la Información (antes Sistemas, Informática, etc.) es su siempre MUY rápida evolución, por sobre todo desde los últimos años de década de los noventa del Siglo XX, y qué decir de lo que llevamos de este Siglo XXI.

Ya en esta tercera década del Siglo XXI, vemos como más que nunca es tan sencillo que una empresa o una persona publique una idea, un concepto y en menos de una semana todos (directa o indirectamente involucrados con las Tecnologías de la Información) hablan del tema.

¿A qué viene todo esto? La palabra o más bien las palabras que ahora están en boca de todos son: "Contenedores" y "Microservicios". Todos ahora las pronuncian y (sin afán de criticar o hacer escarnio de nada o nadie) cada vez es más grande la confusión acerca de estas palabras, aplicadas obviamente a las Tecnologías de la Información.

Como lo dice el título de esta aportación al Blog Tecnológico TechData México, antes de entender Contenedores, entendamos Microservicios. Comencemos pues.

¿Qué son los Microservicios?

Los microservicios son un enfoque arquitectónico para la creación de aplicaciones. Como marco arquitectónico, los microservicios se distribuyen y se acoplan libremente, por lo que los cambios de un equipo no dañarán toda la aplicación. El beneficio del uso de microservicios es que los equipos de desarrollo pueden construir rápidamente nuevos componentes de aplicaciones para satisfacer las cambiantes necesidades comerciales.

El párrafo anterior es para nosotros la mejor definición de qué son, cuales son sus alcances y se vislumbra ya sus beneficios. Desde ya podemos decir que esto se enfoca y tiene sentido, para aquellas empresas que se dedican en cuerpo y alma al Desarrollo, o las áreas de Desarrollo dentro de organizaciones, instituciones y empresas.

Una forma de crear aplicaciones, optimizadas para DevOps y CI/CD

Lo que diferencia a una arquitectura de microservicios de los enfoques monolíticos más tradicionales es cómo divide una aplicación en sus funciones principales. Cada función se llama servicio y se puede construir e implementar de forma independiente, lo que significa que los servicios individuales pueden funcionar (y fallar) sin afectar negativamente a los demás. Esto nos ayuda a adoptar el lado tecnológico de DevOps y hacer que la iteración y entrega constante (constant iteration and delivery o CI/CD) sean más fluidas y alcanzables.

Piense en su última visita a un minorista en línea. Es posible que haya utilizado la barra de búsqueda del sitio para buscar productos. Esa búsqueda representa un servicio. Quizás también haya visto recomendaciones para productos relacionados, recomendaciones extraídas de una base de datos de preferencias de compradores. Eso también es un servicio. ¿Agregaste un artículo a un carrito en línea? Lo has adivinado, otro servicio.

Por lo tanto, un microservicio es una función central de una aplicación y se ejecuta independientemente de otros servicios, pero una arquitectura de microservicios es algo más que el simple acoplamiento de las funciones centrales de una aplicación: se trata de reestructurar los equipos de desarrollo y la comunicación entre servicios de una manera que prepare para fallas inevitables, escalabilidad futura e integración de nuevas características.

¿Cómo se logra esto? Adaptando los conceptos básicos de una Arquitectura Orientada a Servicios (SOA) para implementar microservicios.

Esto suena familiar...

Si desglosar las aplicaciones en sus funciones principales y evitar las trampas de los monolitos suena familiar, es porque el estilo arquitectónico de microservicios es similar a la Arquitectura Orientada a Servicios (SOA). Un estilo de diseño de software ya bien establecido.

En los primeros días del desarrollo de la aplicación, incluso los cambios mínimos en una aplicación existente requerían una actualización de la versión mayorista con su propio ciclo de aseguramiento o garantía de calidad (QA), lo que podría ralentizar a muchos sub-equipos. Este enfoque a menudo se denomina "monolítico" porque el código fuente de toda la aplicación se creó en una sola unidad de implementación (como .war o .ear). Si las actualizaciones de una parte de una aplicación causaron errores, todo se tuvo que desconectar, reducir y corregir. Si bien este enfoque aún es viable para aplicaciones pequeñas, las empresas en crecimiento no pueden permitirse el tiempo de inactividad.

Ingrese a la arquitectura orientada a servicios, que estructura las aplicaciones en servicios discretos y reutilizables que se comunican a través de un bus de servicios empresariales (ESB). En esta arquitectura, los servicios individuales, cada uno organizado en torno a un proceso comercial específico, se adhieren a un protocolo de comunicación (como SOAP, ActiveMQ o Apache Thrift) para compartir a través del ESB. En conjunto, este conjunto de servicios, integrado a través de un ESB, comprende una aplicación.

Por un lado, esto permite que los servicios se construyan, prueben y modifiquen simultáneamente, no más ciclos de desarrollo monolíticos. Por otro lado, sin embargo, el ESB representa un único punto de falla para todo el sistema, por lo que, en cierto modo, el esfuerzo por eliminar el monolito solo creó uno nuevo: el ESB, que podría potencialmente obstaculizar a toda la organización.

De SOA a microservicios

¿Cual es la diferencia? Los microservicios pueden comunicarse entre sí, generalmente sin estado, por lo que las aplicaciones creadas de esta manera pueden ser más tolerantes a fallas y menos dependientes de un único ESB. Esto también permite a los equipos de desarrolladores elegir sus propias herramientas, ya que los microservicios pueden comunicarse a través de Interfaces de Programación de Aplicaciones (API) independientes del lenguaje.

Dada la historia de SOA, los microservicios no son una idea tan nueva. Sin embargo, los microservicios se han vuelto más viables gracias a los avances en las tecnologías de contenedorización. Con los contenedores de Linux, ahora puede ejecutar varias partes de una aplicación de forma independiente, en el mismo hardware, con un control mucho mayor sobre sus piezas individuales y sus ciclos de vida. Junto con los equipos de API y DevOps, los microservicios en contenedores son la base de las aplicaciones nativas de la nube.

¿Cuáles son los beneficios de una arquitectura de microservicios?

Los microservicios dan un impulso a sus equipos y rutinas a través del desarrollo distribuido. También puede desarrollar múltiples microservicios al mismo tiempo. Esto significa que más desarrolladores trabajan en la misma aplicación, al mismo tiempo, lo que resulta en menos tiempo dedicado al desarrollo.

Listo para el mercado más rápido.- Dado que los ciclos de desarrollo se acortan, una arquitectura de microservicios admite una implementación y actualizaciones más ágiles.

Altamente escalable: a medida que crece la demanda de ciertos servicios, puede implementar en múltiples servidores e infraestructuras para satisfacer sus necesidades.

Resistente.- Estos servicios independientes, cuando se construyen adecuadamente, no se impactan entre sí. Esto significa que si una pieza falla, la aplicación completa no se cae, a diferencia del modelo de aplicación monolítica.

Fácil de implementar.- Debido a que sus aplicaciones basadas en microservicios son más modulares y más pequeñas que las aplicaciones monolíticas tradicionales, las preocupaciones que vinieron con esas implementaciones se niegan. Esto requiere más coordinación, con lo que una capa de malla de servicios puede ayudar, pero los beneficios pueden ser enormes.

Accesible.- Debido a que la aplicación más grande se divide en partes más pequeñas, los desarrolladores pueden comprender, actualizar y mejorar más fácilmente esas partes, lo que resulta en ciclos de desarrollo más rápidos, especialmente cuando se combinan con metodologías de desarrollo ágiles.

Más abierto.- Debido al uso de API políglotas, los desarrolladores tienen la libertad de elegir el mejor lenguaje y tecnología para la función necesaria.

¿Y los desafíos?

Si su organización está pensando en cambiar a una arquitectura de microservicios, espere cambiar la forma en que las personas trabajan, no solo las aplicaciones. Los cambios organizativos y culturales se identifican como desafíos en parte porque cada equipo tendrá su propia cadencia de implementación y será responsable de un servicio único con su propio conjunto de clientes. Es posible que esas no sean las preocupaciones típicas del desarrollador, pero serán esenciales para una arquitectura exitosa de microservicios.

Más allá de la cultura y el proceso, la complejidad y la eficiencia son dos desafíos principales de una arquitectura basada en microservicios. John Frizelle, arquitecto de plataforma para Red Hat Mobile, expuso estas ocho categorías de desafío en su charla de 2017 en Red Hat Summit:

Construcción: Debe dedicar tiempo a identificar dependencias entre sus servicios. Tenga en cuenta que completar una compilación puede desencadenar varias otras compilaciones, debido a esas dependencias. También debe tener en cuenta los efectos que los microservicios tienen en sus datos.

Pruebas: Las pruebas de integración, así como las pruebas de extremo a extremo, pueden volverse más difíciles y más importantes que nunca. Tenga en cuenta que una falla en una parte de la arquitectura podría causar que falle un par de saltos, dependiendo de cómo haya diseñado sus servicios para apoyarse mutuamente.

Control de versiones: cuando actualice a nuevas versiones, tenga en cuenta que puede romper la compatibilidad con versiones anteriores. Puede construir una lógica condicional para manejar esto, pero eso se vuelve difícil de manejar y desagradable, rápido. Alternativamente, podría soportar múltiples versiones en vivo para diferentes clientes, pero eso puede ser más complejo en mantenimiento y administración.

Implementación: Sí, esto también es un desafío, al menos en la configuración inicial. Para facilitar la implementación, primero debe invertir en mucha automatización ya que la complejidad de los microservicios se vuelve abrumadora para la implementación humana. Piense cómo va a implementar los servicios y en qué orden.

Registro: con sistemas distribuidos, necesita registros centralizados para unir todo. De lo contrario, la escala es imposible de gestionar.
Monitoreo: es fundamental tener una vista centralizada del sistema para identificar las fuentes de problemas.

Depuración: la depuración remota a través de su entorno de desarrollo integrado local (IDE) no es una opción y no funcionará en docenas o cientos de servicios. Lamentablemente, no hay una respuesta única sobre cómo depurar en este momento.

Conectividad: considere el descubrimiento de servicios, ya sea centralizado o integrado.

Cierto que los Microservicios, al igual que SOA y otros conceptos dentro de las Tecnologías de la Información, pueden aplicarse a su empresa, organización y/o institución de distintas y diversas maneras. Pero en este caso en particular, lo cual abordaremos con más detalle en una entrada posterior, puede ser abordado con los Contenedores.

¿Está Usted listo para los Contenedores?

Tecnología de contenedores: moviéndose en un flujo continuo

Las presiones comerciales y los Ciclos Ágiles están aumentando la frecuencia de lanzamiento requerida para la entrega de programas, aplicaciones y funciones. Se están inspirando y gestando nuevos enfoques para lograr un flujo continuo en DevOps, allanando el camino para entregar software de calidad. Estos desarrollos están empujando a las organizaciones a explorar formas más efectivas de diseñar sus lanzamientos. Uno que está ganando un atractivo significativo para muchas organizaciones de desarrollo es la Tecnología de Contenedores.

Contenedores es una tecnología que está "en llamas" en este momento, ya que las empresas necesitan cada vez más ofrecer soluciones seguras y confiables, sin sacrificar la velocidad de liberación y al mismo tiempo controlar los costos. Este impulso que trae el Contenedor es evidente en prácticamente todos los informes de analistas sobre DevOps.

El estado de los Contenedores

Para 2023, el 70% de las organizaciones ejecutarán tres o más aplicaciones en Contenedores en producción, según una investigación reciente de Gartner. Con la innovación de TI empresarial, DevOps y la Transformación Digital moviéndose a la velocidad de la luz, los Contenedores son clave para ayudar a las organizaciones a aumentar su competitividad y agilidad operativa.

Como se indica en la figura anterior, el atractivo de los Contenedores es innegable. Su diseño significa que la eficiencia y la velocidad superan con creces las instalaciones a "metal desnudo" (bare metal), e incluso a los entornos virtuales. A pesar del atractivo y la promesa de la tecnología de Contenedores, presenta un nuevo ecosistema de tecnologías, que agrega complejidad.

Dentro del ecosistema de software, los Contenedores afectan positivamente a todo, incluido el tiempo de ejecución, la administración, la estructura y las operaciones. Aunado a lo anterior, su capacidad para acelerar los ciclos de entrega de software al tiempo que garantiza la fiabilidad del proceso los hace invaluables para muchas organizaciones.

Potencial casi ilimitado de los Contenedores

Los Contenedores pueden mejorar dramáticamente la velocidad de entrega del software, la independencia de la plataforma, la utilización de los recursos y la confiabilidad del proceso. Son un gran camino para las organizaciones en el mundo acelerado y delgado de hoy.

Independencia de su evidente ventaja que les confiere el poder aprovechar la plataforma y el ambiente de ejecución en cualquier lugar, gracias a que se "conteneriza" el paquete que contiene el código, las configuraciones, las bibliotecas y dependencias que necesitan para ejecutarse de manera consistente en cualquier entorno. Esta portabilidad permite a las organizaciones construir una vez e implementar muchas veces, ya sea localmente o utilizando cualquiera de los proveedores de la Nube Púublica, sin necesidad alguna de reconstruir la aplicación o rearmar el Contenedor.

Sólo por enumerar algunas de las más importantes ventajas que ofrecen los Contenedores, podemos mencionar:

• Utilización de recursos mejorada: los Contenedores proporcionan aislamiento del proceso, lo que permite un control detallado sobre el Procesador y la Memoria para un mejor uso de los recursos. Mientras que una Máquina Virtual a menudo "pesa" varios gigabytes, un Contenedor puede llegar a pesar megabytes, permitiendo que se ejecuten más Contenedores en un solo servidor de lo que es posible con las Máquinas Virtuales. Como resultado de una menor necesidad de recursos, las organizaciones disfrutan de una reducción significativa de costos al pasar de Máquinas Virtuales a un ecosistema de Contenedores.
  
• Arranque rápido: cada Contenedor se ejecuta como un proceso separado que comparte los recursos del sistema operativo subyacente. Las máquinas virtuales pueden tardar varios minutos en arrancar sus sistemas operativos y comenzar a ejecutar las aplicaciones que alojan, mientras que las aplicaciones en Contenedores se pueden iniciar en segundos.
  
• Mayor modularidad y seguridad: en lugar de ejecutar una sola aplicación compleja dentro de un solo Contenedor, la aplicación se puede dividir en módulos (Microservicios). Las aplicaciones creadas de esta manera son más fáciles de administrar, ya que cada módulo es relativamente simple y se pueden realizar cambios en los módulos sin tener que volver a compilar toda la aplicación.
  
• El aislamiento de Contenedores también disminuye los riesgos de seguridad: si una aplicación fuera "pirateada" o violada por malware, cualquier problema resultante no afectaría a otros Contenedores que ejecuten la misma aplicación. Incluso si el software malicioso afecta a un solo microservicio, todos los demás microservicios quedarían a salvo.
  
• Canalización de desarrollo optimizado: la utilización de un ecosistema basado en Contenedores elimina las inconsistencias de los ambientes de ejecución, lo que permite a los desarrolladores garantizar que las aplicaciones funcionen según lo diseñado. Los desarrolladores pasan menos tiempo probando y depurando versiones y configuraciones para ambientes particulares, ya que los Contenedores se pueden replicar para los entornos de desarrollo, prueba, control de calidad y producción de una organización.
  
• Implementación de producción simplificada: actualizar una aplicación en producción se vuelve más fácil usando Contenedores. Se puede realizar utilizando varios métodos de implementación, por lo que una vez que se implementan los cambios, si se encuentran fallas en la producción se pueden revertir inmediatamente a la versión anterior. Esto reduce el impacto de las fallas de implementación en los clientes de una organización.

El papel de los Contenedores en el logro del flujo continuo

Adoptado del mundo de la fabricación, el flujo esbelto y continuo se ha convertido en un ideal que muchas organizaciones de DevOps se esfuerzan por lograr pero luchan por implementar. Para aplicar prácticas esbeltas a los modelos de entrega de software de manera significativa, el flujo del proceso debe soportar el movimiento de los cambios de código a la producción de manera rápida, confiable y continua.

Los Contenedores pueden ayudarlo a acercarse al flujo continuo. Aplicar el mismo pensamiento continuo a los Contenedores puede ayudarlo a trazar un camino hacia adelante, pero hay muchos aspectos a considerar.

Un enfoque continuo de Contenedores ayuda a despejar la niebla a medida que las organizaciones intentan satisfacer las demandas modernas de ciclos más rápidos y avanzar hacia una base de Contenedores. Hay nueve aspectos clave que debe abordar a medida que se traslada a los Contenedores que permiten ejecutar la velocidad y la agilidad durante todo el ciclo de vida de una manera integrada y automatizada. Esto afecta a las personas, los procesos, la tecnología y los cambios culturales.

Para tener aún más claro todo el concepto de los Contenedores, dentro del ámbito de las Tecnologías de la información, vale la pena echar una mirada a los

Nueve aspectos clave

• Contenedorización: la clave para lograr Contenedores continuos es contener las aplicaciones existentes y nuevas.
• Automatización de Contenedores: con ciclos más rápidos y la confianza de calidad requerida, la automatización de Contenedores es crítica.
• Operaciones de Contenedores: operar en un ecosistema de Contenedores significa cambiar los enfoques de operaciones tradicionales. Requiere comprender la nueva cadena de herramientas y el ciclo de vida general.
• Conectividad de Contenedores: los contenedores necesitan nuevas formas de conexión y comunicación. Comprender cómo encajan y se relacionan es fundamental.
• DevOps: Madurar las capacidades de DevOps, lo que significa conectar los silos tradicionales, reexaminar los procesos y racionalizar el ciclo de vida y el flujo.
• Integración del flujo: un componente fundamental de los Contenedores continuos es comprender e integrar la cadena de herramientas y el ciclo de vida general.
• Arquitectura de Contenedores: la conducción a Contenedores debe incluir una arquitectura bien pensada diseñada para satisfacer sus necesidades.
• Cambiar la cultura: los Contenedores continuos implican cambiar la forma en que las personas piensan en todos los niveles de la organización, la forma en que las personas están conectadas y la forma en que trabajan.
• Alineación de personas y organización: los Contenedores continuos exigen un cambio en las responsabilidades, lo que permite que muchos equipos e individuos contribuyan a lo largo del ciclo de vida y el flujo.

Realidades de los Contenedores

Las empresas pueden realizar mejoras sustanciales con los Contenedores. Sin embargo, los Contenedores por si mismos no son una solución "lista para usar". Aprovecharlos correctamente, garantizar que sean seguros y en ocasiones el desplegarlos con éxito involucra ciertas operaciones complejas. Estos son los puntos críticos a considerar:

• Adoptar, implementar y administrar contenedores se logra más fácilmente con un plan integral y una estrategia a largo plazo.
  
• Los comportamientos arraigados y el territorialismo entre los equipos de trabajo pueden ser serios impedimentos para la adopción.
  
• A pesar de su apodo atractivo, los Contenedores no son una solución autónoma. Las actividades asociadas y las herramientas del ecosistema deben acompañar el despliegue.
  
• Para un éxito duradero, las organizaciones preferiblemente ya tendrán una práctica de DevOps madura.

Incluso con estas advertencias, los beneficios para las empresas que adoptan contenedores en términos de velocidad, agilidad y eficiencia del proceso de software son innegables.

¿Conclusión? Los Contenedores no son una palabra rara, una moda, una tendencia efímera o algo que la gente está mencionando para aparentar cierta sofisticación. Son una excelente y muy seria alternativa a los Microservicios, así como un aliado valiosísimo para DevOps. Las empresas que se dedican por completo al Desarrollo de aplicaciones, así como las áreas de Desarrollo de las empresas que dejen fuera a los Contenedores, están seriamente condenadas al fracaso y la extinción.

VMware vSphere 7 con Kubernetes

En el VMworld del año 2019 Pat Gelsinger (CEO de VMware), nos adelantaba cuál sería la tendencia para la nueva versión de VMware (la versión 7), que incluyó lo que en la empresa denominaron como el "Proyecto Pacífico". ¿En qué consiste Proyecto Pacífico? En la inclusión de Contenedores dentro de el ambiente de ejecución de VMware vSphere.

Para comenzar a entender mejor todo esto, comencemos respondiendo a la pregunta:

¿Qué son los Contenedores?

Si buscamos en Google, inmediatamente veremos que un contenedor es "...un recipiente de carga para el transporte marítimo o fluvial, transporte terrestre y transporte multimodal". Cierto. Esas enormes cajas de acero perfilado que utilizan la industria naviera, ferroviaria y de transporte de carga por carretera, para distribuir productos a nivel mundial.

Mas sin embargo en el ámbito de las Tecnologías de la Información, los Contenedores son una solución al problema de cómo hacer que el software se ejecute confiablemente cuando se traslada de un entorno informático a otro. En esencia es el empaquetar código de manera en la que pueda ejecutarse de manera independiente, siendo sólo necesario el contar un el Kernel de un Sistema Operativo.

Antes de los contenedores, era muy poco probable que pudiésemos ejecutar varias aplicaciones sobre el mismo ambiente de ejecución (hardware físico al que ya se le había instalado un Sistema Operativo), pues los recursos que requería una aplicación podrían estar siendo utilizados por otra (u otras) dentro del mismo ambiente. Una manera de resolver esto fue con la Virtualización, pues gracias a las propiedad de Particionamiento, Encapsulamiento y Aislamiento, ahora en el mismo Servidor podíamos tener a varios aplicativos corriendo sin problema alguno.

Todo muy bien hasta aquí, pero para que puedan ejecutarse las Máquinas Virtuales, es necesario contar con un Hipervisor (sustituyendo al Sistema Operativo que otrora se instalaba directamente sobre el Hardware del equipo Servidor). Si la aplicación a ejecutar era pequeña o para cumplir con las nuevas metodologías y tendencias del Desarrollo de Software requerías de Microservicios, una Máquina Virtual para cada Microservicio resultaba en un desperdicio de recursos de Procesador y Memoria (principalmente).

Es entonces cuando en el mundo Linux y Código Abierto, nace el concepto de los Contenedores. Estos últimos NO son máquinas virtuales, sino mas bien la aplicacion o el Microservicio en cuestión, que se ha encapsulado junto con las bibliotecas y recursos informáticos indispensables (y nada más) para su ejecución. Como mencionamos líneas arriba, NO es necesario un Hipervisor, sino el Kernel del Sistema Operativo en el que se ejecuta comúnmente el Microservicio. ¿Resultado? Elementos de ejecución que gozaban también de las propiedades de Particionamiento, Encapsulamiento y Aislamiento, pero que no requieren todo un Hipervisor, tanta Memoria y tanto Procesador.

Ahora bien. Así como en el mundo físico, para que nuestros Contenedores de carga puedan viajar con seguridad y eficiencia por vía marítima se requiere de inmensos buques portacontenedores, los desarrolladores del mundo del Código Abierto crearon software exprofeso. El más famoso y más utilizado se llama "Docker".

¿Qué es Docker?

Per se, la palabra anglosajona "docker" se refiere a un estibador o persona que trabaja en un muelle (dock en inglés), cargando y descargando mercancías en hacia o desde los buques cargueros. Pero en el tema que nos ocupa, Docker es -"...un software que nació como parte del proyecto de código abierto, que automatiza el despliegue de aplicaciones dentro de contenedores de software, proporcionando una capa adicional de abstracción y automatización de virtualización de aplicaciones en múltiples sistemas operativos."- Este texto viene de Wikipedia.

Si quiere Usted profundizar más en el tema, recomendamos ingresar a la página oficial: https://www.docker.com/

Fue tal el éxito de Docker y los Contenedores, que pronto las áreas de Desarrollo de empresas y organizaciones de toda índole y todo tamaño, se volcaron a adoptar esta plataforma para "contenerizar" sus aplicaciones. Esto dio por resultado que fuese necesario algo que permitiera poner orden en un caos cada vez mayor. Nace entonces Kubernetes

¿Qué es Kubernetes?

Wikipedia lo define como: -"...un sistema de Código Abierto para la automatización del despliegue, ajuste, escalabilidad y administración de aplicaciones en contenedores. 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.

De la último enunciado del párrafo inmediato anterior, se infiere que Kubernetes y Docker NO SON RIVALES, sino más bien complementos.

Cabe mencionar que dentro de la comunidad Docker, ya se tiene una opción que puede ser vista como "competencia" o más bien otra alternativa para Docker. Esta se llama Swarm. Pero por su robustez, por sus excelentes resultados y ser una herramienta que permite la automatización del despliegue, ajuste, escalabilidad y administración de aplicaciones en contenedores en ambientes de todo tamaño y de toda índole, se ha tomado a Kubernetes como el estándar "de facto". ¿Más información? Recomendamos ingresar al portal oficial: https://kubernetes.io/

Contenedores en VMware

Algo que debe quedar perfectamente claro y no causar confusión alguna, es el hecho de que los Contenedores NO SON MÁQUINAS VIRTUALES, mientras que las Máquinas Virtuales NO SON CONTENEDORES. vale la pena mencionar que dentro de una Máquina Virtual (con Sistema Operativo Linux principalmente) SÍ puede ejecutar Dockers, Kubernetes y por ende Contenedores. Pero dentro de un contenedor no podemos tener una Máquina Virtual.

vSphere 7 con Kubernetes permite a los operadores y desarrolladores de Tecnologías de la Información acelerar la innovación mediante la convergencia de contenedores y máquinas virtuales, ejecutándose sobre la plataforma vSphere de VMware con Kubernetes nativo. VMware ha aprovechado Kubernetes para volver a diseñar vSphere y extender sus capacidades a todas las aplicaciones modernas y tradicionales.

vSphere 7 con Kubernetes transforma vSphere en la plataforma de aplicaciones del futuro.

Las empresas ahora pueden acelerar el desarrollo y la operación de aplicaciones modernas en VMware vSphere mientras continúan aprovechando las inversiones existentes en tecnología, herramientas y conjuntos de habilidades. Al aprovechar Kubernetes para volver a diseñar vSphere, vSphere 7 con Kubernetes permitirá a los desarrolladores y operadores de TI crear y administrar aplicaciones compuestas de contenedores y/o máquinas virtuales. Este enfoque brinda a las empresas una plataforma única para operar aplicaciones existentes y modernas en paralelo.

vSphere 7 con Kubernetes expone un nuevo conjunto de servicios que los desarrolladores pueden consumir a través de la Application Programming Interface de Kubernetes. El servicio VMware Tanzu Kubernetes Grid para vSphere permite a los desarrolladores administrar el ciclo de vida de los clústeres de Kubernetes bajo demanda. El servicio de red habilita el equilibrio de carga integrado, el ingreso y la política de red para los clústeres de Kubernetes del desarrollador.

El servicio de almacenamiento, integra vSphere Cloud Native Storage en Kubernetes para proporcionar soporte de aplicaciones con estado con volúmenes persistentes gracias a vSphere Virtual Volumes.

El servicio vSphere Pod aprovecha los otros servicios para entregar "Pods" nativos sobre el hipervisor Esxi. El lugar principal donde los clientes ejecutarán los "Pods" es en los clústeres alineados en sentido ascendente, totalmente conformados e implementados a través del servicio de Tanzu Kubernetes Grid. El Pod Service complementa el servicio Tanzu Kubernetes Grid para casos de uso específicos, donde los componentes de la aplicación necesitan el aislamiento de seguridad y rendimiento de una Máquina Virtual, en un factor de formato Pod.

vSphere 7 con Kubernetes tiene un servicio de registro nativo que se puede usar para implementar imágenes de contenedor como Pods de Kubernetes.

La administración enfocada en la aplicación, significa que la política se ha adjuntado a los "Name Spaces" que contienen las aplicaciones del desarrollador. Los equipos de operaciones ahora tienen una vista holística de una aplicación al administrar el "Name Space" que contiene todos los objetos de la aplicación.



Entonces, ¿se trata de la creación de una Máquina Virtual, con Sistema Operativo Linux super básico, al que se le instala la plataforma para Contenedores Dockers, y ahí mismo o en otra Máquina Virtual se instala Kubernets para la administración de esa instancia de Dockers? La respuesta es NO. Lo que se tiene es, dentro de el código del hipervisor ESXi, Pods disponibles para ejecutar los Contenedores creados por el área de Desarrollo, que son administrados por una entidad de Kubernetes que se ejecuta a nivel de Cluster sobre vSphere.

De esta manera, DevOps, Microservicios, Contenedores, etc. se vuelven en una alternativa más, dentro de la plataforma vSphere que, si se nos permite agregar un poco más, ya de por sí ofrece una muy amplia plataforma de Virtualización para la Nube Privada (en Infraestructura como un Servicio), que se incorpora de manera fácil, escalable y segura con Nubes Públicas (también en Infraestructura como un Servicio) para crear un ambiente robusto, seguro y escalable de Nube Híbrida.

La transformación digital de Boeing

Boeing, el gigante aeroespacial, asistió el mes pasado a la Cumbre de Cloud Foundry en Basilea y habló de la Era de la Información y sobre sus esfuerzos para entrar de lleno a la Transformación Digital. Las empresas más grandes necesitan transformarse para sobrevivir en esta era disruptiva.

Ese fue uno de los mensajes principales que surgieron de la cumbre la semana pasada. En parte, las organizaciones pueden lograr esta transformación requerida a través de La Nube. Su adopción no solo mejora la agilidad y flexibilidad (o cualquier otra palabra de moda que se pueda imaginar), sino que también facilita interacciones entre grandes organizaciones y una comunidad global de desarrolladores que escriben código y crean el software necesario, para mejorar y transformar las operaciones y la experiencia del cliente

La transformación digital de Boeing.

La Transformación Digital de Boeing es supervisada por el Director de Información y Vicepresidente Senior, Ted Colbert, quien describió el esfuerzo como -"...un cambio de juego para Boeing. Las mejoras de productividad que hemos visto al implementar un Ambiente de Transformación Digital (Digital Transformation Environment o DTE) en nuestras empresas, superan nuestras expectativas para ahora estar listos para expandir el esfuerzo."-

El gigante aeroespacial utiliza la Fundación Cloud Foundry para ayudar a ejecutar sus aplicaciones a escala y transformación. Pero, esto es solo una gota en una profunda transformación cultural de la empresa.

La transformación cultural de Boeing.

La transformación de Boeing, en general, está más arraigada que lo que típicamente se tiene cuando sólo se incorporan desarrolladores en y/o para una plataforma. La organización está creando lo que llama equipos equilibrados de propietarios de productos de negocios y gerentes de productos, diseñadores de productos, diseñadores de Experiencias de Usuarios (UX por sus siglas en inglés), desarrolladores e ingenieros, trabajando juntos para lograr una misión de carácter comercial.

Para lograr este espíritu, la compañía aeroespacial ha creado cuatro laboratorios o centros de ingeniería, poblados por 300 a 400 personas. Aquí, Boeing capacita a los empleados acerca de los principios básicos de diferentes disciplinas comerciales.

-“Por otro lado, teníamos unos 2,000 desarrolladores en nuestra plataforma. Estamos trabajando para que esto sea fácil de conseguir y libre para el desarrollador, para que no tengan una barrera antinatural para ingresar al sistema. Luego lo hicimos extremadamente estable y rico en características, creando una comunidad a su alrededor”-, dijo un portavoz de Boeing.

-"Este fue el comienzo de transformar la forma en que construimos software en The Boeing Company"- agregó.

Así es como la empresa creó el entorno de Transformación Digital. El impulso provino de los líderes Sénior de la compañía, que observan el mismo patrón con el que luchan todos los demás líderes: cómo transformar a las personas, el proceso y la tecnología para crear oportunidades.

La relación con Cloud Foundry.

Ted Colbert, Chief Information Officer (CIO) y Senior Vice President (SVP) en Boeing, quería centrarse en las personas que entregaban valor comercial. Y ahí es donde entró en juego Cloud Foundry.

Uno de los mayores inhibidores de la transformación son las herramientas y la tecnología. Esto se debe a que las organizaciones se enfocan y analizan las soluciones, sin pensar en el uso comercial.

Para superar este desafío de transformación, el equipo de Transformación Digital quería realmente hacer de la infraestructura un producto abundante, para que las personas pudieran llegar a sus objetivos tan rápido como pudieran.

Para hacer eso, Boeing siguió la ruta de la Plataforma como un Servicio (PaaS). -"Probamos un par de opciones y aterrizamos con Cloud Foundry"-, menciona el portavoz de Boeing.

-“Esta relación cambió el juego de hablar de tecnología e infraestructura, a hablar de negocios y cómo formamos los equipos equilibrados adecuados para resolver problemas empresariales reales. Esto se traduce en responder a la pregunta: ¿cómo podemos realmente agregar valor, en lugar de solo discutir en qué servicio de infraestructura deberíamos estar trabajando?"-

La Cloud Foundry actúa como una carretera para la transformación de Boeing. Pero, una carretera por sí misma no hace nada.

El fácil acceso a la infraestructura permite un tiempo de comercialización más rápido. Pero, realmente se trata de la transformación cultural general que Boeing ha hecho con los equipos.

Resultados de la transformación

"Tenemos tres métricas que hemos estado observando hasta ahora en nuestros esfuerzos de transformación", dijo el portavoz de Boeing.

1. Valor

El valor es el mayor impulsor de la transformación en Boeing, ya sea cultural o digital. El valor se mide ya sea en nuevos ingresos netos, en la reducción del costo, o la soslayar el costo.

-“Cada persona que trabaja de esta manera holística y culturalmente transformada, está logrando un valor medible en el plan de negocios a largo plazo. Por ejemplo, tenemos un equipo de 20 personas trabajando en la optimización de nuestro proceso de ventas. En el pasado, necesitabas de 50 a 100 personas para lograr un valor similar"-, continuó el portavoz.

2. Productividad

Desde que se embarcó en este viaje de transformación, Boeing ha visto entre un 100% y un 300% más de productividad de los equipos de desarrollo de software que trabajan en los laboratorios de Ambientes de Transformación Digital (DTE por sus siglas en inglés).

“La infraestructura es parte de eso, pero tener la misión correcta y el equipo correcto trabajando en los problemas correctos en el entorno correcto, con las herramientas y la infraestructura correctas juntas nos da todo el impulso. Pero, definitivamente, Hacer "partnering" con la organización adecuada y contar con la infraestructura adecuada, son una pieza clave de ese entorno global de transformación".

3. Tiempo en tareas

La siguiente métrica nos lleva a la productividad mejorada: tiempo en tareas/producto.

-"¿Cuánto tiempo estamos gastando en el desarrollo de productos de valor agregado, cuánto tiempo estamos gastando en procesos que no son necesarios o simplemente superficiales, o en la configuración de la infraestructura?"-, Pregunta el portavoz de Boeing. -“Estas cosas realmente no son consecuencia del desarrollo del producto en sí. Hacemos un seguimiento de eso y hemos sido consistentemente más altos en la producción de desarrollo de productos" agrega.

-"Miramos el tiempo para comercializar de dos maneras. Uno es ¿cuánto tiempo se tardó en obtener un Producto Viable Mínimo (MVP)? Por lo general solíamos llevarnos muchos meses o años para que un MVP creíble saliera a producción.”-

-"Con esta metodología general y el nuevo entorno, incluida la infraestructura, pudimos sacar a los MVP en algún lugar entre unos pocos días y no más de tres o cuatro meses, lo que es increíble."-

En general, esto ayudó a mejorar la agilidad y detener el trabajo que no es necesario.

Logrando la transformación empresarial.

La transformación de la empresa, si no se hace adecuadamente, puede ser desalentadora. Es importante para quien lo está liderando, invertir en los lugares correctos y acelerar e invierte más en los lugares donde veas más valor. En el caso de Boeing, está demostrando que pudieron lograr un muy admirable éxito en el entorno de desarrollo de software, mejorando bastante la agilidad de la compañía.

El concepto de tener un equipo equilibrado, con una misión muy clara (y todo lo que los respalda para lograr ese objetivo de transformación) parece haber sido increíblemente valioso.

En conclusión, este es un caso más de una empresa que ha logrado entender y aterrizar el concepto de la Transformación Digital, para poder acelerar e impulsar su crecimiento. Aquí los objetivos medibles fueron la agilidad de operación, el poder entregar valor y con todo esto aumentar las utilidades y reducir costos.

La clave no está en saber (o creer saber) qué es la Transformación Digital. La Transformación Digital "per se" no es un producto o servicio empaquetado, que tenga su SKU y se pueda ordenar por internet o tomar de un estante. La Transformación Digital es todo un proceso que involucra personas, tecnologías, infraestructura, plataformas y por sobre todo, unas muy honestas y sinceras ganas de transformar el negocio. ¿Cómo piensa transformar su negocio para esta nueva era?