Cloud Computing
SaaS
Nube
PaaS
IaaS

Aterrizando la nube

¿Cuánto tiempo llevamos escuchando que la nube nos va a hacer ágiles, eficientes y a generar valor de negocio? Leía esta semana que la mayoría de las empresas del Forbes Global 2000 estaban todavía empezando el viaje hacia la Cloud en todas sus formas desde IaaS a SaaS.

Aterrizando la nube

Está claro y no creo que nadie lo discuta, que si hoy creas una compañía, el 100% de tu infraestructura y tus aplicaciones estará en la nube (salvo excepciones por temas regulatorios).

Pero como el 99,9% de las empresas tienes aplicaciones actuales (las mal llamadas legacy), pasar del “power point” a la ejecución con resultados, es mucho más complejo que lo que cualquier equipo o proveedor puede pensar sobre el papel. Lo qué si hemos aprendido todos a lo largo de los años, es que la curva de aprendizaje no hay quien se la salte, y aunque la tecnología y su uso sea sencillo en teoría, el cambio nunca lo es.

Como a muchos otros CIOs y equipos de tecnología, me ha tocado enfrentarme a pensar por dónde y cómo empezar, y cuando decidimos arrancar hace ya unos cuantos años, hubos tres aproximaciones que nos permitieron empezar a dialogar con el director financiero, porque como siempre: “all is about money”. Más allá de las modas, nos toca explicar y justificar el sentido de negocio de todo este cambio.

La primera aproximación es pensar que aplicaciones no core puedes llevar directamente a un modelo SaaS. Y de esta manera cambias activos, que en muchos casos estarán obsoletos y con interfaces poco atractivos a modelos de pago por uso, sin desarrollo a medida, y parametrizando lo justo para no tener problemas en la evolución de versiones.

En este grupo caben perfectamente el correo y las aplicaciones colaborativas para los empleados, herramientas de RRHH, herramientas de gestión de tickets de gastos de empleados, firma electrónica de documentos, y demás satélites para automatizar tus procesos internos y mejorar las capacidades de tus empleados.

Tenerlo en la nube no significa que no sigas siendo responsable de monitorizarlo, asegurar que se cumplen los niveles de servicio y tener plan B para cuando la nube falla.

Aquí las dos discusiones a las que me ha tocado enfrentarme han sido, cómo cambiar capex por opex, porque siempre habíamos trabajado en un modelo de activo propio, y evitar el tunear las aplicaciones SaaS, porque teníamos una cultura de todo a medida. Teníamos equipos empeñados y perdiendo energía en justificar que lo que le vale al resto del mundo a ellos no.

La segunda aproximación es pensar qué aplicaciones actuales te interesa virtualizar y llevar a nube porque sobre el papel te ahorren costes de infraestructuras, y matas dos pájaros de un tiro: eliminas obsolescencia y empiezas a aprender de la gestión de la nube, que se parece muy poco a la gestión tradicional de las infraestructuras on premise.

En nuestro caso, además aprovechamos para hacer re-arquitectura de las aplicaciones más críticas de negocio, consiguiendo mejoras significativas en performance y reducción de costes de mantenimiento.

Ahora existen soluciones para de manera automática valorar el esfuerzo y el coste de cloudificar tus aplicaciones, pero en aquel momento, hacerlo a mano y sin mucha experiencia previa nos dio algún disgusto de complejidad mal estimada, retrasos y sobre esfuerzos en los equipos.

Y como siempre, el punto que más atención me requirió fue adecuar el modelo de trabajo del equipo a la nube, gestionando miedos, incertidumbres y cambios en las funciones, y quién era responsable ahora de qué. Veníamos de un modelo tradicional arquitectura, implantación y operación, y como además teníamos nube en nuestras instalaciones y nube de otros proveedores, nos enfrentamos a escenarios completamente nuevos para todos los equipos.

Si hoy volviera a empezar esa segunda aproximación, además de utilizar herramientas para automatizar parte del proceso, hubiera empezado aprendiendo con alguna aplicación menos core, porque la curva de aprendizaje hubiera sido más suave y menos disruptiva.

Tengo dudas de que se ahorre mucho en costes de infraestructura en el neto, pero para mí la ventaja indiscutible que se consigue es la agilidad en la provisión y creación de infraestructura.

La tercera aproximación es que trates qué lo nuevo que nazca cloud nativo, usando PaaS, cuando no puedas usar una aplicación SaaS que te cubra tus necesidades. Esto es mucho más sencillo cuando creas una aplicación nueva, pero en la mayoría de las arquitecturas de las grandes compañías, hay un paso intermedio fundamental para poder llegar al uso de PaaS y arquitecturas de consumo de recursos de forma simple y rápida.

Ese paso intermedio se llama Apificar tus aplicaciones con mayor visibilidad para tus clientes, de manera que puedas evolucionar a construir microservicios que te permitan poner nuevas funcionalidades para tu negocio en plazo y coste competitivo. Esto no es sencillo, pero o te planteas hacerlo todo nuevo, lo cual a mí me genera muchas dudas, o tienes que invertir en apificar, como elemento clave de la agilidad de tus desarrollos.

Es un paso fundamental para evolucionar tus modelos de desarrollo de los waterfall a agile, dev-ops…. Pero esto da para un post específico.

Como veis estas tres aproximaciones que usamos, te llevan a que esto no va de nube pública, privada, híbrida, IaaS, CaaS, PaaS, SaaS sólo. De nuevo eso son habilitadores técnicos para dar respuesta a un requisito de negocio: bien para ahorrar costes, bien para nuevos ingresos, bien para fidelizar a nuestros clientes, y para ser mucho más ágiles. Y la respuesta no será nunca única, tendrá varias respuestas según tus necesidades y las capacidades actuales y futuras de tu equipo.

Para mí, la nube es un cambio muy profundo de tecnología y de cultura de gestión, y como tal es un viaje que hay que pensar y preparar bien antes de lanzarse a ejecutarlo. Ya cada viaje será diferente, ¿Estáis ya aterrizando vuestra nube?

Comentarios

Iniciar sesión

Aún no hay comentarios sobre este contenido.

Próximos Eventos