Microservices for beginners

Microservice, you might have heard this term at the coffee corner, looking for a new job opportunity or while scrolling through your LinkedIn feeds. If you’re a “high speed scrolling” type of person, you might have missed it. This post is for those who like to understand the basics of microservices architecture. I’ll try to explain microservice type of architecture without using too much software jargon, abbreviations and so forth.

To understand the context, you’ll need to know that there are different type of software architectures. The most infamous and widely applied software architecture is called the monolith. In the monolith type of architecture you’ll have one application that basically contains all the business logic, services, operational capabilities, API interfaces, and so forth. A typical monolith application has one solution with different projects that produce different DLL’s (if you’re lucky) , requires one compilation stroke to build the application, has one database instance, provides one interface, etc.

Monolith is successfully applied for many years and companies (engineers) are still applying this type of architecture. There is nothing wrong with monolith. However, other type of architectures will become more interesting when considering requirements such as scaling, cloud, fault isolation, fault injection, (automated) testing and automated deployment.

Is Monolith Bad?

Monolith applications are not bad at all. This type of architecture might be the best fit in your case. There is no “one size fits all” type of architecture. One of the disadvantages of using monolith is that the developers should have the discipline to work consistent on applying the overall design principles. Usually, intensive code reviews are used to catch the shortcuts that developers make during the implementation phase of the project. In practice, this is a hopeless thought when working in large teams and/or large codebase. Note that, in microservice type of architecture you'll still need to apply code reviews. However, the chance that someone decides to create a shortcut without being noticed is lower than the monolith type of architecture. In my next post I will explain this in more detail.

The Almighty Netflix

Ever since I’d started reading about microservices, I got more enthusiastic about it. Matter of fact, I’m still exited about this type of architecture. Now that Netflix is tired bragging about it, maybe my post will get some likes.

I will explain the microservices architecture with an example without using too many technical terms. Note that, the example below explains basically one of the major advantages of using microservices architecture, namely fault isolation. There are of course more advantages to mention. However, for now, we'll keep it lightweight. In my next post, we'll take a closer look to the other advantages and disadvantages.

Imagine you’re watching a real cool movie on Netflix and that Netflix has a monolith type of architecture. Let’s assume you’re watching Star Wars, nah, let’s assume you’re watching The Equalizer. Denzel looks at his watch, looks around and analyzes the situation. Starts the timer on his watch, error! What! Suddenly the movie stops and a message box appears that an error has occurred while streaming the movie.

This is of course annoying and is not something you’d expected. In the meanwhile you’re taking a beer, and another one, until the software engineers of Netflix discover that the issue relies in the billing part of the application. While drinking your beer and almost fall asleep, the software engineers has fixed the bug, compiled the source code and deployed it to the production server. Now, the message box disappears, oh no, it’s sleeping time.

Imagine the same situation, there is a bug in the billing system of Netflix. This time, the Netflix architecture is based on microservices. You will enjoy watching The Equalizer and in the meanwhile the billing issue is resolved. You are a happy customer since you didn't noticed anything about the billing issue.

Different Type of Architecture

Besides monolith and microservice type of architecture, there are other type of architectures as well e.g. Services Oriented Architecture (SOA) and Serverless. I’m not going to explain these type of architectures in this post. That would take me decades to write something down (in my spare time). I’ll keep the scope of this post on microservice architecture and maybe in my next posts, if you guys like this article, I’ll write something about the other type of architectures. Since I’m a big fan of Martin Fowler, I’ve added a quote of his definition of microservices.

In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies. --- Martin Fowler

Let’s take a closer look at Martin’s definition. I've chopped his definition into 3 parts and will discuss each part separately.

Part-1: "the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API"

In other words, in the microservices landscape the application needs to be decomposed into smaller chunks of “applications” which are called the services. These services can communicate with each other in order to realize one or more requirements. The most widely used interface is the Web API.

Another interesting thing about these services is that they should be independently deployable from each other. Have you added a new feature to your source control? Bam! The build system is triggered automatically and the source code is compiled, checked (code quality), tested (Unit Test), tested (integration, fault injection), tested (scenario testing) and deployed. There is no need to ship the complete application, only the updated services can be deployed.

No, no! Wait a minute, I (must) deploy my application in one stroke. I told you, we can't apply microservices.

The way you are deploying your application is not tied to microservices. The services should be at least independently deployable. If you like to know my opinion, the world is changing and so your customers. Prepare your architecture for the future.

Part-2: "These services are built around business capabilities"

This is the most crucial part of shaping the microservices landscape. How did you shape the microservices landscape? I love asking this question to engineers who have worked with microservices. I can tell you, I’m getting the most fuzziest answers ever. The answer is quite simple, we have shaped it around the business capabilities. In my next post I can zoom into this part. For now, it's important that you know that the small services are built around business capabilities and not randomly made up.

Part-3: "There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies."

The services within the microservices landscape should be loosely coupled and can be written in different programming languages, for example, the billing application can be written in C# while the streaming service in C++. The billing service might use a NoSQL database while the customer service a SQL (RDBMS) database. Every service can be optimized for its purpose and usage to fulfill the business capability as good as possible.

FGR - Frequently Given Resistance

Microservices should be very small, micro small!

Nope, this is not true. The size of a single service is not tied to the lines of code or the number of classes that a service has. It’s all about responsibility and the part of the business capabilities that you want to realize. I will not smack you with the terms like SOLID, KISS, Open-closed, DRY, etc. Let’s keep this article readable.

Nope, nothing new, microservice is the same as Service Oriented Architecture (SOA).

Just like anything else in the world, you have supporters of something and people who has criticism. In case of microservices, the criticisms claim that there is nothing new to microservice type of architecture. That microservices is very similar to Service Oriented Architecture. However, on a very high level they have, but when looking to the details we can see significant differences.

Next Post

Of course there is a lot more to write e.g. the benefits, the drawbacks, real life examples, how to start refactoring towards a microservices landscape, the differences between SOA and microservices, etc. etc. Please let me know which topics you would like to read more about and hopefully I can add them to my next post.