Elastic Compute Cloud

Veinticuatro de agosto de 2006, Amazon anuncia la disponibilidad de su servicio Elastic Compute Cloud (EC2). La compañía no solo ha superado el pinchazo de la dot-com bubble, sino que irrumpe con fuerza en el mercado tecnológico ofreciendo infraestructura como servicio. La introducción de EC2 fue un hito enorme: el primer ejemplo real de un servicio cloud generalista, accesible para todo el público.

Lino PrahovCloud o la tierra prometida

Ya llevábamos unos años hablando de cloud. Tras la euforia de la burbuja y su estrepitosa caída, los inversores y accionistas habían exigido la vuelta a las estructuras tradicionales, entendiendo que el concepto de todo virtual no podría funcionar para la mayoría de los negocios. El soporte físico y tradicional seguía siendo imprescindible, especialmente en lo referido a cadenas de suministro, stocks, logística y operaciones.

Pero si algo habíamos aprendido de esa experiencia traumática era que la tecnología sí podía ayudar a acelerar y dar flexibilidad al resto de funciones de negocio. La tecnología estaba para quedarse, pero ya no era el fin, sino el medio.

El cloud prometía ser esa tierra prometida —de bendición, abundancia y protección— que nos liberaría de la esclavitud inherente a la tecnología: grandes inversiones; dependencia de un numeroso personal técnico que se ha de captar, desarrollar y mantener; integraciones complejas y lentas… En definitiva, coste y rigidez. El negocio solo tendría que preocuparse por sus aplicaciones, no por la tecnología. Zapatero, a tus zapatos.

  • “Marketing podrá lanzar una web nueva para sus campañas cuando quiera, sin tener que recurrir a TI, y eliminarla cuando quiera… Solo pagará por el tiempo de actividad”.
  • “Nuestro equipo de animación podrá provisionar las máquinas adicionales que necesita para renderizar el nuevo capítulo durante 72 h…”.
  • “No tendremos que invertir cantidades astronómicas en un nuevo centro de datos ni dimensionarlo a tres años vista…”.

¡Maravilloso! ¡Es un cambio de paradigma! Es un cambio de cultura… Pero, con la cultura hemos topado…

El desierto

db59_La tierra prometida o vagar por el desiertoLos departamentos de TI se lanzaron a aprender y a adaptar sus procedimientos, pero también se mostraban reticentes a ceder el control. Finanzas, atraído por la promesa de minimizar el CAPEX y optimizar los costes, falló al identificar al nuevo responsable del presupuesto. Los servicios cloud seguían constando como gasto de TI y ello desincentivaba a los técnicos para que aceptaran proyectos nuevos.

Las unidades de negocio continuaban abrumadas por la complejidad de la tecnología y seguían exigiendo la ayuda de TI. En el proceso, tenían que explicar y justificar sus necesidades y expectativas. Ambos, TI y Negocio, terminaban frustrados por la aparente ineptitud del otro.

Los departamentos de TI veían aumentada su carga de trabajo por la gestión de un nuevo grupo de proveedores, del presupuesto y atribución de costes, la imposibilidad de planificar recursos, preocupaciones de privacidad y seguridad de los datos… Todo ello porque las herramientas de autogestión y control del servicio nunca se llegaron a desarrollar.

Los proveedores de servicios cloud, nativos digitales por naturaleza, ofrecían desde el día cero herramientas de integración que daban acceso a toda la funcionalidad que el cliente necesitaba para ocuparse él mismo de la gestión. Pero la integración requería un desarrollo, cuyo coste nadie quería asumir sin tener garantizado un retorno inmediato. Como cuando queremos lucir cuerpo en la playa, pero no queremos sudar en el gimnasio.

El cloud era la tierra prometida donde nos sacudiríamos el yugo tecnológico

Al final, aparte de unos pocos elegidos, que hoy llamamos nativos digitales, el resto vagábamos por un desierto de burocracia, costes impredecibles y falta de dirección clara. La supuesta libertad para acceder a soluciones tecnológicas nunca llegó, muchos se plantearon volver a los centros de datos tradicionales en propiedad, o se lanzaron a hacerlo.

