Gran parte de lo que hacemos en la oficina del director de Tecnología de Google Cloud (OCTO) es ayudar a los clientes a planificar y ejecutar sus migraciones a la nube, que a menudo son parte de un esfuerzo de transformación mayor. La mayoría de los CIO consideran que la migración a la nube es una tarea esencial, pero aún algo desalentadora. Hemos resumido las conversaciones que tuvimos con CIO, CTO y su personal técnico en varios marcos de trabajo que pueden ayudar a reducir el entusiasmo y la complejidad técnica con el objetivo de ayudar a implementar una estrategia que empodere tanto a las empresas como a las soluciones de TI. Llamamos a uno de esos marcos de trabajo "subir contenido o adaptarlo a la nube". Y no nos referimos a la filosofía laboral rígida de algunas consultoras.

El problema con las soluciones de TI locales

Si bien la infraestructura de las soluciones de TI locales ha mejorado mucho en las últimas dos décadas (por ejemplo, a través de la virtualización o las redes definidas por software), las soluciones empresariales siguen siendo relativamente inflexibles, laboriosas y lentas para aprovisionar o configurar infraestructura. En un entorno de movimiento lento, este tipo de configuración era adecuada porque las demandas empresariales podían predecirse con bastante anticipación y los picos repentinos de carga de trabajo eran raros. Sin embargo, los disruptores digitales y las presiones de costos obligan a las empresas y a las soluciones de TI a avanzar más rápido, lo que supone una importante presión sobre las tecnologías y procesos existentes. 

Migrar a la nube: ¿subir contenido, adaptarlo o ambos métodos?

Se ha demostrado que un modelo operativo de TI basado en la nube ofrece ventajas significativas en términos de despliegue rápido, escalabilidad elástica, operaciones resistentes y seguridad. Sin embargo, las grandes empresas no pueden simplemente despertarse un día con todas sus aplicaciones ejecutándose en la nube. Por lo tanto, el traspaso de cada empresa a la nube es durante el principio un escenario de nube híbrida, donde algunas cargas de trabajo permanecen en las instalaciones y otras se ejecutan en la nube.
Además, muchas empresas confían en la capacidad informática y el almacenamiento de datos distribuidos geográficamente que no se pueden implementar desde un solo centro de datos en la nube. Por ejemplo, la mayoría de las empresas minoristas o de fabricación tienen una fuerte huella de TI en sucursales o plantas debido a consideraciones de latencia o bien para garantizar operaciones continuas en caso de una falla de red. Por lo tanto, cuando planificas una migración a la nube empresarial, no puedes simplemente mover toda tu infraestructura de la noche a la mañana, sino que debes adoptar un enfoque más pragmático que diferencie cuidadosamente datos de cargas de trabajo.
Un modelo que puede ayudar a las empresas a trazar su viaje de adopción de la nube describe el proceso de migración a través de dos ejes: subir y adaptar.

cloud adoption journey.png

Subir contenido en pila

Una de las cosas que puedes hacer es subir tus aplicaciones en pila. Como paso inicial, puedes pasar de ejecutar aplicaciones monolíticas en servidores dedicados a un modelo de plataforma como servicio que implemente aplicaciones y servicios utilizando contenedores administrados por Kubernetes o Google Kubernetes Engine (GKE). La llamada "implementación sin servidor", por ejemplo mediante Cloud Functions, va un paso más allá con funciones de aplicación individuales que ocultan toda la infraestructura que se encuentra en segundo plano.
Subir contenido en pila tiene varias ventajas:
  • Se automatiza la implementación de aplicaciones, lo que facilita el proceso de agregar o quitar capacidad según sea necesario.
  • Las operaciones también se vuelven más resistentes debido a que, en caso de fallas, se pueden implementar rápidamente las nuevas instancias, lo que permite a las plataformas como servicio o sin servidor resistir fallas sin que eso tenga un impacto visible en el cliente.
  • Gracias a las unidades desplegables más pequeñas, se puede utilizar el hardware de manera más eficiente, lo que reduce los costos de ejecución.
  • Por último, las aplicaciones se vuelven más portátiles cuando están mejor aisladas de los detalles de infraestructura, ya que sus contenedores pueden implementarse en una variedad de elementos. Esto abre camino a un escenario de nube híbrida que proporciona un entorno de ejecución de servicios consistente en todo momento, incluidos los proveedores de nube, centros de datos locales, sucursales y dispositivos remotos.
