Reflexiones desde 2015…
Con la ventaja de poder conocer perfectamente los hechos en retrospectiva, me pregunto ahora cómo yo – y muchos otros CIOs- pudimos caer en el engaño de que el hardware era barato durante tanto tiempo. Antiguamente podíamos permitir que cada grupo funcional de la empresa se enamorase de sus propias aplicaciones, cada una de las cuales tenía sus propios requisitos de arquitectura de hardware y middleware. Ya que los gastos en hardware eran siempre la parte más pequeña dentro de una gran operación de compra de sistemas, solíamos de manera sistemática sobredimensionar el hardware para prevenir posibles problemas de bajo rendimiento del sistema. Pero la proporción del espejismo aún era mayor dado que nosotros en realidad nunca hacíamos una auténtica gestión de la capacidad ni evaluación del rendimiento ya que no queríamos conocer la respuesta: todos intuitivamente sabíamos que nuestras granjas de servidores y recursos de almacenamiento estaban notablemente subutilizados.
Cuando los proveedores de servicios de cloud pública empezaron a aprovisionar infraestructura de TI bajo demanda en la modalidad de “pago por uso”, por fin nos despertamos de nuestros sueños y pudimos darnos cuenta de que estas nuevas opciones bajo demanda pronto iban a desplazar a nuestras operaciones in-situ debido a su mayor eficiencia y fiabilidad. Así que empezamos a operar al modo de los proveedores de servicios en nube pública pero dentro de nuestras propias empresas. Quebrantamos las normas con nuestros clientes internos y les empezamos a indicar qué arquitecturas de hardware y middleware estarían soportadas y cuáles no. Les dijimos: “Si no funciona en ninguna de nuestras arquitecturas estándar, no se compra”.
Después tuvimos una jornada de reflexión con nuestros directores financieros. Tendríamos que agachar la cabeza y reconocer que todo el hardware que en la década anterior nos habían dejado comprar estaba allí instalado, en el centro de datos, funcionando por debajo del 50% de su capacidad en un momento dado (con la excepción del mainframe, por supuesto). Les contamos que si nos permitían comprar más capacidad en previsión de nuevas demandas de cara al futuro, y si evitábamos los gastos en ampliaciones de hardware asociados a la adquisición de grandes sistemas, podríamos lograr tasas de retorno de inversión en nuestro hardware de TI mucho mayores. Básicamente acordamos que empezaríamos a informar del nivel de utilización de esta capacidad en compensación por la nueva política de compras destinadas a la ampliación de capacidad en previsión de un aumento de la demanda.
Mirando hacia atrás, me resulta sorprendente todo el tiempo que estuvimos confusos y desorientados con respecto a las cuestiones de la seguridad en las nubes públicas. Ahora de manera rutinaria lo dejamos todo en manos de proveedores de servicios de cloud público para que nos resuelvan una serie de tareas concretas. Nosotros definimos los requisitos de seguridad de cada tarea de computación y empleamos las técnicas de cifrado o traducción de datos adecuadas para garantizar la seguridad de los datos que se traspasan a los proveedores externos.
Aunque algunas modalidades de datos son demasiado sensibles para dejarlos incluso dentro del centro de datos de nuestra propia compañía, estas decisiones de ubicación de tareas ahora se resuelven utilizando procesos automatizados de aprovisionamiento. Ya no caben los debates filosóficos sobre lo que puede y lo que no puede traspasar nuestro firewall. Hace tiempo que zanjamos esa cuestión.
Hace diez años podíamos tardar entre tres y seis semanas de reuniones, correos, valoraciones de hardware y negociaciones de precios para hacernos con los servidores necesarios para proveer a un grupo de desarrollo. A finales de 2010, utilizando configuraciones estándar y scripts automáticos en un entorno virtualizado, los CIOs podían disponer de los mismos servidores tanto en nubes públicas como en nube privada en un plazo de tres a cuatro horas. Hoy podemos hacerlo en unos cuantos minutos. Disponemos de scripts normalizados y automatizados que se emplean para aprovisionar distintos tipos de servidores –como los destinados a desarrollo, los de QA, Web o aplicaciones- en la nube, con lo que no solamente nos ahorramos una enorme cantidad de horas de trabajo del personal, sino que además aporta flexibilidad a la empresa.
Hoy en día yo mismo gestiono una plataforma de cloud computing híbrida que consiste en infraestructura interna, in-situ, combinada con una serie de proveedores externos a los que recurro cuando es necesario para resolver tareas concretas. Si lo pensamos bien, no es muy distinto de la forma en que utilizábamos tiempo atrás el outsourcing estratégico de servicios, para desarrollar y mantener muchas de nuestras aplicaciones de negocio.
En sintonía con el fantasma del año 2000 a finales de los 90, dediqué cinco años a aprender a virtualizar mis equipos de aplicación y desarrollo aprovechando los recursos de TI ubicados en Asia y Europa oriental. Dediqué los últimos cinco años haciendo lo mismo con mi infraestructura, dando un uso diferente a los activos de computación internos y externos de que disponía para cubrir las necesidades de mis clientes de empresa de la manera más económica posible. Ahora me parece que la historia se repite al cabo de los años.
Ya en 2010 la buena noticia es que éramos lo suficientemente maduros e inteligentes para apuntarnos al carro del cloud computing, porque de lo contrario nunca habríamos podido disponer de la flexibilidad y los recursos necesarios para aprovechar la explosión de aplicaciones para móviles que se ha producido en los últimos cinco años. En realidad habríamos tenido que gastar el 60 por ciento de nuestro presupuesto en TI solo para “mantener en marcha” nuestros antiguos sistemas de negocio.
Volviendo a 2010, para mí habría sido un buen año si hubiera podido poner en marcha dos o tres nuevas aplicaciones de negocio importantes y sacar las versiones trimestrales y mensuales necesarias para dar soporte a la “ratonera” de sistemas antiguos que tenía que mantener. Me encontraba a mí mismo compitiendo con Apple y desarrolladores de Android que eran capaces de sacar más de ¡10.000 nuevas aplicaciones por trimestre! Al final es lo mismo que el cloud computing. Decidí rendirme y dejar de competir con estos desarrolladores de aplicaciones para móviles y convertirme yo mismo en uno de ellos. Mi equipo empezó a desarrollar servicios de negocio mucho más granulares que podían funcionar en plataformas táctiles con bastante más frecuencia. Efectivamente, nuestros equipos de desarrollo de aplicaciones evolucionaron hacia equipos internos de fabricación de SaaS mezclando y combinando servicios muy granulares para mejorar la productividad de nuestros usuarios finales y responder así a las amenazas de nuestros competidores.
Empezamos a utilizar versiones SaaS de nuestras aplicaciones de negocio estándar en el periodo 2005-2010. Nuestros usuarios estaban encantados con la rápida introducción de nuevas funcionalidades que ofrecían los fabricantes de SaaS, y nosotros estábamos encantados con los costes tan bajos de soporte que tenían, comparados con los sistemas antiguos. En los últimos cinco años nos hemos convertido nosotros mismos en proveedores de SaaS. La mayoría de las aplicaciones que utilizamos en nuestra empresa hoy día son eso, “mezclas” de diferentes servicios de negocio. La mayor parte de nuestros usuarios desconocen si un servicio concreto proviene de nuestro sistema ERP, nuestro sistema de soporte a clientes, o del sistema de eCommerce o cualquier otro. Simplemente se suscriben a los servicios que necesitan para realizar sus actividades. Ya no tratamos en forma alguna de imponerles funcionalidades. Ellos son los que toman lo que necesitan y después lo comparten de manera mucho más amplia entre los distintos grupos funcionales y geográficos de lo que habíamos conseguido anteriormente.
Una de las consecuencias más positivas del cloud computing para nuestras organizaciones es que conseguimos liberar una enorme cantidad de tiempo que antes dedicábamos al mantenimiento del hardware. Ese tiempo empezamos a aplicarlo a gestionar los datos y la información que alimentaban nuestras aplicaciones de negocio y eso tuvo un impacto mucho mayor en la efectividad de nuestras operaciones de negocio cotidianas.
Ahora vivimos en un mundo radicalmente distinto del que conocíamos hace tan solo cinco años. Ya no nos gastamos 60 céntimos de cada euro destinado a TI en mantenimiento de aplicaciones, operaciones de centro de datos, gastos de instalaciones y demás. Ahora gastamos 60 céntimos de cada euro en TI a poner en marcha nuevos servicios de aplicación y nuevas modalidades de entrega de “información limpia” a los usuarios finales. La plantilla de TI vive ahora mucho más feliz, son conscientes de que generan auténtico valor para nuestros usuarios y no pierden el tiempo en moverse de manera compulsiva tratando de mantener un montón de hardware y software subutilizados. Además estamos cada vez más cerca de conseguir ese estado mítico del “alineamiento perfecto entre la empresa y las TI” que aún, en 2015, sigue apareciendo entre los temas más importantes de investigación de Gartner.
Ahora lo que falta es que mi Tablet-PC incorpore un calentador de tazas de café…
