Preparación para adoptar la nube: una lista de verificación de migración al Cloud
¿Cuál es la Preparación para adoptar la nube? ¿Hay alguna lista de verificación de migración al Cloud? ¿Un checklist prático y efectivo?
Si su organización está buscando modernizar las aplicaciones de misión crítica y está planeando una migración a la nube como parte de este proceso, no desea repetir los errores de los demás. Por lo tanto, esta publicación aprovecha esos aprendizajes para crear una lista de verificación de 10 pasos de las principales áreas que debe considerar y abordar para maximizar sus posibilidades de una migración exitosa a la nube.
Paso 1: establecer el rol de arquitecto de migración
Antes de comenzar su migración a la nube, establezca el rol de arquitecto de migración para liderar el esfuerzo. El arquitecto de migración es un puesto de nivel de arquitecto de sistema responsable de planificar y completar todos los aspectos de la migración; su responsabilidad principal debe incluir definir la refactorización necesaria para que la migración sea exitosa, diseñar estrategias para la migración de datos, definir los requisitos de la solución en la nube y determinar las prioridades de migración y los mecanismos de cambio de producción. Durante el curso de un gran proyecto de migración, se deben tomar muchas decisiones y planes técnicos, y contar con un arquitecto de migración que sea responsable de todos los aspectos de la migración es fundamental para el éxito del proyecto.
Paso 2: elige tu nivel de integración en la nube
Cuando mueve una aplicación desde un centro de datos local a la nube, hay dos formas de migrar su aplicación: una integración en la nube superficial o una integración en la nube profunda.
Para una integración en la nube poco profunda (a veces llamada «levantar y cambiar») , mueve la aplicación local a la nube y no realiza cambios (o limitados) en los servidores que crea instancias en la nube con el fin de ejecutar el solicitud. Cualquier cambio en la aplicación es suficiente para que se ejecute en el nuevo entorno. No utiliza servicios únicos en la nube. Este modelo también se conoce como levantar y cambiar porque la aplicación se levanta «tal cual» y se mueve, o se desplaza, a la nube intacta.
Para una integración profunda en la nube , modifique su aplicación durante el proceso de migración para aprovechar las capacidades clave de la nube. Esto podría no ser nada más avanzado que usar el escalado automático y el equilibrio de carga dinámico, o podría ser tan sofisticado como utilizar capacidades informáticas sin servidor como AWS Lambda para partes de la aplicación. También podría implicar el uso de un almacén de datos específico de la nube, como Amazon S3 o DynamoDB .
Paso 3: elija una sola nube o vaya a varias nubes
Antes de comenzar su migración a la nube, responda esta pregunta: ¿Desea elegir un único proveedor de la nube y migrar su aplicación para que se ejecute optimizada para ese entorno único, o desea que su aplicación se ejecute en múltiples proveedores de la nube?
Optimizar su aplicación para que funcione con un proveedor específico de la nube es relativamente simple. Sus equipos de desarrollo solo tienen que aprender un conjunto de API en la nube, y su aplicación puede aprovechar todo lo que ofrece su proveedor de nube elegido.
La desventaja de este enfoque es el bloqueo del proveedor. Una vez que haya actualizado su aplicación para que funcione con ese único proveedor, mover su aplicación a un proveedor diferente podría requerir tanto esfuerzo como la migración original a la nube. Además, tener un único proveedor en la nube podría afectar negativamente su capacidad de negociar términos importantes, como precios y SLA, con el proveedor de la nube.
Pero espera, se vuelve aún más complicado. Existen varios modelos diferentes para usar múltiples proveedores en la nube:
Una aplicación en una nube; otra aplicación en una nube diferente. Quizás el enfoque más simple de múltiples nubes ejecuta un conjunto de aplicaciones en un proveedor de nube y otro conjunto en otro. Este enfoque le brinda un mayor apalancamiento comercial con múltiples proveedores, así como flexibilidad para ubicar las aplicaciones en el futuro. También le permite optimizar cada aplicación para el proveedor en el que se ejecuta.
Divida su aplicación en múltiples proveedores en la nube. Algunas compañías optan por ejecutar partes de una aplicación en un proveedor de la nube y otras partes en otro. Este enfoque le permite utilizar las ventajas clave que ofrece cada proveedor (por ejemplo, un proveedor podría tener mejores capacidades de IA que otro, que es conocido por sus velocidades de base de datos). El riesgo aquí es que su aplicación esté vinculada al rendimiento de ambos proveedores, y cualquier problema con cualquiera de los proveedores podría afectar la experiencia del cliente de su aplicación.
Cree su aplicación para ser independiente de la nube. Otras compañías crean sus aplicaciones para que se ejecuten en cualquier proveedor de la nube. Con este enfoque, podría ejecutar su aplicación simultáneamente en múltiples proveedores o dividir la carga de su aplicación entre ellos. Este modelo le brinda la máxima flexibilidad en las negociaciones con los proveedores porque puede cambiar fácilmente las cargas de un proveedor de la nube a otro. La desventaja es que puede resultarle difícil utilizar las capacidades clave de cada proveedor de la nube, reduciendo los beneficios de alojar su aplicación en la nube. Este enfoque también puede complicar sus procesos de desarrollo y validación de aplicaciones.
Paso 4: establecer KPI en la nube
Los indicadores clave de rendimiento (KPI) son métricas que recopila sobre su aplicación o servicio para medir su desempeño en función de sus expectativas. Es posible que ya haya definido algunos KPI para sus aplicaciones y servicios, pero ¿siguen siendo los correctos para una aplicación o servicio una vez que está en la nube? Los mejores indicadores clave de rendimiento (KPI) para una migración a la nube muestran cómo le está yendo a su migración en curso, iluminando problemas visibles o invisibles que pueden estar al acecho dentro de su aplicación. Lo más importante, quizás, es que los KPI de migración en la nube pueden ayudarlo a determinar cuándo la migración se ha completado y es exitosa.
Existen varias categorías clave de KPI de migración a la nube:
Categoría KPI de muestra
Experiencia de usuario : Tiempo de carga de página/ Retraso; Tiempo de respuesta; Duración de la sesión.
Rendimiento de aplicación / componente: Tasas de error; Rendimiento; Disponibilidad; Apdex.
Infraestructura: Uso de CPU%; Rendimiento de disco; Uso de memoria/ Rendimiento de red.
Compromiso comercial: El carrito agrega conversiones y porcentajes de conversión, % de participación.
Para cada categoría, determine qué métricas son las más importantes para su negocio y qué métricas se verán más afectadas por la migración a la nube.
Paso 5: establecer líneas de base de rendimiento
La referencia es el proceso de medir el rendimiento actual (anterior a la migración) de su aplicación o servicio para determinar si su rendimiento futuro (posterior a la migración) es aceptable. Las líneas de base lo ayudan a determinar cuándo se completa su migración y le proporcionan la validación de las mejoras de rendimiento posteriores a la migración que esperaba. También puede consultar las líneas base durante una migración a la nube para diagnosticar cualquier problema que surja.
Establezca una métrica de referencia para cada KPI que haya decidido medir. Determine cuánto tiempo recopilará datos para determinar la línea de base. Elegir un período de referencia breve (como un día) le permite moverse más rápido, pero se arriesga a no recopilar una muestra de rendimiento representativa. Elegir un período más largo hasta la línea de base (como un mes) obviamente lleva más tiempo, pero puede proporcionar datos más representativos.
También debe determinar si desea recopilar solo datos de referencia que sean promedio o representativos, o si desea incluir datos recopilados durante períodos «pico» o «crítico». Por ejemplo, si es un sitio de noticias, ¿desea recopilar datos durante un día con un gran evento de noticias o desea evitar esos días?
No importa qué modelo de recopilación de datos sea apropiado para su industria, asegúrese de definir claramente qué tipo de datos recopilará y durante qué período de tiempo.
Paso 6: priorice los componentes de migración
También debe decidir si migrará toda su aplicación de una vez, o si la migrará al componente de la nube por componente o servicio por servicio.
Primero, identifique las conexiones entre sus servicios y qué servicios dependen de qué otros servicios. Para aplicaciones más grandes y complejas, use una aplicación de monitoreo como New Relic APM que puede usar mapas de servicio para generar diagramas de dependencia. Use el diagrama de dependencia para decidir qué componentes deben migrarse y en qué orden. A menudo tiene sentido comenzar con los servicios que tienen la menor cantidad de dependencias. En este caso, primero migrará sus servicios más internos y luego seguirá con sus servicios más externos, generalmente los más cercanos a sus clientes. El enfoque alternativo es comenzar con los servicios más cercanos a sus clientes, los más externos servicios, para que pueda controlar cualquier impacto en sus clientes.
Paso 7: realice la refactorización necesaria
Es posible que desee realizar otro trabajo en sus aplicaciones y servicios antes de migrarlos para que funcionen de la manera más eficaz y eficiente posible en la nube. Por ejemplo, es posible que desee refactorizar su aplicación:
Por lo tanto, funciona de manera efectiva con un número variable de instancias en ejecución para permitir el escalado dinámico, lo que potencialmente le ahorra dinero en costos de servicios en la nube.
Por lo tanto, su utilización de recursos puede aprovechar mejor las capacidades de la nube dinámica, como la capacidad de asignar y desasignar recursos dinámicamente según sea necesario, en lugar de asignarlos estáticamente antes de tiempo.
Para pasar a una arquitectura más orientada al servicio antes de la migración, para que pueda mover más fácilmente los servicios individuales a la nube.
Paso 8: crear un plan de migración de datos
La migración de datos es una de las partes más difíciles de una migración a la nube. La ubicación de sus datos puede afectar significativamente el rendimiento de su aplicación. Mover sus datos a la nube cuando los métodos de acceso a datos todavía están principalmente en las instalaciones puede afectar significativamente el rendimiento. Lo mismo ocurre si los datos aún están en las instalaciones pero el servicio que accede a ellos reside en la nube.
Las opciones para la migración de datos incluyen:
Usando un mecanismo de sincronización bidireccional entre sus bases de datos locales y en la nube. Una vez que haya trasladado a todos los consumidores de los datos a la nube, elimine la base de datos local.
Use una base de datos local con sincronización unidireccional a una base de datos basada en la nube, y permita que los consumidores se conecten solo a la versión local. Cuando esté listo, desactive el acceso a la versión local para que la versión basada en la nube se convierta en la base de datos principal y permita que los consumidores basados en la nube accedan a la nueva base de datos.
Use un servicio de migración de datos en la nube, como los disponibles en Amazon Web Services y Microsoft Azure .
No subestime la complejidad e importancia de la planificación de la migración de datos. No prestar mucha atención a su plan de migración de datos antes de comenzar una migración a la nube puede hacer que las migraciones fallen, o al menos no cumplan con las expectativas. Su arquitecto de migración debe estar muy involucrado en el proceso de planificación de la migración de datos.
Paso 9: Cambiar producción
¿Cuándo y cómo cambia el sistema de producción de la solución heredada local a la nueva versión en la nube? La respuesta depende de la complejidad y la arquitectura de su aplicación, y especialmente de la arquitectura de sus datos y almacenes de datos.
Hay dos enfoques comunes:
Hazlo todo de una vez. Espere hasta que haya movido toda la aplicación o servicio a la nube y validado que funciona allí, y luego cambie el tráfico de la pila local a la pila de la nube.
Hazlo un poco a la vez. Mueva a algunos clientes, pruebe que las cosas todavía funcionan y luego mueva a algunos clientes más. Continúe este proceso hasta que haya trasladado a todos sus clientes a la aplicación basada en la nube.
Paso 10: revise la asignación de recursos de la aplicación
Incluso después de que haya terminado de migrar todo a la nube, hay algunas cosas más que considerar. Lo más importante es la optimización de recursos. La nube está optimizada para la asignación dinámica de recursos, y cuando asigna recursos (servidores, por ejemplo) estáticamente, no está aprovechando las fortalezas de la nube. A medida que avanza en la nube, asegúrese de que sus equipos tengan un plan para distribuir recursos a su aplicación. Cuando necesita asignar recursos adicionales a una aplicación en la nube, generalmente están disponibles del proveedor en prácticamente cualquier cantidad en cualquier momento. Esto significa que normalmente puede confiar en que puede escalar según sea necesario para satisfacer la demanda, suponiendo que sus equipos tengan la arquitectura de la aplicación para soportar el escalado dinámico.
Otras consideraciones para su migración a la nube
Los once pasos en esta lista de verificación cubren mucho terreno, pero definitivamente hay otras cosas que debe considerar durante su migración a la nube. La creación de un entorno de nube seguro y protegido, por ejemplo, es obviamente una parte crítica de cualquier migración a la nube. Afortunadamente, los principales proveedores de la nube ofrecen herramientas y recursos significativos para ayudarlo a construir y mantener un sistema seguro.
Cuando se trata de costos en la nube, existen dos reglas generales sobre el precio de la nube : la nube es más barata que en las instalaciones y la nube es más cara que en las instalaciones . Ambos pueden ser verdaderos o falsos, dependiendo de la situación.
Ciertamente, es posible comenzar a usar la nube y descubrir que su factura de infraestructura, de hecho, ha aumentado en comparación con lo que estaba gastando en su centro de datos físico. Hay un par de razones por las que esto podría suceder:
Primero, hay costos ocultos en todos los sistemas de infraestructura, y es posible que no esté considerando todos los costos involucrados en la administración de su propio centro de datos, mientras que la factura mensual que recibe de su proveedor de la nube aclara los costos. ¿El resultado? A veces terminas comparando manzanas con naranjas, lo que hace que la solución en la nube parezca más cara que la solución local.
En segundo lugar, los costos de una infraestructura local se componen principalmente de gastos de capital (CapEx), mientras que una infraestructura basada en la nube generalmente proviene de los gastos operativos (OpEx). Dependiendo de cómo su negocio maneje sus libros, CapEx puede ser más fácil de encontrar que OpEx, o viceversa. Comprender cómo pagar por las infraestructuras basadas en la nube difiere de una infraestructura local, y asegurarse de que los modelos financieros de su empresa respalden las distinciones, es fundamental para reconocer las mejoras en los costos de la nube.
Para obtener más información sobre el tema de los costos en la nube, consulte Cómo calcular el costo de una migración a la nube .
Finalmente, recomiendo a cualquiera que busque planificar una migración a la nube para familiarizarse con temas como la construcción de aplicaciones modernas utilizando servicios y microservicios, especialmente aplicaciones de doce factores , y el uso de métodos y procedimientos de DevOps como mejores prácticas para construir y ejecutar servicios y aplicaciones en la nube.
Leer también:Mover infraestructura a la nube: 5 beneficios no tan obvios; Automatizar la infraestructura como servicio; ¿Qué es Cloud Vps? ; Servicios en la nube