Complexity is not the issue. Understanding the rules is. Hence, without proper understanding you can really mess it up
With the exception of scaling in the group, the rest are very subjective and really depends on many factors. It reminded those agile sales pitches.
In my opinion, their biggest benefits are
They allow the concept of the best tool for the job, meaning we don't have to use a Windows compatible offering/language while a linux counterpart is better.
Rolling smaller scoped updates. If something goes wrong, less sideeffects.
But I've almost never seen a properly done micro service landscape. I usually see the following
Microservices because we like (or find hype) containers and K8S
Too many async steps that create end to end performance problems
Microservices because we like the Lamda model
And as a result, when things become complicated you end up with a microservice only in code but in all other aspects including culture and ops, a distributed monolith.
In the video I do mention the aspect of being able to use the best tool for the job with microservices, forgot to add it to the summary
you're right about most microservices resulting in a mess, engineering discipline and having the right culture in place is probably the most important factor. In a crunch all the ideals will be thrown out the window to hit a deadline and tech debt begins to pile up
The most common root cause I encounter on this topic is that most people don't understand isolation. They tend to use different services as some sort of database over http/api or computational shared service. The fundamental requirements, that data is not shared is the most common root cause for the mess. And then all the rest follow. Sharing codebases, not versioning and in general everything that breaks isolation and all because as you say "ideals are thrown out of the window".
But we did the same hype word mess with agile, microservices and devops. Nothing wrong, quite the opposite, with each but somehow people in this industry read a couple of blog posts, don't bother to read a book and they make important decision without even half knowledge. Then you have all the companies that need sell each hype word. Anybody remember the "I'm looking to hire an agile developer" as if it is some sort of a skill? Then, after the mess, managers make conclutions that this is not good because of the internal mess.
We have to be the only industry which behaves like this. If civil engineering was like this nothing would be standing up. When I wrote a post about DEVOPS culture , i repeatedly mentioned don't read my post but read the book.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In my opinion the reality is a bit different.
Complexity is not the issue. Understanding the rules is. Hence, without proper understanding you can really mess it up
With the exception of scaling in the group, the rest are very subjective and really depends on many factors. It reminded those agile sales pitches.
In my opinion, their biggest benefits are
But I've almost never seen a properly done micro service landscape. I usually see the following
And as a result, when things become complicated you end up with a microservice only in code but in all other aspects including culture and ops, a distributed monolith.
In the video I do mention the aspect of being able to use the best tool for the job with microservices, forgot to add it to the summary
you're right about most microservices resulting in a mess, engineering discipline and having the right culture in place is probably the most important factor. In a crunch all the ideals will be thrown out the window to hit a deadline and tech debt begins to pile up
The most common root cause I encounter on this topic is that most people don't understand isolation. They tend to use different services as some sort of database over http/api or computational shared service. The fundamental requirements, that data is not shared is the most common root cause for the mess. And then all the rest follow. Sharing codebases, not versioning and in general everything that breaks isolation and all because as you say "ideals are thrown out of the window".
But we did the same hype word mess with agile, microservices and devops. Nothing wrong, quite the opposite, with each but somehow people in this industry read a couple of blog posts, don't bother to read a book and they make important decision without even half knowledge. Then you have all the companies that need sell each hype word. Anybody remember the "I'm looking to hire an agile developer" as if it is some sort of a skill? Then, after the mess, managers make conclutions that this is not good because of the internal mess.
We have to be the only industry which behaves like this. If civil engineering was like this nothing would be standing up. When I wrote a post about DEVOPS culture , i repeatedly mentioned don't read my post but read the book.