Created
January 21, 2015 12:28
-
-
Save kevinsimper/9a8666cc68fcbb6b05e9 to your computer and use it in GitHub Desktop.
Monolith
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| You talked about the place you worked that they wanted to | |
| have a micro service architecture, but they instead ended | |
| up with a split up monolith app because they were all | |
| dependent on each other. | |
| Didn't they have messages queues, and wouldn't that make | |
| it a microservice? | |
| What is the principle for not ending up with a split up monolith? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey Kevin,
The principle for not having a split monolith is that parts of the system can be replaced without affecting the user experience. The whole idea behind microservice architectures is agility and resilience at scale.
Agility is achieved by decoupling all the bits, or microservices. With a monolithic application the Mean Redeploy Impact (I'm calling this MRI because it amuses me) is always 100%, because we have to replace everything. We also have to do clever stuff to achieve zero-downtime deployments.
With a microservices architecture we can replace smaller parts of the system on the fly, which give us the opportunity to reduce our MRI to below 100%, which is a good thing.
So if you split your monolithic application into 20 small services that are all very tightly coupled, you probably still have an MRI close to 100%, which is not the idea.
Does that make any sense? I woke up at 4am.
Mark