Service discovery is the answer to the problem of trying to configuration our services when they are deployed to clusters. In particular, the problem is caused by a high level of dynamism and elasticity. Services are not, anymore, deployed to a particular server but somewhere within a cluster. We are not specifying the destination but the requirement. Deploy anywhere as long as there is the specified amount of CPUs and memory, certain type of hard disk and so on.
Static configuration is not an option anymore. How can we statically configure a proxy if we do not know where our services will be deployed? Even if we do, they will be scaled, descaled and rescheduled. The situation might change from one minute to another. If a configuration is static, we would need an army of operators monitoring the cluster and changing the configuration. Even if we could afford it, the time required to apply changes manually would result in downtime and, probably, prevent us from continuous delivery or deployment. Manual configuration of our services would be another bottleneck that, even with the rest of improvements would slow down everything.
Hence, service discovery enters the scene. The idea is simple. Have a place where everything will be registered automatically and from where others can request info. It always has three components: Service discovery consists of a registry, registration process and discovery or templating.
There must be a place where information is stored. That must be some kind of a lightweight database that is resistant to failure. It must have an API that can be used to put, get and remove data. Some of the commonly used tools for these types are etcd and Consul.
Next, we need a way to register information whenever a new service is deployed, scaled or stopped. Registrator is one of those. It monitors Docker events and adds or removes data from the registry of choice.
Finally, we need a way to change configurations whenever data in the registry is updated. There are plenty of tools in this area, confd and Consul Template being just a few. However, this can quickly turn into an endeavor that is too complicated to maintain. Another approach is to incorporate discovery into our services. That should be avoided when possible since it introduces too much coupling. Both approaches to discovery are slowly fading in favor of software-defined networks (SDN). The idea is that SDNs are created around services that form a group so that all the communication is flowing without any predefined values. Instead of finding out where the database is, let SDN have a target called DB. That way, your service will not need to know anything but the network endpoint.
Service discovery creates another question. What should we do with a proxy?
The DevOps 2.0 Toolkit
If you liked this article, you might be interested in The DevOps 2.0 Toolkit: Automating the Continuous Deployment Pipeline with Containerized Microservices book.
The book is about different techniques that help us architect software in a better and more efficient way with microservices packed as immutable containers, tested and deployed continuously to servers that are automatically provisioned with configuration management tools. It's about fast, reliable and continuous deployments with zero-downtime and ability to roll-back. It's about scaling to any number of servers, the design of self-healing systems capable of recuperation from both hardware and software failures and about centralized logging and monitoring of the cluster.
In other words, this book envelops the full microservices development and deployment lifecycle using some of the latest and greatest practices and tools. We'll use Docker, Ansible, Ubuntu, Docker Swarm and Docker Compose, Consul, etcd, Registrator, confd, Jenkins, nginx, and so on. We'll go through many practices and, even more, tools.
The book is available from Amazon (Amazon.com and other worldwide sites) and LeanPub.