DEV Community

Cover image for Microservices vs. Monolith Architecture

Microservices vs. Monolith Architecture

Alex Barashkov on December 04, 2018

The evolution of technologies has changed the way we build the architecture of applications. Docker, Cloud services, and Container Orchestration se...
Collapse
 
thomasjunkos profile image
Thomas Junkツ

Thanks for this great writeup!

I would like to add two points, which is are not mentioned - at least not explicitely:

a) Developer skillset
It requires different skillsets to run one or the other. If you have a team with sharp skills developing microservices, it would be reasonable to think of doing microservices for upcoming projects.

b) Although monoliths aren't always simple, agreed. But are in terms of complexity easy to reason about. In the world of microservices a simple function call turns into a distributed systems problem. With a bit of humor:

twitter.com/tenderlove/status/1027...

But anyways a good thread.

P.S:

have a team with knowledge of different languages

You could - of course - do microservices with a team, knowing only one language ;)

Collapse
 
alex_barashkov profile image
Alex Barashkov

You could - of course - do microservices with a team, knowing only one language ;)
Actually it happens most of the time :) It's advantage rarely used, only when it really could solve a big problem.

Collapse
 
mfahlandt profile image
Mario

Great article on giving an overview, but i must strongly disagree on the bullets against microservices.

have a small team.

  • the size does not impact if you can maintain microservices or not. Microservices are about just breaking code apart in reasonable packages.

build the MVP version of a new product.

  • if you build a MVP of a product you might want to continue your project after the MVP is reached. When you create a monolith that will fail at some point as the product evolves you create a problem knowingly

did not get millions in investments to hire DevOps or spend extra time on complex architecture

  • this argument is placed by someone who basically misinterpred microservices. You can start your microservice architecture with just having 2 services and as soon as you get to the point that it gets overcomplex you split it apart. It's an evolving process not an and now we do microservices. Setting up basic setups in time of cloud and hosted Kubernetes Clusters or hosted Microservice services is achievable by every devolper.

have experience of development on solid frameworks, such as Ruby on Rails, Laravel, etc.

  • can't see the point of the used framework here? you can create microservices that run laravel ruby etc. microservices are about splitting complexity and business logic and making systems reliable and self sustaining from each other.

don’t see performance bottlenecks for some key functionality.

  • let's be honest, this will not happen :D

think that microservices are cool and it’s a trend.

  • what?
Collapse
 
alex_barashkov profile image
Alex Barashkov • Edited

the size does not impact if you can maintain microservices or not. Microservices are about just breaking code apart in reasonable packages.

agree, let me say that there always be exceptions. some team would be fine with doing microservices and maintaining them even with 1-2 people. Some team will be suffer with devops and 10 devs.

Setting up basic setups in time of cloud and hosted Kubernetes Clusters or hosted Microservice services is achievable by every developer.

achievable definitely yes, but it could take weeks of work without knowledge of how to do so and what does it even mean. With Kubernetes developer without a proper background will have pain on each step because he will need to configure cert manager, he will need to learn yaml syntax required for Kubernetes configuration, terminology, architecture of Kubernetes, then the simple tasks he get used become a problem as well such as - ssl certificates renewal, persistent storage, self hosted or cloud docker registry, configuration of ci/cd services. From perspective of project delivery, it's definitely not the best time thing to spend time on.

this argument is placed by someone who basically misinterpred microservices. You can start your microservice architecture with just having 2 services and as soon as you get to the point that it gets overcomplex you split it apart.

Microservices suppose to have a small as possible isolated parts of your application. I can't imagine that any real product even on the MVP stage could just have 2 microservice. It will be mostly Monolith + maybe 1 microservices, but definitely not a microservices architecture.

can't see the point of the used framework here? you can create microservices that run laravel ruby etc. microservices are about splitting complexity and business logic and making systems reliable and self sustaining from each other.

Microservices on laravel? I don't think someone will be build microservices on laravel framework, there are a lot of alternatives for PHP to make microservices smaller and better than grab all stuff laravel could get to you

