If you are aiming for a microservice architecture everything is easy as long as the services do not have to communicate with each other. When this is necessary the services have to find each other.

Current solutions for service registration and discovery

This process is called service discovery and there are some newer solutions.

• Consul by HashiCorp
• Eureka by NetFlix
• SnoopEE

Standards for service discovery

Besides these implementations a lot of standards have own specifications for service discovery like:

• SSDP – Simple Service Discovery Protocol
• UDDI – Universal Description, Discovery and Integration
• XEP-0030: Service Discovery
• Open Service Broker API

Challenges of current solutions

I don’t think that a new solution is needed because solutions like Consul, Eureka and SnoopEE require the following:

• You have to learn a proprietary API
• You have to maintain an own service registry and discovery server
• You have to use solutions that are mainly made for the Java world
• It is unlikely that your choosen solution will be maintained for a long time
• The given solutions are using a lot of ressources like main memory

Service discovery with DNS  SRV and TXT records

In this blog post I will emphasize on:

• A DNS RR for specifying the location of services (DNS SRV)

In short DNS SRV records.

I am proposing to use DNS SRV records for service lookups and encrypted TXT records for needed configurations. This is shown in the picture above.. Let me give you an example based on the microservice architecture shown in this blog post.

Example Microservice URLs

Let’s assume we have the following URLs for the services.

SRV records

This would result in the following SRV records on the production.example.com domain:

Challenges

Currently two challenges are visible:

1. The entry for invoicing and timetracking point to the same server and the url path is not given in the SRV record.
2. If credentials or other configuration parameters are needed these are not given in the SRV records

Configuration with encrypted TXT records

My proposed solution for saving these information is to encrypt them with the public key of the SSL certificate that is used for production.example.com and then save the base64 encoded string in the TXT record for the given domain.

Example:
path=/timetracking
user=example
password=secret


When encoding this with RSA and openssl ith the following command:
cat _timetracking._tcp.production.example.com.properties | openssl rsautl -encrypt -pubin -inkey public.pem -oaep | openssl base64


The following output will be created:
biymNCFyc5kePbBPANirNKJwFWq5QnQKblFZiyCD/glKelnOCxwvLtnBjTPebXNI
v/cUjLZUdrEd4lWkOoyPultcMseiIfwP8VAQtNVZnJcWjqiDUxSDCJGLWNzM4n6+
rclRRYPyHinw9viga4Rl7jukWWs18bsGVRdk1xvDFVvGuyTn/VpZdWYiyd2pqxhO
AtiB/dadQ3W5uCEu5per34vXQzwUJLeMXVAxA+45JqEQnWFrLIrWGA3dN/uHgL81
iapmYO7J7rM7HoMHUqRnjkaz7POrJbQBu1XbvyY0odG8jX/pFqRdMvF+FlDTUvLG
UatiFNsG/yiB69CpLMv5JA==


This will create the following TXT record
_timetracking._tcp.production.example.com. 60 IN TXT "biymNCFyc5kePbBPANirNKJwFWq5QnQKblFZiyCD/glKelnOCxwvLtnBjTPebXNIv/cUjLZUdrEd4lWkOoyPultcMseiIfwP8VAQtNVZnJcWjqiDUxSDCJGLWNzM4n6+rclRRYPyHinw9viga4Rl7jukWWs18bsGVRdk1xvDFVvGuyTn/VpZdWYiyd2pqxhOAtiB/dadQ3W5uCEu5per34vXQzwUJLeMXVAxA+45JqEQnWFrLIrWGA3dN/uHgL81iapmYO7J7rM7HoMHUqRnjkaz7POrJbQBu1XbvyY0odG8jX/pFqRdMvF+FlDTUvLGUatiFNsG/yiB69CpLMv5JA=="


This record can be decrypted to get back the local values.

Conclusion

Combined with the Microprofile Config API this solves the following service registry, discovery and configuration challenges:

• No new infrastructure needed
• Build on standards that are unlikely to change
• Every programminc language has DNS lookup capabilities
• A JSON Format
• Tools for maintaining records on multiple providers
• Dynamic reconfiguration possible when setting a low time-to-live
• Continuous integration pipelines with build, test and production systems are supported
• Uses the already available SSL public key infrastructure
• DNS is proven to be super scalable, reliable and when using DNSSEC secure