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?

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?

SRE vs. DevOps ¿Realmente son distintos?

Apenas unos días antes de que muriera a principios de la década de 1990, un hombre sabio nos enseñó que "el espectáculo debe continuar". Las palabras de despedida de Freddie Mercury siempre han servido de guía para muchos equipos de operaciones, si no para todos. Desde su punto de vista, el entorno de producción debería exponerse a un riesgo mínimo, incluso a expensas de las nuevas características y la resolución de problemas.

Hace unos 10 años, Google decidió cambiar su enfoque de gestión de la producción. Le tomó a la compañía solo unos pocos años darse cuenta de que mientras Investigación y Desarrollo se enfocaba en crear nuevas características y empujarlas a la producción, el grupo de Operaciones intentaba mantener la producción lo más estable posible: los dos equipos tiraban en direcciones opuestas. Esta tensión surgió debido a los diferentes antecedentes, conjuntos de habilidades, incentivos y métricas de los grupos por los cuales fueron medidos.

Tratando de cerrar esta brecha entre los dos grupos, uno de los líderes de operaciones de Google, Ben Treynor, pensó en una solución innovadora. En lugar de tener un equipo Oerativo creado únicamente por los administradores del sistema, los ingenieros de software -con experiencia y mentalidad en Investigación y Desarrollo- podrían enriquecer la forma en que el equipo trabajó con el grupo de Desarrollo, cambiar sus objetivos y ayudar a automatizar las soluciones.

Ingeniería de Confiabilidad del Sitio, o SRE

Y así, se creó el puesto de Ingeniería de Confiabilidad del Sitio (Site Reliability Engineering). Según Google, los ingenieros de SRE son responsables de la estabilidad del entorno de producción, pero al mismo tiempo están comprometidos con las nuevas funciones y la mejora operativa.

Google decidió que sus equipos de SRE deberían estar compuestos por un 50 por ciento de ingenieros de software y un 50 por ciento de administradores de sistemas.

Los ingenieros se vieron obligados a utilizar el software como una forma de resolver problemas y perfeccionar lo que históricamente se había resuelto a mano. Se integraron fácilmente con el equipo de desarrollo y alentaron las mejoras de la calidad del código y las pruebas de automatización.

Al comprender el valor de SRE, varias organizaciones de diversos tamaños decidieron adoptar sus principios. Algunos, como Dropbox, Netflix y Github, son conocidos por estar a la vanguardia del liderazgo tecnológico.

Espera, ¿Qué eso no es DevOps?

DevOps es un movimiento más reciente, diseñado para ayudar al departamento de Tecnologías de la Información de las organizaciones, a moverse de forma ágil y eficiente. Construye una relación de trabajo saludable entre el personal de Operaciones y el equipo de Desarrollo, lo que permite que cada uno vea cómo su trabajo influye y afecta al otro. Al combinar conocimiento y esfuerzo, DevOps debe producir un producto más robusto, confiable y ágil.

Tanto SRE como DevOps son metodologías que abordan las necesidades de las organizaciones para la gestión de operaciones de producción. Pero las diferencias entre las dos doctrinas son bastante significativas: mientras DevOps plantea problemas y los envía a Desarrollo para que los resuelva, el enfoque de SRE es encontrar problemas y resolver algunos de ellos por sí mismos.

Si bien los equipos de DevOps generalmente elegirían el enfoque más conservador, dejando intacto el entorno de producción a menos que sea absolutamente necesario, los SRE tienen más confianza en su capacidad para mantener un entorno de producción estable, presionar por cambios rápidos y actualizaciones de software.

Al igual que el equipo de DevOps, los SRE también prosperan en un entorno de producción estable, pero uno de los objetivos del equipo de SRE es mejorar el rendimiento y la eficiencia operativa.

Google intentó algunos enfoques para implementar el proceso de SRE antes de encontrar el que más le convenía. Uno de estos enfoques intentó vincular el número de lanzamientos permitidos, con la estabilidad del producto. El principio que subyace en este proceso es que las nuevas versiones se "iluminan en verde" según el rendimiento actual del producto.

