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?

VMware evoluciona como el Sistema Operativo, para la Nube Híbrida del futuro

Echando mano de las tecnologías de la información, hemos podido (mientras impartimos curso de VMware vSphere 6.7) revisar material que va saliendo del VMworld 2018.

¿Para comenzar? Aquí la relación de los patrocinadores diamante del VMworld 2018:

Aunque están ordenados alfabéticamente, resalta la presencia de Amazon Web Services. Viendo el video del "Key Note" que ofreció Pat Geisinger (CEO de VMware) en el evento, no debería de sorprendernos.

¿Cuáles son los retos que VMware considera con respecto a la adopción de una Nube Pública? Para comenzar la diversidad de opciones serias que ya hay en el mercado:

¿Qué y cuáles son esos retos que VMware visualiza con respecto a la adopción de La Nube Pública? Costo, Riesgo e Ineficiencias Operacionales.

A este respecto, VMware YA se convirtió en el Sistema Operativo de la Nube Híbrida del Futuro. Parafraseando a Pat Geisinger y Ray O'Ferrel (EVP & CTO de VMware), se pasa del Centro de Datos Definido por Software al Centro de Datos Auto Administrado.

Si ya de por sí hablar de Centros de Datos Definidos por Software exige Automatización y Administración Basada en Políticas, ahora el Centro de Datos por fin tiene un sustento concreto, verosímil y viable para auto administrarse.

Sobre el ya consabido "moto" o "mantra": "Cualquier Dispositivo, Cualquier Aplicación", ahora se anexa "Cualquier Nube".

Amazon Web Services, IBM Cloud, Google, Microsoft Azure. Todas las nubes públicas ya están con VMware. ¿Para qué? NO sólo para utilizar los servicios de todas y cada una de ellas, sino para acelerar la Nube Híbrida, sin importar quién es quien aporta los recursos de nube pública. En palabras de Pat Geisinger: -"...VMware acelera su viaje a la nube múltiple."-

¿Cómo controlar todas las nubes públicas? VMware apoya en ese punto con un consolidador de facturación de servicios en La Nube Pública, siempre y cuando forme parte de el proyecto VMware de aceleración de la Nube Híbrida. ¿A qué nos suena eso?

Para el área de DevOps y demás tendencias de desarrollo, VMware ya ofrece Cloud Automation Services: -"Habilitamos a los Desarrolladores con un rico conjunto de servicios y acceso controlado a cualquier nube"-

VMware anuncia "VMware Cloud Operations", para la Administración, Seguridad y Operación de Cargas de Trabajo en La Nube. Con la compra de "CloudHealth", un consolidador de Servicios en La Nube, se obtiene el Control de los Costos, Conformidad con Estándares y Analíticos.

Otra novedad es el Proyecto "Dimension". En este proyecto el objetivo es -"entregar la simplicidad de la nube de VMware, tanto al Centro de Datos como al "Borde". ¿El Borde? Todo lo que tenga que ver con dispositivos conectados vía una red (Internet), dotados con algo de inteligencia para todo lo que respecta a Internet de las Cosas.

El enfoque de Nube Híbrida de VMware no solo incluye la Nube Privada y la Nube Pública, sino también eso que se llama "Edge" (la frontera o el borde), que como mencioné en el párrafo anterior incluye Internet de las Cosas. TODO entregado como un Servicio. ¿Y quién entregaría el Servicio? VMware y asociados como un Kyo Networks, que ya cuentan con acuerdos con VMware para efectos de VMware Cloud Air. 

¿Qué hay de VMware concretamente y con respecto a DevOps y Contenedores? Se llama VMware PKS. Entrega rápida y "operacionalización" para la siguiente generación de aplicaciones.

¿Y para Blockchain? Reitero mi aclaración de toda la vida: -"Blochchain NO ES Bitcoin"-. Para Blockchain VMware tiene YA el proyecto Concord. Una Infraestructura Confiable Descentralizada para Blockchains Empresarales. Todo ello aprovechando todo lo que el Código Abierto (Open Source) ya tiene a este respecto.

Cabe señalar que en el discurso de Pat Gelsinger y Ray O'Farrell, se mencionó mucho el compromiso que VMware tiene ahora para interactuar con el Código Abierto (Open Source).

Más delante haremos una entrada con más información. Pero el mensaje es claro: VMware evoluciona como el Sistema Operativo para la Nube Híbrida del futuro. 

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?

Los tres pilares para DevOps, en este 2018

Desde fines del año anterior y al comienzo del actual, siempre es agradable ver las predicciones de las tendencias tecnológicas. Publicaciones como Fortune, CNN Money, Washington Post y The Atlantic especulan sobre qué gadgets y tecnologías van a despegar este año, los psíquicos predicen qué celebridades tendrán bebés y cuáles se enamorarán. Ahora bien: ¿Cuáles son las  tendencias en DevOps y en dónde la industria de la entrega de software se dirige?

