What's one of our favorite Consul customer success stories?

Transcript

When I think about favorite success stories, for me the one that comes to mind is a large European bank who's a customer of ours, and this is a customer that I first engaged with them and introduced them to the idea of Consul itself. It was a relatively new idea—this ability to have a service mesh that is able to act as a registry which knows what are all of the services running where, but also acting as a key/value store so that we can do distributed configuration and centrally manage the configuration of our applications. And then also have the ability to dynamically segment access between which services are allowed to talk to which other services.

In describing this tool to this large customer, they had this "Ah ha!" moment of, "Wait, we have many of those problems inside of our private data center, and today the way we deal with it is with a combination of hardware devices—load balancers and firewalls." And, they described their pain as being, "As we deploy applications, it's not enough just to deploy applications quickly. We then have to file tickets and wait multiple weeks for traffic to actually get to these underlying services."

I had a chance to then visit the same customer three or four months later on a return trip, and the customer was so excited. They were like, "Our production team has said Consul is the best tool we have deployed in the last seven years". And I was like, "You know why? What was so impactful here?" What they realized after starting to roll out Consul, is they can begin to use this notion of the registry. The fact that it knows where are all the services that are registered, and it's programmatically getting updated as new things launch or as systems fail to drive automation around traffic in their data center.

Where they first started was by using Consul to automatically populate their load balancers and firewall rules. What this enabled them to do is launch a new instance and within seconds, update all the rules and allow traffic to flow to that node. But then more interesting than that, they started to realize they could think about their architecture in a different way. Where these load balancers are really being used as stopgaps to basically act as service discovery mechanisms. Applications are hard-coding the address of the load balancer, and the load balancer is masking the fact that there are multiple instances.

But when you have a system like Consul or have a dynamic registry, in fact you don't necessarily need to use a static IP to do this discovery. Your upstreams can instead query Consul and dynamically figure out how many instances there are, do load balancing across them, handle failures, and route traffic as things come and go. So they were able to go so far as to remove thousands of load balancers out of their production environment.

What they were most excited about in some sense—my guess was they were excited about the cost savings of eliminating thousands of these hardware devices. But what the customer was really excited about was their ability to shave off weeks of time from a new instance launching to being able to get traffic, and they were able to go from eight weeks to six seconds.

For them, the hardware cost was actually inconsequential. It was being able to buy back two months of productivity after every change is being made. So for me, this was a really exciting case study of a customer that went from never having even heard of Consul to then months later being in a position where they were productionized, rolled out at a global scale, and had gotten back months worth of production, agility, and capabilities.