I’ve been having this thought on the back of my mind for a long time to write about why it’s often a bad idea to start with microservices for a brand new project.
The time has come, that’s exactly what I’ll talk about in this article.
Microservices are getting natural and we almost feel like we’ve been always living in the world of microservices. Lately when I talked to other developers and asked how they would start a greenfield project, almost certainly the answer was, well, one microservice for this, another one for this, another one for user management, one more for authentication, another for authorization, one more for session management, and the list could go on.
I’m gonna try to shed some light on what nobody is talking about when it comes to microservices. And yeah, it’s gonna be a first-hand experience from a past projects I worked on.
The lie
I collected some of the pros for going microservices other articles are mentioning:
- Fault isolation
- Eliminating the technology lock
- Easier understanding
- Faster deployment
- Scalability
And yeah, these are not false promises in a book but I have to be honest with you, these are not coming easily with your system just because you’re using microservices.
Let me break down each advantage from the list.
Fault isolation. Since the application is consisting of multiple services, if one goes down or something happens to it, only that part of the system will be affected. Think about Netflix, when you’re watching a show, you don’t care about the recommendations. So if they have a service to handle current watchers and provide them with the video stream; and they have another service to handle personal user recommendations. If the recommendation service goes down, the most important functionality in their system will not be affected, i.e. watching shows. The fault is isolated.
Eliminating the technology lock. Think about monoliths. It’s a huge application with hundreds/thousands of APIs, hundreds of database tables are being managed. The app was written in Java and the team spent the last 5 years on developing it. A fancy new language comes out which on paper brings better performance, provides better security, whatever. This could be Go/Rust, and the team wants to experiment with the language and it’s tech stack. How can they do it in a monolith environment? They cannot because it’s a single deployment package. You can just – at least not easily – switch out parts of the app to different languages.
While with microservices, you can use different technology stacks for different services. Service A could be written in Java, service B could be written in Go, service C could be written in Whitespace, if you’re brave enough. 🙂
Easier understanding. When you have multiple services responsible for a smaller fraction of the overall functionality, the service is going to be inherently smaller, hence easier to understand.
Faster deployment. In a regular monolith system, you either deploy completely or you don’t deploy at all. You have one package to be deployed and it’s an all or nothing scenario. With microservices you have the chance to deploy independently, meaning that if you need to deploy an upgrade to the recommendation service (going back to the Netflix example), you can totally deploy that single service and saving up serious time.
Scalability. My all time favorite. You can scale up your services by starting multiple instances to increase the capacity for a particular functionality. As the previous example stands, if people are looking at a lot of recommendations on Netflix, they can easily start multiple instances of the recommendation service to cope with the load. While in a monolith environment, you either scale every single part of your app up or nothing.
Microservices in real life
I’m gonna hit you with hard truth my friend. I’m not saying those advantages cannot be achieved but you, your project, your organization have to work really hard to make those possible.
Infrastructure requirements
Let me start with one of my biggest difficulties with microservices. The infrastructure footprint.
Have you ever deployed a monolith? Of course we can complicate it but in regular cases this is what you’ll need for a monolith if you deploy it to the cloud. Let’s take a simple online store app as an example.
- A load balancer for the app
- A compute instance for running the app
- A (relational) database for the app
- Jenkins for CI(CD)
- Kibana for log aggregation
If you’re going with a microservice:
- A Kubernetes cluster
- A load balancer
- Multiple compute instances for running the app and hosting the K8S cluster
- One or more (relational) databases, depending on whether you’re gonna go with single database per service or not
- A messaging system for service-service communication, e.g. Kafka
- Jenkins for CI(CD)
- Kibana for log aggregation
- Prometheus for monitoring
- Jaeger/Zipkin for distributed tracing
And this is just a high-level overview. This should be fairly clear. Microservices can really bring value to the table, but the question is; at what cost?
Even though the promises sound really good, you have more moving pieces within your architecture which naturally leads to more failure. What if your messaging system breaks? What if there’s an issue with your K8S cluster? What if Jaeger is down and you can’t trace errors? What if metrics are not coming into Prometheus?
Initially you’re going to spend more time (and money for that matter) to build and operate this complex system.
Faster deployments?
I’m gonna touch the first point from the advantage list; faster deployments. When you think about Netflix, Facebook, Twitter and you watch their conference talks when they describe the amount of microservices they’re running and how they can commit something to Git and within the matter of hours it’ll be in production. Is it too good to be true?
It’s definitely achievable in my opinion but I admit I’ve never ever worked on a microservice project like this. I’m not saying it’s not possible, it’s just really hard to get to, both from a stability, infrastructure and cultural point of view.
Let me share how this usually panned out from my experience. Before even doing a single line of coding on a greenfield project, you usually start with some discovery, how the product can be transformed into a technical solution. You design the system, you design your microservices, how many of them are gonna be there, responsibilities, etc.
One really education project was where we did this exercise and we ended up with 80+ microservices in what, 4 months?
What these 80+ microservices meant in reality is that we can definitely deploy faster a single service than putting the 80+ microservices together into a monolith and deploying that, but…
The 80+ microservices were so excessively small that a single development unit – story in the Agile world – was never ever fitting into touching only one service. The system was fundamentally screwed and the promise of faster deployment was gone immediately. We were not having faster deployments but the contrary, slower ones. Much slower.
Plus, and I’ll reflect back to this multiple times. More moving pieces during a deployment means more potential faults. And it happened a lot of times that the infra was not stable enough and deployments randomly failed because
- Artifactory/Nexus/Docker repo was unavailable for a tiny fraction of a second when downloading/uploading packages
- The Jenkins builder randomly got stuck
That’s just one piece of the puzzle. The product has to be decomposed into microservices. Each service should be responsible for its own thing. For example a recommendation-service in the Netflix should be responsible for giving recommendations to users.
Not everything is Netflix and definitely not everything is so easy to decompose into the right size and with the right responsibility. This is where DDD and bounded contexts can help but on one hand it’s not that easy to practice and sometimes there’s not even enough time/openness to play with these things.
The supporting culture
Anyway, in my opinion the second difficulty with microservices is the organizational/project culture. What if the product (department) doesn’t give a damn about the underlying system architecture? I mean shall they?
An example: what if you have a complex architecture with tons of microservices. The Product Owner comes in and says to the team, let’s develop this entire feature. After the team analyzes the feature request, turns out it’s going to touch 10-15 microservices because it’s connected with a lot of other existing features. What do you do in that case?
You try to break it down into smaller pieces but it smells fishy because the feature doesn’t make sense in pieces and it adds a lot of overhead to release it service-by-service. You certainly cannot say to the Product Owner it’s going to take 3-4x time just because we’re using microservices, can you?
How would that conversation look like?
- Product Owner: Hey guys, I came up with this really great feature. Our competitors are already doing it so we gotta do it quickly. Is it possible to do it in 2 weeks?
- Team: Well, by the initial looks of it, yeah, we can do it. And the feature also looks to be a good idea to bring more customers. We’ll regroup and talk it through.
- Team: Okay, slight problem with that 2 weeks. Since we’re doing microservices to be faster, we need more time to implement this thing because we have to touch 15 services, so we’d need like 6 weeks to do the initial implementation.
- Product Owner: Initial implementation?
- Team: Yeah. It’s 15 services for which the communication is critical so the initial implementation won’t include error handling, resilient communication patterns, tracing for debugging purposes and other neat things. For that we’ll need an extra 4 weeks.
- * Product Owner jumps out of the window
Better fault isolation
This one is naturally true. If one service goes down, only that service will go down right?
While that’s kinda true, it’s not black and white. Let me show you an imaginary architecture for Netflix – and I’m going to oversimplify it:
Let’s say the user wants to see recommendations. The request goes to the recommendation service and it queries the user data to know details about the user and the stores the recommendations in it’s database (which is not on the picture) and since this is user related data, they might need to encrypt it as well.
Now, what happens if the data encryption service goes down? Can we still do recommendations? Not sure, because we’re unable to encrypt the user’s data, so naturally we’ll say, hey dude, we can’t give you recommendations right now, check back in 5 mins. The fault was affecting the system only until the recommendation service and it gracefully responded with the fact that it’s unable to give recommendations right now.
But do you know how much work you have to do to gracefully handle these kind of situations? A lot.
Let’s take another example. The user tries to log in to the system using the login service. Data encryption service is still failing and the login service is calling the analytics service to have some metrics about how many users are trying to log in within a minute timeframe and some other imaginary metrics. The analytics service though is talking to the data encryption service since this data also needs to be encrypted.
Now, the team who wrote the analytics service was in a rush and didn’t have the time to implement proper error handling, so the issue with the data encryption service circles up to the login service. Apparently the login service has been done months ago and the service is not prepared for handling the underlying error from the analytics service so user logins will be simply rejected even though the non-critical analytics service failed.
And I know what you think. Yeah, the team who implemented the login service was irresponsible for not preparing it for this case but what if they thought the analytics service will handle this gracefully? That was written down in the API contract of the analytics service yet it doesn’t work that way.
So what happens when you’re in a monolith app? A service crashing doesn’t really have a meaning in that context, but assume that for some reason the database table that’s connected to data encryption is inaccessible.
In that case, the error handling will be simple because the only thing you need to prepare for is an exception. Although before praising monoliths too much, there’s the downside, if the monolith goes down, nothing works. So it’s a balance question, but ask yourself. Is it easier to implement a try-catch block or to handle a synchronous HTTP call/async messaging error?
I remember it was an enourmous to standardize error handling with the 80+ microservices and it took months for a team to finish it. And that didn’t even mean introducing error handling everywhere but just rewriting existing errors to a custom library we used so we can reduce the tedious work required for future error handling scenarios.
Takeaway
I’m not finished. See you in chapter 2.
Update: chapter 2 is here, The truth about starting with microservices.
P.S. follow me on Facebook/Twitter if you feel like.
This is some ***** (moderated by admin). Your lists of requirements for monolith vs. microservices is so biased, it’s painful.
So you need a load balancer with your monolith, but you still only have one compute instance running. Then why do you need a load balancer? That’s what I thought: You will have multiple compute instances with your monolith, same as with your microservices.
Would you need a Kubernetes cluster just because you have multiple compute instances? No, of course you won’t, so let’s scratch that from the list.
No, you don’t need a messaging system for interservice communication, just because you have microservices. I don’t know where you got that idea from – presumably just more nonsense spawned from ignorance.
Next up is “Prometheus for monitoring”. So apparently you only need monitoring when you use microservices? Monitoring doesn’t matter with a monolith? What kind of nonsense is that? It’sl ike you read some guide that said “monitoring is important” in conjunction with microservices – then you look at your own monolith setup, noticed you didn’t have monitoring, and concluded “oh, monitoring must be a microservices thing”, which is obviously wrong.
Lastly, you meantion distributed tracing. Not essentially, but admittedly useful with microservices. In conclusion: You _need_ the exact same things whether you use a monolith or microservices.
You fully live up to my expectation of how a cookie-cutter Java developer thinks the world works.
Why are you angry ?
It is not only him saying microservices is not that great, nearly every seasoned architects and leads I read articles of say the same, check uncle bob view on microservices for example.
That was ok until you mentioned that fraud of “uncle Bob”. Last guy to take advices from, the guy is not into microservices for one major reason: it doesn’t work with his world view and make most of his stuff very obsolete.
I agree with you on that point. Uncle Bob is probably not the best person to look for advice around microservices.
Why is “Unlce Bob” a fraud? I am not a fan of his politics but found many of his coding concepts pretty helpful.
Relax. Clearly there are tradeoffs and this is highlighting how microservices don’t magically solve everything and have their own problems. Like when something like a logging framework has a RCE and you need to patch and deploy 8 billion things.
That’s very true. The recently discovered Log4J vulnerability is one example of the pains. Upgrading dependencies might look easy at first sight but the thing is, after each upgrade you have to test your components individually if anything is broken and you have to test your system together.
Testing could be a pain in the butt if you don’t have a reasonable amount of automated tests.
By default, force a Null Pointer Exception if a dependency fails a Unit Test.
When all dependencies passes Unit Tests, then do End to End test.
Most of the bullets track with microservice systems I’ve seen in the wild. Need or not, many (if not most) microservices have them. Your last sentence is very salty and makes me wonder if you designed a microservices architecture that doesn’t work and everyone hates.
> Need or not, many (if not most) microservices have them.
Well this speaks more towards people using microservices wrong rather than microservices being wrong.
> Your last sentence is very salty and makes me wonder if you designed a microservices architecture that doesn’t work and everyone hates.
As someone who have built a microservice platform as a service my impression is that when someone applies the design principle of a monolith to a microservice architecture you will have a bad time. This is an inherent feature of Java developers IMO.
“Well this speaks more towards people using microservices wrong rather than microservices being wrong.”
Microservices cannot fail, they can only BE failed.
“Well this speaks more towards people using microservices wrong rather than microservices being wrong.”
Of course of course.. same story with EJB 2.. they used them wrong..
In other words, stop the bullshit. And I mention EJB, because same as with “microservices”, it is another solution searching for a problem. But then, at least EJB had a spec 🙂
**conclusion: You _need_ the exact same things whether you use a monolith or microservices.**
yeah but you need exactly one of each of these things for a monolith, you need n of each of these things for microservices … 1 is waaaay simpler then n.
Again, this is a matter of how well you built everything.
Generally speaking I think you’re right but if you have the right amount of automation and validation frameworks in place that makes it a 1-clicker to spin up a new ElasticSearch instance and put it into the cluster, then it’s easy.
What I’ve seen so far is there’s lack of automation available and every single infrastructural change is painful as hell, yet I’m not saying there isn’t an environment where the opposite is true.
This is needlessly salty, and your gotchas aren’t really as strong as you think they are.
“That’s what I thought: You will have multiple compute instances with your monolith, same as with your microservices.”
It’s trivial to configure deploying multiple compute instances behind a load balancer when deploying a monolith, and that is NOT the same thing as deploying multiple microservices, which usually live in different codebases and may even have different deployment configurations altogether. That is a false equivalency.
Agreed.
Using foul language adds nothing positive to the point you’re making.
In fact, it portrays your message as more of a temper tantrum, and you – in that moment at least – as someone who lacks respect for others.
Thanks Michael. 😉
I think you’re missing the point. You’re correct you don’t necessarily need tool “x” or framework “y” in either scenario.
I think the point is, splitting into microservices adds cost in terms of time and effort you should weigh against the classic challenges of a monolith. Like everything, there are tradeoffs.
Thank you for the article, I enjoyed reading it.
It really describes my experiences with micro-services so far (2 companies).
Hoping that you will talk about the absurd numbers of different programming languages in a single project in your next article!
PS: I hope you won’t be too affected by the negativity of the previous comment
Hi Dorian,
Thanks for the support and I’m glad you liked it. I wanna make it clear I’m not stating whether microservices or monoliths are better or as a matter of fact any architectural pattern is better than the other. I’m just trying to give perspective to others what people are not thinking about when deciding one way or another.
On the programming languages, absolutely. Again, I have personal xp here where the architecture was heterogeneous and contained 5 different languages.
> I hope you won’t be too affected by the negativity of the previous comment
Thanks dude for the support. 😉 The positivity of these comments beats the negativity of the few people. :))
One thing is true, if you use log4j in microservices, you have to build and deploy it many times for the same fix. And this is true for any form of vulnerabilities found, you will find that you ended up managing updates to dependencies a lot of time, this can become time consuming.
Another unmentioned reasons why microservices can be bad is that, microservices uses network to communicate among objects whether it is http, or msg bus, and these things fails more than just doing it as simple in process calls.
It’s all about tradeoffs, just like the article says.. START with monolith.. after you have experience and knows the pitfalls then you make a decision on to having microservices. What i found is that inexperienced ppl just go start with microservices.
P.s. i run a system thay has to 400+ microservices, been there, done that! Dont be rude and respect others opinion
Hi Jancker,
Really agree with the Log4J vulnerability there. I’ve done that exercise many times with Spring upgrades and other dependencies.
On your other point with network communication. I completely agree and it was only briefly mentioned in the article. It’s hard to fit everything into a single one that’s why there’ll be a chapter 2.
> What i found is that inexperienced ppl just go start with microservices.
This is so true. It’s about evolution both organizationally and technically. You won’t immediately know how to do microservices right, you have to learn it. But the thing is, every beginning is difficult and we best learn from mistakes, so I simply think mastering microservices can only be done via failing a couple times.
Cheers.
This comment is a bit off topic but this article reminds me on (from my point of view) a very common misunderstanding.
1. There is no either microservices (ms) or monolith (ml). In most cases you want to provide a ms backend and in most cases you dont want ms in the frontend. Because this is what brings complexity to another level and often results in burning hell.
2. A ms does not have to be micro, nor does there only be one task to solve. Its like louse coupling to a corresponding service but strong cohesion to strongly dependent tasks. There is no need to scatter everything up because of the word micro.
3. A lot of services in a kubernetes cluster need less to zero attention after the initial configuration, like CNI for example.
4. When it take 10 weeks to implement a POC in a system which should actually be desinged for a certain concept in general, like Netflix is for streaming. Then maybe the conditions werent clear enough from the beginning which raise the questions for a redesingn. Maybe the task is hard to put in the existing system because it does not belong there, so you should think of maybe there is a service which solves most of this task by it self and connect the result to the system.
Micro-service means it is front end. Modular-service means it is back end with monolith as a front end.
Hi Ben,
Thanks for the comment. Maybe it wasn’t clear but I didn’t try to decide whether you should go microservices or monoliths because one of them is better. I wouldn’t do that. Everything is about tradeoffs and balance. I was just trying to shed some light on why it’s important to see the dark side of doing microservices wrong because often people just think there’s only benefits coming with the architectural pattern.
Cheers.
Some of the negatives you raised against MS are glass-half empty. You can invest more tooling around observability because it is easier to do so. You won’t have to retry reproducing the production environment locally to see which subsystem is failing.
The key point you raised, I have to agree. The cost & complexity associated with inter-service comms is usually not worth the hassle.
You’re definitely more competent than the other guy. 😉
Thanks.
I have mixed feelings for both Microservices and Monolith. To me what matters is continerization and cloud native.
Continerization – it doesn’t matter whether it is Microservices or monolith. Converting app into container and using orchestration like Kubernetes definitely helps.
Cloud Native – Ability to scale without service restarts.
I think the mixed feeling is okay. You just have to recognize and objectively decide which architectural pattern is more suitable for the problem you’re trying to solve. It’s about balance and tradeoffs.
Micro-service (and object-oriented language in general) is using another level of indirection to solve the problem with too many layers of indirection.
“All problems in computer science can be solved by another level of indirection.” –Butler Lampson quoted David Wheeler with a truncated statement.
“All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection.” –Kevlin Henny fixed Lampson’s wrong quote.
When you reach the point that microservices need Kubernetes and multiple instances, and monolith doesn’t… You can stop reading this because author doesn’t understand anything about deployment and scaling.
If you continue reading, you will see that monolith does not need monitoring, for example.
People like those should really gain some experience before writing low quality articles.
Thanks Jehy. I hope the article didn’t offend you too much and I hope you can forgive that I wasn’t able to fit in every single monolith use-case into it.
Believe it or not, there are still a ton of monoliths running in single instance mode and simply putting more resources into the machine solves the scaling issue and that’s why I chose this use-case over another one.
Cheers.
I like the post, and agree with most of the issues mentioned.
With microservices there is a trade off between increased complexity and more agility. An the optimal solution may depend on the complexity of your business domain.
If you want to implement a core banking with microservices, you end up having several hundreds of microservices, that need to cooperate for most of the business functions, so there are a lot of API calls between them, so finally you have a distributed monolith. The result is much more management complexity (troubleshooting, deployment) and compromised agility.
Something in the middle between a unique monolith and a pure microservices design maybe a better fit.
Just my opinion.
Hi Javier,
I have to agree with you and that’s one of the points I’m planning to cover in chapter 2, organizational/management complexity.
Probably you’ve also seen projects do microservices on paper yet scheduling monthly/bi-monthly releases and deploying it like a full monolith.
Cheers.
Seems this clickbait article reached its goal – Starting a heated discussion, bringing it up in the google ranking. So let me help you on that: I barely saw an article that brought up the downsides of a poorly designed microservice architecture in such a way. I could write the same article flipped upside down pro microsservices
Hi Marc,
I’m sensing some anger from your comment, maybe I’m wrong though. I didn’t make the article clickbait at all – at least in my opinion – and I didn’t even plan to start the “heated” discussions here, hackernews or reddit. I’m sorry my friend but you’re wrong here.
I’m totally open to your objective arguments but I didn’t read any, only that you didn’t like the article.
And to be fair, I wasn’t trying to decide for you or anybody whether or not to go with microservices or monoliths. I was trying to shed some light on the downsides I experienced with them. These I points I didn’t really read from other people so far yet I see from the “heated” discussions it happens to a lot of other folks as well.
While, in fact, I wouldn’t start an MVP with microservices.
Articles saying “don’t do this, do that” are usually biased towards one thing or another, and these are the articles I rarely agree with. I’d say if you go with the wrong architecture for your project, you will inevitably experience most of the pain points, no matter if this is a monolith or microservices based app.
If you start building your microservices splitting everything into pieces so small you end up with 80+ microservices in a short time, my guess is you started splitting up too soon and some of these services could be logically aggregated. If there are issues with communication, error handling etc., maybe some things weren’t given enough development time in the early stages, before moving on? As always, it comes down to predicting the impact of your architecture decisions.
These things aren’t black and white, both solutions have pros and cons; the art is in finding the balance and choosing whatever works best for your scenario. I think the frustration comes from making the wrong choice early on and sticking to it.
> Articles saying “don’t do this, do that” are usually biased towards one thing or another, and these are the articles I rarely agree with.
I fully agree and I think the same. That’s why I didn’t say who’s the winner decision for me because there’s none. You gotta be able to recognize when or not to use an architectural pattern for a problem you’re having. They have pros and cons, you have to compare. The point I was trying to make is to see what are the other potential issues of microservices if done wrong, from my experience.
> If you start building your microservices splitting everything into pieces so small you end up with 80+ microservices in a short time, my guess is you started splitting up too soon and some of these services could be logically aggregated.
Well, the thing is, this project I was referring to started as microservices from the beginning. There were a couple people who were initially on the project and thought this will be a good fit. Well, it wasn’t.
And eventually we spent like almost a year to reduce the number of services to 5 by merging a lot of them into logical pieces.
> These things aren’t black and white, both solutions have pros and cons; the art is in finding the balance and choosing whatever works best for your scenario. I think the frustration comes from making the wrong choice early on and sticking to it.
Absolutely, it’s a balance question, as always.
In terms of frustration, I don’t have any but the second point you’re making there is true. Making the wrong choice early on and sticking to it. It was kind of easy to reliaze this is not the path we want to go down but the product pressure is always there, feature development, production releases, security fixes. It’s a balance question as well. We weren’t able to back off but as I said, we at least were able to reduce the amount of services to 5 in a year.
Thanks for sharing your thoughts.
Cheers.
So I guess we do agree in our point of view after all! Maybe the title was a little harsh and the ending is abrupt, so it’s easy to misinterpret it. I’m waiting for the part 2 to read the conclusions, but it all makes sense to me after that comment.
Ah, the product pressure. I wish people managing the product understood the deadlines are not everything, but sadly that’s often not the case and there’s no time to do proper POCs. So if you started on the wrong foot, well…
About the frustration, I didn’t mean you in particular, I was rather referring to the general frustration that people face from using microservices architecture the wrong way. I observe this quite often. Sorry if it came out more like a personal attack, I didn’t mean to 🙂
Have a good day.
> I wish people managing the product understood the deadlines are not everything, but sadly that’s often not the case and there’s no time to do proper POCs. So if you started on the wrong foot, well…
Yeah absolutely. What a lot of people and organizations don’t understand – at least that’s what I think – is the fact that microservices or as a matter of fact any architectural decision is a commitment on some level and not only developers but product also has to respect that something has pros and cons.
> About the frustration, I didn’t mean you in particular, I was rather referring to the general frustration that people face from using microservices architecture the wrong way. I observe this quite often. Sorry if it came out more like a personal attack, I didn’t mean to 🙂
Got it and no offense taken. 😉
This is what I call a a constructive discussion.
Cheers.
Thank you very much for the post, it’s an interesting point of view, I don’t have much experience n microservices yet, but I agree that DDD helps. My criteria are that we should always face a problem with a decoupled monolith with the help of DDD, that is easy to grow and above all EVOLVE, either in several microservices, modules, or more monoliths. After all, each problem and comply s a different world, or as you mention not all are Netflix.
Greetings from Ecuador.
That’s a very important point. Evolution. Both the organization and the system have to evolve with the new requirements otherwise it’s a lost fight in my opinion.
Cheers dude and thanks for the support. 😉
Agile teaching us to iterate. If you can afford a development with iterations its better to start with a MVP product to check your ideas and monolith here allows to start quick. You can make a layered component based monolith witch later will allow you to extract some parts as a microservices. You don’t have to have a perfect solution in one step.
Been in an unicorn organization with 50 different microservices. I won’t say much here because I don’t have time to explain.
Use your sixth sense. If your management seems to know what kind of beast they are dealing with, you’ll enjoy your ride and learn alot.
If not, get out ASAP
Most, if not all, of the points and issues you pointed out, has absolutely nothing to do with the idea of microservices. It’s simply by organizational culture, people problems, and lack of programming skills to implement distributed systems without creating a distributed spaghetti.
Do not fight with science
I find it funny that the article triggered all of these discussions in the comments section (purposely or not). I personally found your article to be interesting, although sometimes it seems like the problems you mention aren’t necessarily a “microservices problem” but rather issues with a bad overall design of the system, poor decision-making, or bad practices. Still, I enjoyed the read. Looking forward to part-2!
I agree with the author.
The recent Log4J vulnerability is the perfect example of pain with a micro service architecture.
You have to update manually ALL repositories and to deploy them again. By the way: It could become the same pain, if everyone is using its own Docker container as operating system layer.
I struggled with the concerns reported in this article in the past.
But with more experience and by reading more books and applying the principles I’ve read, now I don’t have the problems listed here anymore.
I think a lot of takeaways in this article could be fixed just with more knowledge and culture.
I agree: Microservices is not a silver bullet… mostly if you (like many many others) are chaining microservices. You are not making microservices at all, just encapuslating methods as services.
Where microservices is usefull is to provide an END functionallity (it should not depend on any other microservice). Of course, this is more difficult to accomplish, and you might end up having just a service (“not micro”).
But, if you can get it, then you can delete your article 🙂
You shouldn’t start with neither microservices nor monolith. You should start with event storming.