Microservices Tutorial: Everything to Know at a High Level

Microservice architecture is the new golden standard for building software. The overall idea is that instead of building your whole application as one single piece, you build it in multiple smaller pieces. This brings many advantages, and in this post, we will give you a high-level overview of microservices design. However, there’s no single standard way to build microservices, and it’s easy to do microservices wrong. The mastery of microservices requires either a lot of hands-on practice or proper training.

The Monolith

To better understand microservices, we first need to talk about what are they trying to solve. Microservice architecture is an alternative to monolith architecture. Nowadays, a monolith is considered an old-school way of building software. But why is that? What’s wrong with a monolith approach?

Time to Market

One of the biggest disadvantages of a monolith is the fact that even the simplest changes in the code require redeployment of the whole application. It means that even if you want to do something as simple as changing the color of a button on your website, you have to redeploy the whole application. And redeploying the whole application in the case of a monolith is not a simple task. Usually, it requires running multiple tests beforehand because, again, you need to test the whole application. Usually, for each deployment, you need to get approvals from a lot of people. This all comes to a single conclusion: implementing new features, fixing bugs, or even experimenting all takes a lot of time and effort.

Team Structure and Hiring

A monolithic application requires all developers to have a similar level of knowledge about the application. Usually, they all need to know the same programming language. This means that you are limited when hiring new team members. On top of that, onboarding them also takes quite some time, as they need to more or less understand the whole application before they are able to work on it.

(Lack Of) Scaling

A monolithic application doesn’t allow you to scale different parts of it independently. If your front end is doing a lot more work than your back end, you’ll have to scale the whole application, which means you’ll probably waste quite a lot of resources.

Microservices

The microservice approach was created in order to solve the problems of a monolith. The general idea is to build the software not as one single piece but as a few smaller services that talk to each other (usually via HTTP REST API). For example, in the case of an e-commerce online shop, instead of having one big component that does everything, you can build multiple smaller services, each having a specific task. These tasks could be, for example, a recommendation engine, a user registration service, an order service, a promotions service, etc. Then, a front-end component would connect to each of these services to generate the website, which will be presented to the user. You may be thinking, this seems like more work, so how does this benefit me? Well, while microservices require more network communication and cooperation, at the end of the day, they bring more advantages than disadvantages.

The Good and the Bad

The biggest advantage of microservices is flexibility. The more components your application consists of, the easier it is to implement changes without the risk of breaking the whole application. Microservices are smaller in size than a monolith, so it’s quicker to deploy a new version of a microservice. You don’t need to test the whole application when making changes to only one microservice as well. Usually, it’s also better to structure teams differently for microservices and give them more control and governance. Developers won’t need to understand the whole application since they can be responsible for only a few specific microservices. Hiring becomes way easier as different microservices can be written in different languages. Scaling microservices is straightforward: services that consume more resources can get more resources assigned without changing the rest.

Microservices, in general, solve the biggest problems of a monolith. They do, however, bring some disadvantages too. We mentioned earlier that microservices need more networking overhead. Indeed, this is the price that you need to pay for all the benefits of microservices. Some aspects of testing are easier, but others are a bit more complicated. With microservices, you need to test not only the microservice itself but also if it connects properly with other services.

Are Microservices Great for Everyone?

The disadvantages of microservices can be negligible if the microservices themselves are designed properly. It’s easy to cut a monolith in a few pieces and call it microservices. But without a proper redesign of an application, the disadvantages of microservices can be more visible. So it’s important to understand that microservices are not a golden solution for every application. It’s also worth noting that if an application is overall poorly developed as a monolith, then it’ll still be poorly developed as microservices.

So it’s definitely not the case that microservices will solve all your problems. It’s just a different approach for building applications. It’s considered the most common and most agile approach nowadays, but there are still some edge use cases where a monolith would work better.

Extra Features

So far, we’ve discussed how microservices solve common problems of a monolith. They can also bring some extra possibilities to your app.

Experimentation

Testing new functionality or experimenting with a new library or runtime for your application is very easy with microservices. Things like canary releases allow you to run multiple versions of the same microservice in parallel in order to test which one performs best. That’s not easy to do with a monolith. That gives you a huge advantage. You can respond to your clients’ needs quicker and more efficiently.

Customization

There is another advantage of running multiple versions of the same microservice: you can customize your application for different clients. You can, for example, run the same microservice in web and mobile versions, or for different markets, or in different languages. With a monolith, you would either have to add all these scenarios to a monolith (which would make it even bigger) or you would have to create multiple versions of a monolith (meaning a lot of redundant code). Microservices allow you to customize your app more easily and much more efficiently. You only need to create multiple versions of the microservice you’re changing.

How to Do Microservices Properly

We mentioned at the beginning that it’s not that straightforward to move to microservices. Failure stories usually come from the wrong monolith to microservices migration. But there are also cases where building an application from scratch with microservices in mind fails. Proper microservices design requires quite a good architectural design. It’s not as simple as “do many small pieces instead of one big one.”

It is true, though, that usually bad microservices are still better than a good monolith. This shouldn’t, however, stop you from spending enough time on designing good microservices. But what does “good” mean in terms of microservices? There are many things to keep in mind. Not duplicating functionality, using stateless microservices, avoiding relying on disks (but saving data into a database or bus messaging systems), and much more. Before you jump in and start building microservices for the first time, consider joining this hands-on boot camp to learn how to avoid these costly mistakes.