¿Qué es multi-cloud y qué tipos hay?

• Arbitrario: En este caso, la decisión se toma en función de la preferencia del dueño de la empresa o la alta dirección, independientemente de los méritos técnicos o específicos del proveedor.

• Elección: Aquí se realiza un análisis y evaluación exhaustiva de los proveedores para elegir lo mejor de cada uno y optimizar la elección de proveedores de nube.

• Agnóstico: Utilizar tecnologías y soluciones que sean independientes de proveedores específicos, lo que permite una mayor portabilidad y evita la dependencia de un proveedor en particular.

• Paralelo: Mantener copias de aplicaciones o servicios en múltiples proveedores de nube para garantizar la disponibilidad en caso de que uno de los proveedores experimente problemas.

• Segmentado: Dividir componentes o cargas de trabajo de una aplicación en diferentes proveedores de nube según sus fortalezas específicas.

Definición de Multi-Nube: Utilizar más de un proveedor de servicios de nube pública para desplegar una aplicación, plataforma o sistema. Ejemplo: PlatziWallet corriendo en AWS teniendo servicios en GCP. Hay empresas que son multi nube.
++Estrategias de multi nube ++(que puede definir que despliegue determinada parte de la aplicación en la nube A o B):

1. ARBITRARIO: no es una decisión técnica. Puede ser por un convenio ó MSA con el Cloud Provider, decisión de negocios, skills lock-in (los trabajadores saben X plataforma), legal lock-in (contrato por varios años con el CP).
2. ELECCIÓN: seleccionar lo mejor de los mundos que se acomode a nuestro caso de uso. Mirar pros y contra de los CP realizando un estudio.
   Ejemplo: Backend corre en AWS (Kubernetes) y DevOps corre en Azure (despliegue). Estoy tomando lo mejor de los mundos. Puedo tener Vendor Lock-in porque si Azure DevOps lo quiero llevar a AWS tengo que rehacerlo todo prácticamente. Por otro lado, los trabajadores van a tener que saber de AWS y de Azure.
3. AGNÓSTICO: que los servicios de la aplicación puedan ser desplegados fácilmente en todos los Cloud Provider. Ejemplo: desplegar una aplicación usando Open Source en Kubernetes en AWS y hago su réplica en Kubernetes en Azure. Al ser todo Kubernetes y Open Source puedo replicarlo más fácil.
   La limitación Lock-in puede estar dada por los productos específicos de Open Source.
4. PARALELO: Si se me cae una nube que entre otra. Es muy difícil de implementar porque tiene una complejidad técnica muy alta. Porque necesitas personal con conocimiento muy alto en 2 nubes.
   Funciona como un DRP (disaster recovery). Para esto las empresas tienen que definir el RTO y el RPO.
5. SEGMENTADO: Ejemplo: todo nuestro Backend va a correr en Azure pero toda la parte de Data, Analítica y Machine Learning va a correr en GCP. Segmentando cargas de trabajo para que sean ejecutadas en distintos CP. Existe un skill lock-in porque el equipo de data saba GCP y el equipo de backend sabe Azure.

Que es una Multi-Nube

Utilizar mas de un proveedor de servicios de nube pública para desplegar una aplicacion, plataforma o sistema.

Arbitrariedad

- Decision de negocio
- Convenio o MSA
- Skills lock-in
- Legal lock-in

Elección

-  Lo mejor de cada CSP.
- Alto conocimiento en 2 CSP (kubernetes de AWS y Despliege de Azure)
- Buscar lo mejor de ambos mundos para la aplicacion.

Agnóstico

- Uso de open-source.

Paralelo

- Funciona como DRP
- RTO y RPO definidos
- Alta complejidad tecnica
- Alto Conocimiento en 2CSP

Segmentado

- Division de cargas de trabajo. (Backend en aws y AI en gcp)

Cuando se habla de una “nube agnóstica,” se hace referencia a una estrategia o enfoque de tecnología que no depende de un proveedor de nube específico y es compatible con múltiples proveedores de servicios en la nube. Ser “agnóstico” en este contexto significa que una aplicación, servicio o infraestructura está diseñado para funcionar de manera independiente de las características o servicios propios de un proveedor de nube en particular.

Hay varios aspectos en los que una solución o enfoque puede ser agnóstica en la nube:

1. Infraestructura como Código (IaC): El uso de herramientas como Terraform o Ansible para gestionar la infraestructura de manera programática y declarativa. Esto permite definir la infraestructura una vez y desplegarla en diferentes proveedores de nube.

2. Contenedores y Orquestación: Utilizar tecnologías de contenedores como Docker y orquestadores como Kubernetes para crear aplicaciones portátiles que se ejecuten de manera consistente en diferentes entornos de nube.

3. Interfaz de API Estándar: Desarrollar aplicaciones que se comuniquen con servicios en la nube a través de interfaces de programación de aplicaciones (API) estandarizadas y abiertas en lugar de depender de características o API específicas de un proveedor.

4. Políticas y Prácticas de Datos: Implementar políticas y prácticas de datos que sean coherentes y cumplan con regulaciones y estándares de seguridad en diferentes nubes.

5. Portabilidad: Diseñar aplicaciones y servicios de manera que puedan moverse fácilmente de un proveedor de nube a otro sin requerir modificaciones significativas.

La nube agnóstica permite a las organizaciones evitar el bloqueo del proveedor (vendor lock-in) al que a menudo se asocia con la adopción de una plataforma de nube específica. Esto significa que las organizaciones pueden elegir el proveedor de nube que mejor se adapte a sus necesidades sin verse atrapadas en un ecosistema cerrado y pueden migrar aplicaciones y datos con relativa facilidad si es necesario.

Sin embargo, es importante tener en cuenta que, aunque la nube agnóstica ofrece flexibilidad y portabilidad, también puede implicar ciertas limitaciones en términos de aprovechar al máximo las características específicas de un proveedor de nube. La elección entre una estrategia agnóstica en la nube y una estrategia centrada en un proveedor depende de las necesidades y objetivos de cada organización.

La mejor decisión es la que está bien planeada.