Let's take a moment and compare a monolithic application with a microservice application. The following diagram shows the most obvious difference between microservices and a monolith; monoliths are everything in one piece as opposed to microservices, which are split up in to different parts:

As you can see, the most obvious difference is that a monolith is one code base. Every code is within the same project and connected. In contrast to that, microservices are loose and independent but are often working together.

In the following subsections, we will compare concepts that highlight the difference between microservices and monoliths:

• Reusable code base
• Multiple versions online
• No downtime
• Updates are as slow or fast as required
• Common microservice use cases

Let's start by looking at the reusable code base.

This concept exists with monolithic applications as well as microservices. For monoliths, it's most commonly called plugins or modules. A lot of commonly used platforms are heavily utilizing this concept. Examples include WordPress, Magento, Drupal, Redmine, and Wikimedia. Many websites utilize plugins to extend the core functionality of the underlying monolithic system.

The underlying principle is to use the same code base across multiple use cases and projects. For monolith applications, however, all elements of that system will need to use the same programming language. For example, a WordPress plugin will need to be in PHP, just like WordPress. In opposition to that, microservices can be in various programming languages. You can have one service written in PHP but another one in Swift—they will work together just fine.

In a monolithic application, all parts are co-dependent on each other. If one part fails, all other parts are potentially affected. For example, one faulty plugin may cause the entire site to not load on certain or all parts. Microservices can be at various stages and not be impacted by others. Also, a non-operational service will not bring down the entire system. At the same time, it can be much harder for someone very familiar with one programming language and framework to work another piece in the same system. A monolithic application can be easier to maintain.

Both approaches allow you to reuse code; microservices, however, are a lot more flexible by allowing you to use various languages and versions together, whereas monoliths do not. Next, we will look at multiple versions online, another feature of microservices.

You can run two versions of the same microservice at the same time. If you have a user base that is using an old version of your API, for example, you can keep the old service available for them. Especially when updating apps, it often happens that not all users update to the newest version as soon as they can.

For the clients/users to differentiate between different versions of your service, you often use URL-identifiers such as https://api.domain.com/v1/users versus https://api.domain.com/v2/users

Notice that it contains a versioning string in the URL. The little v1 indicates that we want a specific version of this API service. We could run a second version of this service that is using v2 as an indicator and would return a different return-code.

You could, of course, deliver the same result using a monolithic application; however, in this case, you don't need to deploy two versions of the entire application but only this particular service.

Microservices allow you to keep legacy versions available without having to keep the entire old infrastructure alive. Let's take a look at how microservices allow you zero downtime.

As mentioned before, most hosting providers offer some Continuous Integration (CI) tools to keep downtime to a minimum. The principle is that you start the new version of the service first and then deploy it. Once it is up and running, the load balancer will lead traffic to the new service. Once the new service is fully functional, the old service will be turned off. The effect is that the user experiences no downtime.

A monolithic application can do the same; however, it takes a lot more work, energy, and server power to run a whole second instance of the entire application. If you need 100 servers for average traffic, you would need twice that many servers to complete deployment with this method. With microservices, you can only deploy the service in question while having minimal server overhead. Don't forget that most bigger updates usually require some database adjustments as well.

A monolith almost always uses one and the same database for the entire project. Even if you deploy your monolith in a way that two versions exist at the same time, it is a lot more complicated to do it with databases, especially when data is constantly being added or modified. On the other hand, each microservice is using its own database and you only need to work on the one you are updating.

Microservices are most efficiently used when they allow you to update with no downtime, which leads us to the next topic: updates are as slow or fast as required.

You can update only the services you want/need, allowing you to spread an update out. Especially for young companies and start-ups, it is widespread to have unclear and changing specifications. As changes and new features come in, you can gradually update your backend. For a lot of cases, adding features is equivalent to adding new services.

For example, if you have a social media app and you want to offer the functionality to comment on posts, it would only take you to add a Comment Service. This service would do nothing else but record comments on content.

If you are then tasked later on to add an "Answer" feature to your app, it could be an extension of the Comment Service. This feature could also alternatively be its own new service. Either way, adding these features can be done without touching the other parts of your backend at all!

To conclude, microservices allow for gradual functional extensions. Finally, let's explore common microservice use cases.

Here is a short, non-exhaustive list of the common use cases for microservices:

• Authentication
• Profile management
• Address verification
• Email handling
• Payment processing
• Social media streaming
• Order management
• Content management

This list can be extended by adding many more use cases to it. You might wonder how these small pieces of functionality can even function like an app. The next section will go into how to upgrade a monolith to microservices and explain how to draw the lines.