Para cada servicio, el equipo de SRE establece un Acuerdo de Nivel de Servicio (SLA por sus siglas en inglés) que define qué tan confiable debe ser el sistema para los usuarios finales. Si el equipo acepta un SLA del 99.9 por ciento, eso les da un presupuesto de error del 0.1 por ciento.

Un presupuesto de error es exactamente lo que sugiere su nombre: el límite máximo permitido para errores e interrupciones. Y es aquí donde está lo interesante: el equipo de desarrollo puede "gastar" este presupuesto de error de la manera que quiera. Si el producto se está ejecutando sin problemas, con pocos o ningún error, pueden ejecutar lo que quieran, cuando lo deseen. Por el contrario, si han cumplido o excedido el presupuesto de error, y están funcionando en el SLA definido o por debajo, todas las nuevas versiones se congelan hasta que reduzcan la cantidad de errores a un nivel que permita que el lanzamiento continúe. Este proceso asegura que tanto los SRE como los desarrolladores tengan un fuerte incentivo para minimizar el número de errores en la producción.

Otro enfoque interesante recomendado por Treynor, que está más relacionado con el profesionalismo y la eficiencia de SRE, está permitiendo que los SRE se muevan entre proyectos. Además, sugiere permitir que los ingenieros de SRE se muevan hacia el desarrollo, e incluso al revés.

Como el trabajo realizado por ambos equipos es similar, estas transiciones ayudan al equipo de Operaciones a obtener un mejor y más profundo conocimiento del producto y el código, llevando a los equipos de Desarrollo al espacio de producción para ayudarlos a comprender sus desafíos. Esto promueve fuertemente una atmósfera de equipo, en lugar de una en la que un individuo siente que "estoy en el equipo de SRE para este producto".

Como parte de este enfoque, Treynor hizo que los equipos de Desarrollo manejaran el 5 por ciento de la carga de trabajo de las operaciones. Esto de acuerdo con muchas organizaciones, se suma a la motivación y efectividad del equipo de SRE.

Acertijos en la oscuridad

Bueno, SRE parece perfecto. Como ya se dijo, varias organizaciones a gran escala han decidido trasladar algunas de sus operaciones de producción de antiguas áreas cien por ciento Operativas a SRE. Sin embargo, todavía hay algunas preguntas que deben hacerse:

¿El puesto de Administrador de Sistemas (producción/operaciones) ya no es relevante para los Administradores de Sistemas?

Históricamente casi todos los administradores de sistemas han asumido sus roles, a través de soporte técnico y trabajo similar, o incluso simplemente ejecutando Linux en sus escritorios y luego haciendo la transición al trabajo del servidor. Debería quedar bastante claro que el mismo camino no está disponible en SRE. Para conservar sus posiciones, los Administradores de Sistemas ahora deberían estar más orientado al código, tener un mejor conocimiento tecnológico y ser receptivos a los nuevos métodos para realizar el trabajo que ya realizan.

¿Puede un equipo de SRE evitar incidentes de producción?

Una de las fortalezas de un Ingeniero de Confiabilidad del Sitio profesional, es la capacidad de manejar el crecimiento de la carga de producción y el tráfico interno. Monitorear y analizar procesos y registros con plataformas como ELK (Elasticsearch, Logstash, and Kibana) Stack, es parte de la carga de trabajo diaria, debiendo de ser capaz el equipo de identificar problemas a medida que ocurren, e incluso prever riesgos para la estabilidad del software.

El poder de este puesto, basado en el conjunto de habilidades que requiere, radica en desarrollar soluciones para estos problemas y riesgos. Como Ciara, un ingeniero de software en el equipo SRE de almacenamiento en la nube de Google, lo describió en una publicación de "La vida en Google": "Resolvemos problemas más fríos en formas más frescas".

¿Estamos haciendo DevOps o estamos haciendo SRE?

