The world of microservices

The architecture of most applications resembles one big ball of mud, commonly called a monolith. At the application level the hallmarks are ballooning library dependencies and closely coupled parts that leave the application unable to withstand failures in individual parts. At the operating system level it's one big, resource-hungry process. Monoliths have one enormous advantage: they're easy to develop. You don't have to work out how your code will interact with the rest of the system. You just write it, and it becomes part of the application. But monoliths have plenty of drawbacks. You can only scale them as a whole, which leads to inefficient resource use. If one part fails, even if it's entirely noncritical to users, the failure cascades and takes down the entire application. A classic example is a memory leak that affects the whole application. A microservices architecture is an alternative to the monolith.

In a microservices architecture, the application and its functionality are composed of many small services joined together into larger units. An important feature of this approach is, or should be, the isolation of individual services. Adrian Cockcroft (Netflix, eBay, Sun) championed the idea that any microservice can fail and its consumers must plan for that from the start. Under Adrian Cockcroft's leadership, Netflix built its entire stack around this architecture.

Size matters

It's hard to quantify the size of a microservice. I've read opinions that it ought to be no more than a few hundred lines of code, but I don't find that a useful measure. What's much more important is that it have just one responsibility, (the single responsibility principle). Each microservice should do exactly one thing: sign-in, checkout, search, displaying a shopping cart, and so on. For a REST interface, one resource per microservice seems like the right granularity to me, or at least one piece of functionality from the user's perspective. The opposite extreme is a real risk: you can fragment an application too much by creating hundreds of microservices. Each has its own requirements. In Java, for example, you have to account for the JVM's overhead, and every call between services adds network overhead. Somewhere I saw a rather funny comparison that called microservices Enterprise JavaBeans for hipsters.

Hidden costs

The most attractive thing about a monolith is that adding features to the application comes at no extra cost. With microservices you need quite a bit of infrastructure, and you need it for every service. Say our microservices all share a common REST interface using HTTP and JSON. Each microservice needs a container to run in. You need monitoring and alerting. Each service should be highly available. Clients of the services, including other microservices, need a way to find out where they run. You can start with the endpoints in some configuration file, but sooner or later you'll need a registry of services and endpoints, because services can gain new versions or fail during the life of the application. That's just the runtime environment. On top of that you need deployment automation, such as Puppet or Chef.

When to start

Whenever I merge a pull request, I dread a bug taking down the whole server and having to get up at two in the morning to deal with it. You can try splitting the application into critical and noncritical components from the user's perspective or asking whether you could scale parts of it efficiently. But the most reliable sign is the fear that the application's complexity is getting out of hand. That's a good time to start thinking about microservices. A big advantage of the approach is that you can migrate individual parts gradually. It doesn't have to be a big bang from the start. Microservices won't save you on their own. You can still make a mistake, but if you get the architecture right, a bug is much more likely to take down just one small part of the application.

Sources and useful links

• Dystopia as a service (Adrian Cockcroft's presentation)
• Micro Service Architecture (an interesting blog post)
• Micro Services: Java, the Unix Way (presentation)
• Building Systems: Libraries and Frameworks (microservice size)
• Migrating to micro services
• Spring boot (Spring's framework for microservices)
• Dropwizard (a framework for building microservices that Yammer uses)
• Netflix OSS (an overview of the technology behind Netflix's microservices)