La nube híbrida es una nueva realidad de la TI. Si bien son muchos los beneficios que este modelo aporta, 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? Aún cuando cada una de estas alternativas tenga sus méritos propios, organizarlas puede resultar difícil.
Por ello, la plataforma 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. Y es que no es recomendable entregar todo nuestro trabajo a un único proveedor. Es una forma de mantener la competencia y cierto grado de independencia. La nube híbrida abierta es realmente una innovación para el CIO.
¿Cómo puede un CIO aprovechar la nube híbrida abierta?
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, pueden 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 puede ofrecer. Desde su perspectiva, las múltiples nubes híbridas abiertas son capaces de ofrecer la combinación de mayor durabilidad y portabilidad.
En 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 va a operarlo?
Los servicios gestionados no son precisamente nuevos; han existido a un nivel básico durante décadas con la subcontratación de Datacenters, el correo electrónico y hasta capacidades como los sistemas ERP y CRM.
Sin embargo, 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 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 a 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 “hazlo tú mismo” frente a la TI a fin de crear sus propios paquetes de soluciones personalizados.
Cada vez veo a más CIOs 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. Sin embargo, 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 “hazlo tú 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.
