Con la aceleración digital de las empresas, la necesidad de infraestructuras informáticas más grandes y flexibles ha desencadenado una carrera hacia el cloud computing. Para muchas empresas, sin embargo, el procesamiento de datos en la nube no ha sido la solución más adecuada, lo que ha generado un costoso proceso de retorno del trabajo al data center on premise.
Entender sobre las causas de este movimiento de pivotaje y gestionar el riesgo de esta maniobra en la toma de decisiones hacia la nube es el tema de este episodio del podcast greenTALKS: Cómo evitar la repatriación de los workloads, con el Arquitecto de Soluciones de green4T, Gustavo de Biasi.
Siga la transcripción de la entrevista concedida al periodista Fabiano Mazzei para el podcast:
Fabiano Mazzei – Hola, sean muy bienvenidos, sean muy bienvenidos a otro episodio del podcast greenTALKS. Les recuerdo que pueden encontrar este contenido aquí en Spotify, en YouTube, en nuestro blog Insights y también en todas nuestras redes sociales.
El tema de hoy es «Cómo evitar la repatriación de workloads»: cuáles son los casos más frecuentes y las dificultades que encuentran las empresas al adoptar esta estrategia. La importancia de una correcta planificación y del análisis de la carga de trabajo antes de migrar. ¿Y cómo evitar este riesgo? Para hablar de esto, invitamos a Gustavo de Biasi, que es Arquitecto de Soluciones en green4T, que vuelve aquí para el podcast en su segunda participación. Gustavo, muchas gracias por aceptar la invitación. Bienvenido de nuevo a greenTalks.
Gustavo de Biasi – Gracias, Fabiano. Gracias, Fabiano. ¿Cómo va todo?
Fabiano – De acuerdo. Vamos a hablar de este tema que es muy importante en el mercado. Me gustaría empezar preguntándole cuáles son los casos más frecuentes y qué tipo de dificultades pueden encontrar las empresas que les llevan a tomar esta decisión de devolución de la repatriación de la workload?
Gustavo – Bueno, en primer lugar la repatriación de la workload – de la nube a infraestructuras on premise o dentro del centro de datos – es algo que empezó a suceder desde el momento en que algunas empresas encontraron dificultades para mantener estas workloads dentro de la nube, exactamente porque no entendían o no comprendían correctamente el viaje a la cloud.
A veces era por una tendencia del momento o por alguna aplicación que demandaba soluciones específicas y decidían migrar sus workloads del data center a la cloud. Y esto es algo que ha ido creciendo. No era tan visible, incluso con grandes analistas de futurología: viendo este tipo de cosas, muchas empresas no se imaginaban que iba a pasar. Pero ha ocurrido.
Estas son algunas razones que fueron apareciendo y haciéndose cada vez más explícitas, haciendo que las empresas volvieran a mirar dentro de su centro de datos, de su entorno on promise, y comprendieran que tendría sentido volver (con el procesamiento de datos) al «in house». Esto, como he dicho, es algo que surgió debido a un… No voy a hablar de un fallo en la estrategia, sino, quizás, de algunos puntos que no se observaron.
Desde el momento en que estás diseñando un modelo de entorno futuro, esto puede llevar a que los costes sean más altos exactamente por no entender el uso de estos recursos que estaban dentro de casa cuando los llevas a una nube pública, por ejemplo.
También está la parte de la seguridad, el modelo de seguridad dentro de la nube. Es un poco diferente del modelo de seguridad dentro de un entorno on premise y, por eso, hay que cambiar las herramientas que se utilizan y los procesos. Y esto no cambia única y exclusivamente en las herramientas: hay que ver la parte normativa para que, a partir de los informes de monitorización, se pueda mantener esta seguridad.
Por lo tanto, crea una cierta complejidad y esto es algo que hace que la gente reevalúe algunos puntos y vuelva al data center. También hay una gran preocupación por la ubicación del vendor location, que en realidad no es otra cosa que estar atado a una determinada tecnología, incluso cuando hablamos de infraestructura como servicio.
Pero si nos damos cuenta, hay diferentes maneras de mantener sus recursos y avanzar en la producción. Por lo tanto, el tipo de red, el tipo de aplicaciones, balizas, cargas, todo esto, porque algunas de las reglas son las mismas. Pero las APIs más la forma de aplicar estas reglas son diferentes, esto exigirá más conocimiento, tendrá estas especificidades que casi te obligarán a quedarte en un determinado hyperscaler. Así que, debido a todo eso, en el momento en que miras todos esos puntos y analizas cómo lo harías y cómo, cómo podrías hacerlo mirando a través de tu prisma de una TI clásica que estaba dentro de tu on premise, ves que tiene mucho sentido para ciertos entornos y traerlos de vuelta a casa. No todos los entornos, pero algunos entornos, sí.
Fabiano – Muy bien. ¿Entendemos cómo las empresas pueden evitar este riesgo de repatriación?
Gustavo – Para evitar la repatriación, tiene que entender muy bien su viaje a cloud. Cuando decimos nube, no se trata de una simple migración a la cloud: simplemente coger tu hardware y tus workloads y ponerlos de una forma única, como una máquina virtual que estuviera dentro de un entorno de cloud privada. Tienes que entender y comprender los recursos que exige, cuál sería la mejor aplicación de eso y qué se necesita para que ejecutes tu producción, para que realices las operaciones cotidianas, para que mantengas el entorno.
Así que hay una estrategia de viaje a cloud. Hay que saber qué hay que observar. Dentro de este viaje, primero tenemos la identificación y preparación de la empresa en su conjunto, con el equipo de TI integrado con las preocupaciones de las soluciones de la empresa. Es decir, es parte del núcleo de la empresa, es mucho más simple para que usted pueda identificar el flujo de información y desarrollar mejor una estrategia de cloud.
Por lo tanto, cuando se necesita una innovación y se va a colocar dentro de su entorno de TI, tiene que estar unida y tener un único mensaje para toda la empresa. Esta estrategia es fundamental: entender el origen y la aplicación de workloads dentro de la cloud es importante. Alguns workloads, algunos elementos de producción que son más sensibles a la latencia o que requieren una mayor cantidad de información que vas a descargar, el uso de estos recursos cuando tienes una cantidad muy grande de información que vas a tener que procesar internamente -y administrativamente hablando- empieza a ser demasiado caro para estar en la cloud.
Si tienes, por ejemplo, problemas de conectividad o incluso limitaciones por latencia, puedes estar en peligro poniendo una ejecución o un sistema concreto dentro de la cloud. Entonces, observar todo esto es entender sus características y entender que cada workload tiene una aplicabilidad y, a partir de ahí, desarrollar una buena estrategia.
Y, obviamente, hacerlo por pasos, donde puedas validar tu infraestructura, tu operación, para que puedas instalar tu ambiente, posicionar tu core dentro de una cloud de la mejor manera posible y, obviamente, usando esto de una manera inteligente, de una manera donde no vayas a tener problemas de costo o cosas así.
Fabiano – Perfecto. ¿Cuál es la solución para una empresa que necesita la nube, pero también debe mantener parte de los datos on premise. ¿Sería la cloud híbrida? ¿Qué recomienda?
Gustavo – Sí, la cloud híbrida hoy en día sí. De hecho, hace tiempo que hablamos de nube y desde el momento en que pones un poco de see cloud dentro de una nube pública. Pero siguen estando interconectadas de alguna manera, con recursos que están dentro de tu centro de datos o dentro del entorno y tienes que orquestar todo eso. Y la cloud híbrida es donde toma forma.
Así que, para que la nube híbrida funcione bien, es básico que conozcas muy bien tus workloads. Como he dicho, entiende tus necesidades. También creo que cuando nos fijamos en aquellos entornos en los que tienes una solución de cloud nativa y lista, ya tiene todos sus recursos allí y no sólo vas a utilizar una infraestructura como servicio, sino el recurso listo y ya gestionado, orquestado, tienes una buena aplicación de cloud, workload. Las herramientas de orquestación, que pueden abstraer la mayor parte de la complejidad de la cloud y on premise a un único modelo de gestión, ayudan mucho en la operación y esto, obviamente, reduce los costes involucrados, la complejidad de mantener los elementos de producción. Y eso ayuda mucho.
Todo esto forma parte de un diseño, de una estrategia que es asumida y gestionada no sólo por el equipo de TI, sino también por el núcleo de la empresa, por el desarrollo del producto, por los procesos de la empresa para que puedas conseguirlo. Pero, desde luego, desde el momento en que vemos un análisis del modelo de madurez de TI, que forma parte del estudio de esta estrategia, podemos identificar dónde tenemos que reforzar el equipo y qué tenemos que aprender para tener un viaje a la cloud exitoso, sin miedo a tener que repatriarlo después. Porque el coste de llevarlo puede ser alto, pero el de traerlo de vuelta… Ya has tenido toda la carga de llevarlo (a la cloud), y luego necesitas gastar un poco más para traerlo de vuelta. Así que eso es importante. La estrategia lo es todo.
Fabiano – Se podría entender la ventaja financiera que conlleva este proceso y el aumento de la eficiencia. ¿Podemos relacionar esta cuestión con la de la sostenibilidad?
Gustavo – Pues sí. Principalmente con lo siguiente: cuando hablamos de cloud, sabemos que nuestro entorno estará dentro de un centro de datos que consumirá recursos que, en ocasiones, serán compartidos o no. Y el hyperscaler se encargará de todo eso. Es importante tener en cuenta que todos somos responsables del uso sostenible que hagamos de estos recursos. Cuando estamos dentro de nuestro centro de datos – y esto es algo que nosotros, dentro de green4T, tenemos muy fuerte, como el uso de DCIM, donde puedo controlar todos los elementos dentro de un data center, como la temperatura, el clima, todos los elementos de configuración que forman parte de nuestra solución – somos capaces de trabajar de una manera de extraer el máximo de eso de una manera más «verde». Podemos mejorar el uso de estos recursos. Cuando miramos a la cloud, y creo que es muy importante hacer lo que algunas empresas están haciendo, pedir a los hiperescaladores información sobre su huella de carbono. Hoy podemos hacerlo dentro de green4T, porque tenemos el DCIM y podemos rastrear estas métricas dentro del portal.
Sin embargo, cuando hablamos de hyperscalers, no disponemos de la misma información. Pero es interesante observar todo esto para cuando tengamos que desarrollar un plan o incluso una campaña de forma más sostenible, entendiendo que todo esto está conectado. Y el sector de las TI, obviamente, como uno de los mayores consumidores de energía, y por cuestiones climáticas, no queda al margen.
Fabiano – Bueno, creo que he podido arrojar algo de luz sobre este importante tema. Me gustaría dar las gracias a Gustavo de Biasi, que es Arquitecto de Soluciones en green4T, sobre «Cómo evitar la repatriación de los workloads «. Gustavo, gracias de nuevo por tu presencia para compartir tus conocimientos aquí en greenTALKS.
Gustavo – ¡Gracias, muchas gracias!
Fabiano – Así que eso es todo, si te ha gustado este contenido, por favor, dale a me gusta y compártelo en tus redes sociales y consulta otros contenidos relevantes sobre tecnología que publicamos en nuestro blog, en páginas web, en YouTube y en nuestras redes sociales, además de aquí, por supuesto, en Spotify. Muchas gracias a todos.
