Blog de Amazon Web Services (AWS)

Practicas probadas para desarrollar una Estrategia de Multicloud

Por Tom Godden
Multicloud clarityComo estratega empresarial, encuentro que los temas de multicloud surgen en muchas discusiones plagadas de confusión, falsa certeza y vacilación. Las empresas son bombardeadas con mensajes contradictorios que les dicen que nunca adopten un enfoque multicloud o que no se lo pierdan porque “todos están cambiando a la nube múltiple”.

Existen buenas razones para perseguir o evitar estrategias multicloud. Este blog se centra en ocho prácticas comprobadas para tener éxito con la estrategia de multicloud, incluyendo cuándo y dónde tiene sentido el multicloud y cómo se posiciona AWS para ayudar a las empresas a tener éxito con sus estrategias de multicloud.

Multicloud se refiere al uso simultáneo de más de un proveedor de servicios en la nube (CSP) en una organización. Pero primero, aclaremos alguna terminología. El uso de productos SaaS, como el correo electrónico o el software de gestión de proyectos, junto con un CSP no constituye un entorno multicloud puro. Es una buena estrategia, y podría permitirte aprovechar múltiples nubes, pero en el contexto de este blog, eso no es multicloud desde el punto de vista de nubes públicas.

1. Persiga la nube múltiple (Multicloud) solo para satisfacer las necesidades comerciales legítimas

Aunque aconsejamos a los clientes de AWS que obtengan plenamente los beneficios de la nube eligiendo un proveedor de nube principal, donde la mayoría de sus cargas de trabajo se encuentran en un solo CSP, existen razones válidas por las que un enfoque multicloud podría ser adecuado para su organización. Las situaciones que pueden requerir la complejidad de una infraestructura multicloud incluyen:

Fusiones y Adquisiciones

Se puede crear un entorno multicloud durante una transacción de fusiones y adquisiciones cuando la empresa adquirente está en un CSP primario y la compañía adquirida está en otro. ¡Bienvenido a la nube múltiple! Lo que viene después no es fácil. El ingeniero en mí quiere decir consolide —menos, es más. Sin embargo, puede que no tenga sentido consolidarse de inmediato. Su estrategia general de integración tecnológica y su enfoque de evaluación deben reflejarse en este proceso; conviértalo en parte de su libro de estrategias de M&A. Lo que se mueve de un proveedor a otro, cuándo se mueve, y lo que se deja por la paz puede variar. Pero establecer una estrategia de integración es tan importante como evitar que múltiples instancias de ERP se ejecuten para siempre.

Querer aprovechar las capacidades diferenciadas a largo plazo de otro CSP

El miedo a perderse impulsa a algunas empresas a querer un poco de cada nube. Creemos que las empresas están mejor atendidas seleccionando un CSP que pueda resolver la mayoría de los desafíos de su organización en lugar de adoptar una estrategia más difusa. Una estrategia 80/20 es una buena manera de pensar sobre esto. La indexación sobre el 80% (y no el 20%) puede resultar en mejores eficiencias, retención de talento y valor. Si bien puede haber cargas de trabajo especializadas que requieran cierta tecnología, esas situaciones deben abordarse caso por caso, donde se pueden considerar beneficios y compensaciones.

Las empresas pueden pensar en “la carga de trabajo adecuada para la nube adecuada”. Asegúrese de que el análisis de lo que constituye la “nube correcta” se extienda más allá de las consideraciones para una carga de trabajo específica. Pregúntese cómo la difusión de esta carga de trabajo en un CSP adicional afectaría la complejidad general. Recomiendo que se realice un cuidadoso análisis de precio y rendimiento de cada carga de trabajo en cada nube para asegurarte de que el valor es suficiente para justificar esto.

Multicloud en el Holding Company y Nube Primaria en la Compañía Operativa/Línea de Negocio

