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.
