Oh sí. Está sucediendo. Considere convertirlo en parte de su estrategia general en la nube para que el proceso sea menos doloroso.
¿Qué tienen en común los siguientes? Salmón, gansos canadienses, mariposas monarca y aplicações.
Si adivinaste que todas estas son cosas que migran de un lugar a otro, date una palmadita en la espalda.
Ahora bien, generalmente cuando hablamos de migración a la nube, nos referimos a pasar de una infraestructura local a una externa. Con razón. Hay muchos datos ( incluidos los nuestros ) que indican un aumento en la adopción del uso de la nube pública. De lo que casi nunca hablamos es de la migración que ocurre a la inversa. Ya puedo oír los gritos de “¡Herejía!”, pero seamos realistas: sucede, y con más frecuencia de lo que uno se imagina.
Por ejemplo:
El 42% de los encuestados que adoptaron una IaaS pública en producción indicaron que “ tienen la intención de migrar de su estrategia actual, ya sea dentro de los próximos cuatro años o como un proceso continuo ”. El 70% de ellos “ anticipó migrar a una nube híbrida en lugar de cambiar exclusivamente a una solución de nube privada ”.
¿La razón? El factor más común fue la reducción de costos (67%), seguido de la seguridad y la estabilidad. Así lo demuestran historias como ésta sobre la migración de Pubmatic de la nube pública a la privada . Los costos fueron un factor importante.
Pero otros están migrando en la dirección opuesta, como todos hemos oído. Mucho. El 57% de quienes utilizan una plataforma IaaS privada “ tienen la intención de migrar a una nube híbrida y el 77% de los encuestados indica que planean adoptar un enfoque híbrido”.
¿Su razonamiento? Escalabilidad (71%), seguida de cerca por la flexibilidad. Los costos ocuparon el tercer lugar, con un 50% de los encuestados.
La escalabilidad lleva a las personas a la nube pública, y los costos a largo plazo parecen empujarlas de regreso a la nube privada.
La realidad es que la mayoría de las organizaciones no son ni una tienda de “nube pública” ni una tienda de “nube privada únicamente”. Son multi-cloud , incluso después de mover aplicaciones de un lado a otro. La realidad se puede comprobar examinando las tendencias de desarrollo, como las informadas por Cap Gemini en su informe “Cloud Native Comes of Age”, que señaló que “una sexta parte (15 %) de las nuevas aplicações de las empresas encuestadas se crean hoy en un entorno cloud-native”.
Ahora bien, si el 15% es nativo de la nube, eso implica que el otro 85% no lo es. Probablemente esto incluya mainframes. Y cliente-servidor. Y aplicaciones web de tres niveles. Ah, y también microservicios en entornos contenerizados.
La organización empresarial moderna no es sólo multi-nube, sino también multigeneracional en términos de sus arquitecturas de aplicação .
Esto significa que las probabilidades de migrar algún tipo de aplicación desde un entorno local (privado) a un entorno externo (público) o viceversa son bastante buenas, porque hay más que aplicaciones nativas de la nube. Lo importante entonces es incorporar esa premisa a su estrategia de nube. En otras palabras, necesitas entender qué puedes hacer desde el principio para que el proceso (quizás inevitable) sea menos doloroso.
Una de las primeras cosas a tener en cuenta es la vida útil esperada de la aplicación que estás trasladando. Si es a largo plazo, es un candidato para la migración de nube a nube en el futuro. Si no es así (ya sea por motivos promocionales, de marketing o basados en eventos), puede pasar directamente al final de esta lista e implementarlo.
Ahora que ha determinado que la aplicación tendrá una vida útil más larga, debe pensar en cómo va a escalarla y protegerla.
BARRA LATERAL DE LA CAJA DE JABÓN DE SEGURIDAD Incluso si la aplicación no acepta entrada o datos táctiles, aún necesita cierta seguridad. La seguridad de las aplicaciones es un todo, y hay plataformas y protocolos que pueden dejarte expuesto a riesgos si no proteges ambos. Los ataques de manipulación de metadatos (aquellos que tienen como objetivo los encabezados HTTP) son tan peligrosos (quizás más) que las vulnerabilidades inducidas por código personalizado. Todas las aplicaciones son fundamentales en materia de seguridad. |
La respuesta rápida (y fácil) si la aplicación es nativa de la nube es "usaremos servicios del proveedor de la nube". Esa es una opción válida, así como “usaremos lo que siempre hemos usado” es una opción válida si la aplicación va a vivir en una nube privada local. Sin embargo, ambas opciones conllevan un riesgo potencial en el futuro, ya que no podrá migrar sin problemas los servicios o políticas de una nube a otra. Es hora de analizar en profundidad lo que está utilizando ahora para escalar y garantizar la seguridad y determinar si esos servicios de aplicação pueden migrar junto con su aplicación, en ambas direcciones.
Dado que las empresas utilizan un promedio de 16 servicios de aplicação para entregar y proteger sus aplicaciones, esta es un área que puede obstaculizar significativamente su capacidad de soportar aplicaciones que puedan migrar, y mucho menos soportarlas en un mundo de múltiples nubes. Tenga en cuenta que algunos de esos 16 servicios deberán ser servicios nativos de la nube. Básicamente, si considera su ruta de datos como compuesta por servicios de aplicação corporativas compartidas y servicios por aplicación, puede comenzar a ver que la división arquitectónica coincide estrechamente con la línea trazada por los proveedores de nube pública en la capa de infraestructura. No es una división perfecta, pero sí proporciona una separación lógica que ofrece orientación sobre qué servicios deben ser “multicloud” y en cuáles se puede confiar, ya sean servicios nativos de la nube o de centros de datos tradicionales.
Cuanto más consistente sea la consistencia de los servicios de aplicação que utiliza en las diferentes nubes, más fácil será migrar entre las dos (o tres o cuatro o más) porque habrá menos ataduras. Este enfoque tiene el beneficio adicional de ampliar los esfuerzos de automatización para llegar a la nube pública y aliviar al negocio, al menos, de los costos operativos asociados con el mantenimiento de personal y procedimientos operativos separados.
La nube era inevitable. Lo mismo ocurre con la multi-nube. Lo que en última instancia significa que habrá migración entre ellos. Estar atento a las dependencias y utilizar servicios de aplicação entre nubes antes de tomar la decisión inicial sobre dónde se debe implementar la aplicación puede hacer que el proceso sea menos complicado.
Haga que la idea de la migración de nube a nube sea, al menos, parte de su estrategia de nube de alto nivel. Estar preparado puede evitarle una migración dolorosa (y costosa) en el futuro.