Breaking the Monolith: Practical Microservices Architecture for 2015

It’s 4:45 PM on a Friday. You’re staring at a terminal window, finger hovering over the Enter key. You’re about to deploy a 2GB .war file to production. If this fails, the entire e-commerce platform goes down—checkout, catalog, user profiles, everything. You’ll be spending your weekend parsing 500MB log files looking for a NullPointerException in a module you didn't even write.

If this sounds familiar, your architecture is the problem.

The industry is shifting. While companies like Netflix have been shouting about "fine-grained SOA" for years, 2014 was the year the tools finally trickled down to the rest of us. We are talking about Microservices. But moving from a comfortable (albeit fragile) monolith to a distributed system introduces complexity that can kill a project faster than bad code.

I’m going to walk you through the architecture patterns that actually work right now, using tools available today like Docker 1.3 and Nginx, and explain why your infrastructure choice—specifically KVM-based virtualization like CoolVDS—is the linchpin of success.

The Core Problem: Dependency Hell

In a monolithic architecture, your catalog service shares the same database and libraries as your billing service. If the catalog team upgrades a shared library (say, openssl or a specific Ruby gem) and breaks backward compatibility, the billing service crashes. The entire application is coupled.

Microservices decouple these components. Each service runs in its own process, manages its own database, and communicates via lightweight mechanisms like HTTP/REST or AMQP.

Pattern 1: The API Gateway (Nginx)

When you split your app into ten different services, you cannot ask your mobile client to make requests to ten different IP addresses. You need a gatekeeper. An API Gateway handles routing, composition, and protocol translation.

Nginx is the battle-tested choice here. While HAProxy is great for pure TCP load balancing, Nginx handles HTTP headers and SSL termination better for this use case.

Here is a production-ready snippet for an API Gateway configuration that routes traffic based on URL segments. This allows you to split your backend without changing the frontend endpoint.

upstream user_service {
    server 10.0.0.1:4000;
    server 10.0.0.2:4000;
}

upstream catalog_service {
    server 10.0.0.3:5000;
    server 10.0.0.4:5000;
}

server {
    listen 80;
    server_name api.coolvds-demo.no;

    # Global timeout settings are crucial for microservices
    # to prevent cascading failures
    proxy_connect_timeout 600;
    proxy_send_timeout 600;
    proxy_read_timeout 600;
    send_timeout 600;

    location /users/ {
        proxy_pass http://user_service;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        # Strip the prefix before passing to the service
        rewrite ^/users/(.*) /$1 break;
    }

    location /catalog/ {
        proxy_pass http://catalog_service;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $host;
        rewrite ^/catalog/(.*) /$1 break;
    }
}

Pro Tip: Never expose your internal microservices directly to the public internet. Use the Gateway as a DMZ. This simplifies your firewall rules on the host nodes.

Pattern 2: Containerization with Docker

Until recently, running 20 services meant managing 20 different Virtual Machines (VMs) or dealing with dependency conflicts on a single server. Docker has changed this landscape completely this year. With the release of Docker 1.0 back in June, and now 1.3, it is stable enough for serious evaluation.

Docker allows you to package the service with its specific environment. However, running Docker requires a modern kernel (3.10+ recommended). This is where many budget VPS providers fail you. They use OpenVZ, which shares the host kernel. You cannot run Docker properly on OpenVZ.

You need KVM (Kernel-based Virtual Machine) virtualization. CoolVDS provides full hardware virtualization, meaning you can install your own kernel or run CoreOS, which is optimized for Docker.

Example: Dockerizing a Python Service

Here is a Dockerfile for a simple Flask microservice. Note the specific pinning of the base image version—always pin your versions!

FROM python:2.7-slim

WORKDIR /app

# Install dependencies separately to leverage layer caching
COPY requirements.txt /app/
RUN pip install -r requirements.txt

COPY . /app

EXPOSE 5000

# Use Gunicorn for production, not the dev server
CMD ["gunicorn", "-w", "4", "-b", "0.0.0.0:5000", "app:app"]

Pattern 3: Service Discovery (Consul)

In a dynamic environment where containers spin up and down, hardcoding IP addresses in nginx.conf (like I did above) is a temporary hack. You need Service Discovery.

Zookeeper has been the standard for years, but it's a beast to manage (Java, heavy memory usage). HashiCorp released Consul earlier this year, and it is a breath of fresh air. It uses Go, is lightweight, and includes health checking.

Instead of hardcoding IPs, your application queries Consul via DNS or HTTP to find the `catalog-service`.

# Starting a Consul agent in server mode (bootstrap expect 1 for dev)
./consul agent -server -bootstrap-expect 1 -data-dir /tmp/consul -ui-dir /path/to/ui

Infrastructure Matters: Latency and I/O

Microservices generate significantly more network traffic than monoliths. A single user request might trigger 15 internal RPC calls between your services. If your hosting provider has high internal latency or overcommitted CPU, your application will feel sluggish regardless of how optimized your code is.

Furthermore, running multiple databases (one per service) dramatically increases random I/O operations on the disk. Spinning rust (HDD) cannot keep up with this pattern.

At CoolVDS, we utilize pure SSD storage and KVM virtualization. This ensures that when your logging service is writing terabytes of data, your checkout service doesn't stall waiting for disk cycles. This is critical for the Nordic market where users expect instant load times.

Data Sovereignty in Norway

Moving to the cloud doesn't mean ignoring the law. With the current landscape regarding the EU Data Protection Directive and the Norwegian Personopplysningsloven, you need to know where your data lives. Latency to Oslo is not just about speed; it's about keeping data within legal jurisdictions you understand.

While US-based clouds rely on Safe Harbor frameworks (which are coming under increasing scrutiny), hosting locally in Norway or Northern Europe provides a layer of legal safety and lower latency for your Norwegian customer base. Ping times from Oslo to a CoolVDS instance in our local datacenter are typically under 5ms, compared to 30-40ms to Frankfurt or London.

The Implementation Plan

Don't rewrite your whole system at once. That is suicide. Use the "Strangler Pattern":

1. Identify one non-critical domain (e.g., User Avatars or PDF generation).
2. Build it as a separate microservice using Docker.
3. Deploy it to a robust KVM VPS.
4. Route traffic to it using Nginx.
5. Repeat.

The complexity of microservices requires solid ground. You cannot build a skyscraper on a swamp. Ensure your underlying infrastructure supports the kernel features and I/O throughput this architecture demands.

Ready to test your first container cluster? Deploy a high-performance KVM instance on CoolVDS today and see the difference dedicated resources make.