Esta pregunta generalmente la hacen personas que intentan posicionarse en el mundo de Operaciones. Según muchas empresas que implementaron SRE de una manera ligeramente diferente a Google, no tienen qué decidir. En Reddit, los ingenieros de operaciones trabajan para reducir el trabajo pesado, mejorando los procesos de implementación y escalado, pero se les conoce como "DevOps".

En Logz.io, cerraron la brecha entre los desarrolladores y la producción a través del uso de monitoreo automatizado, así como pruebas de esfuerzo de rendimiento. En Logz.io lo llaman "DevOps" en lugar de "SRE".

Entonces, ¿es solo una cuestión de contexto?

En su blog, Charity Majors habla de que -"SRE y DevOps son dos enfoques operativos diferentes que cualquier organización puede elegir para trabajar"-, pero insiste en enfatizar que no existe un enfoque "correcto".

Aunque Google y Dropbox han decidido por SRE, esto no significa que el resto del mundo también deba hacerlo. Lo que se ajusta a las necesidades y la filosofía organizacional de Google, no necesariamente funciona para otras organizaciones a cualquier escala.

Además Charity cree que DevOps, habiendo crecido y evolucionado dentro de una variedad más amplia de organizaciones de software, es el enfoque más flexible, colaborativo y adaptable, funcionando mejor para la mayoría de las organizaciones de software en todas las etapas de desarrollo.

Por otro lado, el ingeniero senior de SoundCloud, Matthias Rampke, emitió una serie de tweets sobre cómo SRE y DevOps eran básicamente los mismos, con solo un soporte de gestión altamente diferenciado. Aunque en contradicción con su blog, Charity le dio peso a esta opinión durante un evento AskMeAnything que giró en torno a DevOps y SRE. En el evento Compartió una historia sobre un amigo que estaba contratando para una startup, que como experimento, publicó exactamente la misma descripción del trabajo dos veces, la única diferencia es que una lista se tituló "DevOps engineer" y la otra "SRE". el momento de relatar la historia, DevOps estaba ganando en un 10 o 20 por ciento.

Sin embargo, todo esto significa que el título del puesto es irrelevante y nombrar a un equipo de SRE, no le confiere mágicamente cualidades. En lugar de centrarse en el título, las organizaciones deben enfocarse en el trabajo que se está haciendo.

Para resumir, podemos citar a Matt Simmons, un tecnólogo con muchos conocimientos sobre este tema, quien dice: -"No todas las infraestructuras necesitan un SRE, pero cada infraestructura podría usar un administrador que actuara más como uno"-.

Para Usted, ¿SRE o DevOps?

Cloud Foundry para Desarrolladores: Parte 1

Ha oído hablar de Cloud Foundry. Sabe que está creciendo rápidamente y podría ser algo que le interese. Pero, ¿qué es exactamente Cloud Foundry? Una posible respuesta corta es: "Sin embargo otra cosa en La Nube" (Yet Another Cloudy Thingy), porque seguramente hay muchos proyectos en la nube. Una mejor respuesta corta es Plataforma como un Servicio (Paas por sus siglas en inglés) para construir, administrar, aprovisionar o desplegar aplicaciones nativas de La Nube.

En esta serie, le presentaremos Cloud Foundry y cómo empezar a usarlo para desarrollar aplicaciones. En las primeras tres partes, cubriremos los conceptos básicos, la terminología, una descripción general técnica y la arquitectura. En las dos siguientes, mostraremos cómo escribir y enviar una aplicación a una instancia de Cloud Foundry.

La información en esta serie se basa en el curso de capacitación "Cloud Foundry para Desarrolladores" (LFD232) de Cloud Foundry y The Linux Foundation. Puede descargar un capítulo de muestra del curso aquí.

¿Qué es PaaS?

Plataforma como un Servicio o PaaS (por sus siglas en inglés), describe una infraestructura completa para desarrollar, administrar y desplegar aplicaciones. Agrupa servidores, redes, almacenamiento, sistemas operativos, middleware, bases de datos y herramientas de desarrollo en una pila de software y hardware escalable y administrada de manera centralizada.

