Migrar una carga de AWS a Oracle Cloud: el mapeo y las partes que no mapean

Casi todos los servicios tienen su equivalente y la traducción es mecánica. Tres cosas no lo son, y deciden si la migración merece la pena siquiera.

La pregunta rara vez es "¿deberíamos mover todo?". Es "esta carga es cara en AWS por un motivo que entendemos, ¿tiene sentido moverla?". Es una buena pregunta y tiene una respuesta estructurada.

El mapeo mecánico

Para la mayor parte de una carga estándar hay un equivalente:

AWS OCI
EC2 Compute (formas flexibles)
VPC, subredes, grupos de seguridad VCN, subredes, NSG
Transit Gateway Dynamic Routing Gateway
S3 Object Storage
EBS Block Volume
EFS File Storage
RDS PostgreSQL / MySQL Database with PostgreSQL / MySQL HeatWave
EKS OKE
Lambda Functions
CloudWatch Monitoring y Logging
Roles IAM, perfiles de instancia Políticas, grupos dinámicos, principales de instancia
KMS, Secrets Manager Vault
Route 53 DNS
CloudFront un socio de CDN, que es una carencia real

Para cargas en contenedores y sin estado, este mapeo es casi completo y la migración es en gran medida un ejercicio de pipeline y de red. Construye para la arquitectura correcta, publica en OCI Registry, despliega en OKE, apunta el DNS.

Las tres cosas que no mapean

La identidad es un modelo distinto. AWS son políticas JSON enganchadas a principales; OCI son sentencias escritas contra compartimentos y grupos. No hay traducción automática y no deberías intentarla — reescribe las políticas desde la intención, usando el verbo más pequeño que funcione y grupos dinámicos para las cargas. El artículo de políticas de OCI cubre las trampas. Reserva tiempo real para esto; es la parte que más subestiman los equipos.

El catálogo de servicios gestionados es más pequeño. Si tu carga se apoya en un servicio gestionado concreto de AWS —Step Functions, Kinesis, DynamoDB con un patrón de acceso particular, un servicio analítico de nicho— comprueba el equivalente con cuidado antes de comprometerte. A veces existe, a veces hay un equivalente autogestionado que ahora operas tú, y a veces la respuesta honesta es que esa carga se queda.

Regiones y dominios de disponibilidad. Menos regiones, y varias tienen un único dominio de disponibilidad donde AWS te daría tres zonas. Los dominios de fallo dentro de un AD protegen frente a fallos de hardware y mantenimiento, no frente a un evento a nivel de AD. Si tu objetivo de disponibilidad supone tres zonas independientes, verifica la región destino antes de diseñar.

El orden que funciona

  1. Elige una carga con un motivo. Salida de datos alta, cómputo amigable con ARM o una posición de licencias de Oracle — los casos donde el modelo de coste de OCI de verdad difiere. Una carga sin motivo específico para moverse no debería moverse.
  2. Construye la landing zone primero. Compartimentos, políticas, espacios de nombres de etiquetas, VCN, logging, Cloud Guard. Dos semanas, y la migración aterriza sobre algo en vez de al lado.
  3. Establece la conectividad pronto. La VPN sitio a sitio sobre el DRG es rápida; FastConnect tiene un plazo de semanas. Si la migración necesita ancho de banda dedicado, pídelo antes que nada.
  4. Mueve los datos primero y mantenlos sincronizados. Object Storage tiene API compatible con S3 y admite transferencia masiva; las bases de datos usan su replicación nativa o un servicio de migración con replicación continua. Llega a un régimen estable donde el destino esté continuamente al día.
  5. Ejecuta ambos en paralelo con el tráfico repartido. Un porcentaje del tráfico de producción a la pila de OCI, observado una semana. Aquí es donde encuentras la sorpresa de latencia, la regla de NSG que falta y la consulta que se degradó.
  6. Corta por DNS y conserva el origen quince días. El plan de vuelta atrás es reapuntar, y solo existe mientras el origen siga vivo.
  7. Da de baja a propósito, incluidos el circuito de FastConnect y el peering que montaste para la migración, que si no facturan para siempre.

Qué medir antes y después

Latencia p99 desde ubicaciones reales de clientes, coste por unidad de trabajo (no por hora de instancia), GB de salida y tasa de error. Publica las cifras de antes antes de empezar, para que las de después signifiquen algo. Una migración que mejora la factura y degrada el p99 en silencio no es un éxito, y sin la base de referencia nadie puede saberlo.

El resumen honesto

Las migraciones dirigidas funcionan. Las masivas normalmente no se pagan solas salvo que haya un motivo de licencias o contractual detrás. El patrón que más recomendamos es un entorno repartido: la carga intensiva en salida o con licencia Oracle en OCI, el resto donde está, con un camino de red claro entre ambos.

Eso es una arquitectura legítima, no una falta de compromiso, y es el motivo de que nuestro trabajo cloud abarque los cuatro proveedores — y de que Skyline dibuje el entorno actual en todos ellos antes de que nadie discuta dónde deberían vivir las cosas.

Qué hacer esta semana

Elige la carga que más sospechas que sería más barata en OCI y escribe por qué en una frase. Si la frase habla de salida de datos, cómputo ARM o una licencia de Oracle, modélalo bien. Si no puedes escribir la frase, esa carga no es candidata a migrar.

ConsultorIA

¿Quieres esto en tu nube?

El diagnóstico de diez días en solo lectura es gratuito, y con Skyline puedes ver tu entorno en un mapa antes de escribirnos.

Artículos relacionados

Módulos que la gente reutiliza en vez de copiar

Los dos fracasos son un módulo que envuelve un recurso y no aporta nada, y un módulo que lo hace todo y que nadie se atreve a cambiar. Una interfaz mínima, valores por defecto seguros y un versionado honesto son lo que los separa.