“No hay madurez en el mercado, ni en los clientes ni en algunos de los proveedores”

Ingeniero industrial de profesión, Jorge Pestaña cuenta con un background tanto técnico como de negocio, que ha ido adquiriendo a través de una trayectoria profesional que le ha llevado a vivir de forma cercana los retos asociados al sector telco. A esto hay que sumar también su experiencia en el rol de alianzas desde el punto de vista del fabricante, pero también desde el lado del proveedor de servicios.

¿Por qué este doble rol de cloud y alianzas?

Con el nacimiento de DXC Technology en España, me encargaron la tarea de crear la función de alianzas aprovechando mi anterior experiencia en HPE, aunque el rol que tenía entonces estaba muy ligado al producto. Cuando pusimos en marcha la función en DXC Technology percibí que una de las alianzas más importantes que había que construir era precisamente con los grandes proveedores de cloud pública. Este fue uno de los principales focos y ha sido donde más esfuerzo se ha volcado hasta la fecha.

En el ámbito de alianzas, las que se definen con los distintos fabricantes de hardware surgen de forma más “natural”. Es importante contar con unas relaciones bien construidas para tener una operación ágil y unos precios competitivos, pero esto es algo más business as usual. Cuando sí nos jugamos el futuro de la compañía es si no tenemos bien construidas las capacidades de colaboración con las grandes firmas del mercado cloud (Google, Microsoft, Amazon, VMware…), que son las que están marcando el futuro. Esas son las relaciones realmente estratégicas.

¿Qué percepción se tiene acerca del cloud?

Respecto al convencimiento de que la nube es el futuro, es decir, el grado de aceptación acerca de la realidad hacia la que deben ir las empresas, es muy alto. Casi todas reconocen que la nube es el futuro y que hay que estar ahí. El proceso de aceptar esa realidad ha sido relativamente rápido y sencillo. Pero es muy distinta la idea de la ejecución.

Todo el mundo habla del cloud, pero muy pocos hacen, especialmente las grandes compañías

Todos están convencidos y quieren ir a la nube pública, pero una cosa es querer y otra es poder. Todo el mundo habla, pero muy pocos hacen, especialmente las grandes compañías, que son las que tienen más dificultades debido a la enorme complejidad de toda su “maquinaria”. Durante muchos años, sus infraestructuras se han organizado para trabajar de una forma determinada, muy distinta de aquella hacia la que ahora deben dirigirse.

No hay que convencer a nadie de que cloud es el futuro, la cuestión es cómo ir allí. Es muy importante abrir el debate en torno a lo que está dificultando que las empresas no estén yendo a la nube tan rápido como se espera. No hay movimientos claros. Se están haciendo muchas pruebas, llevando pequeñas cargas, pero —a grandes rasgos—el core business sigue estando en los sistemas tradicionales.

¿Qué papel están desempeñando los grandes proveedores de nube?

Los hyperscalers viven y mueren por llevar clientes a sus nubes. Lo que podemos esperar de ellos es una simplificación del problema. Son los grandes evangelizadores del mundo cloud, pero la realidad es la que es. Su interés está en el consumo real, no en los contratos de compromiso que firman con compañías como la nuestra cuando iniciamos el proceso de transformación de un cliente.

De hecho, nosotros ya hemos iniciado alguno de estos procesos de transformación radical para grandes corporaciones y tenemos la experiencia de que llevar a una gran empresa a la nube pública toma su tiempo. Nuestro compromiso para ejecutar la migración de cargas de trabajo hacia cloud es de aproximadamente un año. Los primeros meses se dedican básicamente a analizar todo el contexto, ver cómo trocear el pastel y qué cargas deben ir a cada modelo. Cuando ya llevamos unos meses trabajando es cuando se empiezan a subir algunas cargas y, al final, si todo ha ido bien, se ve el consumo real.

¿Por qué no se está yendo a la nube a la velocidad que se espera?