PaaS puede ser especializado, por ejemplo para el desarrollo de aplicaciones móviles o generalizado, y admite una amplia gama de plataformas y entornos de desarrollo.

PaaS puede estar en su Centro de Datos Local ("on premise"/en sus instalaciones) o pagar según el uso de un proveedor de servicios públicos o una combinación de ambos. Algunos proveedores comerciales populares de PaaS son Amazon Web Services, Google App Engine, Red Hat's OpenShift Online, Microsoft Azure y Salesforce.

El objetivo es agilizar el desarrollo y la administración de aplicaciones al liberar a los desarrolladores de la molestia de crear y mantener sus propios entornos de desarrollo e implementación. Un host PaaS tiene el mismo aspecto para el usuario, ya sea local o remoto: todo lo que necesita es una computadora y una conexión de red para acceder a todo lo que necesita.

Cloud Foundry

Hay una tonelada de información en cloudfoundry.org, pero debe buscar para averiguar qué es Cloud Foundry. Es una plataforma para construir proyectos PaaS; no es un producto independiente, sino que debe ejecutarse sobre una plataforma IaaS (Infraestructura como Servicio). Cloud Foundry se creó en VMware en 2009 y fue diseñado para ejecutarse en VMware vSphere.

Cloud Foundry se transformó y creció hasta convertirse en un proyecto independiente de la Fundación Linux sin fines de lucro. Utiliza Open Container Initiative y muchas otras tecnologías en la nube, incluidas Docker, Kubernetes y BOSH.

Cloud Foundry también se ejecuta en OpenStack y pretende ser neutral en la plataforma, ejecutándose en cualquier IaaS. Si desea intentar crear su propia instancia de Cloud Foundry, siga estas instrucciones en OpenStack.org. Si desea ir directamente al desarrollo de aplicaciones y no tener problemas con la construcción de su propio PaaS, CloudFoundry.org mantiene una lista de proveedores certificados, donde puede comenzar de manera gratuita o de bajo costo.

La Fundación certifica estos proyectos, que deben cumplir con ciertos estándares. La licencia de Cloud Foundry es Licencia Apache 2.0, una licencia permisiva que permite liberar (valga la redundancia) código modificado bajo diferentes licencias y otorga derechos de patente permisivos. La Fundación también ofrece certificaciones para desarrolladores y administra el Examen de Desarrollador Certificado, de Cloud Foundry.

La Fundación Cloud Foundry posee las marcas registradas y administra el proyecto, que no es una tarea pequeña, ya que los contribuyentes y seguidores incluyen algunos pesos pesados ​​de la industria. El trabajo de la Fundación es ser neutral y garantizar que ninguna entidad individual pueda controlar el código.

Hay una gran cantidad de problemas de "propiedad intelectual" para navegar y armonizar. Si este tipo de cosas le interesan, visite Cloud Foundry Foundation para conocer todo sobre administración y control, su junta directiva, membresía y una serie de otras tareas y problemas que la Fundación administra.

"Todos los negocios, son un negocio de software"

Esta es una cita popular ahora, y aunque no estamos completamente de acuerdo con ella, es cierto que la mayoría de las empresas deben ser conocedoras de la tecnología sobre el desarrollo de aplicaciones personalizadas. Cornelia Davis de Pivotal dice: "Estamos construyendo un negocio de software o perdiendo a alguien que sí lo está". Algunos ejemplos clásicos son Netflix vs. Blockbuster, Uber y Lyft vs. compañías de taxis y limusinas, Airbnb vs. la industria de hoteles/moteles.