Para las organizaciones de capital privado o las grandes sociedades de cartera con varias compañías de cartera o subsidiarias, puede tener sentido que cada compañía de cartera tenga su propia estrategia CSP (frecuentemente impulsada por fusiones y adquisiciones). Enfocar más tus gastos en un solo proveedor de la nube podría permitir aprovechar sus descuentos por volumen e incentivos para reservar instancias. Pero las otras carencias en torno al talento, las cargas de trabajo fragmentadas y el aumento de los riesgos se pasan por alto en gran medida, ya que cada organización opera de manera independiente.

2. Tenga en mente los mitos de la Multicloud

Mito 1: Todo mundo está adoptando Estrategias de Multicloud

Las empresas de asesoría y las empresas de medios han publicado hallazgos mixtos sobre la medida en que las empresas colocan sus cargas de trabajo en múltiples nubes. Nuestro consejo es hacer lo correcto para su firma y tomar decisiones basadas en costos y riesgos, independientemente de cuán prevalente pueda aparecer esta práctica.

Mito 2: El Multicloud reduce el riesgo de bloqueo de proveedores

Algunas empresas citan el miedo al bloqueo (tanto desde la perspectiva contractual como tecnológica) como una razón principal para buscar estrategias multicloud. En entornos locales, las empresas se ven impulsadas a grandes inversiones de capital a largo plazo, a menudo gobernadas por contratos de servicio largos y complicados. Estas son grandes decisiones de puertas unidireccionales (es decir, difíciles y costosas de revertir) para las empresas y éstas necesitarán un fuerte enfoque en la reducción del riesgo.

La nube es diferente. Las empresas que ejecutan la misma carga de trabajo en múltiples proveedores de nube a menudo sienten la presión de usar el “denominador común más bajo”, deben considerar las limitaciones. En algunos casos, pueden evitar este problema ejecutando diferentes cargas de trabajo con diferentes proveedores.

Mi recomendación es que las empresas trabajen para comprender completamente sus costos potenciales de cambio si necesitan salir de su CSP existente y la probabilidad de que eso ocurra. A partir de ahí, es posible definir el mejor enfoque para reducir el bloqueo mediante la evaluación del costo y la probabilidad de necesitar cambiar los CSP frente a los beneficios estratégicos de tener un proveedor primario.

También es importante señalar que la nube es inherentemente más abierta que el modelo tradicional de TI, y no creemos que la multinube sea necesaria para evitar el bloqueo. Descubra cómo AWS crea servicios en tecnologías y estándares de código abierto, como SQL, Linux y contenedores. Los clientes tienen la opción de utilizar servicios gestionados de código abierto, como Amazon Relational Database Service (RDS) para MySQL y Amazon RDS para PostgreSQL o bloques de creación fundacionales, y pagan según lo que consuman; no hay compromiso directo a largo plazo. Nos esforzamos por crear servicios que los clientes quieran usar, pero si un cliente elige alejarse, AWS lo hace se hace lo más simple posible. AWS proporciona múltiples herramientas de migración no solo para ayudar a los clientes a mover recursos de las instalaciones a AWS más fácilmente, sino también para devolverlos a las instalaciones o a otras nubes si los clientes así lo eligen.

Mito 3: Multicloud mejora la disponibilidad

Reducir el riesgo de interrupción del servicio si el CSP principal de una compañía tiene una interrupción es una razón cada vez más rara para adoptar una estrategia multicloud. En estos casos, existe la creencia de que una empresa puede cambiar de manera simple y sin problemas sus cargas de trabajo a un CSP secundario.

La conmutación por error, en el multicloud, supone que una aplicación puede pasar por error a otra nube. Como muchas empresas han encontrado, esto es extremadamente desafiante. Lograr esto requiere que la compañía mantenga la portabilidad total entre dos CSP, agregando complejidad, riesgo y trabajo adicional con la creencia de que la conmutación por error o por falla es posible.

