Antes de plantearte una migración a la nube, hay decisiones clave que definir, y las más importantes giran en torno al valor de negocio que vas a generar. Descubre qué más necesitas saber.
Evalúa qué tan apto es cada workload antes de moverlo a la nube o a otra plataforma cloud
Migrar a la nube pública no es un fin en sí mismo, sino el primer paso de un proceso continuo. Si ya has dominado las etapas clave de una migración a la nube con algunos de tus workloads, lo más probable es que más adelante decidas mover otros. O quizá te plantees migrar a una nube distinta para reducir costos o ganar en funcionalidad o seguridad. Pero antes de mover nada, conviene hacerte algunas preguntas clave.
1. ¿Cuentas con el respaldo de la dirección?
Si la respuesta no es un "sí" rotundo, tu migración a la nube va camino al fracaso. Aunque la mayoría de las grandes empresas se proponen tener el 80% de su hosting de TI en la nube para 2024, son pocos los ejecutivos del C-suite que confían plenamente en que las iniciativas de migración a la nube de su compañía vayan a entregar los resultados prometidos. Por eso es tan importante entender la nube como mucho más que un programa de TI: necesitas asegurar el respaldo del liderazgo para usarla como una plataforma que potencie la eficiencia, la innovación y el crecimiento que garantizarán el éxito futuro de la compañía.
Ese respaldo depende de qué tan persuasivo sea tu plan de migración, que debe demostrar un enfoque cuidadoso, sistemático y estratégico sobre qué vas a migrar y a dónde y —lo más importante— qué reto de negocio va a resolver. Toma en cuenta el crecimiento, la escala y los puntos de dolor actuales de tu compañía para presentar un caso convincente sobre el valor de negocio real que se va a generar con la migración.
2. ¿Qué busca lograr el negocio con esta migración?
Gartner prevé que la proporción de nuevos workloads digitales desplegados en plataformas cloud-native pase del 30% en 2021 a más del 95% en 2025. Antes de mover workloads entre nubes o de trasladar a la nube los que aún están on-premises, conviene tener claras las razones por las que se avanza con esa migración en concreto.
Entre los factores que impulsan la decisión están el ahorro de costos, una menor carga de infraestructura, la escalabilidad, la disponibilidad y una mejor experiencia de usuario. Quizás el crecimiento esté llevando los sistemas e infraestructura on-premises de la compañía al límite y haga falta montar nuevos sistemas que escalen al ritmo del negocio. Tal vez el objetivo sea agilizar procedimientos y procesos para desarrolladores y usuarios, hacer la TI más eficiente para responder más rápido a los requerimientos de los clientes o ganar agilidad para reaccionar mejor a los cambios del mercado global.
La migración a la nube ayuda a acelerar la innovación a escala y al ritmo necesario, y permite que las empresas alcancen hitos clave para su éxito que, sin la nube, tomarían años. Sea cual sea el objetivo, los líderes de negocio deben tener claridad sobre el propósito de la migración para que el avance hacia su consecución se pueda medir y monitorear.
3. ¿Es este workload un buen candidato para la nube?
Tiene sentido desplegar muchas aplicaciones de frontend en la nube pública: como tienden a cambiar con frecuencia, se benefician de la flexibilidad que ofrece la nube. Los workloads más adecuados para la nube suelen tener ciclos de vida cortos, picos frecuentes de uso y necesidad de despliegue rápido de infraestructura.
Pero no todo workload encaja bien en la nube. Las aplicaciones que requieren latencia inferior al milisegundo conviene mantenerlas, en general, on-premises. Si operas un sistema de trading financiero, por ejemplo, la nube no sería la solución óptima para ese componente de la plataforma. La manufactura es otro vertical extremadamente sensible a los retrasos, razón por la cual algunos de los grandes fabricantes de automóviles usan sistemas como AWS Outposts para construir y ejecutar aplicaciones en sus propias instalaciones, sin tener que asumir la latencia relativamente alta de la nube frente a on-premises.
Otra situación en la que dejar los workloads on-premises puede ser la mejor opción —al menos a corto o mediano plazo— es cuando has invertido un Capex (gasto de capital) sustancial en tu infraestructura on-premises y necesitas extraer el máximo retorno antes de pasar al modelo financiero de Opex (gasto operativo) que implica la nube.
Sin embargo, contrario a la creencia popular, el cumplimiento normativo no suele ser una razón para mantener un workload on-premises. De hecho, el potencial de mayor visibilidad y de controles más estrictos hace de la nube, posiblemente, una mejor ubicación para este tipo de workloads. Toma como ejemplo el Reglamento General de Protección de Datos (GDPR) de la UE: prestando atención a la regulación y con un sólido entendimiento de la nube, es posible obtener un retorno de inversión superior con un despliegue cloud que en un data center.
Conviene apoyarse en un partner de nube para realizar un análisis exhaustivo de workloads y determinar el modelo de despliegue óptimo. Así obtendrás un panorama claro del escenario técnico de tus workloads actuales, sus retos y dependencias, el valor de la migración frente al esfuerzo que implica y la secuencia óptima de migración.
4. ¿Por qué esta nube?
Aunque la mayoría de las organizaciones usa varias nubes, no siempre lo hace de forma eficiente o estratégica. En parte, eso se debe a que muchas iniciativas de nube pública son resultado del shadow IT: software, dispositivos y servicios que se contratan sin el conocimiento ni el control del área de TI.
Los workloads también suelen asignarse a una nube por conveniencia y no por análisis. Sin datos precisos sobre cómo se está comportando la infraestructura para cada workload, elegir la nube correcta para cada uno se vuelve cuestión de suerte y no de una decisión informada.
Considera las razones por las que estás moviendo tus workloads a una nube específica. Los principales proveedores tienen fortalezas particulares que pueden encajar con tu caso de uso de negocio. Por ejemplo, muchos clientes migran a Amazon Web Services (AWS) por la amplitud y profundidad de sus servicios; los clientes que ya usan Microsoft suelen optar por Azure para innovar con servicios que conocen, y Google Cloud destaca por sus capacidades de analítica de datos.
En teoría, puedes ejecutar el mismo workload en varias nubes, pero al hacerlo te ajustas al mínimo común denominador. Cada proveedor tiene servicios nativos que simplemente no están disponibles en las nubes de la competencia, así que no es realista esperar que tus workloads corran sin fricción en cualquier proveedor. Sacar provecho de la nube pública por la innovación que habilita implica apostar por las fortalezas de la nube que elijas a la hora de decidir dónde desplegar cada workload.
5. ¿Qué enfoque vas a usar para la migración?
Según tu experiencia previa con migraciones a la nube y el acceso de tu compañía al expertise adecuado, tu enfoque caerá en una (o en una combinación) de cinco categorías: rehost (lift and shift), refactor, replatform, rebuild, replace o retire:
- Rehosting es el enfoque más sencillo, porque consiste simplemente en redesplegar datos y aplicaciones existentes en almacenamiento y recursos de cómputo en la nube, sin modificarlos. Requiere relativamente poca experiencia en nube, pero no aprovecha sus capacidades y no es adecuado para todos los workloads.
- Refactoring es más complejo, porque implica rediseñar la arquitectura de las aplicaciones antes de moverlas a un entorno cloud, pero también ofrece un alto retorno de inversión al capitalizar las funcionalidades nativas de la nube y su flexibilidad y elasticidad inherentes.
- Replatforming es un punto medio entre rehosting y refactoring, e implica cierta modificación del workload para aprovechar beneficios propios de la nube, como la automatización y un mejor escalado.
- Rebuilding consiste, en esencia, en recrear el workload desde cero para sacar el máximo partido a la funcionalidad del entorno cloud. Esto exige un alto grado de habilidad y compromiso.
- Replacing los workloads con una aplicación cloud-native significa que retiras una aplicación existente y migras solo los datos necesarios para ejecutarla. Puede ser una opción prudente si resulta más fácil usar una utilidad que ofrece el proveedor de nube, en lugar de intentar desplegar y operar las mismas herramientas que ejecutas on-premises.
- Retirar los workloads que ya cumplieron su propósito es importante para no desperdiciar tiempo ni recursos durante la migración. Eso sí, antes de retirar nada conviene identificar todas las dependencias upstream.
El enfoque de migración que elijas influirá en todo, desde tus costos en la nube hasta tus decisiones de arquitectura.
6. ¿Cuánto va a costar?
El presupuesto para una migración a la nube debe contemplar todas las etapas del proceso, desde la planificación previa hasta la operación posterior de los workloads en la nube. Aunque el liderazgo esté de acuerdo en la necesidad de migrar, debe conocer los costos involucrados para decidir cómo avanzar y a qué ritmo.
El costo total de propiedad (TCO) en la nube es un método para calcular los distintos costos asociados a operar workloads en la nube a lo largo de su vida útil. Cada despliegue es distinto, pero es importante comparar lo que cuesta ejecutar la misma aplicación on-premises y en la nube. La funcionalidad de la aplicación debe analizarse en su conjunto, sobre todo aspectos como seguridad, dependencias con otras aplicaciones y otras áreas que pueden pesar de forma considerable en los costos. Otro elemento importante del TCO en la nube es el costo de cerrar las brechas de habilidades para poner a los equipos al día en las distintas plataformas cloud asociadas a la migración.
7. ¿Cuáles son las implicaciones de seguridad y cumplimiento de la migración?
Los controles y prácticas de seguridad que has construido para tus entornos on-premises no van a funcionar en la nube. Una de las principales diferencias que tendrás que asumir es el modelo de responsabilidad compartida: el proveedor asume la mayor parte de la responsabilidad sobre la seguridad de la infraestructura, mientras que el cliente se hace cargo de las configuraciones y ajustes que están bajo su control directo, como datos y aplicaciones. También se suele plantear como "de la nube" frente a "en la nube": el proveedor responde por la seguridad de la nube y el cliente, por proteger lo que está dentro de ella.
Otra característica de la seguridad cloud es que su naturaleza basada en software impone requisitos específicos de controles y procesos que quizá tengas que cubrir con nuevas tecnologías. También es posible que necesites reestructurar los flujos de gobernanza y sus alineaciones para hacerlos más ágiles y continuos. Prepárate para involucrar a representantes de un amplio abanico de stakeholders y disciplinas técnicas.
8. ¿Tienes acceso a los recursos necesarios para ejecutar la migración?
La escasez de profesionales de TI calificados está frenando la adopción de tecnologías cloud. En su Emerging Technology Roadmap 2021-2023, Gartner reveló que los ejecutivos de TI consideran la falta de talento como la mayor barrera para desplegar tecnologías emergentes —incluidas bases de datos, machine learning, almacenamiento avanzado y analítica—, todas habilitadas por la nube.
Una vez que tengas las habilidades necesarias, debes asegurarte de que tu equipo opere como una unidad cohesionada: el proceso se cae si tus data engineers trabajan aislados de los expertos en redes, por ejemplo, y cada quien da por terminado el trabajo en cuanto su parte está lista. Fomenta la participación activa de todos e instaura la mentalidad de que nadie ha terminado hasta que todos hayan terminado. Esta es una de las razones principales por las que se necesita el involucramiento y respaldo de stakeholders senior en el proceso: para asegurar que no haya bloqueos a la hora de armar equipos integrales que se hagan cargo del cloud journey. De lo contrario, el proyecto de migración se estancará a medida que se acumulen los obstáculos.
Si te faltan habilidades internas para ejecutar tu migración a la nube, podrías capacitar y desarrollar a tu equipo para que asuma la tarea. Ten en cuenta que ese proceso lleva tiempo y, además, implica desviar a personas del trabajo valioso que ya están haciendo. Trabajar con un partner de nube que tenga el expertise y la experiencia para guiarte en la migración puede ser una decisión prudente y, potencialmente, acelerar el camino con consejos sólidos y basados en experiencia, de la mano de arquitectos con trayectoria.
9. ¿Qué deberías hacer ahora?
Después de hacerte todas estas preguntas, puede que te quedes pensando si tienes las habilidades y los recursos necesarios para llevar a cabo una migración a la nube exitosa. La buena noticia es que existe una alternativa: al trabajar con un partner de nube como DoiT, accedes a expertos en migración que pueden guiarte durante todo el proceso sin costo adicional.
Como premier partner de AWS y Google Cloud, ofrecemos expertise multicloud respaldado por una valiosa tecnología de optimización, analítica y gobernanza. Te ayudamos a recopilar requerimientos y definir objetivos de negocio, a construir la arquitectura cloud adecuada y a escalar tu infraestructura. Con un soporte así, tu próxima pregunta debería ser "¿por dónde empiezo?".