Consul Introduction

Say youv’e got an application that needs to be highly available (HA).

Typically you’d run a proxy in front of multiple instances of the application. To check if the application is up, you’d use something to do Service Discovery. That would be Consul.

The first question is – why not use an AWS solution instead such as:

  • ELB (Elastic Load Balancer) /ALB (Application Load Balancer)
  • ASGs (Auto Scale Groups)
  • Route53 (DNS)

The simple answer is it’s simply not the best solution. And you’ll get charged a ton for doing it this way.

E.g. you’ll ship a ton of data via your ELBs (and have to run them). You’ll get charged a boat load for the network data plus running them.

E.g. these guys were spending around $100K per annum basically on “Service Discovery”.


Getting back to the “best solution”, if you’re running a lot of microservices then you simply need a common discovery platform. Otherwise, your network design is going to become hideously complex. And it’s the job of something like Consul to handle that complexity.


Failure Detection:

Note that Consul will use something like haproxyto also do Failure Detection. E.g. to detect if an instance is out of service.

Multi Datacentre:

Assuming we’re using different datacentres (and need to configure services in these different cloud environments), Consul will help with this configuration.


Traditional System Design

Web – DB (e.g. a blog)

Web – API – DB (which lets us split things out – e.g. we might focus just on the API and DB if we’re offering a service)

Many Microservices

The modern approach is to have many APIs for many services (such as Customers, Orders, Inventory, etc).

We could stick a load balancer in front of each service. But we now have Service Discovery and Health Checks happening all over the place. Keeping track of these endpoints is tricky and this is where Consul comes in.