We recently organized another Treblle Twitter Space and invited some of the most outspoken developers and engineers on this particular topic of Monoliths vs Microservices.

It turned out to be a great round table where we talked about not only what are Monoliths and what are Microservices, but also tried to give the answer to when to use them, what are some of the challenges and how to overcome those challenges.

The whole discussion + Q&A section went on for almost 2 hours, so we won’t go into detail here about everything that was said. If you didn’t have the chance to be present on the talk, the recording is available.

Twitter Space Recording

What is a Monolith Infrastructure?

A monolith infrastructure simply means that all of the things you are building is in one code base and you deploy it all together.

This means all of the parts of your product/service are interconnected and may be interdependent on each other. Making changes can be tricky in these kinds of environments, but it seems it is actually a really good thing when you have a small team.

Stackoverflow is still a monolith!

Everybody in the team is aware of everything and if team communication is good, there shouldn’t be many problems happening.

However, Stack Overflow for one would beg to differ. Fun Fact, Stackoverflow is still a monolith! So it can work. It just really depends from team to team.

There is also the distributed monolith, which is a number of microservices that depend on each other. If you want to change one, you have to deploy or asynchronize with all the others. These distributed monoliths sometimes get confused for microservices as Jens explained:

“And what some people are actually calling microservices are actually just distributed monoliths and then they are extremely hard to maintain and operate.”

What is a Microservice Infrastructure?

A microservice is software built from small independent parts that come from loose coupling and independent deployability. The loose coupling means that whenever there is a change made in one of the parts, there will very rarely be a need to change something in another part of the microservice.

Sometimes parts of a monolith might mature enough to become an independent part, and we could also say that then this part is a microservice. It needs to be able to scale, but to truly justify on making it a microservice it probably needs to answer to some crucial questions, like if this part of the monolith truly only does one task, how well does it do it.

Anwar and Vedran also pointed out, that sometimes these parts of a monolith might mature enough to become its own product that can scale.

“If you have a thing that can scale into a separate business that might be the definition of a true microservice.”

Monolith vs Microservice is a Spectrum

Dev Agrawal pointed out:

“Monoliths and microservices are not black and white, an on-and-off switch. It's more like a spectrum where a full microservice is on the one extreme and a monolith is on the other.”

For most companies, the sweet spot will be somewhere within that spectrum. Microservices can be really complex. Not just as part of the architecture but also business-wise. It is no simple task to decide if you want to go one or the other route.

Vedran gave a real-world example:

“One of the things everyone should note is, you need a consistent database layer across all your microservices. For us, doing that was one of the hardest parts of splitting out the monolith.”

Even third-party services that you use a business could be a microservice. So if like Vedran you went in the route of uncoupling your website, and even as far down as the blog with some sort of third party service. As long as you can affirmatively answer 2 fundamental questions Dev Agrawal proposed, you can consider them to be a microservice:

“To answer if an external service can be a microservice, we just need to go back to the questions.
A) Can you work on it, and develop it independently of everything else.
B) Can you deploy that, can you operate that independently of everything else.
If you can do both of those things, I have no problem in thinking of it as a separate microservice.”

There are always multiple ways you can go about deciding if something needs to be a microservice or keeping it within a monolith. Like we said, some big companies still to this day use a monolith. The core business of GitHub is still one. So, maybe monoliths are actually being unfairly judged.

You have to figure out what is best for your business and for your team. Like with a lot of things in tech, there is no real silver bullet here. It all comes down to making a decision, and the best way of making a decision is doing it with as much data as possible.

When and how to decide to go from Monolith to Microservice?

So what is the data you might need to decide to go from Monolith to Microservice? This might mean several things. It might mean you sitting down with your team to decide what would be the best course of action.

You might have to evaluate pieces of your business that are connected to some part of the monolith. Even evaluating parts of your human team to see if you can champion some of them as RB described:

“If we have a really large team then it becomes really hard to communicate so we need to have 2, 3, 4 champions and build microservices that are independent of each other.”

Before you go into this whole process, there are some core questions you might want to answer first. This is how Dev put it:

“…you need to figure out why you think you need microservices. What problems are you running into that a microservice could solve?”

As we said, most problems can be solved with different approaches. Dev gave an example of this:

“For example, we had a monolith written in NodeJS that wanted to talk to some sort of a legacy system to pull some data from it. Instead of doing that in the monolith, we just had one person write a service for it independently, and we basically had a hybrid of a monolith and this one microservice that has the job of talking to the legacy system. And our monolith then just talks to that microservice and gets the data.”

Round Table Discussion Conclusion

It was a great discussion for anybody who is still in the phase of deciding if monolith or microservices are the best routes for them. Some general conclusion that might be helpful is that it is fine if you first start with a monolith with a mindset that some parts might become a microservice.

With that in mind, your architecture might reflect that and it will be easier to decide and make something a microservice when the time comes.

Follow Treblle on Twitter to follow this live discussion and engage our speakers in the Q&A. We have also started giving out some merch through our LinkedIn and Twitter profiles, so be sure to follow and get your hands on some free tech merch, books, and gadgets!

As always, stay hAPI!