Hay muchas incertidumbres en torno a este proceso porque significa un cambio muy importante. El primero de los retos surge con el propio proceso de migración. Llevar las cargas de trabajo clásicas a la nube no es algo sencillo y para hacerlo bien hay que dedicar esfuerzos y recursos, tanto económicos como de tiempo.

Pero una vez que has superado este paso aparecen cuestiones como el gobierno de los procesos, las herramientas de gestión, la monitorización, los SLA, la seguridad… No se pueden tener dos mundos separados, un silo para lo nuevo y otro para lo antiguo. ¿Cómo conviven? ¿Cómo interactúan unas aplicaciones con otras? ¿Cómo engloban los procesos de seguridad esa nueva realidad?

Una de nuestras políticas es que la consola está prohibida en todo lo que tiene que ver con la operación cloud

Otro tema importante es el relacionado con la facturación. En el mundo clásico el coste de TI es predecible y cierto, ya sea como CAPEX o como OPEX en el caso del outsourcing, porque las unidades de recurso han sido tradicionalmente muy estáticas. En el mundo de la nube hay mucha incertidumbre y se producen sorpresas. Es más complicado planificar lo que se va a gastar, porque está en relación con los consumos que tendrán las aplicaciones, pero… ¿qué ocurre cuando se desvía? ¿Cómo controlo ese coste extra? En este escenario se necesita, por ejemplo, de una oficina financiera, algo que no tiene nada que ver con los sistemas de control de gestión clásicos de TI, con funciones radicalmente distintas a las que había antes.

Esto implica entrar en una dinámica de optimización continua, analizando dónde se están produciendo ineficiencias y consumos no necesarios, adaptando los servicios a lo que realmente se requiere para tener un consumo adecuado.

Los datos constituyen otra de las grandes incógnitas en este modelo

El concepto de edge compunting es una de las respuestas que se están planteando ante la explosión de datos que está trayendo el mundo del IoT. Aunque en España este es un concepto que todavía va despacio, es evidente el interés que despierta dentro del sector industrial.

El cloud computing no puede resolverlo todo y, teniendo en cuenta dónde se generan los datos, no es eficiente tratar de gestionar ese volumen masivo de información solo con la nube pública. Deberá complementarse con el edge computing. Pero antes de esto debería asentarse la gestión de los procesos analíticos en la nube para aprovechar todas las características de agilidad, capacidad o escalabilidad. Gestionar este volumen de información en un contexto on-premise ya no es eficiente. Pero es que, además, en la nube es más fácil incorporar nuevas fuentes de datos de forma inmediata, sin tener que adquirir infraestructura para desplegar: click to consume.

Los perfiles profesionales también cambian

Efectivamente, el del talento es seguramente uno de los retos más importantes. Si lleváramos veinte años trabajando en este escenario, ya podríamos responder a todas estas cuestiones, tendríamos experiencias previas y sabríamos cómo abordar este tipo de proyectos. Pero eso no es así. No existe esa madurez en el mercado, ni en las empresas cliente ni en algunos de los proveedores.

Nosotros hemos tenido que trabajar internamente para poder responder a ello. Por ejemplo, hemos abierto una serie de business groups mediante los que estamos respondiendo a todas esas cuestiones: monitorización, seguridad, procesos de ITSM, facturación (con el concepto de oficina financiera), etc. Todo esto lleva mucho esfuerzo. Te enfrentas a una hoja en blanco y hay muchas compañías que ni siquiera han empezado a pensar en eso.

Todavía no hay un ecosistema de proveedores con todas las respuestas a estas cuestiones. Hay mucho PowerPoint, pero no veo muchos proyectos en ejecución. Seguramente, además, el cliente también está detectando cierta simplicidad en los mensajes, que se está traduciendo en desconfianza.

¿Cómo estáis abordando este reto desde DXC Technology?