Como aspecto negativo, subir contenido en pila requiere que cambies la forma en que creas aplicaciones y manejas la infraestructura que las admite.

Adaptar para la nube

La segunda opción es retirar, modificar y rediseñar las aplicaciones existentes sin cambios en la nube, por ejemplo, transfiriendo las máquinas virtuales a Compute Engine o reemplazando los archivos de datos locales con Cloud Storage. El cambio en las cargas de trabajo en la nube se puede simplificar e incluso automatizar, por ejemplo, mediante el uso de herramientas como Velostrata.
A pesar de que no se modifican las aplicaciones, moverlas de un centro de datos local a la nube y cambiar el modelo operativo a uno más automatizado también tiene varias ventajas:
  • Las soluciones de escalabilidad económicas permiten realizar operaciones más rentables.
  • La disciplina de parches automatizada mejora la seguridad, ya que garantiza que no se ejecute ningún software con vulnerabilidades conocidas.
  • Una mayor transparencia permite una administración más eficiente de los recursos de TI, por ejemplo, mediante el dimensionamiento de servidores o la detección y el retiro de recursos no utilizados.
Mudarse a la nube transforma la manera en que opera una empresa y adquiere la infraestructura de TI de un modelo basado en recursos a uno basado en el uso. Sin embargo, no todo es blanco o negro. Al igual que en la transformación de arquitecturas de aplicaciones para subir contenido en pila hacia la de servicios y sistemas nativos de la nube, adaptar el contenido puede considerarse como una transformación progresiva en busca de operaciones centradas en la nube.
  • Quitar aplicaciones existentes y replanificarlas en la infraestructura de la nube minimiza el esfuerzo inicial, lo que evita los costos de reurbanización y permite a una empresa transformar sus procesos de adquisición y escalabilidad de infraestructura, al mismo tiempo que minimiza el impacto en los modelos de operaciones existentes.
  • Ajustar los modelos de operaciones para aumentar el uso de la automatización y las herramientas nativas de la nube acelera la transformación general y maximiza el valor de los servicios de infraestructura abstraídos.
  • Por último, desarmar los elementos de las aplicaciones para aprovechar los servicios en la nube administrados, como migrar de las bases de datos My SQL autogestionadas a una base de datos como servicio administrada por el proveedor, requiere un esfuerzo adicional, aunque sienta las bases para ir más allá de ver la nube como otro proveedor de infraestructura.
No solo es posible combinar ambos métodos, sino que también es lo recomendado. Consideramos que es un modelo híbrido nativo en la nube, en el que las aplicaciones se implementan como contenedores o funciones, y se pueden cambiar fácilmente de la nube a las instalaciones, según sea necesario, al mismo tiempo que se mantiene un marco de administración, implementación y tiempo de ejecución coherente.

Cómo trazar una ruta de migración

No hay una sola ruta a la nube, ni para empresas ni aplicaciones individuales. Lamentablemente, inspiradas en la esperanza de simplicidad, las empresas suelen asumir que todas las migraciones de carga de trabajo seguirán una trayectoria común. Más bien, te recomendamos que uses un marco que fomente la flexibilidad. El marco de trabajo mixto puede ayudar a una organización de TI y a sus líderes a caracterizar cómo pueden beneficiarse de la migración de sus servicios o cargas de trabajo. El marco actúa como un patrón general que resalta la continuidad de enfoques que se pueden explorar. No todos los componentes de una sola carga de trabajo seguirán la misma ruta, ni deberían hacerlo.
Ten en cuenta algunas preguntas:
  • ¿Qué elementos de una aplicación o servicio se beneficiarían más de un enfoque basado en eventos y sin servidor?
  • ¿Qué elementos de un servicio requieren lanzamientos rápidos de código o la capacidad de validar nuevas funciones mediante pruebas A/B (lo que significa que una nueva versión del software está disponible para un porcentaje de usuarios)?
  • ¿Qué elementos cambian con poca frecuencia, pero se beneficiarían de la implementación y escalabilidad automatizadas?
