Keep up with the dynamics of the market. Try microservices!

To stay on monolith or to re-write it to microservices? This is the question! The question for more and more companies who rely on apps in their business. Do you know what both of these terms mean? What are the differences in the architecture of microservices and monolithic structure? What are the business benefits and challenges of each of them?

Monolith

“Monolith application” or simply “monolith” is a term related to the type of architecture of the app. Wikipedia defines a monolith as a “geological feature consisting of a single massive stone or rock, such as some mountains, or a single large piece of rock placed as, or within, a monument or building.” This description explains it very well if you consider it a metaphor for an app as a piece of rock

A monolithic app is actually one huge piece of code full of dependencies.

Its main disadvantage is that if you want to make a small tweak in the code, you have to update the entire structure.

Disadvantages of monolith

In my opinion, the main disadvantages of the monolith that can have a major impact on your business are:

1. When releasing a new version of the application it is very easy for something to go wrong and the entire code to get “broken”

It is very normal that sometimes things don't go exactly according to the plan. The problem is, that if the entire application is interconnected with different dependencies (which is a standard for the monolithic architecture), a minor issue with a non-significant functionality may cause a collapse of the entire app.

To illustrate that, let's have a look at a well-known Facebook feature “the poke”. Imagine that a developer decides to enhance it, but while doing so he'd make some minor errors, and after releasing a new version suddenly the entire newsfeed (the most important feature of Facebook) becomes unavailable. If Facebook was a monolith this would be a very likely scenario.

2. Impossibility to promptly react to changes

Nowadays it is extremely important to grow fast, not only when it comes to the development of your app. You want to be agile, be able to immediately react to the dynamics of the market and especially to your customers' needs. The speed of your development is simply crucial. With a large monolithic app, it is impossible to promptly react to changes. It makes me think about the financial sector. Without pigeonholing, my experience with banks is that most of them announce a release of a new version of mobile banking at least once a year. If you think about it, it doesn't make much sense. If the development team needs a whole year to release a new version of the app, it technically means that some of the functionalities in the new release are at least a year old! It's a vicious circle with no escape. With this approach, it is impossible to keep up with technology development without making compromises.

This, of course, applies to other sectors as well. Another good example is MS Office. You know this - version 2010, 2013, 2016 and so on. The Office has a new release approximately every 3 years. Assuming that they start working on a new version immediately after releasing the previous one, in practice it means that at the day of the release the system is technically at least 3 years old, which is not ideal.

Are there any benefits to the monolith architecture at all?

Yes, there are. I’d like to emphasise the following:

1. The team that manages your application has relatively less work with operations

2. The app is written in a single coding language. Server-side application logic, front end client side logic, background jobs, etc, are all defined in the same code base. As it is easier to manage.

Microservices

I guess that from the above description it starts to become obvious what microservices are. Yes, they are the exact opposite of the monolith. Imagine a big application divided into a lot of small pieces that are independent. If you do it right when you change a piece of code in one part and something goes wrong, the issue will only affect this small piece of the app, and the rest of it is safe and works with no problems. This way you can easily avoid a major outage caused by some minor issue (for example, an issue with “the poke” feature won't cause an outage of the entire Facebook)

The following definition sums it up in a very comprehensive way: “Microservices are small, autonomous services that work together.”

(https://www.oreilly.com/ideas/a-quick-and-simple-definition-of-microservices)

What's the best approach to microservices

I bet you are telling yourself “Wow, I want it!” However, if you are currently operating on a monolithic legacy application, you have to brace yourself for a large number of issues trying to re-write it to microservices. It is much better to start building your app from scratch using microservices. A de facto standard for this is Docker + Kubernetes. You can read more about Kubernetes in my recent article here. Leaving the technical details, for now, let's concentrate on the business itself.

Disadvantages of microservices

Every solution has its benefits and disadvantages. That is also true for microservices

They are cloud-based and has to be stateless, in order to be able to achieve scalability. They also require a higher financial investment initially and you will need a whole team of skilled people who know how to work with them. In my opinion, however, these challenges are worthy of undertaking as leveraging the potential of microservices will make a tremendous impact on your business.

Advantages of microservices

1. Zero downtime when releasing new versions

Because you only work with one part of the code at the time, which does not affect the rest of the application, you will not experience any sort of downtime when releasing new versions, and most importantly your clients won't even notice something is happening. You will have a chance to keep improving your product right under their noses. There are plenty of benefits for your DevOps team as they do not need to get up at 2 am to launch an update.

The only requirement to make al this possible is that your application is stateless. I will elaborate on what it means in my next article.

2. You can release multiple versions many times a day

Not only can you release a new version with zero downtime, but you can also do it as many times a day as you need without the slightest sign of an outage. When the developer finishes the code of one piece of the app, he doesn't have to wait for other teams to finish their part of a job. Because each piece of the code is independent it is impossible for one update to cause issues with other parts. This way you can quickly test out new functionalities and make them available for your clients as soon as they are developed.

3. Independent teams

Both above-mentioned arguments are valid because each microservice is an independent entity. You can also have different teams working on different parts of the code. The applications are becoming more and more complex these days and it is a big advantage to be able to work on each part independently without endangering the functioning of the entire structure.

4. Maximum automation

When building a microservices based architecture the best practice is to maximise the automation of the deployment of new releases. It wouldn't be very efficient for manual testing to be holding you back. Initially, it will take some time to do it, but in the long run, it will save you tremendous amounts of time.

In my opinion, it is all about time to market/time to value (however you may call it). It is crucial to make new services and functionalities easily available to your clients as it will be fruitful for your business in the long run.

You can find a great real-life example of how switching from the monolithic architecture to managed microservices in the case study of a ticket selling platform GoOut which solved most of their issues by implementing Google Kubernetes Engine. Read the full story here.

If you have any questions regarding this topic don't hesitate to contact me at kas@revolgy.com