No todos están completamente contentos con esta invasión de software en todo. Cada restaurante, tienda y producto ahora tiene su propia aplicación, y cada vez más dispositivos nos ladran todo el tiempo. ¿Recuerda la historia corta de Ray Bradbury, "The Murderer"? Albert Brock está harto del ruido incesante de la sociedad moderna, la gente lo llama en su radio de muñeca, e incluso su casa lo regaña, por lo que se embarca en una cruzada de destrucción para cerrar todo. Muy profético para haberse escrito en el ya lejano año 1953.

Pero este es el estado de nuestro mundo ahora y aquí es donde el crecimiento y las oportunidades, son para los desarrolladores de software. Y para mantenerse al día con estos tiempos modernos, en las siguientes cuatro partes de esta serie, veremos cómo comenzar a utilizar Cloud Foundry como La Plataforma de desarrollo.

Le recomendamos descargar ahora el capítulo de muestra de "Cloud Foundry for Developers".

DevOps. Una explicación...

A partir de la Tercera Plataforma, acelerado por la Cuarta Revolución Industrial e indispensable para la Transformación Digital, nace una práctica de ingeniería de software que tiene como objetivo unificar el desarrollo de software (Dev) y la operación del software (Ops). DevOps para los amigos.

Hace un momento alguien me preguntaba: -"...¿entonces qué producto, de qué proveedor, debo adquirir para tener DevOps en mi empresa?"- Me quedé pensativo un momento y mi respuesta casi automática fue: -"No. No existe un producto etiquetado como "<el-nombre-del-proveedor-que-ustedes-quieran> DevOps © V.x o cosa semejante."- Cierto. No es un producto o una "suite" de productos. Es una práctica de ingeniería de software.

Reflexionando en esa pregunta y mi tal vez atolondrada respuesta, es que decidí penetrar más a fondo esta práctica de ingeniería de software. Por ello entonces, comenzaré con los

Antecedentes

El Desarrollo de aplicaciones es una actividad que ya se puede considerar como vieja. Desde que nace la Informática, los Sistemas de Cómputo, éstos vinieron aparejados de los Lenguajes de Programación. Fortran, Cobol, RPG los más antiguos. C, Basic, Java, PHP, etc. como los más "nuevos". No están en orden cronológico pero simplemente quise incluirlos para tener una mejor idea.

Nacen pues los Desarrolladores. Una élite de profesionales especializados en convertir las necesidades del usuario, en código que al ser ejecutado en un equipo de cómputo, permitiendo resolver dichos requerimientos.

No es ajeno para nadie cómo estos seres de luz, estos amos y señores de la codificación, regularmente entraban en conflicto con otros seres cuasi mágicos, que sin ellos, el código que se ejecuta en los sistemas de cómputo, sería letra muerta (código muerto): Los Operadores.

En un cuasi eterno toma y daca, los sistemas de cómputo y los programas de cómputo provistos por los Desarrolladores, han sido blanco de inefables críticas y en ocasiones foco de ríspidas discusiones que llegaban a terminar (incluso) en ataques verbales o hasta físicos.

Ante toda esta vorágine, toda esta debacle que invariablemente quedaba en nada, nacen paradigmas, ideas y conceptos que pedían a gritos algo que permitiese a los "Shōgunes" del Desarrollo y los Señores de la Operación, trabajasen en sana paz, de manera ordenada, coordinada y útil.

Con todo esto en la mente y después de las tempestades

Nace Dev Ops.

Repitiendo el concepto que nos regala Wikipedia: DevOps es una práctica de ingeniería de software que tiene como objetivo unificar el desarrollo de software (Dev) y la operación del software (Ops).

Con lo mejor, lo más concreto y lo más relevante de ambos mundos, DevOps es un ciclo que más allá de un círculo virtuoso, su mejor representación viene en un interminable e infinito Anillo o Banda de Möbius, cual símbolo matemático de Infinito.

Este par de círculos entrelazados, el izquierdo con los pasos fundamentales del Desarrollo (Dev) y su contraparte izquierda con lo propio para la Operación (Ops), suma entonces los siguientes pasos o etapas:

Dev

• Codificación
• Construcción
• Prueba

Ops

