2

We have microservices in separate machines that currently use IP addresses in their configuration to communicate via REST APIs. There are also domain names defined for these machines.

Is it a good practice to use IP address for communication or domain names should be used in case IP addresses change?

What are the pros and cons between them?

Improve this question
2
  • 1
    Could you explain what you think the advantage of using IP addresses might be?
    – Philip Kendall
    Nov 13, 2021 at 17:29
  • I actually just use them since I always used them, not for any advantage. If anything comes to mind maybe if dns is down or dns resolution time overhead? I would otherwise will prefer domain names but would like to know what are the preference in general. I reworded the question to reflect this, thank you.
    – Cemre
    Nov 13, 2021 at 17:35

3 Answers 3

Reset to default
8

I'd use DNS.

As long as these IP addresses are on a private subnet where you manage IP address allocation, using IP addresses is perfectly fine. They won't randomly change – you are assigning addresses.

However, IP addresses might be difficult to remember. It is not obvious to which service a given address relates. This raises the risk of misconfiguration when deploying or maintaining your system.

DNS is very good because DNS lets you give nice mnemnonic names for your services. You can have db.invoicing-service.cluster2.internal.example.com. That's better than 10.0.37.129. And while it's probably not relevant here, using domain names make it possible to deploy multiple HTTP services on the same machine.

Many tools for managing services have DNS built-in, for example Kubernetes.

Drawbacks of using DNS is that this introduces additional complexity that can be misconfigured as well. Too often, the question is it DNS? has to be answered with “yes”. Especially fun is stale data in the DNS database, for example when a service is shut down but the DNS entry remains. In a comment you voice concern about extra latency due to DNS requests but that is typically not a problem within a data centre, especially as DNS results are cached locally.

Improve this answer
6
  • Thank you, we don't use kubernetes yet but I read that the IP address change during scale up/down so people go with domain names
    – Cemre
    Nov 13, 2021 at 17:38
  • 2
    @Cemre Exactly, when using cluster management tools and especially with auto-scaling, you have no guarantees about on which host a service will run. That's not actually a point against IP addresses, as each host can dynamically change which IP addresses it listens to. But it's typically easier to let IP addresses be assigned automatically e.g. via DHCP and use DNS for service discovery.
    – amon
    Nov 13, 2021 at 17:42
  • "using domain names make it possible to deploy multiple HTTP services on the same machine." could you please elaborate on this a little bit if you dont mind? We currently have different ports for different services on the same machine so how does it improve the situation?
    – Cemre
    Nov 13, 2021 at 17:50
  • 2
    @Cemre different ports work just as well though you now have to manage port numbers in addition to IP addresses. When sending HTTP requests to a domain name, the request contains the Host header. A webserver or reverse proxy can look at that header to decide how to handle the request. Such virtual hosts / vhosts are easy to configure when using Nginx as a reverse proxy. It's not something you have to do when you're on a private network, but it is a pretty common configuration.
    – amon
    Nov 13, 2021 at 18:04
  • 1
    Using DNS also makes upgrading the server easier. The new (replacement) server can be installed and tested, then the DNS entry updated. The old server can be shutdown once all the traffic is talking to the new one. If you use IP addresses you either have to update the configs for all the microservices, or stop the current server, then update the new one with the old IP address.
    – 1201ProgramAlarm
    Nov 13, 2021 at 18:10
3

IP addresses are subject to change, DNS names change far less frequently.

The only "advantage" of using an IP address directly is that you're not needing to do a DNS lookup, which would be very quick from a local cache anyway after the first request.

IP addresses as stated already tend to also be harder to remember (though some companies have extremely cumbersome schemes for their internal DNS nomenclature, which doesn't help).

Improve this answer
-2

Everyone is focussed on DNS vs IP when the real question is about microservice architecture intercommunication

I.e. there's no public internet addressing

Ergo you may never need a DNS record to have microservices communicate because they may reside within the same domain so forcing DNS where it isn't needed will add unnecessary complexity.

Microservices commonly communicate over local IP address ranges if they even leave the host. Many answers include containers in thier answers meaning the communication may never even leave a server host (never traverse a network cable) Even a Kubernetes node with many pods fits this description, and DNS is completely optional in Kubernetes contrary to the other answers.

Needless to say that even when communicating over an actual network occurs, it may never traverse the internet.

Even when DNS is used, regardless of the networking situation, there's little benefit of a DNS record if server IP addresses are static.

So ask yourself is the server static?

Do the microservices communicate over a network?

Over the internet?

Is the DNS record management routed over the internet?

Should the microservice be reachable using the public internet reachable DNS records?

Are the DNS records managed on an internal DNS resolver? If the microservices must remain inaccessible from the internet this is a requirement for DNS to be an option

And using DNS isn't required for multiple services using a single IP, that's just a lack of understanding in other answers. Kubernetes node is a single host, 1 IP, and many pods can respond from that 1 host and single IP even when not using DNS because containers are addressible using network overlays (similar concept to the NAT router you have at home allows many devices to work behind your 1 IP address given to you by the ISP)

There's also the concept of SNI in the TLS communication that will help you run many services behind a single IP, because TLS is using TCI/IP it is already unaware of DNS and yet it works (due to SNI, not DNS).

Service meshes and reverse proxy (like a load balancer) are other options that sometimes ise DNS but can also work with URL paths on the same single IP address or single domain but many microservices behind it

Improve this answer
12
  • 1
    so you are arguing that myservice.domain.com is worse than 10.0.x.y:1234 ?
    – Ewan
    Nov 14, 2021 at 12:10
  • @Ewan I specifically started my answer by stating others are comparing DNS vs IP and my answer is NOT doing that. My answer is quite detailed, your question is not. Please describe your question with a little more detail so we know what you're actually asking
    – Stof
    Nov 14, 2021 at 12:28
  • 1
    you seem to suggest that DNS is only required for public internet addressing and there is no benefit to using it with static ip addresses? but you don't really back up these points. The obvious benefit of DNS is you get a name rather than a number. Why is it in your view better to use the number?
    – Ewan
    Nov 14, 2021 at 12:49
  • 1
    "Everyone is focussed on DNS vs IP when the real question is about microservice architecture intercommunication" – The real question is not about microservice architecture intercommunication. The real question is [bold emphasis mine]: "We have microservices in separate machines that currently use IP addresses in their configuration to communicate via REST APIs. There are also domain names defined for these machines. Is it a good practice to use IP address for communication or domain names should be used in case IP addresses change?"
    – Jörg W Mittag
    Nov 14, 2021 at 17:20
  • @Ewan exactly. When there's no public DNS and static IP, forcing DNS adds unnecessary complexity where the only perceived benefit is for a human readable name but only the machine uses it (no human interaction with endpoints occurs with microservices intercommunication. Fact is, maintaining additional infrastructure for the benefit of human readable name is not a benefit when the added complexity is now a human issue
    – Stof
    Nov 14, 2021 at 21:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.