If you’ve never used 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 they build application logic on top of the database. Finally, they put the user experience 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 rat’s nest.
The easiest way to think about building a microservices-based application is to start with the front end and work backward. Turn traditional architectural practice on its head.
Building an example microservices app
To illustrate this inverted approach, 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, and so on. An article might have various writers, so you may want to create a join table for articles and authors.
IDG WorldwideWith microservices, you might start out by taking the blog’s homepage mockup and considering the elements in 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 works 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 functionality than necessary—thus the “micro” in “microservice.”
At this stage, 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 relevant, 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 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.
Programming issues in building microservice apps
As developers and managers wade into microservices, many of the same questions arise again and again. Here are the answers to some of the most common queries.
How do you associate data among different databases in microservices?
The first concern that people have when building microservices is letting go of join tables. Once you start building applications more complicated than the simple blog example in this article, this problem becomes very apparent.
The simple solution is to use application-level joins instead of database-level joins. The use of application-level joins often results in more database queries than a single SQL command might incur, but you can mitigate that by incorporating caching in the microservice layers. After all, each microservice can have its own caching technology. Over the long haul, this approach might be less elegant than a straightforward database join, but it’s certainly more scalable.
A more sophisticated solution is to incorporate an event-driven, pub-sub message bus into your microservices architecture. The message bus lets various microservices communicate with events happening throughout the application. This architecture is the foundation of building truly rich and complex microservices-based applications, because you no longer need to rely on service APIs being instantly available 100 percent of the time.
How do you orchestrate microservices?
The operational overhead of running dozens or hundreds of smaller microservices instead of one big monolithic application might seem daunting. Without question, keeping track of all the dependencies adds complexity. Fortunately, new orchestration solutions for these problems are becoming more stable and more reliable every day.
Whether you are looking at Kubernetes, Mesos, Swarm, or Nomad, these orchestration tools all basically do the same thing: They let you declaratively architect your devops platform.
Traditional devops tools are great at launching, managing, and monitoring individual applications, but the difference between devops tools and orchestration services is that orchestration services are built to manage complex microservices environments with dependencies among running services.
At their foundation, all these orchestration tools are just job-scheduling message buses. If you are already using a message bus in your architecture, you may want to build your orchestration engine on top of that existing message bus.
How do you decompose existing applications into microservices?
You may not have the luxury of rebuilding your application using microservices architecture from the ground up. The great thing is that you don’t need to.
If you are sitting on a significant legacy application and you would like to break it into microservices, but you want to proceed slowly, you can start by building faux microservices.
A faux microservice is the same as a regular microservice except the data store isn’t isolated from other parts of the application yet. For example, if you have a complex custom blogging application, you could create a faux Article microservice that is a separate application whose only responsibility is doing the Article REST API. The underlying articles database, however, is still in the same big relational database model. That way, the data is not duplicated.
Eventually, when enough of the faux microservices are built, you can work on segmenting the data stores into separate silos.
What about background processes in microservices?
Long-running background processes are becoming more and more common with the rise of big data analytics. Fortunately, microservices are well-suited for this kind of problem.
If you have already incorporated a pub-sub message bus into your application architecture, background processes are just another microservice without the need for a port binding. They can attach themselves by subscribing to the message bus and then wait until an event is triggered.
Can you use third-party services in a microservices app?
The decentralized, loose coupling philosophy behind microservices is well-suited to using third-party services. For example, instead of building your own Comment microservice, you might use Disqus. Instead of creating your own authentication microservice, you might use Janrain.
Stand on the shoulder of giants
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.