Megaport: hacia una nueva forma de entender la conectividad entre centros de datos y la nube

Durante muchos años, interconectar centros de datos, acceder a proveedores cloud o contratar conectividad privada entre distintas ubicaciones ha significado desplegar circuitos dedicados, negociar contratos independientes y esperar los correspondientes plazos de provisión.

Pero existe otra manera de abordar el problema: contratar acceso a una plataforma de interconexión y utilizarla para construir múltiples servicios de conectividad bajo demanda.

Este es el planteamiento de Megaport, una plataforma de Network as a Service (NaaS) que permite crear conexiones virtuales entre centros de datos, proveedores cloud y otros servicios de red.

Su interés no reside únicamente en transportar tráfico entre dos puntos. Lo verdaderamente atractivo es la posibilidad de convertir una conexión física en una infraestructura de comunicaciones flexible y reutilizable.

1. Del circuito dedicado a la interconexión como servicio

En un modelo tradicional, una empresa puede necesitar diferentes servicios de conectividad:

• Un enlace privado entre dos centros de datos.
• Conectividad con un proveedor cloud.
• Acceso a una segunda plataforma cloud.
• Intercambio de tráfico con otras redes.
• Conexiones temporales para migraciones o proyectos específicos.

Cada necesidad puede terminar convirtiéndose en un circuito distinto, con su propia contratación, instalación y gestión.

Megaport propone separar dos conceptos: el acceso físico a la plataforma y las conexiones virtuales que utilizamos sobre ella.

El acceso se realiza mediante un puerto físico, denominado Megaport Port, instalado en una ubicación donde el servicio esté disponible.

Sobre ese puerto pueden aprovisionarse conexiones virtuales, conocidas como Virtual Cross Connects (VXC), que permiten interconectar distintos extremos.

flowchart TB
    A["Red corporativa"] --> P["Puerto Megaport"]
    P --> F["Megaport Network Fabric"]

    F --> D["Otro centro de datos"]
    F --> C1["Proveedor cloud A"]
    F --> C2["Proveedor cloud B"]
    F --> I["Otros servicios de interconexión"]

La diferencia conceptual es importante: el puerto físico deja de estar vinculado a una única finalidad.

Una misma infraestructura de acceso puede servir para construir distintas conexiones, siempre dentro de sus límites de capacidad y de las condiciones técnicas y comerciales de cada servicio.

2. Los componentes principales de Megaport

Megaport Port: la puerta de entrada

El puerto es la conexión física entre nuestra infraestructura y la red de Megaport.

Puede contratarse con distintas capacidades, según la disponibilidad de la ubicación y la oferta vigente.

Por ejemplo, un puerto de 10 Gbps permite disponer de una capacidad física de acceso que puede distribuirse entre diferentes conexiones virtuales.

Eso no significa que cada conexión disponga automáticamente de 10 Gbps independientes. La capacidad agregada sigue estando limitada por el puerto físico y por la configuración de los servicios contratados.

VXC: conexiones virtuales entre extremos

Las VXC permiten establecer conectividad privada entre puntos compatibles de la plataforma.

Desde el punto de vista arquitectónico, resultan especialmente interesantes para transportar tráfico de capa 2 entre infraestructuras situadas en distintas ubicaciones.

Sobre esa conectividad podemos desplegar nuestros propios protocolos y políticas de red, incluyendo enrutamiento IP y sesiones BGP cuando el diseño de los extremos lo permita.

Es importante distinguir el transporte del enrutamiento: una VXC no sustituye automáticamente a nuestros routers ni a nuestra arquitectura de routing.

Megaport Cloud Router (MCR)

Megaport también dispone de un servicio de enrutamiento virtual gestionado, denominado Megaport Cloud Router.

Este servicio permite construir escenarios de conectividad de capa 3 sin desplegar necesariamente un router físico propio en cada punto de interconexión.

Puede resultar especialmente útil para conectar distintas plataformas cloud o interconectar servicios que necesitan intercambiar rutas.

Sin embargo, no siempre será necesario.

Si ya disponemos de routers de frontera y una arquitectura BGP consolidada, puede ser más conveniente mantener el control del enrutamiento en nuestros propios equipos y utilizar Megaport principalmente como transporte.

MegaIX y conectividad con otras redes