Ante la escasez de profesionales capaces de responder a este escenario, nosotros hemos tomado dos caminos. Por un lado, estamos contratando personas con conocimientos específicos en determinados hyperscalers para reforzar nuestros equipos, pero al mismo tiempo estamos construyendo nuestra propia cantera a través de la capacitación y formación de los perfiles ya existentes y de los que incorporamos del entorno universitario.

Todavía no hay un ecosistema de proveedores con todas las respuestas a estas cuestiones

De hecho, la gente que sale de las universidades viene sin prácticas aprendidas, buenas o malas, lo que los convierte en un perfil idóneo para recibir formación en el nuevo modelo. Ahí los hyperscalers están haciendo un esfuerzo muy importante. Algunos están invirtiendo mucho dinero con programas que suponen una apuesta muy interesante para fomentar la formación en el ecosistema.

Por ejemplo, Microsoft tiene el programa Alumno 4.0 a través de un acuerdo con la Universidad y con compañías como la nuestra. Buscan demanda de perfiles especializados en tecnologías del mundo cloud y, a través de la Universidad, se acuerda la captación de talento joven en los últimos años de carrera. Se les proporciona formación y certificación oficial, en este caso de Microsoft, que se complementa con un compromiso de contratación por nuestra parte. Ese es el modelo acertado.

En este aspecto, los hyperscalers tienen un rol muy importante que desarrollar, y Microsoft lo está haciendo especialmente bien con programas de este tipo, que van un paso más allá.

El cambio que implica este modelo afecta a todos los actores

Es un cambio cultural increíble para todos, pero las que primero se están dando cuenta son las empresas que gestionan las infraestructuras de muchas compañías, con miles de empleados que se dedican a esto y que se tienen que reciclar. Por ejemplo, una de nuestras políticas es que la consola está prohibida en todo lo que tiene que ver con la operación cloud. En el escenario anterior, cuando había que hacer una intervención en on-premise, los operadores recibían la solicitud a través del ITSM, entraban en las consolas, hacían los cambios solicitados y emitían la confirmación. Todo a base de consolas, de unos u otros fabricantes y con diferentes tecnologías.

En el mundo cloud le damos una importancia crucial a la automatización y tratamos de que todo se haga a través de un proceso de continuous integration, continuous delivery, continuous deployment. Todo programado: la infraestructura se despliega y se mantiene por código. Si hay que modificarla, se recoge la versión anterior, se modifica, se crea una versión nueva, se prueba y se despliega.

Esto permite ser mucho más rápido a la hora de desplegar entornos similares. Si el catálogo de servicios está como código, desplegar una nueva instancia de un servicio es muy rápido. Además, es predecible y no hay fallos. Si el catálogo va sufriendo cambios, se va documentando en el código que despliega esa infraestructura, de manera que me pueda beneficiar de ese automatismo. Esa es la filosofía.

La tendencia es que todos los procesos de TI clásicos se hagan de forma automática y eso requiere de unas habilidades muy distintas en los profesionales. El técnico de sistemas tradicional, que sabía cómo gestionar consolas, debe adquirir un perfil más ligado al del desarrollador, aunque utilizando API y lenguajes propios del mundo de la infraestructura como código (Terraform, Ansible, Cloudformation). Necesitamos que sepan gestionar herramientas y pipelines de desarrollo, y que trabajen con una filosofía Agile, porque las cosas se tienen que hacer forma distinta.

Se dice que Dios creó el mundo en siete días, pero porque no había base instalada

Este modelo de gestión automatizado requiere contar con “programadores técnicos de sistema”, un híbrido capaz de integrarse en este mundo del DevOps: grupos multidisciplinares y expertos que se complementan para formar equipos de alto rendimiento. La nube lo cambia todo, la organización, la habilidades, las tecnologías… Este es el modelo hacia el que hay que ir, pero todavía no está asentado y esta es una de las razones por las que no está ya implementado de forma generalizada. Se dice que Dios creó el mundo en siete días, pero porque no había base instalada.