Why you should use microservices

So you’re sitting on hundreds of thousands of lines of legacy C++. Oh, who are we trying to kid? It’s millions of lines of Vectran, a short-lived Fortran variant created by IBM in the ’70s. But hey, if it ain’t broke, right?

Except it is broken. Anytime someone tries to add a feature, the thing breaks. Even trying to fix bugs creates more bugs. But if you just don’t touch it, it keeps on working.

The problem is that innovation demands agility and velocity. All the cool companies that never had to worry about Y2K are outpacing your clunky old legacy software. Investors are demanding the next big thing. Customers are jumping ship in droves.

The good news is that you’re not alone. Believe it or not, even the cool kids have faced similar problems. Netflix, eBay, Amazon, Twitter, PayPal, and more didn’t start out with beautifully architected scalable code that was fast and agile.

In 2006, eBay did a presentation at the SD Forum [PDF] about its architecture. The company confessed to having built a monolithic 3.3-million-line C++ ISAPI DLL that compiled into a 150MB binary. eBay developers were hitting compiler limits on the number of methods per class, while being expected to add more 1,200 new features per year with 99.94 percent availability.

How did eBay overcome its overburdened legacy architecture? The same way PayPal, Twitter, Amazon, and Netflix did: by killing their application monolith. They re-architected their infrastructure using microservices, a technique that breaks large applications into lightweight apps that can be scaled horizontally.

Breaking down monoliths

Microservices segment functionality into separate applications that are loosely coupled by RESTful APIs. For example, eBay created different Java servlet applications that handled users, items, accounts, feedback, transactions, and more than 70 other elements back in 2006. Each of those logical functional applications is now considered a microservice. Now eBay probably runs hundreds of microservices.

Each of these microservices is self-contained. They do not share a data layer. Each one has its own database and load balancer. Isolation is a critical component of microservices architectures; different microservices require different scaling techniques. For example, some microservices might use relational databases whereas others might employ NoSQL databases.

Building applications this way increases the scalability of teams building applications. With monolithic code, you have one big team of people working on one big piece of code and stepping on each other’s feet all the time. The speed of development slows exponentially with the growth of the code monolith. With microservices architecture, apps are built by small, decentralized development teams that work and change microservices independently. This makes it easier to upgrade services and add functionality. Both the software and the development process become more agile.

For all these reasons, microservices have enjoyed increasing popularity. But every architecture has its strengths and weaknesses. Microservices architectures bring a whole new set of problems that are hard to tackle.

In this article, we’ll explore the pros and cons of microservices as we unpack this modern method of building applications. Then we’ll walk through how to build a microservices-based blogging application to show how microservices work in the real world. Finally, we’ll address some of the most frequent concerns about microservices and answer the biggest question: Should you be making use of microservices?

The answer to that last question may surprise you.

The pros and cons of microservices

Microservices philosophy tears down large monolithic applications with massive complex internal architectures into smaller, independently scalable applications. If you’re eBay, for example, you might expect that the user feedback microservice would be smaller and less complex than the bidding microservice.

When you think about it, why should those functionalities need to be built into a single application in the first place? In theory, at least, you can imagine they would live in separate application and data silos without major problems. For example, if the average auction received two bids, but only a quarter of all sales received feedback, the bidding service would be at least eight times as active as the feedback application at any time of day.

In that way, separating different functionality groups into separate applications makes intuitive sense. Yet the benefit of being able to build and scale different parts of your application indepen- dently comes with a whole new set of concerns—specifically around logging, monitoring, testing, and debugging your newly decentralized, loosely coupled application.

If there’s a bug, which microservice is responsible for it? The interdependencies between microservices can make that question maddeningly hard to answer. Microservices communicate with each other, generally through lightweight JSON REST APIs. Unlike their predecessors XML-RPC and SOAP, REST interfaces tend to be more loosely defined. These lighter-weight APIs are more flexible and easier to extend, but they also add a new interface that needs monitoring and may break or cause bugs.

In the old days with monolithic applications, you could add debugging hooks within the code and logically step through every execution layer to discover the problem areas. When you are dealing with a mesh of dozens or even hundreds of separate applications talking to each other with loosely defined APIs, you lose that luxury.

Nonetheless, with careful planning youcan overcome these difficulties. At the present moment, you have relatively few off-the-shelf microservices debugging tools to choose from. You will probably have to stitch together your own solutions based on other, partial situations out there. But when you architect around microservices philosophies, you gain hidden benefits, such as tying in with other new technologies such as PaaS, Docker, and Linux containers.

Microservices, containers, and PaaS

There is a common misconception floating around right now that to use microservices you need to use PaaS or Linux containers or something similar. It’s simply not true. You can use PaaS and Linux containers without microservices, and you can use microservices without PaaS or Linux containers. Neither requires the other.

But in many ways, they do complement each other well. PaaS environments, whether in the form of public clouds such as Heroku or private clouds such as Cloud Foundry or OpenShift, optimize for running many smaller applications. Portinga 3.3-million-line C++ application to a PaaS platform will never happen.

If you deconstruct your application into smaller, bite-sized applications that are each self-contained and scale independently, those bite-sized applications often end up being good candidates for a PaaS environment.

For that reason, thinking about adopting microservices architectures can help accelerate adoption of other technologies that might already be on your road map. Likewise, Linux containers are better suited for small, stateless applications than large monolithic ones.

After all, one of the biggest and most obvious differences between a virtual machine and a Linux container is the lack of state. Virtual machines can be configured to keep their state, whereas the architecture of Linux containers intrinsically throws out any differences from the base image. With Linux containers, you can mount stateful folders in them, but the container itself won’t change unless you commit the change.


