Cuando una aplicación deja de responder, uno de los primeros diagnósticos suele ser: «es un problema de DNS». En muchas ocasiones lo es, pero otras veces el verdadero problema está en el sistema de Service Discovery. Aunque ambos mecanismos ayudan a localizar recursos en una red, cumplen funciones muy distintas y trabajan en niveles diferentes de la infraestructura.
La llegada de Kubernetes, Docker, los microservicios y el cloud nativo ha hecho que ambos conceptos convivan constantemente, provocando una confusión habitual incluso entre administradores de sistemas con experiencia. La realidad es que DNS y Service Discovery no compiten entre sí; se complementan.
Las claves de DNS y Service Discovery en 20 segundos
- DNS traduce nombres de dominio en direcciones IP para localizar servidores.
- Service Discovery permite que unas aplicaciones encuentren automáticamente otras aplicaciones.
- Los entornos cloud cambian continuamente de IP, por lo que el DNS tradicional resulta insuficiente.
- Kubernetes combina ambos mecanismos para ofrecer una infraestructura dinámica y resiliente.
Si el artículo anterior sobre CDN y caché explicaba cómo acelerar el acceso al contenido, DNS y Service Discovery resuelven otro problema: cómo localizar correctamente los servicios cuando la infraestructura cambia constantemente.
DNS: el directorio telefónico de Internet
El Domain Name System (DNS) existe desde los primeros años de Internet y continúa siendo uno de sus pilares fundamentales.
Su función consiste en convertir nombres fáciles de recordar, como:
- google.com
- github.com
- stackoverflow.com
en las direcciones IP que realmente utilizan los ordenadores para comunicarse.
Por ejemplo, cuando un usuario escribe:
www.example.comsu equipo pregunta al servidor DNS cuál es la dirección IP asociada.
La respuesta podría ser:
203.0.113.10A partir de ese momento, el navegador ya sabe dónde debe enviar la petición.
Todo este proceso suele completarse en apenas unos milisegundos y resulta prácticamente transparente para el usuario.
Sin DNS sería necesario memorizar la dirección IP de cada página web que visitamos.
El problema: las aplicaciones modernas ya no son servidores estáticos
Durante muchos años los servidores apenas cambiaban.
Una empresa instalaba un servidor físico o una máquina virtual y mantenía la misma dirección IP durante meses o incluso años.
En ese escenario, DNS funcionaba perfectamente.
Pero la arquitectura moderna es completamente distinta.
Hoy una aplicación puede estar formada por decenas o cientos de pequeños servicios independientes.
Cada uno de ellos puede ejecutarse en:
- Contenedores Docker.
- Pods de Kubernetes.
- Máquinas virtuales.
- Funciones serverless.
- Instancias cloud que aparecen y desaparecen automáticamente.
En este entorno las direcciones IP cambian constantemente.
Es aquí donde aparece Service Discovery.
Qué es Service Discovery
Service Discovery permite que una aplicación encuentre automáticamente otra aplicación sin conocer previamente su dirección IP.
En lugar de preguntar:
¿Dónde está 10.25.17.84?pregunta:
¿Dónde está Payment Service?El sistema devuelve la instancia disponible en ese momento.
Así, si un contenedor desaparece y Kubernetes crea otro con una IP completamente distinta, el resto de servicios continúa funcionando sin modificar una sola línea de configuración.
Las aplicaciones únicamente conocen el nombre lógico del servicio.
El sistema de descubrimiento se ocupa del resto.
Un ejemplo sencillo
Imaginemos una tienda online basada en microservicios.
Está formada por:
- User Service
- Product Service
- Order Service
- Payment Service
- Notification Service
Cuando un cliente realiza una compra, el servicio de pedidos necesita comunicarse con el servicio de pagos.
Si utilizara directamente una dirección IP, cualquier reinicio del contenedor rompería la comunicación.
Ayer:
Payment Service
192.168.10.25Después de reiniciar:
Payment Service
192.168.10.61La IP ha cambiado.
Sin Service Discovery habría que actualizar manualmente todas las aplicaciones que utilizan ese servicio.
Con Service Discovery basta con preguntar:
¿Dónde está Payment Service?El sistema responde automáticamente con la nueva ubicación.
Para la aplicación nada ha cambiado.
Kubernetes automatiza todo el proceso
Kubernetes incorpora Service Discovery de forma nativa.
Cuando se crea un recurso Service, automáticamente genera un nombre DNS interno como:
payment-service.default.svc.cluster.localLas aplicaciones simplemente realizan sus peticiones utilizando:
http://payment-serviceNo necesitan conocer:
- cuántos Pods existen,
- qué direcciones IP tienen,
- cuál acaba de reiniciarse,
- cuál ha sido sustituido.
Kubernetes mantiene actualizada toda esa información automáticamente.
Si un Pod falla, el tráfico pasa a otro disponible sin que la aplicación cliente tenga que modificar nada.
Esta combinación entre DNS interno y Service Discovery es uno de los pilares de Kubernetes.
DNS y Service Discovery resuelven problemas distintos
Aunque ambos ayudan a localizar recursos, trabajan en niveles diferentes.
| DNS | Service Discovery |
|---|---|
| Localiza servidores. | Localiza aplicaciones o servicios. |
| Traduce nombres de dominio a IP. | Encuentra automáticamente instancias disponibles. |
| Pensado para infraestructura relativamente estable. | Diseñado para entornos dinámicos y cloud native. |
| Utilizado por usuarios y aplicaciones externas. | Utilizado principalmente entre microservicios. |
| Cambia con poca frecuencia. | Se actualiza continuamente. |
La diferencia puede resumirse así:
DNS ayuda a las personas a encontrar servidores.
Service Discovery ayuda a las aplicaciones a encontrarse entre ellas.
Un ejemplo real: Netflix
Cuando un usuario escribe:
www.netflix.comel primer paso consiste en resolver ese dominio mediante DNS.
Una vez que la petición llega a la infraestructura de Netflix comienza otro proceso completamente diferente.
Decenas de servicios internos empiezan a comunicarse entre sí:
- autenticación,
- perfiles,
- recomendaciones,
- catálogo,
- facturación,
- reproducción,
- monitorización.
Estos componentes no suelen utilizar nombres públicos.
En su lugar emplean sistemas de Service Discovery para localizar en tiempo real las instancias disponibles de cada microservicio.
Para el usuario todo parece una única aplicación.
Internamente pueden estar interviniendo cientos de servicios distribuidos en múltiples centros de datos.
Service Discovery no sustituye al DNS
Una idea equivocada bastante extendida consiste en pensar que Kubernetes ha sustituido al DNS tradicional.
No es cierto.
Lo que hace Kubernetes es utilizar DNS como mecanismo para implementar parte del Service Discovery interno.
De hecho, ambos trabajan conjuntamente.
El flujo habitual es:
- El usuario utiliza DNS para localizar la aplicación.
- La petición llega al clúster.
- Dentro del clúster, los microservicios utilizan Service Discovery para encontrarse entre sí.
- Kubernetes actualiza automáticamente las rutas cuando aparecen o desaparecen nuevas instancias.
La infraestructura cloud necesita los dos
Las aplicaciones modernas ya no funcionan sobre unos pocos servidores estáticos.
La escalabilidad automática, los despliegues continuos, los contenedores y la orquestación hacen que las direcciones IP cambien constantemente.
DNS sigue siendo imprescindible para acceder a aplicaciones y servicios desde Internet.
Service Discovery permite que esas aplicaciones continúen funcionando correctamente aunque la infraestructura cambie cientos de veces al día.
Por eso tecnologías como Kubernetes, Consul, Istio, Linkerd o AWS Cloud Map incorporan mecanismos avanzados de descubrimiento de servicios.
No sustituyen al DNS.
Lo complementan.
En la práctica, cualquier arquitectura cloud nativa moderna necesita ambos mecanismos trabajando conjuntamente para ofrecer alta disponibilidad, escalabilidad y resiliencia.
Preguntas frecuentes
¿DNS y Service Discovery son lo mismo?
No. DNS traduce nombres de dominio en direcciones IP, mientras que Service Discovery permite localizar automáticamente aplicaciones o microservicios cuya ubicación puede cambiar continuamente.
¿Por qué Kubernetes utiliza ambos?
Porque DNS facilita nombres estables para acceder a los servicios, mientras que Kubernetes actualiza automáticamente qué Pods saludables responden detrás de cada uno de esos nombres.
¿Puede funcionar una aplicación solo con DNS?
Sí, especialmente en infraestructuras tradicionales donde las direcciones IP apenas cambian. En arquitecturas basadas en microservicios resulta mucho más difícil mantener esa configuración manualmente.
¿Qué soluciones de Service Discovery existen además de Kubernetes?
Entre las más conocidas se encuentran HashiCorp Consul, AWS Cloud Map, Eureka de Netflix y los mecanismos integrados en plataformas como Kubernetes o OpenShift.