La plataforma también ofrece posibilidades de interconexión mediante servicios como MegaIX, orientados al intercambio de tráfico entre redes participantes.

Estos servicios abren oportunidades adicionales para arquitecturas que utilizan sistemas autónomos propios y necesitan optimizar sus relaciones de conectividad.

Su utilidad concreta dependerá de los participantes disponibles, la ubicación y las condiciones de cada servicio.

3. Una arquitectura de interconexión entre centros de datos

Imaginemos una organización con dos centros de datos, uno principal y otro secundario.

En un planteamiento convencional, podría contratar un enlace dedicado entre ambos.

Con una plataforma de interconexión, podemos utilizar un puerto en cada ubicación y crear una conexión virtual entre ellos.

Pero esos mismos puertos podrían aprovecharse posteriormente para acceder a servicios cloud o ampliar la conectividad.

flowchart LR
    subgraph DC1["Centro de datos A"]
        R1["Router de frontera"]
        P1["Puerto Megaport"]
        R1 --- P1
    end

    subgraph FABRIC["Megaport Fabric"]
        VXC["VXC privada"]
    end

    subgraph DC2["Centro de datos B"]
        P2["Puerto Megaport"]
        R2["Router de frontera"]
        P2 --- R2
    end

    P1 --- VXC
    VXC --- P2

    P1 -.-> CLOUD["Servicios cloud"]
    P2 -.-> OTHER["Otras interconexiones"]

La principal ventaja no es necesariamente el ahorro económico de un enlace concreto.

Es la posibilidad de convertir la infraestructura de interconexión entre centros de datos en una plataforma multipropósito.

Esto resulta especialmente interesante cuando una organización prevé evolucionar hacia arquitecturas híbridas, estrategias multicloud o nuevos escenarios de recuperación ante desastres.

4. Los puntos fuertes del modelo

Flexibilidad

La creación de conexiones virtuales permite adaptar la topología a nuevas necesidades sin tener que desplegar necesariamente un nuevo acceso físico para cada servicio.

Esto puede simplificar proyectos de migración, ampliaciones y cambios de arquitectura.

Aprovisionamiento y automatización

Uno de los aspectos más interesantes de este modelo es la gestión mediante portal y API.

La conectividad empieza a parecerse a otros recursos de infraestructura definidos mediante software.

Esto permite plantear integraciones con herramientas de automatización, sistemas de provisión y procesos de infraestructura como código.

Conectividad híbrida y multicloud

Disponer de acceso a una plataforma de interconexión facilita construir conexiones privadas hacia proveedores cloud compatibles.

Es especialmente interesante para organizaciones que mantienen sistemas locales, pero necesitan utilizar servicios cloud de manera permanente o durante determinados periodos.

Evolución de la recuperación ante desastres

Una infraestructura flexible de interconexión puede facilitar escenarios de replicación, migración y recuperación entre ubicaciones.

No obstante, disponer de conectividad no equivale por sí mismo a disponer de una arquitectura de recuperación ante desastres.

La estrategia debe contemplar también almacenamiento, consistencia de datos, orquestación, capacidad de recuperación y procedimientos operativos.

Posibilidad de crecimiento

Una organización puede comenzar utilizando la plataforma para una necesidad concreta y ampliar posteriormente sus servicios.

Esta capacidad de evolución es uno de los elementos que diferencian una plataforma de interconexión de un circuito contratado para una única finalidad.

5. Lo que Megaport no sustituye

Es importante evitar una interpretación excesivamente optimista de estas plataformas.

Megaport no elimina la necesidad de diseñar correctamente la red.

Tampoco sustituye automáticamente todos los servicios de un operador de telecomunicaciones.

El acceso local sigue siendo fundamental. Para utilizar la plataforma necesitamos conectividad hasta un punto donde esté disponible.

Esto es especialmente relevante para sedes remotas o ubicaciones internacionales sin presencia próxima de la plataforma.

En esos escenarios puede ser necesario combinar distintos modelos:

• Conectividad privada donde exista disponibilidad.

• Acceso mediante operadores locales.

• VPN o SD-WAN sobre Internet.

• Soluciones híbridas que combinen varios transportes.

Además, la conectividad de capa 2 no resuelve por sí misma cuestiones como el enrutamiento, la seguridad, la segmentación o la alta disponibilidad.