• Aprovisionamiento
• Operación
• Monitoreo

Como etapas conjuntas, quedan la Planeación (que es el paso que dispara todo este proceso sin fin) y la Liberación (que es la que entrelaza a ambas áreas, coronando un ciclo).

Evidentemente y desde el punto de vista de las Tecnologías de la Información, lo que más le atañe es la sección correspondiente al Desarrollo (Dev). Pero lo hermoso de DevOps es que Dev no tiene sentido sin Ops y este último, no puede acelerar el negocio sin el primero.

Ahora bien y aterrizando todo esto. ¿Qué es lo que los Proveedores de Productos y Soluciones para las Tecnologías de la Información (TI), tienen para DevOps?

Para comenzar, todo producto y/o solución de TI requiere de una Infraestructura. ¿Física, Virtual, Contenedores, On-Premise, en La Nube, Nube Pública, Nube Privada? Esta es la Primera Decisión Crítica que se debe tomar. Sin entrar en detalles, recordemos que es necesario un Sistema Operativo (completo) o los Binarios y Bibliotecas correspondientes (dentro del contenedor).

Tomada la primera decisión crítica, ¿qué plataforma de desarrollo es la indicada? Java, .net, PHP, Ruby, Python, etc. Esto depende pues de los Desarrolladores. Recordemos que al final la Codificación deberá realizarse apegándonos a la sintaxis, semántica y reglas de la plataforma de ejecución. Esta es la Segunda Decisión Crítica.

Para lo tocante a la Construcción, esto debe realizarse respetando los cánones de la plataforma seleccionada, así como apegada a la metodología de desarrollo y aseguramiento de la calidad (Quality Assurance).

La etapa de Prueba, perfectamente en cumplimiento con todo incluido en el párrafo inmediato anterior, así como en común acuerdo con lo requerido y de preferencia esta etapa involucrando a Operación.

La Liberación, sea en un evento masivo o con toda la discreción, llevada a cabo por ambas áreas para coronar la primer mitad del primer ciclo DevOps. Todo esto se repite "ad infinitum".

Las actividades arriba descritas, que sólo incluyen a las que son responsabilidad del área de Desarrollo, pueden efectuarse de manera manual y utilizando herramientas tan humildes como papel y lápiz. Qué decir también de esas actividades que le tocan al área de Operaciones. Pero, ¿existen herramientas que permitan, siguiendo una metodología  bien definida, auxiliar a ambos actores en este ciclo? Open Source las tiene. En esta imagen se muestran las más características, que incluso se han convertido en estándares "de facto".

¿Es necesario implementar todas? Depende de la metodología que se quiera implementar. Cada una de ellas (dentro de su misma área) tiene un ejército de desarrolladores, consultores y profesionales que pueden auxiliarnos (o no) en la implementación.

Muy importante a tomar en cuenta, en nuestra muy humilde opinión, es revisar con nuestros proveedores de productos para desarrollo, qué herramientas nos ofrecen, qué etapas de DevOps incluyen y con qué otras herramientas es necesario involucrar estos productos. Todo esto, apegado siempre a nuestra metodología predilecta.

¿Para la ejecución de los Desarrollos? Una buena plataforma de ejecución, sobre un excelente Sistema Operativo. Ambos deben de ser estables, seguros, escalables y confiables.

Entonces, ¿Contenedores o no Contenedores? Si en tu ambiente de DevOps requieres orientarte por Micro Arquitectura, el Contenedor es la mejor alternativa. "Contenedores no es Virtualización". Recuerda siempre este "mantra" y repítelo en tu mente con toda la confianza y convencimiento. Esto depende mucho de la Primera Decisión Crítica (ver párrafos anteriores).

En conclusión, DevOps es una excelente práctica de ingeniería de software, que responde y con creces a las demandas y retos que exigen la Tercera Plataforma, la Cuarta Revolución Industrial y su hija (de ambas) la Transformación Digital.

¿Ya implementaste DevOps como tu práctica de ingeniería de software?