La distinguida analista vicepresidente Lydia Leong de Gartner, resumió los problemas con la conmutación por error en multicloud en su tweet, “La conmutación por error en multicloud es compleja y costosa hasta el punto de casi siempre ser poco práctica, y no es una forma especialmente efectiva de abordar los riesgos de la nube y la resiliencia”. El problema al hacer que la conmutación por error o falla funcione son todos los diferenciadores CSP (por ejemplo, las diferentes arquitecturas y características de red, diferentes capacidades de almacenamiento, servicios patentados de nivel superior, capas de bases de datos, servicios ML, junto con diferentes capacidades de seguridad, etc.). Cuando las cargas de trabajo se distribuyen entre CSP, una falla en cualquiera de los CSP podría causar una interrupción. En este caso, la difusión de las cargas de trabajo entre los CSP en realidad aumenta el riesgo.

En cambio, recomiendo que las empresas mitiguen el riesgo “implementando y simplificando”. Apunte una carga de trabajo o aplicación específica para una sola nube, migre, domine, tome costos y riesgos, y repita. Fomente un aprendizaje más profundo de las características y capacidades específicas de cada CSP a través de la capacitación y aproveche los servicios y herramientas específicos del CSP de nivel superior que ya están integrados. Finalmente, y quizás lo más importante, aproveche las regiones y las zonas de disponibilidad de AWS. Las capacidades de AWS en esta área ya brindan a los clientes de AWS excelentes capacidades para garantizar soluciones confiables y de alta disponibilidad.

Mito 4: La Multicloud ofrece mejores precios

La competitividad de los precios podría ser el argumento más débil de todos para la multicloud. Las experiencias de las organizaciones con contratos de software o centros de datos complicados y costosos que los bloquean en acuerdos plurianuales, las han hecho recelosas a la hora de contratar servicios de TI. Los enfoques tradicionales de adquisición no se han adaptado a las compras de pago por uso, los descuentos por volumen o la realidad de la competencia de precios en la nube. (AWS ha reducido los precios 129 veces desde su creación).

El mayor impulsor de la reducción de costos es lo bien administrado y optimizado que está el entorno en la nube de una empresa. Una empresa puede ver una mejor optimización de costos al trabajar principalmente con un proveedor cuyos servicios ofrecen ventajas de precio-rendimiento (como instancias informáticas basadas en chips diseñados a medida como AWS Graviton) y tiene soluciones superiores de gestión financiera en la nube. Según un estudio del Grupo Hackett 2021 de más de 1,000 organizaciones, el gasto en infraestructura como porcentaje del gasto total de TI fue 20% menor para los clientes de AWS que para las organizaciones multicloud.

Nuestra experiencia ha demostrado que las empresas no anticipan el costo agregado y la complejidad de operar en múltiples nubes, ni lo pesan adecuadamente contra la ganancia percibida en un compromiso de abastecimiento cara a cara.

3. Tenga una clara Estrategia y Gobernabilidad para soportarla

Simplemente decidir perseguir una estrategia multicloud es insuficiente; también debe establecer una estrategia para cumplir con su objetivo multicloud, incluyendo un gobierno claro para qué cargas de trabajo irán a dónde y por qué. Se deben utilizar criterios de evaluación para optimizar las cargas de trabajo y sus dependencias. Si se deja en manos de los individuos, la expansión descoordinada entre los CSP probablemente erosionará cualquier valor que la estrategia de multicloud buscaría lograr. Evalúe el rendimiento de la carga de trabajo de CSP regularmente y utilice su evaluación como entrada clave para la selección de CSP, los criterios y el uso futuro.

Es crucial tener una visibilidad integral del número total de servicios, aplicaciones y componentes utilizados en toda la empresa como parte de una estrategia general de gobierno. Una parte integral de esto es una estrategia de etiquetado robusta que abarca CSP y establece una propiedad, uso y entorno claros (por ejemplo, desarrollo, control de calidad, etapa y producción) para el 100% de los recursos desplegados. Todo debe ser etiquetado a un propietario o responsable; si no está etiquetado o no se puede identificar a un propietario, debe ser eliminado. Esto codifica las reglas de gobierno y automatiza la aplicación en lugar de crear bloques para el progreso (barandillas, no puertas). El costo, las operaciones, y la seguridad deben ser rastreados, monitoreados y actuados de la misma manera con la misma profundidad de datos y transparencia en todos los CSPs. Se prefiere una herramienta única para una necesidad determinada que pueda operar a través de todos los CSPs.

