Código abierto: la nube

Redacción20/02/2019

4 minutos de lectura

Por Mike Kelly, CIO, y Matt Hicks, vicepresidente senior de ingeniería de software de Red Hat:

La nube híbrida es una nueva realidad de la TI. Si bien son muchos los beneficios que aporta este modelo, creo que las organizaciones deberían adoptarlo por las posibilidades que potencialmente ofrece.

La plataforma que hemos desarrollado, OpenShift, está diseñada para brindar un mayor margen al momento de elegir cómo aprovechar los beneficios de un mundo de múltiples nubes híbridas.

Como el entorno empresarial puede llevar a que las compañías a considerarse una empresa de software, las organizaciones pueden recurrir a sus equipos de TI para transformarse y la forma en que podemos hacerlo es escribiendo software. Hoy, cuando los equipos de TI tienen un problema empresarial que no pueden resolver con las herramientas con las que cuentan, pueden diseñar las soluciones por su cuenta, y pueden hacerlo sobre nuestra plataforma OpenShift. Una vez que el CIO decide modernizar las aplicaciones conforme a un modelo de múltiples nubes híbridas abiertas, puede hacerlo sin tener que recurrir a los monolitos que solíamos conocer. Es por eso que el CIO es capaz de hacer cambios con mayor fluidez y aprovechar lo que un modelo de múltiples nubes híbridas abiertas puede ofrecer. Desde la perspectiva del CIO, las múltiples nubes híbridas abiertas son capaces de ofrecer la combinación de mayor durabilidad y portabilidad.

El incremento de la nube como eje estructural informático y la disponibilidad inmediata del software de código abierto significa que los líderes de TI pueden adoptar un enfoque “hágalo usted mismo” frente a la TI a fin de crear sus propios paquetes de soluciones personalizados. Cada vez veo a más CIO a quienes les dicen que ahora deberían construir sus propios paquetes de soluciones en lugar de intentar adquirir tecnologías específicas. Esto puede ser provechoso desde el momento en que podrían diseñar exactamente lo que deseen. Pero también puede ser una desventaja ya que, dado el ritmo del desarrollo del open source, es probable que estos paquetes personalizados no sean capaces de consumir la nueva innovación al paso en que se produce y podrían volverse insostenibles.

Uno de los aspectos más desafiantes es que diseñar su propio paquete de soluciones puede ser muy eficaz y eficiente al comienzo, y en eso consiste su atractivo. Pero esa es la parte sencilla. El futuro del paquete de soluciones requiere:

Mantenimiento continuo, lo cual puede ser cada vez más complejo, especialmente a medida que la implementación se amplía y aloja cargas de trabajo y sistemas más y más complicados. Esto requiere de un conjunto nuevo y mayor de habilidades cada vez más especializadas para supervisar debidamente facetas que tal vez no existan en una organización determinada.

Correcciones y parches cuando algo no funcione (y siempre habrá algo que no funcione). Los conocimientos especializados requeridos para comprender y solucionar problemas de la TI moderna van en aumento y existen capas de API que abarcan desde el núcleo hasta el sistema de orquestación. Cuando ocurre una falla se ponen en duda millones de líneas de código en todos los sistemas donde las sutilezas y matices son más complejos que en los sistemas de software de antaño. Puede resultar difícil diagnosticar una falla e incluso más difícil corregirla.

Provisión de correcciones y parches a la comunidad open source para ayudar a limitar las posibilidades de que una organización se tope con estos problemas otra vez en un versión futura del código. Éste es un hecho crítico y con frecuencia olvidado en el uso de proyectos de código abierto. Que lo haya corregido una vez no significa que quede corregido en la comunidad, en especial si no está involucrado con el desarrollo.

Lo que he observado es que los paquetes de soluciones “hágalo usted mismo” fallan donde confluyen el mantenimiento, el talento y la influencia open source. Desafortunadamente, es probable que cuando fallen ya estén alojando aplicaciones críticas que hagan que el riesgo sea mucho mayor. Los CIO de las empresas son conscientes de cuán elevado puede ser este riesgo y deberían analizar detenidamente los desafíos que plantea el diseñar versus el comprar, aunque sufran la presión de “sólo” diseñar.

Naturalmente diremos que Red Hat puede ayudarlos. Nuestra meta es ofrecer productos de clase empresarial que permitan aprovechar la innovación de código abierto que los sustenta. No nos limitamos a entregar componentes open source. Son miles los ingenieros que asignamos a estos proyectos para que comprendan cabalmente el código que entregamos y colaboramos con estas comunidades para ayudar a ejercer la influencia necesaria para poder lograr las correcciones incluidas en las versiones más nuevas.

En vista de este nuevo entorno de “libertad de elección” y el ritmo del cambio y la innovación que se están sucediendo, la capacidad de aprovechar la innovación —desde la nube hasta los contenedores y más aún— ayuda a que tanto los CIO como los directores de tecnología y el sector de la TI sean más optimistas. Hay optimismo respecto de la capacidad de resolver los desafíos que surjan, de proveer servicios y productos nuevos y diferenciados a nuestros usuarios finales y de estar mejor preparados para un entorno empresarial cambiante. Los líderes de TI no deberían dejarse abrumar por esta libertad de elección. No obstante ello, es en esta instancia donde entran en escena los socios de confianza como Red Hat. Ya hemos pasado por esto y, a pesar del cambiante panorama poblado por cada vez más nubes, seguimos aquí para ayudar a diseñar su TI de próxima generación.

[email protected]