Con las respuestas a estas preguntas, puedes comenzar a desarmar las cargas de trabajo (si es posible) y modificarlas según el marco que prefieras, presentando así a tu organización un enfoque de migración pragmático que maximice el valor.

Cómo aplicar el modelo

Cuando una empresa minorista importante comenzó a migrar a GCP, el modelo de subir o adaptar los ayudó a decidir qué partes de su contenido de TI debía seguir qué camino.
El front-end orientado a los usuarios del minorista requería frecuentes lanzamientos de funciones para mantenerse a la vanguardia en un mercado competitivo a fin de evaluar los niveles de adopción y el valor de las nuevas implementaciones. Las pruebas A/B eran necesarias para satisfacer estas necesidades, mientras que una canalización automatizada de CI/CD implementaba aplicaciones nativas en la nube mediante Google Kubernetes Engine (GKE), subiéndolas en pila y cargándolas a la nube.
Con el paso del tiempo, el procesamiento de aplicaciones de nivel intermedio del minorista también podría beneficiarse de la refactorización y la nueva arquitectura, aunque se podría generar un valor más inmediato al cambiar a un modelo de escalabilidad automático y obtener eficiencias operativas en la nube. Estas aplicaciones fueron transferidas a Google Compute Engine.
Los sistemas de catálogo de back-end del minorista cambian muy raramente y se alojaron en sistemas bien entendidos y de fácil mantenimiento. Para enfocar su energía inicial, decidieron mantenerlos en su lugar hasta que puedan reemplazarlos por completo en el futuro.
Adoptar este enfoque permitió a la empresa minorista minimizar el tiempo y el esfuerzo necesarios para lograr su objetivo principal: una rápida iteración de la experiencia del cliente que se estaba volviendo obsoleta. También obtuvieron eficiencias operativas y de capital, y estuvieron en una buena posición para migrar sus datos de catálogo a la nube cuando el momento y el precio eran los adecuados.

enterprise_IT.png

Conclusión

Al planificar una migración a la nube, trazar un camino para las cargas de trabajo individuales y los elementos arquitectónicos en el marco elegido permite a los responsables de la toma de decisiones de TI enfocarse en los beneficios que se obtienen al volver a la plataforma, a la nueva arquitectura o a una combinación de ambas.  También comunica las rutas de migración con el paso del tiempo de una manera accesible que puede compartirse con un amplio público, tanto empresarial como de TI. Es típico y, de hecho, recomendado que diferentes componentes tomen caminos únicos. Cualquiera sea la mejor ruta, Google Cloud Platform incluye los productos y las herramientas de migración necesarios, que van desde el lift-and-shift a Compute Engine, las aplicaciones de portabilidad a GKE en las instalaciones o en la nube, o la implementación de servicios nativos a funciones de la nube.

Próximos pasos

Los marcos simples pero evocadores, como los que vimos, pueden ayudar a los encargados de tomar decisiones de TI a navegar por la complejidad inevitable de una migración a la nube. Como cualquier buen modelo, la simplicidad es una característica, no un error, ya que ayuda a mantener el enfoque en el resultado deseado y se comunica fácilmente a una variedad de públicos.
Trazar los caminos de adopción para diferentes partes de tu contenido de TI es un primer paso importante. En los siguientes artículos, profundizaremos un poco más y exploraremos algunas de las transformaciones de la tecnología y la arquitectura que implica cada uno de estos caminos.