4. No repartir las cargas de trabajo contiguas entre CSPs

En mi opinión, las cargas de trabajo que abarcan múltiples CSPs introducen una complejidad, un riesgo y costo innecesarios, al tiempo que complican el soporte, la implementación y la arquitectura con poco valor agregado. Las cargas de trabajo contiguas a menudo implican grandes volúmenes de datos que deben procesarse y analizarse juntos. Cuando los datos se distribuyen a través de múltiples proveedores de nube, pueden crear desafíos en el movimiento de datos, la sincronización y el mantenimiento de la coherencia. Además, administrar una carga de trabajo contigua a través de múltiples CSP puede ser compleja y llevar mucho tiempo. Requiere tratar con diferentes APIs, interfaces de administración, modelos de seguridad y procesos operativos para cada CSP. Esta complejidad aumenta las posibilidades de errores, aumenta la sobrecarga operativa y puede dificultar la agilidad y escalabilidad.

Deben establecerse criterios específicos y principios rectores a la hora de evaluar este tipo de diseño y necesidad de negocio.

5. Las Aplicaciones deben permanecer con sus Datos Transaccionales

Se debe tener cuidado cuando los desarrolladores necesitan mover grandes volúmenes de datos entre aplicaciones en diferentes nubes, especialmente con cómputos/aplicaciones implementadas en un CSP y almacenamiento de datos en otro. Tal situación puede agregar complejidad y latencia que pueden compensar los beneficios percibidos.

Los criterios de decisión para determinar un CSP para una carga de trabajo deben incluir una visión a largo plazo de integración de esa carga de trabajo con otras. ¿Serán necesarios los datos para análisis avanzados o ML más allá de su alcance actual? ¿Los servicios proporcionados se consumirán ampliamente en otros CSPs, o están aislados de las cargas de trabajo en ese CSP? Para obtener más orientación y un modelo de decisión para las consideraciones de implementación, consulte el blog Multi-cloud: From Buzzword to Decision Model de mi colega Gregor Hohpe.

6. Los contenedores ayudan, pero se debe entender que no solucionan todos los casos de uso.

El uso de contenedores es generalmente una buena idea para cualquier aplicación moderna, y ayudan con muchos elementos de portabilidad. Los contenedores son agnósticos de la plataforma, lo que significa que pueden ejecutarse en cualquier plataforma o infraestructura en la nube que admita la contenerización. Esto le permite desarrollar y empaquetar su aplicación una vez e implementarla de manera consistente en múltiples proveedores de nube o entornos locales sin modificaciones significativas. Pero tenga precaución ya que los contenedores no funcionan en todos los casos (por ejemplo, grandes aplicaciones monolíticas), ni resuelven todos los problemas (especialmente datos, políticas y seguridad) en torno a la portabilidad entre CSPs.

7. Los contenedores ayudan, pero se debe entender que no solucionan todos

Como asesoramos a muchos clientes de AWS, debe aprovechar un CCOE (Cloud Center of Excellence) dentro de su organización para proporcionar liderazgo, estandarización y aceleración de su viaje a la nube. Cuando se trata de multicloud, encontramos que las empresas más exitosas tienen un solo CCOE, pero se especializan dentro de ese CCOE las habilidades, herramientas y mecanismos particulares de un CSP específico. Descubrimos que cuando los clientes de AWS tienen múltiples CCOE para cada CSP, a menudo conduce a divergencia, reingeniería y desperdicio en lugar de un enfoque más coordinado a través de un solo CCOE.

