What are microservices

As a software engineer or web developer, you've probably heard the term "microservice" before, but for less seasoned developers, the concept of microservices is likely an unfamiliar and seemingly daunting term.

The goal here is to break it down - explain what it is and why you should care.

Monoliths and the "monolithic server"

Before we can understand microservices, it's important to understand the traditional architecture used for building applications, commonly referred to as the "monolithic server".

The traditional full-stack applications is engineered into two primary parts:

1. The client (front-end)
2. The server (back-end)

This segments the presentation and of information and the implementation of business logic into the front-end, while the backend supports those features and enables persistence of data.

Monoliths

Meriam-webster defines "monolith" as:

1. "a single great stone often in the form of an obelisk or column"
2. "a massive structure"
3. "an organized whole that acts as a single unified powerful or influential force"

While not specific to software, the analogy is the same.

Typically the monolithic architecture is referencing the back-end (server) that supports data persistence and handles all the logic pertaining to creating, modifying, deleting, and retrieving information related to an application (or applications).

With Monolithic servers, every feature is run on the same system (computer/server) and is part of the same codebase and the same database.

In short → a monolithic application, implements every feature of the application.

Microservice Applications

Microservices are design around the applications features.With each microservice operating independently from each other, but working together to support all the functionality of the application.

In the microservice application architecture, each feature has its own small service called a "microservice" with no dependencies on the other services or features offered as part of the application.

Microservices vs. Monoliths

If each approach was taken to the extreme...

• a monolithic server architecture would consist of a single server responsible for all the features, functions and middleware of the application such as:
  • routing
  • authentication
  • business logic
  • database interactions
• a microservice based architecture would consist of multiple servers. Each server supporting all the functionality associated with a single feature of the application, and each microservice having independent routing, independent code bases, independent business logic, independent authentication, and independent data management.

Implications

The important take-away is that each microservice is self-contained, without any dependence on the other microservices. Using more technical terms, the features assocaited with the application in a monolithic application architecture are tightly coupled together.

This results in an application and development workflow that tightly ties together different developers from different teams, working on different features to a single shared code base, running the same shared middleware, and accessing the same shared database. In short, the application's features are highly dependent upon each other and a single feature breaking could result in the entire application failing.

Microservices seek to address this architectural issue, by making independent servers or services ("microservices") that only are responsible for a single feature of the application.

In a microservice based architecture, routing, authentication, business logic, and database interactions, are all wrapped into small independent pieces ("microservices") and have can operate on their own. With microservices, no feature of the application is dependent on shared code or servers.

This is similar to the idea behind "thin vertical slices" ([here] is an explanation of thin vertical slices if you are not familiar with the approach) commonly embraced in agile methodologies as well as the single responsibility principle.

The problem with the monolithic approach

If a hardware failure occurs in a monolithic architecture, the entire application can be broken, since all of the features, routing, middleware, business logic, and database interactions all occur on the same system.

Similarly, since every feature is running on a single server, that server is using a large code base, that is shared between multiple developer/engineers and teams. As a result each feature is highly dependent on the others, and any addition or modification to the functionality of the application means modifying the code for the entire application.

Drawbacks of Microservices

The microservice approach sounds great so far, but there are some drawbacks.

1. Communication between services
   • most applications require information from one feature in order to implement another feature. Since the microservice makes each feature independent of each other, data is managed independently and is not inherently available to other parts of the application.
2. Greater resource requirements
   • Data management
     • Data Duplication:
       • to avoid being reliant on other microservices, most applications implemented with a microservice architecture duplicate data, with each service having its own copy of the information it needs to operate.
     • Data model associations
       • associating information from one microservice to another is a complex process, since each service has no direct access to the database pertaining to another feature of the application.
   • More computing resources:
     • in order to be truly independent from the other microservices, each microservice must run on a server/computer that is only used for that feature.
     • for every feature to work in microservice architecture, multiple servers must all be running at the same time (compared to a single server in the monolithic application architecture)
     • development teams will often duplicate efforts implemented in other microservices, writing code that is very similar (if not the same) to the code implementing similar functionality in a different microservice.
   • More complex testing & debugging
     • integration testing involving multiple features, is more complicated under the microservice based approach.
     • logs for each microservice (feature) are on different servers, and could be in completely different formats.

Still unclear?

Hopefully the difference between the fundamental paradigms behind application architecture (microservice vs. monolith) is a little clearer. However, I firmly believe the best approach to understanding anything in software development is to build it.

If that's of interest to you, look out for a follow-up tutorial demonstrating the microservice architecture.