Microservices Architecture: A Realistic Guide (Part 1)

5 min readNov 23, 2019

A typical microservices image of how microservices look like

There are excellent articles on microservices explaining the great promises that the theory offer to modelling distributed systems. Unfortunately, most of these articles were written by developers without prior experience with planning and deploying large scale microservices architectures.

The objective of this series of articles is to show that it is much harder to implement microservices architectures correctly than how developers generally present it. This first article will focus its attention on the prerequisites for microservices architecture understanding for successful large scale deployments.

Before we start diving deep into the common pitfalls of microservices´ architectures, we need to clarify something. To become an outstanding microservices architect, you need to be as sensitive as the ears of an orchestra conductor. To achieve that one must first develop the skill of modelling.

This is a context map, one of the most important types of models when planning your microservices architecture

There are many different types of modelling, and it takes time to learn to orchestrate them. You have to understand how your data will flow from your database to your distinct services. You also have to know what are the relationships between different services and how will your different teams organize to accomplish all new features and code changes.

A successful microservices architect should understand not only how to develop code, but how developers interactions might ruin all the precious time and effort he/she devoted. Sorry for the realistic way of saying it, but manager skills are valuable in this field.

Domain-Driven Design

For those willing to become microservices elite architects, Domain-Driven Design (DDD) is a must. It is a theory that unites building a ubiquitous language, modelling your business rules and developing highly expressive and robust code.

This is an example of an event storming meeting result: a context map with clear intersections between bounded contexts

The most ignored aspect of DDD is the concept of bounded contexts, subdomains and domains. Unfortunately, there is no magic wand to make you learn it instantaneously, but time and practice. To make it as clear as water, when you finish modelling your bounded contexts, they become your microservices, and the subdomains become the levels in which you start taking care of orchestration.

It is not the objective of this first article to teach you to do this but to indicate how to model your microservices highly scalable project. Focus your attention on context maps and in strategies of how to identify and map them. One of the most effective and popular ways of modelling your bounded contexts is to use a methodology called event storming.

Another great piece of advice is to read all the strategies to deal with bounded context intersections. These intersections become the communications among your microservices, so make sure you understand how all of that work. Some of the strategies are Customer/Supplier, Partner, Conformist, Shared Kernel, etc.

Distributed Systems / Cloud Computing

If you have guessed that I was going to mention DevOps, you are right! But, not quite right. Cloud computing is much broader if compared to DevOps. The origin of the word DevOps comes from two words: Development and Operations. Hence it cares only about how to develop and maintain your infrastructure. Cloud computing is a large set of components, one of which is DevOps.

These are the three types of cloud deployments

The first thing you need to know about cloud computing is databases, not just one database, but the highest amount of different products and paradigms as you can because it will allow you to simplify your data models. Below is a list of the most common flavours:

Relational Databases
Key-Value Stores
Columnar Databases
Document Oriented Databases
Graph Databases
Time Series Databases
Probabilistic Databases

The CAP theorem is another important concept that should be understood by heart. It implies some boundaries of how will your software scale and will make you understand the trade-offs of each infrastructure choice you make.

CAP theorem can be thought as a venn diagram for distributed systems choice tradeoffs

Learn about software integration, as it will allow you to solve the most complicated problems. There are four types of software integration: File system, shared database, RPC and message passing. For each category, there are tons of different patterns of communication, such as the splitter and the process manager pattern in message passing. Learning the patterns takes a lot of time, but once you have heard about them, it becomes easier to search for them.

When modelling your Cloud Computing infrastructure, make sure you stay data-driven. It makes everything much easier, I promise.

Security

It is not my intention to go deep into this topic, but it is a common trend for developers and architects to ignore security completely. If you are interested in knowing more about how vulnerabilities work, I have written another article about this topic:

https://medium.com/@douglasbellonrocha/defend-from-hackers-using-computer-networking-fundamentals-d80275f37af3

Learn about building secure networking and how to isolate critical infrastructure into private subnets. Understand what a reverse proxy is and what types of attacks a hacker can perform. Most popular cloud providers have excellent protection features you can use, such as DDoS filters and input filtering.

BizOps

This is TOGAF, the most relevant enterprise architecture framework out there

Another buzzword? Yes! Business Operations is here to stay and change the way we deal with distributed systems. It is not microservices specific but is the first effort to join IT and Business into one single entity.

BizOps is all about establishing SLAs, SLOs and SLIs with your clients and teammates. In case these three new acronyms are new to you check out this article:

https://cloud.google.com/blog/products/gcp/sre-fundamentals-slis-slas-and-slos

It is the task of a microservices architect to monitor all the metrics that guarantees none of the SLAs is being broken or ignored. SLAs are fundamental for strategical business decisions and are a small piece of a large area called enterprise architecture.

Now what?

This article is the first of a series of microservices architecture for starters. In part 2, I will mention the common pitfalls of microservices architecture and how to avoid them.