8. Asegúrese de que la Seguridad tenga siempre la más alta Prioridad

La nube múltiple dificulta la seguridad al aumentar el riesgo de acceso no autorizado o violación de datos. La nube múltiple obliga a las empresas a lidiar con múltiples modelos de seguridad en todos los CSPs en áreas como la administración de identidades, la seguridad de la red, la administración de activos y el registro de auditorías.

Esta complejidad dificulta la transparencia y aumenta la carga de los equipos de seguridad, elevando el riesgo. Aunque no son exclusivas de la multinube, varias prácticas de seguridad básicas se vuelven más importantes, como son: (1) cambiar la seguridad que queda al automatizarla e integrarla en los canales de entrega, los entornos de nube y las prioridades del equipo; y (2) cifrar los datos en reposo y en tránsito dentro o entre CSP.

Un enfoque útil para la adopción de multicloud es crear un único destino para los datos de seguridad (es decir, un solo panel de visualización). Aumente esto con herramientas nativas de la nube desarrolladas por cada CSP para presentar estos datos de manera que tenga sentido dentro de ese entorno.

Conclusión

Para la mayoría de las organizaciones, una estrategia de nube primaria proporciona el mayor valor a través de la simplicidad, el enfoque y la mitigación de riesgos, al tiempo que permite a las empresas profundizar su asociación y conocimiento de trabajo de sus CSPs y servicios primarios. Esto aumenta la capacidad de una organización para aprovechar servicios más sofisticados y atraer y retener mejor el talento mientras entrega valor a las empresas más rápido.

Un enfoque multicloud puede tener sentido, pero las empresas deben asegurarse de que su decisión de adoptar dicho enfoque sea impulsada por las necesidades del negocio y hecha con una comprensión clara de las compensaciones involucradas. En tales casos, recomendamos un modelo de nube enfocado en aplicaciones y flujos de trabajo de negocios que se puedan entregar desde un único CSP, es poco probable que comparta datos entre varios CSPs y tenga un gobierno claro de qué carga de trabajo va a dónde.

Para obtener más información sobre los servicios de AWS que pueden ayudar a centralizar y simplificar la administración y supervisión de entornos híbridos y multicloud, proporcionar acceso a todos sus datos dondequiera que se encuentren almacenados y ejecutar aplicaciones en AWS, on-premise y otras nubes con los servicios de contenedores de AWS, por favor consulte las soluciones de AWS para nube híbrida y multicloud.

 

Este artículo se tradujo del Blog Post de AWS en Inglés.


Acerca de los autores

Tom Godden es un estratega y evangelista de industria en Amazon Web Services (AWS). Antes de AWS, Tom se desempeñó como el CIO (Chief Information Officer) de la Fundación de Medicina donde colaboró para construir la plataforma de investigación del diagnóstico de los genomas del cáncer. Esta plataforma, regulada por la FDA, permitió construir una plataforma de experiencia para mejorar los resultados de la siguiente generación de medicina de precisión. Previamente, Tom se desempeñó en múltiples roles de liderazgo senior en Wolters Kluwer en Alphen aan den Rijn, en Holanda, y posee mas de 17 años de experiencia en las áreas de cuidado de la salud e industrias de ciencias de la vida. Tom tiene un grado de licenciatura de la Universidad Estatal de Arizona, USA.

 

 

 

 

Revisores

Guillermo Fernandez desempeña como el Global Customer Solutions Manager (CSM) en la vertical de Cloud Telco para México, Centro y Sudamérica. Guillermo cuenta con mas de 19 años de experiencia como líder de proyectos y programas en la vertical de telecomunicaciones y servicios.

 

 

 

 

Georgette Martínez es FSI Customer Solutions Manager en AWS de clientes globales de la industria de servicios financieros en México. Tiene más de 8 años de experiencia en el sector Tecnológico liderando programas de adopción de la nube. Adicionalmente, experiencia en el sector de Telecomunicaciones e investigación.