The horizontal scaling philosophy of microservices architecture promotes the concept of share-nothing, stateless applications. That
is, they do not store or modify the underlying file system. You can see why people conflate microservices with Linux containers: Neither retain their state.

Microservices offer a sound approach to application development, as long as you are aware of the problems and shortcomings. It’s not just another tech trend that will go away next season. It’s the way many of the biggest names in technology have tackled the problems of large-scale growth during the past 10 years.

How to think about building microservices apps


If you’ve never created a microservices architecture before, it takes a different way of thinking. Many developers start application design by starting with the database layout. They create a whole slew of tables, including complicated join tables. Then the application logic is built on top of the database. Finally, the user experience is put on top of the application logic. Like a three-layer cake, this approach to building applications can work well at first.

The problem with this architecture is that as features are added to the application, new tables and join tables are added to the database. Then new functionality is grafted to existing code. Over time, this becomes a huge rats’ nest.

The easiest way to think about building a microservice-based application is to start with the front end and work backward. Turn traditional architectural practice on its head.

To illustrate this inverted approach, let’s consider a simple blogging application. Traditionally, you might start building a blog app by creating one database with an articles table, a comments table, an authors table, etc. An article might have various writers, so you may want to create a join table for articles and authors.

With microservices, you might start out by taking the blog’s homepage mockup and consid- ering the elements within it. Comments are not on the homepage of a blog, so there’s no need to define them at this point. You don’t even need to build a comments database yet. That can happen later.

First, you could create a self-contained REST API microservice called Article. The front-end mockup could become functional code by integrating a JavaScript client such as Backbone, Angular, or Ember. All three of these JavaScript clients natively work with any REST API and can pull data into a design that was previously just a mockup.

The Article REST API microservice would be a lightweight application that focuses on the core functionality of storing and retrieving article data. In this stage of the microservice application development, you don’t need to worry about authentication or security models. Additional microservices can be layered in later. Don’t overburden any microservice with more func- tionality than necessary—hence the “micro” in microservice.

One of the important things to point out at this stage is that because each microservice has a limited scope of functionality, you end up having a lot more flexibility for the data storage options. Without large, complicated database designs, relational databases become less rele- vant, and NoSQL databases such as MongoDB, Couchbase, Cassandra, Redis, and Riak might end up working better. In theory each microservice could use a different underlying data storage mechanism that is best suited for that microservice.

Once you have built your Article REST API and it is serving dynamic data to the front-end client, you might want to tackle comments. You can build a new self-contained Comment REST API microservice that incorporates spam filters and identity technology unique to commenting. The Comment microservice fully encapsulates all of the fancy commenting code. Your front-end client can now pull dynamic data from this new API as necessary.

Finally, you might think about building an Author microservice that handles authentication and permission for creating new articles. The Author service would presumably have a control panel front-end. It would let blog authors log
in and write new blog posts. The Author microservice could then be integrated into both the front-end client and the Article microservice. The Article microservice could make an API call to the Author microservice during the article creation process to ensure that the author has permission to write new blog posts.

In the past, permissions-checking might have been done through a join table in a relational database. The lightweight interservice API calls can sometimes replace the join tables.

The front-end microservices application now pulls from three separate microservices, two of which also talk to each other. Everything in this application is decentralized. Instead of one big relational database, each microservice has its own database. Each microservice can scale independently. You might set up a load balancer with dozens of application servers for the Article microservice, but need only one instance of the Author microservice with no load balancer.

The decentralized, loose coupling philosophy behind microservices is well suited to leveraging third-party services. For example, instead of building your Comment microservice, you might use Disqus. Instead of creating your own authentication microservice, you might employ Janrain.

The microservices approach to building applications might seem strange at first. But microservices architecture has proven itself to be a viable alternative to the old monolithic beasts. If you decide to go down this path, you will be standing on the shoulders of giants.

Are microservices right for you?

Earlier I suggested that the answer to the question of whether you should use microservices might surprise you. The answer is not always going to be yes. As microservices consultant Chris Richardson says, “It is not simple, but then again, the reason you are using microservices is to tackle complexity.”

It’s important to remember that microservices are a response to hitting a glass ceiling. At some point, traditional monolithic application architectures don’t scale anymore. This happens to every successful software project. Either the database grows too large, or there are too many millions of lines of code, or you simply can’t add features quickly enough anymore.

If you have not hit a glass ceiling yet—that is, if your legacy application is still working well and doesn’t need to be changed much—then adopting microservices for their own sake will gain you very little beyond headaches.

After all, microservices bring quirks and difficulties to the development process. Keeping all of these new services running can sometimes feel like juggling a dozen balls in the air. Adopting declarative orchestration tools such
as Kubernetes can take some adjustment as well. Complex microservices architectures have their own lexicon to cover all of the new software patterns you will need to adopt.

Yet microservices aren’t nearly as daunting as SOA used to be. In fact, microservices practices can be implemented in even the smallest software projects—and you don’t need to throw away all of your old code to get started. You can start by building faux microservices.

If you have a large application that is getting out of hand,
with software lifecycles that take too long and a pace of innovation that
has ground to a standstill, then microservices might be just the thing you need. Alternatively, if you are just starting out, it would be smart to consider building a microservices-based application from the beginning.

eBay has said that microservices architecture has enabled the company to expand to massive scale, increased code scalability and maintainability, spurred rapid business innovation, created faster product delivery, and even enhanced security. Google, Amazon, Twitter, PayPal, and Netflix have all had similar experiences. Many of these companies have also created tools to make adopting microservices easier.

Whether you are suffering from the problems of maintaining legacy code and don’t know how to move forward, or you are starting out with a brand-new greenfield application, now would be a good time to evaluate a microservices approach to application development.