Abdelfetah Sghiouar es ingeniero de nube en Google y fue uno de los ponentes del evento DevOps2020. Nuestros Squadians tuvieron el placer de entrevistarlo. Hablamos sobre las últimas tendencias en DevOps y la nube, así como sobre lo que depara el futuro para las organizaciones que han iniciado su transición hacia una infraestructura basada en la nube.
Squad tuvo la oportunidad de asistir a tu conferencia en DevOps 2020 sobre la plataforma Google Cloud. ¿Cuáles serán las principales tendencias de la nube en los próximos años?
Últimamente, este es el tema de moda. Si leemos los artículos de medios especializados como Gartner, veremos que «En 2020, todas las empresas estarán en la nube».
Me he dado cuenta de algo: los directores técnicos (CTO) y los directores de sistemas de información (CIO) comprenden mejor lo que está en juego. La actividad principal de la empresa no es dedicarse a la informática, así que no hay motivo para lanzarse a ese campo. Es mejor dejar que se ocupe de ello alguien con la formación adecuada y optar por una infraestructura en la nube.
Es más barato, más resistente y más seguro, porque no puedes contratar a expertos en seguridad como Google o Amazon, que sí tienen la capacidad para hacerlo.
Tanto las empresas como los proveedores de servicios buscan cada vez más cumplir con la normativa, obteniendo diversas certificaciones, sobre todo para adaptarse mejor a las necesidades de las empresas.
Por lo tanto, pasar a la nube supone un verdadero valor añadido. Si echamos la vista atrás 20 años, el ciclo de vida de las tecnologías de la información era diferente. Todo empezaba con la compra de varios servidores por unos cuantos millones de euros, los utilizabas, comprabas las infraestructuras, contratabas personal, los ponías en funcionamiento y, cinco años después, tu infraestructura quedaba obsoleta. Así que tenías que comprar más y entrabas en un nuevo ciclo.
Las empresas, si no disponen de los medios financieros necesarios, no podrán adquirir más infraestructuras al cabo de cinco años, sobre todo si estas son demasiado antiguas.
Gracias a la nube, el modelo «Pay As You Go» te permite pagar solo por lo que utilizas. Puedes reducir o aumentar tu presupuesto, y es más fácil que tener servidores en tu propio centro de datos.
¿Cuáles crees que son los límites?
Hoy en día, el problema que veo es que la nube exige muchas cosas, no solo en lo técnico, sino que requiere un gran cambio en la cultura de la empresa.
Por eso se habla realmente de un «viaje» hacia la transición a la nube, ya que no es como si se tratara de lanzar una moneda al aire. Se trata de una transformación lenta, ya que no todos los sistemas informáticos están optimizados y los proveedores no ofrecen todo lo que uno desearía tener en un centro de datos.
Otra tendencia es que los proveedores de servicios en la nube intentan llevar la nube hasta el cliente. Hay empresas que ofrecen un servicio que se puede implementar en la infraestructura física del cliente, pero que se gestiona desde una plataforma en la nube. Es lo que comúnmente se conoce como una plataforma «híbrida» o «multinube».
Es un aspecto interesante y un reto para los próximos años, ya que, al hacerlo, se genera un verdadero valor añadido, en el sentido de que los clientes podrán llevar a cabo su transformación de forma más «gradual».
Hay otros aspectos: las grandes empresas que nunca hubiéramos imaginado que darían el salto a la nube están haciéndolo. Lufthansa, una de las mayores compañías aéreas y que lleva siglos en activo, cuenta con un sistema SAP (* Systems Applications and Products) muy antiguo.
Entienden las ventajas de dar el salto a la nube. Veremos cómo muchas de estas grandes empresas se decantan por la nube. Es solo cuestión de tiempo, como ya he dicho antes al referirme a los antiguos sistemas y servidores que las empresas tienen hoy en día.
En cuanto a las dificultades organizativas, ¿crees que uno de los mayores retos del DevOps es más bien una transición organizativa o una transición técnica para el equipo operativo?
Creo que es un poco de ambas cosas. Pero diría que se trata más bien de una transición organizativa y cultural que de una transición técnica, porque, al fin y al cabo, solo es código, ¿no? No son más que líneas de código.
La implementación no es lo difícil. Lo difícil es, en mi opinión, adoptar la cultura DevOps.
Hay mucho que decir sobre este tema. Por un lado está la comprensión organizativa y, por otro, la voluntad organizativa.
La comprensión organizativa consiste en entender qué es DevOps, lo que me lleva el 50 % de mi tiempo. Porque uno de los problemas que tengo personalmente es que el término «DevOps», fuera de contexto, deja de tener sentido.
Hay un montón de prácticas, pero ¿cuál tiene sentido para la organización? En cierto modo, eso es lo que definirá qué será DevOps dentro de tu organización.
La segunda dificultad es la disposición de las personas a cambiar su forma de trabajar, ya que cualquier cambio en una empresa supone mucho trabajo.
¿Hasta qué punto están dispuestos a dedicar tiempo y dinero para afrontar el reto?
¿Es DevOps el futuro para los desarrolladores de software y todos los ingenieros de operaciones?
No lo creo, aunque las empresas hayan adoptado DevOps. Tomemos este ejemplo.
Google es uno de los pioneros de esta cultura «DevOps». Contamos con un equipo de SRE que se asemeja a una implementación de DevOps; ambos comparten aspectos similares en cuanto a automatización y método de trabajo.
Hay tantos SRE que no se dedican a la ingeniería de software. Tienen funciones y responsabilidades distintas.
Hay casos en los que necesitamos ingenieros de software y otros en los que solo los necesitamos para un aspecto concreto.
Por lo tanto, los ingenieros de software que crean soluciones bancarias son personas con competencias muy específicas, que no se limitan a los conocimientos técnicos, sino que también comprenden el funcionamiento de la empresa y del sector bancario, así como todos los requisitos y normas, aspectos que hacen que un software bancario sea, precisamente, un «software bancario».
Sacar a estas personas de sus puestos de trabajo para convertirlas en especialistas en DevOps no aporta ningún valor, ya que deben especializarse en lo que hacen. Lo mismo ocurre con quienes se dedican a la inteligencia artificial, el aprendizaje automático y la ciencia de datos…
Por lo tanto, creo que un ingeniero de software con una especialización vertical debe seguir siéndolo, mientras que un ingeniero de software sin especialización o con conocimientos de automatización deberá orientarse hacia DevOps.
Squad ha dado el salto a DevOps y DevSecOps ayudando a sus empleados a desarrollar sus conocimientos mediante cursos de formación y el intercambio de experiencias. ¿Crees que es una buena estrategia?
Sin duda, es una buena estrategia si hay demanda. Squad es una empresa de consultoría y existe una necesidad real. La formación o la enseñanza de ingeniería de software, en particular sobre el diseño de CD/CI, es indudablemente útil.
Hay gente que lleva mucho tiempo practicando CI/CD sin saberlo realmente, y quienes llevan ya un tiempo haciéndolo se limitan a escribir scripts en Python o Bash que se encargan de todo el proceso de compilación y despliegue en su nombre, ya que estos scripts se ejecutan de forma automática y no son controlados por personas.
Por lo tanto, comprender que implementar un proceso de CI/CD para dejarlo funcionar sin tener que preocuparse por él significa, para un desarrollador, que podrá centrarse más en escribir código que en solucionar problemas de la infraestructura. Y eso tiene un gran valor y es una buena estrategia.
Si una organización cuenta con ingenieros especializados en un único ámbito, en una gran organización esto probablemente resulte más productivo, ya que pueden crear esa infraestructura común para los ingenieros de software, por lo que estos no tienen que hacerlo por sí mismos. En una gran empresa, esto supone un valor añadido.
En una empresa pequeña, no siempre se puede permitir ese lujo, ya que probablemente cuente con unos 10 o 20 empleados.
Por lo tanto, adoptar el modelo DevOps, con responsabilidades compartidas, es probablemente el camino a seguir hasta alcanzar un tamaño suficiente que permita contar con equipos especializados.
Hoy en día, trabajamos con empresas de distintos tamaños y uno de los aspectos —que, en cierto modo, está relacionado con DevOps en lo que respecta a las comunidades— es la gestión de clústeres de comunidades.
Es más eficaz y, potencialmente, más seguro. Por ejemplo, tenemos clientes de grandes organizaciones que, una vez que estamos allí, quieren crear 20 grupos de comunidades, porque quieren un microservicio por clúster. Y yo les digo: «¿Por qué queréis hacer eso? Es muy poco productivo» y «vamos a repartir vuestros conocimientos entre 20 equipos ».
Intentamos orientar a estos clientes hacia entornos en los que hay operaciones centralizadas y equipos de DevOps que trabajan en software de infraestructura como desarrolladores: solo código, un archivo Docker, un comando, y así estos desarrolladores no tienen que preocuparse de cómo llega a producción.
Es lo que yo llamaría «el desarrollo al estilo Google», porque así es como funciona. El desarrollador de Google es productivo desde el primer día. Dispone de plantillas de CI, pruebas integradas y funciones de seguridad. No tiene que preocuparse de nada de eso. Probablemente tenga que escribir un pequeño archivo de configuración, pero eso es todo.
En el caso de las pequeñas empresas, es necesario integrar mejor este tipo de conocimientos en todo el equipo, de modo que cada miembro asuma la responsabilidad de aplicar las prácticas de DevOps y las tenga en cuenta a la hora de desarrollar las aplicaciones.
