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.
Hasta hace poco las opciones con las que contábamos para proveer soluciones eran esencialmente excluyentes entre sí.
¿Diseño la aplicación internamente por mi cuenta? ¿Tercerizo la infraestructura a un proveedor de servicios? ¿Compro una aplicación basada en SaaS? ¿Subo todo a la nube pública?
Aun cuando cada una de estas alternativas tenga sus méritos propios, organizarlas puede resultar difícil.
La plataforma que hemos desarrollado —Red Hat 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.
Durante nuestra trayectoria en TI también hemos tomado la decisión de no entregar todo nuestro trabajo a un único proveedor. Es una forma de mantener la competencia y cierto grado de independencia.
Pienso en la nube híbrida abierta como en una innovación para el CIO. Nos gusta imaginar a los CIO diciendo: “Ya no estoy más atado a cosas que han venido limitando la velocidad a la que puedo moverme, como la infraestructura y las operaciones, y puedo dedicarme al arte de desarrollar software mientras aprovecho las capacidades que me brinda un entorno de múltiples nubes híbridas abiertas.”
Como el entorno empresarial dinámico puede llevar a que las empresas deban 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 año 2018 me demostró que la libertad de elección sigue reinando en la TI empresarial. Pero no se trata de la misma libertad que hemos experimentado en el pasado como proveedor de TI, en gran parte gracias al cloud computing.
La elección del hardware, el software y dónde ejecutarlo sigue siendo muy importante y es objeto de análisis por parte de los responsables de las decisiones informáticas, pero el concepto de elección ha evolucionado hasta abarcar preguntas más existenciales de las organizaciones de TI:
• ¿A quién elijo para operar mi infraestructura si yo no lo hago?
• ¿Por qué no diseño yo mi propio paquete de soluciones?
Existen dos conceptos que apuntalan estas nuevas preguntas: la nube y el código abierto.
¿Quién la va a operar?
Los servicios gestionados no son precisamente nuevos; han existido a un nivel básico durante décadas con la subcontratación de data centers, el correo electrónico y hasta capacidades como los sistemas ERP y CRM.
Pero los servicios de 2018 ocuparon otro nivel, siendo diseñados para abstraerse de las complejidades de operar la infraestructura y hasta los servicios —como las bases de datos—, dejando que los equipos de TI se concentren más a menudo en extraer valor de su trabajo sin ocuparse de las nimiedades del mantenimiento.
En vista de nuestra costumbre anterior de definir la libertad de elección como “software” y “recurso”, podríamos haber pasado por alto el deseo de los CIO y gerentes de TI de que alguien distinto operara su infraestructura; después de todo, no se trata de una elección de software.
Dada nuestra opinión del software de código abierto, esto requiere de una clase de servicios gestionados capaces de funcionar en armonía con los proyectos open source subyacentes.
Pero no es nuestro anhelo dedicarnos a evitar los desafíos. Y hoy, de manera similar a lo sucedido con Red Hat como líder de los modelos de código abierto tradicionales, buscamos impulsar enfoques para los servicios gestionados a través de productos como Red Hat OpenShift Dedicated y Red Hat OpenShift sobre Azure.
Esta puede ser la oportunidad de aportar nuestra experiencia con el software de infraestructura; no sólo diseñamos estas tecnologías sino que además sabemos cómo hacer que funcionen mejor, cómo reforzar la seguridad y brindarles soporte.
Como proveedor de servicios, básicamente nos estamos convirtiendo en nuestro propio cliente en favor de nuestros clientes. Esto ayuda a optimizar nuestros productos para aquellos clientes que eligen operar ellos mismos nuestras tecnologías.
Olvidémonos de operarla. ¿Por qué no la diseñamos?
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.
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.