Cómo cruzar el rio

Casi dos décadas después, seguimos buscando el vado para llegar a la tierra prometida. Tras ayudar a decenas de clientes en esa búsqueda a lo largo de los años, he llegado a la conclusión de que la única forma de cruzar el río sin ahogarse es… no intentarlo… O al menos no siempre. Deberíamos entender que las soluciones que han nacido en la esclavitud del pasado no podrán cruzar, al menos sin generar más problemas, coste y riesgo que los que pretenden mitigar.

Frecuentemente, para esas soluciones heredadas la mejor opción es mantenerlas en un modelo on-premises o volver a trasladarlas a él; o, como mucho, colocarlas a medio camino, en la orilla del lado del desierto: usar infraestructura como servicio, fija y dedicada a cada solución. Así podríamos, al menos, aprovechar parte de las ventajas del cloud: no tener que lidiar con grandes inversiones en equipos y su amortización, trasladar los riesgos ambientales a un proveedor, etc.

Cloud_mRHoustonSin embargo, las soluciones nuevas pueden nacer ya en la tierra prometida y florecer. Ya estamos preparados para ello. La disrupción que supuso la pandemia y los cambios organizativos que provocó ayudaron a las empresas a cambiar de mentalidad. Ya entienden la necesidad de inversión en tecnologías y procesos intangibles que antes se consideraban “capricho”: la mayoría de los presupuestos incluyen partidas dedicadas a tecnologías emergentes, prototipos o desarrollo continuo; las unidades de negocio ya están más versadas y experimentadas en trabajo remoto y virtual.

Además, el cambio de mentalidad ha coincidido con la madurez y disponibilidad generalizada de soluciones SaaS para todas las funciones de negocio estándares (CRM, ERP, finanzas, gestión de proyectos, comunicaciones y ofimática general, etc.). Adoptando estas soluciones, la organización se puede limitar a buscar y mantener desarrollos a medida solo para aquellas de sus capacidades que son únicas o estratégicas.

Ahí es donde ya tenemos experiencia y conocimientos que han demostrado ser efectivos. Los procesos de desarrollo a medida, tradicionalmente los más costosos y propensos al fracaso, son los que mejor pueden adaptarse a ese nuevo entorno. Solo hay que recurrir a una cultura, metodologías y técnicas que han ido evolucionando en paralelo al cloud durante décadas —Agile, DevOps, InfraOps— y que permiten integrar el proceso completo de desarrollo de la solución, desde la recogida de requisitos de negocio hasta la operación continua en producción.

El proceso se iniciaría en las herramientas de colaboración y gestión de proyectos compartidos entre Negocio y Desarrollo (las cuales, paradójicamente, son también en su mayoría cloud SaaS), donde Negocio podría definir sus necesidades y requisitos, y observar en tiempo real cómo éstos se mueven en el flujo del proyecto.

La introducción de EC2 fue un hito enorme: el primer ejemplo real de un servicio cloud generalista, accesible para todo el público

El equipo técnico realizaría su trabajo de manera independiente y, tras la entrega y validación de los resultados, las soluciones DevOps realizarían todos los trabajos de comprobación funcional, integración, generación de código y de infraestructura, despliegue…; es decir, pocos minutos tras finalizar su trabajo, un programador vería la aplicación “automágicamente” disponible y operativa para que Negocio la pueda validar o utilizar.

Además de reducir la probabilidad de errores y los tiempos y costes de integración, el equipo técnico pasaría de proveedor de servicio —que negocia una transacción comercial— a socio, que busca soluciones mutuamente beneficiosas a largo plazo.

Conclusión

El desierto es real, pero hay esperanza. Aplicar metodologías colaborativas, como Agile y DevOps, en nuevos proyectos puede allanar el camino hacia un autoservicio de TI transparente, flexible y amigable. Existe un ecosistema de soluciones, herramientas y profesionales experimentados que pueden respaldar la adopción de estas metodologías y los cambios culturales necesarios.