6. BGP, redundancia y dominios de fallo

Desde una perspectiva de ingeniería de redes, uno de los puntos más importantes es distinguir flexibilidad de conectividad y redundancia real.

Disponer de varias VXC sobre un mismo puerto no significa disponer de varios caminos físicos independientes.

Si todas las conexiones dependen del mismo puerto, un fallo de ese puerto puede afectar a todas ellas.

De forma similar, dos puertos distintos no garantizan por sí solos diversidad completa si comparten elementos críticos de infraestructura.

Por ello, antes de diseñar una solución de alta disponibilidad, debemos analizar:

• La diversidad física de los accesos.

• Los equipos y rutas compartidos.

• Los dominios de fallo de la plataforma.

• Los mecanismos de detección y recuperación.

• Las condiciones de servicio y los acuerdos de nivel de servicio.

• La arquitectura de routing y sus políticas de convergencia.

En redes con BGP, las conexiones virtuales pueden actuar como transporte para sesiones de enrutamiento independientes, pero la política de rutas y el comportamiento ante fallos siguen siendo responsabilidad del diseño global.

También conviene evitar extender innecesariamente dominios de capa 2 entre centros de datos. Cuando sea posible, las arquitecturas de capa 3 suelen ofrecer límites operativos más claros y un comportamiento más predecible ante incidencias.

7. El papel de SD-WAN

Otro ámbito de interés es la relación entre las plataformas de interconexión y las arquitecturas SD-WAN.

No todas las ubicaciones necesitan, o pueden disponer, de conectividad privada directa a una plataforma como Megaport.

Una arquitectura híbrida puede combinar enlaces privados de alta capacidad en ubicaciones estratégicas con soluciones SD-WAN para otras sedes.

En este contexto, conviene distinguir entre la red privada de interconexión, los servicios específicos de acceso SD-WAN y los túneles establecidos sobre Internet.

No son tecnologías equivalentes, aunque pueden formar parte de una misma arquitectura.

La elección dependerá de factores como la cobertura geográfica, la latencia, los requisitos de seguridad, la disponibilidad y los costes.

8. ¿Qué debemos evaluar antes de contratar?

Más allá de las posibilidades comerciales, cualquier proyecto debería comenzar con una validación técnica y económica.

Entre los aspectos que consideramos fundamentales están la disponibilidad real en las ubicaciones deseadas, la capacidad de los puertos, los límites de las conexiones virtuales, las MTU soportadas, los mecanismos de redundancia y las condiciones de operación.

También es importante estudiar el modelo económico completo.

El coste puede incluir puertos físicos, conexiones virtuales, servicios de enrutamiento, accesos locales y otros conceptos.

Por tanto, no es correcto comparar únicamente el precio de una VXC con el de un circuito dedicado sin considerar todos los componentes necesarios para prestar el servicio.

Finalmente, merece especial atención la automatización: disponer de una API es interesante, pero su verdadero valor aparece cuando se integra con los procesos de operación y gestión de cambios de la organización.

9. Nuestra valoración

En Merática consideramos especialmente interesante la evolución hacia modelos de conectividad programable.

Durante años, las redes empresariales han avanzado en automatización, virtualización y gestión centralizada, mientras que una parte importante de la conectividad entre ubicaciones ha seguido dependiendo de circuitos relativamente rígidos.

Plataformas como Megaport representan un cambio de enfoque: la conectividad puede empezar a gestionarse como un recurso de infraestructura, con mayor flexibilidad para adaptarse a las necesidades del negocio.

Su mayor potencial aparece cuando dejamos de pensar en sustituir un circuito por otro y empezamos a pensar en construir una plataforma de interconexión reutilizable.

Eso sí, la flexibilidad no sustituye a la ingeniería.

Seguimos necesitando una arquitectura de red sólida, una estrategia de seguridad adecuada, un diseño de redundancia verificable y un conocimiento preciso de los límites de cada servicio.

La conectividad como servicio no elimina esos requisitos. Nos proporciona nuevas herramientas para abordarlos.

En Merática trabajamos en el diseño, integración y operación de redes empresariales, conectividad entre centros de datos y arquitecturas híbridas. Nuestro enfoque combina las posibilidades de las nuevas plataformas con los principios clásicos de ingeniería de redes: simplicidad, control, seguridad y resiliencia.