Poniendo atención a algunas predicciones de DevOps del año pasado, DevOps Digest predijo que DevOps se acercaría más al corazón del negocio en 2017. Pudimos observar entonces que los Indicadores Clave del Rendimiento (KPI por sus siglas en inglés), las métricas y los datos se convertirían en un punto focal para las organizaciones que avanzan con las iniciativas de DevOps.

El Vice Presidente de Estrategia y Administración de Producto en CollabNet, Eric Robertson, predijo en un artículo en DevOps Summit Journal que -"...los análisis desempeñarían un papel más importante en la integración de la herramienta DevOps y que estos dos, junto con las primeras pruebas, serían puntos importantes de discusión para TI líderes en 2017."-

Agregó entonces que: -"...al mirar hacia atrás en el año, las oportunidades únicas que se presentaron, los desafíos que enfrentamos y las decisiones que tomamos como compañía, CollabNet aprendió una o dos cosas (o una docena) sobre DevOps. Y aunque algunas cosas cambian, y siempre estamos aprendiendo, algunas cosas permanecen igual. Por eso este año, cuando hice predicciones sobre las prioridades para DevOps en 2018, mi pensamiento no fue revolucionario."-

Algunas de las tendencias de las que hablamos a comienzos de 2017, como medir el éxito de DevOps, han crecido en importancia durante el año pasado. Las corazonadas que Eric Robertson a fines de 2016 se confirmaron en conversaciones sostenidas con una compañía tras otra, de aquellas que necesitaban una forma de conectarse y medir sus esfuerzos y los resultados de haber adoptado las nuevas herramientas.

De hecho, las necesidades que hemos visto en la industria de entrega de software durante la última década, no han cambiado significativamente. Lo que ha cambiado son las actitudes y voluntades de las personas para cambiar la cultura de una empresa, adoptar nuevas ideas y desarrollar sus organizaciones. Esto nos entusiasma para el 2018.

En 2018, vemos tres pilares principales para el éxito de DevOps que ya son Los Tres Temas Principales de Discusión. Las organizaciones que prestan atención en estas tres áreas, van a ver cómo el desarrollo y la entrega del software florecen de una nueva manera, a medida que se esfuerzan por modernizar procesos y prácticas con Agile y DevOps.

Los tres pilares para el éxito continuado de Devops son:

• Flujos de valor
• Visibilidad y contexto conectados
• Mejora del cumplimiento, el control y la seguridad

Devops, como ideología y práctica, ha madurado de manera espectacular en los últimos años (gracias al ágil movimiento para sentar las bases), y los analistas ahora lo llaman corriente principal. Para no decir que la adopción está completa de ninguna manera, muchas compañías aún están pensando en cómo comenzar el viaje de devops.

Sin embargo, en este punto, cualquier organización ganadora que entregue servicios a clientes a través de software, ha descubierto que los mejores tipos de soluciones de software son aquellos desarrollados y lanzados en sincronización. Eso significa que con ambos lados de la casa Dev y Ops se comunican. Toda una economía surgió para apoyar este objetivo: conectar el ciclo de vida de desarrollo de software y automatizar procesos.

Ahora que la industria tiene una idea de lo que significa DevOps, las empresas han invertido en herramientas, y el concepto ha "crecido", es hora de que DevOps empiece a cumplir su promesa y demuestre que vale la pena. La evolución de la industria de desarrollo de software nos lleva al punto donde tres componentes clave serán parte de cualquier discusión futura de DevOps.

En primer lugar, el enfoque se desplazará a la gestión del flujo de valor y se prestará más atención a la experiencia del usuario. En segundo lugar, la visibilidad será la única forma de gestionar el valor y el contexto será esencial para la automatización y las decisiones comerciales. En tercer lugar, las herramientas se centrarán cada vez más en facilitar el control, el cumplimiento y fortalecer la seguridad.

Comencemos con flujos de valores, el primero de los tres pilares.

El valor de monitoreo es un indicador crucial de la salud, la vitalidad y el éxito de la empresa. El liderazgo de alto nivel pregunta: ¿Cómo identificamos el valor real en nuestros servicios, cómo seguimos el valor para asegurarnos de que estamos innovando correctamente y cómo aumentamos la cantidad entregada a los clientes? Esas son las preguntas que (deberían) impulsar las decisiones comerciales.

En casi cualquier organización importante en la actualidad, el software es esencial para el flujo de valor, particularmente cuando se trata de facilitar la forma en que los clientes interactúan con los servicios de una compañía.