what?

that's advice could be addressed for everything development related. Don't go ahead with technology for production usage if you the only one reason you chose it is "it's cool"

Collapse
 
mfahlandt profile image
Mario

Someone has to do the hosting even of your monolith and it comes down to either a developer or a devops. and i think we can agree that is way more pain hosting a LAMP or whatever sytem and maintaining it than to have docke swarms or kubernetes clusters. especially when you start a new project.

Instagram clone, one services handeling accounts one service distributing images without extracting the database handling logic out of it. Yes you can split it further by one for rendering images and so on. But here you have the point. You start with a small microservice layout. and as soon as you se it gets to complex you split a service again. this is the point of having an evolving microservice architecture. You cannot possible all the services that you will end up with.

Laravel even have a microservice addition: lumen.laravel.com/ :D
There is no this now not a microservice, for example you have an onlineshop and you are using laraval for model creation in each of the services.

An important point is: "There is nothing inherently “micro” about microservices per se. While they tend to be smaller than the average monolith, they do not have to be tiny. Some are, but size is relative and there’s no standard of unit of measure across organizations."

Collapse
 
bcalik profile image
Burak Çalık • Edited

...Microservices are about just breaking code apart in reasonable packages...

No it's not. If you plan to develop your app using microservices then you need a really good architecture, otherwise it will become a monolith application with set of packages. The main goal is creating different domain knowledges on different developers, so that the developers won't need to know the whole system to develop anything. But then it comes with a challenge of "communication", which requires a good architecture, devops and planning.

Nobody would like to invest millions and wait years and years to make profit, when its not really clear that project will be a success nowadays. So the rapid application development is always the best choice for startups.

Get the MVP fast, see the success, make profit, see the future requirements. You can always rewrite the app at some point since the app is already success.

Collapse
 
steveguo1984 profile image
steveguo1984

This is a interesting blog for comparing Microservices  and Monolith. And also lots of interesting reply’s.

What I feel is micro service is not always good and Monolith is not always evil. Both has pros and cons. And in real case those 2 minds should be used hybrid.  It depends on what is your product, what is the expected scale and complexity and lots of factors.

Decouple a project is like cutting a cake, the key is not how small you can cut but how to cut it in to the right size.😀

Collapse
 
svenalhamad profile image
Sven A

In my view. microservices recently became much simpler to manage and deploy. I wouldn't stay they are reserved only for big and complex applications. Especially now that you can use different serverless approaches to architect your services.

I recently wrote a blog post on this topic, curious to hear what you think: blog.webiny.com/the-serverless-sup...

Collapse
 
uruit profile image
UruIT

Hi Alex :) How are you?
That's an interesting perspective! A colleague recently wrote an article on microservices as well, based on his experience as a software developer. In the article he shares positive and negative aspects of working with microservices, maybe it can interest you: uruit.com/blog/microservices-archi...

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

Nice post.

I miss the paragraph about debugging. I'm interested to know your thoughts about debugging the Monoltyh and Microservice Architecture solutions.

Collapse
 
alex_barashkov profile image
Alex Barashkov

Just published the article with guide for Docker/Node.js debugging. You could take a look on it, if that's a technology stack you use.
dev.to/alex_barashkov/how-to-debug...

Collapse
 
rafalpienkowski profile image
Rafal Pienkowski

Thanks for the info. I've just marked this post, and I'm going to read it in my free time.

Cheers!

Collapse
 
alex_barashkov profile image
Alex Barashkov

Hi Rafal,

Good point, I think I missed it because from our tech stack there always no difference. We use mostly Node.js, so in order to debug it you just need to expose extra port and allow access to debug from any address. Probably, I will write a mini article about it during this week.

So unfortunately can't say how debug goes with other languages.

Collapse
 
prachip1 profile image
prachip1

You have explained it very clearly. I am very new to it but got a very clear concept of what to do and what not.