Desplegar una nueva versión sin tirar nada. Migrar servicios por partes. Probar en producción con un subconjunto real de usuarios. Todo esto se puede hacer desde la CDN, sin tocar el DNS, sin esperar propagaciones de TTL y sin el estrés de coordinar planes de emergencia entre equipos.
La configuración multiorigen de Transparent Edge permite asignar distintos backends según cualquier elemento de la petición HTTP: la URL, una cookie, una cabecera. El VCL permite ajustar las reglas de enrutado con gran precisión, se despliega en segundos y se puede revertir igual de rápido.
Qué es multiorigen y cómo funciona
En una configuración estándar, un dominio apunta a un solo backend. En multiorigen, la CDN decide a qué backend enviar cada petición antes de que llegue al origen. La decisión puede depender de cualquier elemento visible en la request: la ruta, una cabecera de negociación de contenido, una cookie de sesión, el país del usuario, la versión del cliente y más.
El mecanismo es directo: en 'vcl_recv' se establece 'req.backend_hint' con el backend destino. Se declaran los backends necesarios en el dashboard y se referencian desde el VCL.
sub vcl_recv {
# Backend por defecto
set req.backend_hint = c83_monolito.backend();
# El blog va a otro servidor
if (req.url ~ "^/blog") {
set req.backend_hint = c83_blog.backend();
}
}
La petición llega al CDN, el VCL la evalúa y la reenvía al backend correcto. El DNS no participa en ese proceso. El cambio se aplica en segundos.
Migrar el monolito ruta a ruta por URL
El caso más frecuente en arquitecturas en transición es el siguiente: hay un monolito que lo gestiona todo y un equipo extrayendo servicios poco a poco. El nuevo microservicio está listo, pero la validación en producción requiere tráfico real. Con un cambio de DNS eso es arriesgado; con multiorigen, es seguro.
Se configura el nuevo servicio como un backend en Transparent Edge y se enruta hacia él por prefijo de URL:
sub vcl_recv {
set req.backend_hint = c83_monolito.backend();
# Las rutas de la API de pedidos van al nuevo microservicio
if (req.url ~ "^/api/orders") {
set req.backend_hint = c83_orders_service.backend();
}
}
El usuario no nota nada. El DNS no cambia. Si algo falla, revertir el VCL tarda minutos. El monolito sigue respondiendo el resto mientras el equipo trabaja en paralelo.
El patrón es compatible con una extracción gradual: primero ‘/api/orders‘, luego ‘/api/products‘, luego ‘/api/users‘. Cada ruta migrada se valida de forma independiente antes de pasar a la siguiente.
Despliegues controlados por cookies
El despliegue blue/green mantiene dos entornos idénticos corriendo a la vez, uno activo y uno en espera. Conmutar el tráfico entre ellos, con multiorigen, es un cambio de VCL. Sin DNS, sin ventana de mantenimiento.
El canary deployment va un paso más allá y envía solo una fracción del tráfico al entorno nuevo antes de abrir del todo. La cookie permite hacerlo con control preciso. Los usuarios que tienen una cookie concreta van al backend nuevo; el resto sigue en el actual.
sub vcl_recv {
set req.backend_hint = c83_blue.backend();
# Los usuarios con la cookie de canary van al entorno green
if (req.http.Cookie ~ "deployment=green") {
set req.backend_hint = c83_green.backend();
}
}
En la práctica, el equipo de QA o los beta testers reciben esa cookie. El tráfico de producción no se ve afectado. Cuando la validación es satisfactoria, se cambia el VCL para que todos vayan al entorno green. La conmutación es instantánea.
El mismo mecanismo sirve para despliegues progresivos basados en segmentos de usuario: clientes enterprise, usuarios de un plan concreto, sesiones iniciadas en una fecha determinada. Si la información está en una cookie, la CDN puede tomar la decisión.
La cabecera como señal de enrutado
Los headers dan un control más explícito, especialmente útil cuando el cliente es un servicio interno, un pipeline de CI/CD o una herramienta de QA que puede construir la petición con cabeceras personalizadas.
sub vcl_recv {
set req.backend_hint = c83_produccion.backend();
# Las peticiones internas con el header de staging van al entorno de pruebas
if (req.http.X-Target-Env == "staging") {
set req.backend_hint = c83_staging.backend();
}
}
Con este patrón, un pipeline de CI puede lanzar pruebas de integración contra el dominio de producción real (misma URL, mismo certificado TLS, misma CDN) pero enrutados a un backend de entorno de pruebas. El usuario final nunca ve esas peticiones. El equipo prueba contra la infraestructura real, no contra un entorno paralelo que siempre tiene alguna diferencia.
Este esquema también es útil en arquitecturas multiregión: la cabecera indica la región de origen del cliente, y el VCL selecciona el backend correspondiente sin necesidad de subdominios separados ni registros DNS adicionales.
Lo que cambia en la práctica
Multiorigen convierte el CDN en una capa de enrutado que opera antes de que las peticiones lleguen a ningún servidor de aplicaciones.
Las consecuencias son concretas:
- Los despliegues blue/green dejan de depender de la propagación del DNS.
- Las migraciones de monolito a microservicios se hacen ruta a ruta, con tráfico real y rollback en segundos.
- Los entornos de prueba pueden usar el dominio de producción sin infraestructura adicional.
El modelo de configuración es declarativo. Se escribe VCL, se aplica, y Transparent Edge lo distribuye en los nodos edge. Si algo falla, la reversión usa la misma operación. El proceso completo, de cambio a validación, cabe en el tiempo de una reunión de equipo.
Para generar los snippets de VCL adaptados a tu configuración, ve al Easy Setup en tu panel de control y te guiará paso a paso. Si tienes dudas sobre el enrutado o necesitas ayuda con un caso concreto, el equipo de soporte de Transparent Edge está disponible para acompañarte.
Documentación de referencia:
Sonia Arévalo es Product Marketing Manager en Transparent Edge.
Cómo acabó una Analista de Sistemas estudiando Tecnología de los Alimentos es complicado de explicar. Si le añades que luego decidió dedicarse al Marketing Digital, ya es un enigma completo que esta chica haga tantas cosas bien. Más argentina que el asado, Sonia mantiene nuestra web y redes sociales traduciendo el
élficolenguaje técnico a algo asimilable para la gente normal. “Exselente” es su interjección favorita, que hace juego con su trabajo.