Las aplicaciones se han convertido en la nueva cara de las empresas en muchas industrias diferentes, desde banca y finanzas hasta servicios gubernamentales. Ayudar a las organizaciones a enfocarse en el flujo de valor, el proceso de inicio y finalización del desarrollo y la entrega de software, simplifica enormemente un proceso que de otra manera sería muy complicado.

La gestión del flujo de valor se parece a conectar equipos y procesos dispares, supervisar y conectar herramientas, priorizar tareas, garantizar una mayor eficiencia en las operaciones, eliminar interrupciones mediante la creación de bucles de retroalimentación y tomar decisiones informadas y basadas en datos.

Un enfoque en la corriente de valor también significa un enfoque en la experiencia del usuario final. Esta es la razón principal por la cual la administración de flujo de valor aumenta el valor comercial.

En lugar del seguimiento tradicional basado en proyectos o aplicaciones, la asignación de flujos de valor conecta la cadena de herramientas a una cadena de valor o secuencia de valores. Por lo tanto, proporciona más trazabilidad, visibilidad y datos para trabajar.

Una vez que su equipo asigna sus herramientas en su proceso a un flujo de valor, pueden comenzar a rastrear las métricas que son importantes para ellos. El resultado es un sistema que recopila datos a medida que el equipo crea y entrega software. Las medidas pueden incluir elementos tales como:

• MTBF: tiempo medio entre fallas, tiempo promedio entre cuando se encuentra un problema en el entorno de prueba y cuando se soluciona
• Tasa de defectos: cantidad de defectos que se encuentran por unidad de tiempo
• CLT: cambiar el tiempo de entrega
• RWR (Tasa de retrabajo): Porcentaje de tickets asignados a publicaciones
• UWR (Tasa de trabajo no planificada): Porcentaje de problemas no planificados

Al obtener una comprensión más profunda del valor y el impacto a medida que la información fluye a través de un flujo de valor designado, puede identificar mejor dónde centrar el tiempo y las inversiones futuras.

En última instancia, la gestión del flujo de valor se trata de satisfacer mejor las necesidades del cliente y proporcionar experiencias digitales personalizadas. La gestión del flujo de valores permite una mejor calidad y una entrega más rápida.

Visibilidad y contexto conectados. El segundo de los tres pilares

Sin embargo, para gestionar los flujos de valor, las organizaciones deben tener una visibilidad completa del ciclo de vida del desarrollo del software. Y no solo eso, sino que esta visión debe proporcionar al negocio un contexto para tomar decisiones. De hecho, DevOps no sería posible sin Visibilidad.

Para tener una buena comprensión y una "visión" del flujo de valor, las organizaciones necesitan bastante información. Existen flujos de valor, pero pocos líderes empresariales y sus equipos de administración tienen Visibilidad donde deberían. Nadie puede negar que el ciclo de vida del desarrollo de software es una cadena interconectada.

Cada etapa es esencial para el conjunto y los líderes de TI deben ser capaces de administrar y ver fácilmente, las dependencias y muchas partes móviles. Y no olvidemos la cadena de herramientas. A menudo, las herramientas individuales tienen una buena cantidad de datos que se deben capturar para tener una comprensión completa de lo que funciona y lo que no.

La necesidad de Visibilidad no solo se aplica a las fases iniciales de desarrollo, sino también a la supervisión y medición de un producto después de su implementación. Estas mediciones proporcionan datos críticos necesarios para construir el contexto en torno a cada proceso, especialmente aquellos que están automatizados.

Los eventos de seguimiento, por ejemplo, pueden proporcionar información útil a los gerentes acerca de cómo dar servicio a un producto implementado y qué recursos usar.

Sin embargo, no se trata simplemente de recopilar mediciones y métricas. Los datos deben utilizarse en una vista contextualizada y centralizada para que sean útiles para tomar decisiones empresariales inteligentes.

Esto libera una gran cantidad de conocimiento de los equipos de liderazgo con respecto a los cuellos de botella, problemas de cumplimiento (lo discutiremos en la próxima publicación), ineficiencias, etc. Esto es particularmente importante en el mundo laboral actual cuando los equipos se distribuyen y, a menudo, dentro de la organización.

Mientras más contexto rodee cada decisión, más inteligentes serán esas decisiones. Esto es particularmente importante para impulsar la automatización. Cuanto más contexto, mejores son las decisiones y, en última instancia, más personalizada es la experiencia para el cliente o el usuario final.

El contexto lo es todo en el servicio al cliente y cuanto mayor es el contexto en torno a cada cliente, mejores aplicaciones pueden atender las necesidades de ese individuo. El contexto de construcción dentro del ciclo de vida del desarrollo de software, comienza primero con la medición de los Indicadores Clave de Desempeño y posteriormente, interpretándolos.

