Surviving the Microservices Hype: Building a Resilient Service Fabric with Consul 0.4 and HAProxy 1.5

Everyone is talking about microservices these days. If you read the recent papers from Netflix or Martin Fowler, you’d think the monolith is extinct. But let’s be real: for most of us running production workloads in Oslo or anywhere else in Europe, splitting an application into fifty pieces doesn't just solve problems—it creates a networking nightmare.

I’ve seen it happen. You decompose your app, and suddenly you have 30 services trying to talk to each other. You hardcode an IP in a config file, the server dies, and you get woken up at 3 AM because the shopping cart service can't find the inventory service. The old way of managing /etc/hosts or manual load balancer configs is dead. If you want to survive 2015, you need dynamic service discovery.

In this guide, I’m going to show you how to build what I call a "Service Connectivity Fabric" (some folks are starting to call this a mesh, but let's stick to what works). We will use Consul 0.4 for discovery and the brand-new HAProxy 1.5 for routing. And we’re going to deploy it on CoolVDS because, frankly, if your underlying I/O is garbage, no amount of clever routing will save you.

The Latency Trap: Why Hardware Matters

Before we touch a single config file, we need to talk about where this runs. Microservices differ from monoliths in one critical way: chattiness. A single user request might spawn 20 internal RPC calls. If your virtualization platform steals CPU cycles or your storage latency spikes, those 20 calls cascade into a massive timeout failure.

This is why I stopped using budget VPS providers for distributed systems. You need consistent performance. I host my reference architecture on CoolVDS because they offer PCIe-based Flash (NVMe) storage. Most providers are still selling you spinning rust or SATA SSDs with noisy neighbors. When you are running a Consul cluster, disk write latency (fsync) is critical for the Raft consensus protocol. If your disk is slow, your cluster loses leadership, and your network thinks your database is down.

Pro Tip: On CoolVDS, I always set the I/O scheduler to noop or deadline for these NVMe instances. It shaves off those critical milliseconds that keep the consensus protocol stable.

Step 1: The Brain (Consul Setup)

We are going to use HashiCorp's Consul. It's relatively new (v0.4 just dropped), but it blows ZooKeeper out of the water for ease of use. It handles service discovery and health checking in one binary.

First, bootstrap a 3-node server cluster. Do not run a single server in production—if you lose it, you lose your network map. Here is a battle-tested consul.json configuration I use for the bootstrap node:

{
  "datacenter": "oslo-dc1",
  "data_dir": "/var/lib/consul",
  "log_level": "INFO",
  "node_name": "coolvds-node-01",
  "server": true,
  "bootstrap_expect": 3,
  "bind_addr": "10.0.0.5",
  "client_addr": "127.0.0.1"
}

Start it up with Upstart on Ubuntu 14.04:

start on runlevel [2345]
stop on runlevel [!2345]

exec /usr/local/bin/consul agent -config-dir=/etc/consul.d/server

Once your three nodes are up, they will elect a leader. Now, every other service you deploy (API, Web, Database) runs a local Consul agent in "client" mode. They register themselves, and Consul performs the health checks. If a node vanishes—maybe a kernel panic or a network partition—Consul marks it dead instantly.

Step 2: The Muscle (HAProxy 1.5 + Consul Template)

Knowing a service is alive is useless if your load balancer doesn't know. This is where the magic happens. We used to manually edit haproxy.cfg and reload. That’s too slow.

We will use a tool called consul-template. It watches the Consul cluster for changes and rewrites the HAProxy config in real-time. HAProxy 1.5 is crucial here because it supports SSL termination and keeps connections alive better than 1.4, which reduces the TCP handshake overhead between your microservices.

Here is the template logic you need. Save this as haproxy.ctmpl:

global
    log 127.0.0.1 local0
    maxconn 4096

defaults
    mode http
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms

frontend http-in
    bind *:80
    acl is_api path_beg /api
    use_backend api_backend if is_api

backend api_backend
    balance roundrobin
    {{range service "api-service"}}
    server {{.Node}} {{.Address}}:{{.Port}} check inter 2000 rise 2 fall 3
    {{end}}

Run the template daemon:

consul-template \
  -consul 127.0.0.1:8500 \
  -template "/etc/haproxy/haproxy.ctmpl:/etc/haproxy/haproxy.cfg:service haproxy reload"

Now, the second you launch a new API instance on a CoolVDS node, Consul sees it, consul-template writes the IP to the config, and HAProxy reloads seamlessly without dropping connections. It feels like magic.

The Norwegian Context: Data Sovereignty

For my clients operating here in Norway, we have to talk about Datatilsynet. Even though we aren't fully under EU jurisdiction yet in the same way, the privacy laws (Personopplysningsloven) are strict. You cannot just fling data across the ocean to a US cloud.

This is another reason I stick to local, high-performance hosting. Keeping the traffic inside the country or within the EEA is mandatory for many financial and health sector clients. CoolVDS has data centers that peer directly at NIX (Norwegian Internet Exchange). The latency difference between hitting a local CoolVDS instance versus a server in Frankfurt is noticeable when you are doing high-frequency API calls.

Performance: A Quick Benchmark

I ran a quick ab (Apache Bench) test against this setup. I compared a standard budget VPS against a CoolVDS NVMe instance running this exact Consul/HAProxy stack.

The difference isn't subtle. When you are routing traffic dynamically, the I/O wait time on the load balancer for logging and socket handling adds up fast. CoolVDS simply gets out of the way and lets the software run.

Conclusion

Building a distributed system in 2014 is hard work. The tooling is young, and the patterns are still being defined. But by combining Consul for truth, HAProxy for routing, and CoolVDS for raw horsepower, you can build a system that heals itself when things break.

Don't let your infrastructure become a bottleneck. If you are serious about microservices, you need a foundation that can handle the chatter.

Ready to build your own fabric? Deploy a high-performance CoolVDS instance today and stop fighting your hardware.