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.
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.
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.
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
¿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
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.
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.
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.
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?
No hay comentarios:
Publicar un comentario
Todos los derechos reservados.
Copyright © 2025.