En el área de Desarrollo se ha estado hablando de visibilidad por años. Es uno de los puntos fuertes de la premiada plataforma de colaboración TeamForge, utilizada por los clientes para construir algunas de las aplicaciones de software más ingeniosas del mundo. Conectar el complejo ciclo de vida del desarrollo de software de una manera que escala Agile en toda la empresa nunca ha sido más esencial y las organizaciones se están dando cuenta de eso.

Los beneficios de visibilidad entre personas, herramientas y procesos en el desarrollo y la entrega de software no se pueden enfatizar lo suficiente, y con las últimas tecnologías de vanguardia en la medición de Indicadores Clave del Desempeño, métricas y monitoreo de eventos, los líderes de vista contextual que ahora pueden tener sus productos y servicios es una cambiador de juego para la industria.

Las organizaciones no pueden permitirse operar con una visión turbia de lo que está sucediendo en sus equipos de desarrollo, pruebas, control de calidad y lanzamiento. Los costos son demasiado altos y eso es algo que discutiremos más adelante cuando hablemos de la mejora del cumplimiento, el control y la seguridad.

La visibilidad continuará siendo un tema para los esfuerzos de DevOps a medida que avanzamos hacia 2018 y pronto verá a muchos proveedores incorporando esta palabra en soluciones.

Mejora del Cumplimiento, el Control y la Seguridad. El Tercer Pilar

Concluyendo con el tercer pilare clave para el éxito de los DevOps, esenciales para cualquier debate de devops en 2018, sería negligente no abordar las necesidades regulatorias y de cumplimiento que las compañías de software deben observar.

Ya analizamos la gestión del flujo de valores, una forma de ver el ciclo de vida del desarrollo de software que mide el verdadero valor y el éxito de los procesos y las herramientas. También cubrimos el cómo hacerlo y hablé de la visibilidad y el contexto como elementos esenciales para crear y entregar software que satisfaga las necesidades de los clientes.

La visibilidad y la medición son los pilares necesarios para cumplir con las obligaciones de cumplimiento, gobierno y seguridad. Si estamos hablando de un banco, un fabricante de automóviles, una organización de atención médica o incluso una agencia gubernamental, su empresa ha asignado personas y recursos para entregar software que puede ser un producto, un servicio o un componente.

Pero más allá de brindar una experiencia positiva al cliente, existe una necesidad particularmente apremiante de "Value Stream Management", habilitada por la visibilidad y el contexto, para la entrega de software en industrias con naturales y muy necesarias restricciones regulatorias.

Las empresas en el sector financiero o en las industrias del cuidado de la salud por ejemplo, tienen obligaciones de control, auditoría y riesgo que las distinguen de otras industrias. Estas organizaciones pueden estar invirtiendo mucho tratando de mejorar la forma en que entregan valor a los clientes a través del software, pero muchas de ellas no tienen una manera de mostrar claramente el valor de sus esfuerzos, o una manera eficiente de demostrar que se están tomando en cuenta los requisitos reglamentarios.

Cuanto mayor sea el perfil, más fácil será rastrear todos los aspectos de un servicio de software hasta su código correspondiente y a los miembros del equipo responsable. Esto es esencial para el cumplimiento. Las organizaciones necesitan poder rastrear cada compromiso, cada artefacto y necesitar una vista completa del ciclo de vida del desarrollo de software para hacer esto.

Y mientras hablamos de control y cumplimiento, no nos olvidemos de la seguridad. La medición y las métricas son los mejores amigos de la seguridad. Cuanto más refinado sea el contexto, mayores serán las medidas de seguridad que se pueden emplear y más fácil será llevar la seguridad a la etapa inicial del Ciclo de Vida de Desarrollo de Sistemas (SDLC por sus siglas en inglés).

Para mantener a su empresa fuera de los titulares por una violación de datos, sus equipos deben comenzar a pensar en la seguridad desde el primer día: en los procesos de planificación del software.

De alguna manera, todo ha cambiado: la tecnología avanza todos los días. En otros aspectos, veo cómo las necesidades de las empresas realmente no han cambiado tanto.

Hablando con los CTO, los CIO, los ingenieros y los gerentes de proyectos, nos comparten que todavía están tratando de descubrir cómo unificar y alinear los procesos de desarrollo. Están buscando maneras de ver a todas las personas, procesos y herramientas de una manera centralizada para desplegar más rápido y con mayor confianza.

En conclusión, aún hay mucho camino que recorrer dentro de DevOps, principalmente en lo que toca a los Tres Pilares Fundamentales. Pero como dice el proverbio chino: -"Un viaje de diez mil pasos, siempre tiene que comenzar con el primero."- ¿Ya dio Usted, su empresa u organización el primer paso en el camino de DevOps?