Estrategia de alto nivel
Una vez que una organización ha determinado que está lista para migrar a la nube, hay que tomar una serie de decisiones específicas del contexto. Tener una estrategia general y orientadora es fundamental.
Establecer sus objetivos y los problemas que espera abordar a través de su estrategia de migración a la nube puede ayudar a garantizar que sus estrategias comerciales y tecnológicas estén alineadas. ¿Qué espera lograr?
- ¿Está tratando de reducir costos o mejorar el tiempo de comercialización?
- ¿Tiene dificultades para atraer y retener personal calificado?
- ¿Está tratando de mejorar la calidad de sus productos o servicios?
- ¿Son estos objetivos urgentes o a largo plazo?
- ¿Tiene requisitos de cumplimiento que deben cumplirse al migrar a la nube?
Estos factores son fundamentales para determinar cómo debería ser su estrategia de migración a la nube.
Selección de proveedores
Para una organización relativamente pequeña con un conjunto homogéneo de requisitos de carga de trabajo, una estrategia de nube de un solo proveedor podría ser la más apropiada, ya que hay poca necesidad de invertir en múltiples proveedores de nube para lograr redundancia técnica o evitar la dependencia de un proveedor.
Una organización mucho más grande, como un banco global con diversas cargas de trabajo y distintos niveles de requisitos técnicos, sería más probable que siguiera una estrategia de múltiples nubes, ya que eso daría a cada equipo de proyecto la flexibilidad de elegir el proveedor que mejor se adapte a sus necesidades. . Además, es más probable que las organizaciones más grandes tengan requisitos de cumplimiento internos y externos que cumplir, y estos pueden requerir la capacidad de mover cargas de trabajo entre proveedores de nube con un aviso relativamente corto.
Una estrategia híbrida, en la que participan tanto un centro de datos tradicional como proveedores de nube, también puede tener sentido para empresas medianas y grandes, especialmente si la transición a la nube durará varios años. Esta estrategia también puede ser relevante si es necesario evolucionar sus tácticas de migración a la nube de manera más dinámica a medida que aprende más sobre la implementación de tecnologías de nube dentro de su empresa.
Las seis R
Una vez que haya determinado sus objetivos de migración a la nube y la estrategia del proveedor, el siguiente paso es decidir cómo migrar sus cargas de trabajo a la nube.
Primero, querrá realizar una auditoría de su aplicación existente. Esto puede darle una idea del nivel y la naturaleza del trabajo necesario para migrar a la nube. Durante esta auditoría, puede clasificar su aplicación según el enfoque que desea que adopten los equipos responsables de ella con su migración a la nube. AWS describe seis “estrategias de migración comunes”. Estos pueden aplicarse en todos los ámbitos o cada equipo puede elegir la estrategia más adecuada para su configuración particular en ese momento, dependiendo del tamaño de la organización y la complejidad involucrada.
1. Rehospedar
La primera y más sencilla estrategia es volver a alojar su aplicación (también conocida como "levantar y cambiar"). Implica trasladarlos de servidores físicos que se ejecutan en un centro de datos a servidores virtuales que se ejecutan en la nube. En general, esto no requiere cambios de código y relativamente pocos cambios en los procesos y tecnologías circundantes, como las redes. También puede permitirle a su organización desarrollar las habilidades y la experiencia en la nube necesarias para otras prácticas nativas de la nube.
2. Replataforma
También conocido como “levantar, retocar y cambiar”, este enfoque es similar al realojamiento, pero va un paso más allá al integrar una serie de servicios fundamentales en la nube a nivel de aplicación. Por ejemplo, AWS IAM (Gestión de identidad y acceso) podría integrarse en su aplicación para reemplazar o complementar sistemas IAM más tradicionales orientados al centro de datos.
3. Recompra
También conocido como "drop and shop", este enfoque implica reemplazar una aplicación local existente con un servicio con licencia basado en la nube. Esto puede implicar cambiar el modelo de licencia que utiliza su empresa, reducir el costo de mantenimiento y potencialmente permitir una ruta de actualización más rápida y sencilla.
4. Refactor/Rearquitecto
Un enfoque más nativo de la nube es tomar sus bases de código existentes y modificarlas o ampliarlas para que funcionen dentro de servicios de nube más modernos. Un ejemplo es contener el código de su aplicación, ejecutar la configuración y ejecutarla dentro de un servicio Kubernetes basado en la nube, como EKS de Amazon o AKS de Azure. Esto puede implicar reescrituras sustanciales de su código base existente para permitirle funcionar y aumentar la escalabilidad; Es posible que incluso sea necesaria una reescritura completa para utilizar herramientas verdaderamente nativas de la nube (por ejemplo, herramientas sin servidor como AWS Lambda o Azure Functions).
5. Retirar
Con las dos últimas estrategias “pasivas”, las cargas de trabajo no se migran a la nube en absoluto. Su auditoría de carga de trabajo puede descubrir sistemas que son redundantes o que ya no vale la pena mantener. Estas aplicaciones se pueden retirar.
6. Retener
La última estrategia "pasiva", la retención, implica mantener la aplicación en ejecución y elegir no migrarla a la nube en el futuro previsible. Existen varias razones posibles para mantener su aplicación fuera de la nube, entre ellas:
- Restricciones regulatorias sobre dónde se puede ejecutar la aplicación o altas exigencias de cumplimiento interno en materia de seguridad.
- Mission-criticality of software that can make planning a move to cloud technologies earlier in the migration cycle too risky and uncertain
- No hay argumentos comerciales para la interrupción causada por el traslado de la aplicación.
- Los sistemas heredados no son compatibles con entornos de nube
¿Dónde empezar?
Además de decidir su estrategia general y clasificar el enfoque táctico por carga de trabajo, necesitará un plan sobre cómo construir su infraestructura en la nube para soportar el movimiento de cargas de trabajo. Un enfoque es dejar que cada equipo elija cómo construir sus propios sistemas en la nube. Sin embargo, este enfoque tiene varias desventajas, ya que los equipos pueden duplicar antipatrones de implementación y repetir los errores de los demás o violar las reglas de cumplimiento internas/externas.
Un enfoque alternativo es crear un tipo de “centro de excelencia” centralizado o equipo de infraestructura en la nube. Este equipo puede elegir establecer los sistemas centrales en los que otros equipos pueden ejecutar sus cargas de trabajo.
Cuando se trata de establecer estos rieles de protección, hay ciertos elementos de diseño que deben priorizarse sobre otros.
Cuentas
La unidad más básica de su arquitectura en la nube es la cuenta en la nube. El uso de una cuenta en toda su organización casi siempre no logra escalar, ya que termina chocando con los límites de cuenta. Por lo tanto, es importante determinar los límites de la cuenta. ¿La cuenta se utilizará para representar una unidad de negocios en particular, un equipo individual o una agrupación de servicios de software? ¿Cómo va a funcionar esto con su departamento de finanzas? ¿Quién debería recibir la factura? Es importante resolver esto desde el principio, ya que los costos pueden acumular rápidamente.
IAM
La siguiente unidad más básica de arquitectura es el sistema de administración de identidad y acceso. A medida que su infraestructura en la nube crezca, deberá considerar las implicaciones de seguridad del acceso de los usuarios a los diversos servicios y datos en la nube, y cuanto antes, mejor. Imponer estas reglas retrospectivamente en sistemas que ya se están ejecutando puede ser complicado.
Conexión
La migración a la nube implica la virtualización de su red existente o un rediseño completo. El servicio VPC (AWS) o VNet (Azure) le permite configurar una red aislada para ejecutar un conjunto separado de servicios dentro de su cuenta. Se debe prestar especial atención a la comunicación entre redes entre los servicios de su organización y los recursos básicos de la red, como las direcciones IP.
Migración de datos
Si bien es fácil pasar a los servicios informáticos a la nube, migrar datos puede ser un poco más desafiante. Los principales almacenes de datos pueden ser infraestructuras grandes y complejas que requieren una planificación cuidadosa para moverse. Esto requiere una comprensión suficientemente profunda de cómo mover sus datos a la nube mientras se ajusta a los estándares de rendimiento, cumplimiento y operatividad de su organización.
Conclusión
Una vez que tenga clara su estrategia de nube de alto nivel, desarrollar una estrategia de migración a la nube exitosa requiere una planificación y consideración meticulosas de todos los aspectos de su negocio. El siguiente paso es elegir la estrategia de proveedor de nube adecuada para usted, ya sea una migración sencilla de un solo proveedor, un enfoque de proveedores de múltiples nubes o una estrategia híbrida. Finalmente, querrá diseñar su migración a la nube considerando primero los componentes de infraestructura clave antes de comenzar a incorporar la aplicación.
Espero que esta publicación de blog haya sido interesante y valiosa.
Esté atento a las próximas publicaciones de blog sobre contenedores/Kubernetes y servicios sin servidor.
Si está comenzando su viaje hacia la nube, tal vez le gustaría leer mi nuevo documento técnico sobre las cinco mejores prácticas para una migración segura a la nube.
Puede leer más sobre las soluciones de seguridad en la nube de Check Point aquí o programar una demostración con uno de los ingenieros de seguridad en la nube de Check Point aquí.
Para comprender cómo diseñar e implementar arquitecturas de nube seguras, consulte este documento técnico.
Comentarios