6 ms·

Don’t you find it weird that everybody else is either over or underengineering, but you, you engineer things exactly the right amount? I bet when you’re drivin

Don’t you find it weird that everybody else is either over or underengineering, but you, you engineer things exactly the right amount? I bet when you’re driving, you also tend to notice that everyone else is either an idiot driving way too slow in the middle lane or a maniac speeding past you. Nobody else drives as well as you do. It must be exhausting for these people to live in a world surrounded by strawmen, while they alone have achieved perfection. Which they will detail how they do in a later blogpost.

disintegore 4y ago
It does not appear that you have read the article
jfoster 4y ago
I would argue the inverse. If you reject both extremes, and are somewhere in the middle, you probably are much closer to something reasonable. (both in engineering and when driving)
- philosopher1234 4y ago
  Doing the average of everything is a great way to be pretty wrong. If you have to guess, guessing average seems fine, but if you know better, going with the herd can be foolish.
  - jfoster 4y ago
    If the herd is at one extreme or the other, the middle ground is the opposite of going with the herd. It could be unpopular because it's wrong, or it might be the insightful choice. Critical thinking will probably help figure out which it is.
- jameshart 4y ago
  I actually chose driving speed very deliberately. When you drive down a freeway, no matter what speed you are driving at, you will see far more cars traveling at a different speed than you than at the same speed. The cars going at the same speed as you never pass you and you never pass them. The only cars you notice are the ones who are driving differently. It is easy to convince yourself that you are taking the sensible middle course, no matter what speed you are driving at. Because you can always point to an extreme outlier and say ‘I’m not that guy’.
strken 4y ago
This post reads more like "I created an overengineered microservice architecture once and I'm now jaded because of my bad experiences." See "10 years ago I wanted modules, but I as well found microservice architectures." It's in the same genre as "I nearly wrapped myself around a tree and now I drive slowly when it's wet", not "I am perfect and everyone else is wrong."
gfodor 4y ago
You could say this about any criticism of mainstream practice. This is not a rebuttal and contains no new information. Actually, I lied - this post is actually a strawman: it contains the information that you actually didn’t understand the point of the article. He is referring to people who have deployed microservices when they needed modules, not people who deployed microservices when they needed microservices.
- _ea1k 4y ago
  TBH, his definition of "module" brings it awfully close to microservice.
  - JAlexoid 4y ago
    Common definition of a microservice is basically a module. This is not the first thread on the topic. And considering the number of people actively defending microservices, like it's debates about iPhone vs Android over a decade ago - I'm going to say that too many people can't rationally look at this at this point. Too many emotions flying around.
  - gfodor 4y ago
    I thought he was referring to typical in-process encapsulation. If you do that well, you can run those separately “for free” optionally, but I think his definition of module is nothing unique.
    - _ea1k 4y ago
      From the article: "Modules which can be easily be deployed independently - when the need arises." I read this to mean that they would always be deployed independently, but now I think I misread it. He actually meant that they should be really easy to split. In practice, I think people with this view underestimate the difficulty in splitting even seemingly unrelated services from a monolith. Its never completely trivial. Its better not to start that way if it is foreseeable as an undesirable end state.
deleted 4y ago
[deleted]
PaulHoule 4y ago
I get the feeling he really misses the point. The most dangerous thing about microservices is that many people squee when they hear "You can write 45 different microservices in 35 different languages". Writing a new microservice? What a great opportunity to learn a new language! Now it is true that by decoupling the address spaces microservices do let you take advantage of different runtime systems: you might really want access to scikit-learn in Python, for instance, certain libraries available in Java, but also like the speed of Go. That's alright, to a point. If a microservice system is going to be maintainable you need to minimize the excessive complexity of using different libraries and frameworks for build, configuration, serialization, logging, database access, and other cross cutting concern. To the extent that that stuff is standardized the programmer who works on service Q can do some work on service B and be focused on the application instead of having to do a research project on where to put a configuration variable or log a message. It's hard to do because in the microservice environment people seem to get a lot of joy out of not being disciplined, will make endless excuses why they can't update the version of the language they are using, etc. It's the kind of freedom that Orwell warned you about.
- jameshart 4y ago
  Not having to upgrade in lockstep is great though - the downfall of many monoliths is the ‘forced death match to port to new version of the platform because we put this off so long it’s about to leave LTS’. Being able to use different stacks where appropriate is also great (but needs care). E.g. if you are a Java shop but you want to deploy an ML pipeline you should at least consider carving out a pathway for deploying python microservices.
  - PaulHoule 4y ago
    I'm not against having more than one runtime or some variation in component versions. But you've got to be deliberate about it, not blunder into it the way most people do.
  - JAlexoid 4y ago
    I'm sorry, but as someone that actually works on ML pipelines - no ML is a microservice. Data space doesn't work well with microservices.
asddubs 4y ago
now I'm not a fan of microservices, but I'll be the first to admit that whenever I finish anything I look at it proudly and mutter "hmm, this sucks"
hot_gril 4y ago
You may not like it, but my nodejs server with nearly all the code in a single file, and most of the business logic in inlined SQL, is what peak swe looks like.
jeffbee 4y ago
Nailed it. This kind of post belongs to a genre where "micro" is tautologically defined to mean "too small". The rest of the post follows logically and could have been written by an automaton.
thatwasunusual 4y ago
Wow. Is there a way to favorite a comment on HN, because this is so spot on. I've worked on _a lot_ of different applications, and all of them have their ups and downs. Knowing when to implement a micro service, and when not to, depends on experience and knowledge of the application(s) at hand. Same goes for _everything else_ in the software world. How many of us hasn't used something wrongly in our dev-life time?
- deleted 4y ago
  [deleted]
- nsomaru 4y ago
  Click on the comment time stamp then click “favourite” in the comment header.
csomar 4y ago
What the author or many people miss is that this is still an unsolved problem. We still don’t know how to do this right. Doing it either way results in unmanageable complexity. The same still goes for the front-end. It’s too complex that someone decides to start another JS framework to fix the status quo. What many people miss is that these attempts are the solution to the problem. People will keep trying different ways until they find the “optimal” (or close) solution and the problem space is solved. React, in some sense, made front-end development at this level of complexity accessible to so many people with little engineering know-how.
- CuriouslyC 4y ago
  We are closer than that. Services are just aggregation layers for functions. The functions are the things of interest, and the aggregation/abstraction is meaningless from a runtime perspective. By creating a function-first architecture (ala Lambda) using a runtime with a common compilation target (e.g. WASM), you can have a single code-base with hints/IDE navigation while also allowing for polyglot execution.
  - dagss 4y ago
    I think many (including me) would still consider an application written in Lambda functions a monolith. It's how databases are used etc. that matters for service boundaries. There really isn't that much difference between a stateless monolith deployed in k8s, a Lambda function, and a microservices with one function in each service ... it's all just stateless code anyway.
- neffy 4y ago
  At some level it both is and it isn't. The problems behind scaling a distributed application are quite well understood at this point, the problem that hasn't been solved is that too many won't accept the answer in terms of development time and discipline. The mess that could be created with micro-services which simply recreated the mess within the monoliths, was both predictable and predicted. At some level it's the Forth Bridge all over again. The Forth bridge was constructed within 10 years of the Tay Bridge disaster. It wasn't that civil engineers of that time didn't know how to build bridges that wouldn't fall down, they just hadn't learned to not go with the lowest bidder.
jacquesm 4y ago
This happens a lot. Otoh, sometimes you come across cases where you wonder if you accidentally landed on a different planet. Mid sized project, 500 microservices, 800 repositories...
- jameshart 4y ago
  And sometimes when you’re driving you’ll pass a car upside down in a ditch and think ‘glad I’m not that guy’. But you know that can still happen to you, right? Even if you’re careful? The sales team promised a massive contract; the system design has to be able to hit x TPS to make it; we need to pull out the stops and build to scale for that and to allow for all this future expandability. Six months later, that sales director has left, the product has pivoted, and you’re ‘over engineered’.
  - jacquesm 4y ago
    > And sometimes when you’re driving you’ll pass a car upside down in a ditch and think ‘glad I’m not that guy’. No, I'd stop and see if I can help.
    - jameshart 4y ago
      For the purposes of my analogy, please assume the police are on the scene already and directing you to continue driving past.
  - JAlexoid 4y ago
    This ties into the fallacy that microservice architecture is inherently infinitely scalable. Microservice advocates championed this fallacy, implemented it... but now, when it's time for critical retrospective - it's not their failure.
  - candybar 4y ago
    Being able to scale to any specific amount of usage is never a reason to use microservices. Plenty of planet-scale services and apps are powered by monoliths. And you never run into any kind of ridiculous overengineering when you refactor things into services for scaling reasons and that's not a microservices architecture in the first place. The problem has always been about people deciding that different parts of the app that differ mostly in terms of business logic somehow need to be independently deployable. It's like deciding that instead of having a single database cluster and having multiple databases and tables, you need a separate, independently scalable cluster for each database table, because of some bogus reasons like some tables are queries more than others and different teams work on different tables and we can't let people join tables because it breaks boundaries or something.
kemiller2002 4y ago
I don't understand. Why would I build something that isn't correct? (jk, excellent comment.)
Lapsa 4y ago
I don't know... perhaps a bit harsh but article seems reasonable to me. I'm also yet to see "wow, what an engineering!" application that heavily depends on microservices. mostly it does feel like an unnecessary complex pile of mud.
- jameshart 4y ago
  I’m honestly mainly reacting to the part where they judge interview candidates on the basis that they worked on systems that implemented microservices. It is hubristic in the extreme to sit in judgement over the architectural choices a team has made on a system you don’t know or understand, and just downright rude to conjecture all the worst failure modes of that architecture and then assume that they constitute what your candidate values. The only thing you can extract from talking to a candidate about their past projects is their impression of that project. What did they learn? What architectural choices did they like and why? What choices do they regret? Just because they made a choice you wouldn’t have does not mean they are irredeemably broken. ‘Oh, you worked on microservices. Bet it was a big ball of mud.’ then you ask a bunch of questions to confirm that suspicion - you’re just dumping your prejudice against an approach onto someone who might have learned something useful from their experience of working on that thing! And if they did work on a badly architected micro service system, maybe they learned ‘micro services often turn into a big ball of mud, I’ve seen it happen’. Maybe through that experience they learned something about how to avoid that fate? Or maybe they now share your opinion that microservices are a terrible idea; and if you like hiring people who agree with all your ideas then they would be a great add to your team. We have all worked on systems that had architectural flaws. We have all built systems with architectural flaws. What matters is how we took those lessons and incorporated them into our understanding and taste for what makes good architecture.
  - bvrmn 4y ago
    > It is hubristic in the extreme to sit in judgement over the architectural choices a team has made on a system you don’t know or understand, and just downright rude to conjecture all the worst failure modes of that architecture and then assume that they constitute what your candidate values. It's more like a cultural fit. Microservice oriented people brings too much friction into the process.
ThereIsNoWorry 4y ago
Yeah, it's crazy the hate microservices get. I happen to work on a product that needs to scale to handle millions of transactions distributed all over the world and the cloud microservice system is just flawless for this purpose. Is it harder to debug than a monolith? Sure. You need a team that has a good understanding about distributed systems (most coworkers have degrees and the ones without are really good at self-teaching, kudos to them). Could you easily develop our system in a monolith? No, it would be a nightmare, if even feasible given the same availability, security and performance constraints. I totally agree not everyone works on stuff I love to work on (huge scalable systems), but Google and co didn't engineer this tech because they felt like it, but because there was a clear need for it.
- brightstep 4y ago
  > cloud microservice system is just flawless for this purpose > Is it harder to debug than a monolith? Sure. Doesn’t sound flawless to me
- leidenfrost 4y ago
  Often the microservices hate is around sole developers ranting about how a waste they are, and how everything would be way better if only everyone was very careful and had good practices totally as second nature. And it's similar in nature as the hate around high level languages: "If only everyone had decades of experience with C, "toy languages" wouldn't exist and programs would be lighter and faster today".
- FpUser 4y ago
  >"Could you easily develop our system in a monolith?" You have a specific requirement and constraints that call for your system to be distributed. However solutions applicable to majority of regular businesses do not require high scalability and can get easily away with monolith. I've personally built both types of systems: distributed and monoliths. My take is to always stick with the monolith until you can't.
- JAlexoid 4y ago
  The "hate" is directly proportional to the failure of microservice zealots to deliver on the ultimate, everlasting, universal prosperity and harmony, that they promised.
pammf 4y ago
Nailed it.
zug_zug 4y ago
Uh… the authors point was to achieve isolation by modules, not network boundaries, so I think your point is irrelevant
fckgnad 4y ago
Don't you find it strange that YOU live in a world where everyone else but YOU thinks that everyone else around them is over engineering or under engineering things? You're not the guy who thinks everyone else is a maniac and is driving too fast or too slow. You're the guy who thinks everyone but you is under this delusion of thinking that everyone else is a maniac and you think you are an exception to the delusion because you can see it in other people. I am here to tell you that there is a higher plane of understanding. This higher plane of understanding is this: Even when you are aware that others are prone to biased and fallacies, this awareness does not make you immune to those same biases and fallacies. Because what you understand is also cliche. You are voted up because your awareness is also shared by others. Others observe the biased and fallacies of other people and think that they themselves are above it when in actuality everyone is just looking at each other. We are all mirrors. There is an even higher plane of understanding. I am not on this level and neither are you. This plane of understanding is the realization that one of us is NOT delusional. Someone is actually right. Someone sees the reality of how something should work and he is right and he is ACTUALLY surrounded by straw men. The tragedy of the design of computer programs is that we have no theory of efficiency, no theory of what is most optimal. So if someone is right, we have no way of knowing. We are doomed to forever live in a world of blog posts where one of those blog posts is right but we can't know for sure. You obviously wrote this because you think that the author of the blog post is NOT that man. But because we have no theory to prove otherwise, you simply state common tropes of human fallacies and biases and you use that analogy to discredit his post. It's pointless. Analogies aren't proof, they are themselves delusions but weaponized and used to seemingly prove a point or discredit one. They are convincing but manipulative. Your post can actually discredit every blogpost in the universe and that is why it is useless, pointless and manipulative. Rather then write sweeping analogies of human biases which can actually "disprove" every single blog post on the face of the earth... offer evidence and example scenarios about why you disagree. Because personally I think the blog poster is right. His thoughts on microservices is correct. Convince me about why he isn't that one guy who is actually right, but know that the argument is endless because none of us can actually verify anything.
- bradhe 4y ago
  If you ask a room full of 100 engineers if they are better engineers than their peers, 80 of the 100 will say yes.
techdmn 4y ago
You should credit the late great George Carlin for this. :-) "Look at this idiot here!" "Whoa, look at that maniac go!"

disintegore 4y ago

It does not appear that you have read the article

jfoster 4y ago

I would argue the inverse. If you reject both extremes, and are somewhere in the middle, you probably are much closer to something reasonable. (both in engineering and when driving)

philosopher1234 4y ago
Doing the average of everything is a great way to be pretty wrong. If you have to guess, guessing average seems fine, but if you know better, going with the herd can be foolish.
- jfoster 4y ago
  If the herd is at one extreme or the other, the middle ground is the opposite of going with the herd. It could be unpopular because it's wrong, or it might be the insightful choice. Critical thinking will probably help figure out which it is.
jameshart 4y ago
I actually chose driving speed very deliberately. When you drive down a freeway, no matter what speed you are driving at, you will see far more cars traveling at a different speed than you than at the same speed. The cars going at the same speed as you never pass you and you never pass them. The only cars you notice are the ones who are driving differently. It is easy to convince yourself that you are taking the sensible middle course, no matter what speed you are driving at. Because you can always point to an extreme outlier and say ‘I’m not that guy’.

strken 4y ago

This post reads more like "I created an overengineered microservice architecture once and I'm now jaded because of my bad experiences." See "10 years ago I wanted modules, but I as well found microservice architectures." It's in the same genre as "I nearly wrapped myself around a tree and now I drive slowly when it's wet", not "I am perfect and everyone else is wrong."

gfodor 4y ago

You could say this about any criticism of mainstream practice. This is not a rebuttal and contains no new information. Actually, I lied - this post is actually a strawman: it contains the information that you actually didn’t understand the point of the article. He is referring to people who have deployed microservices when they needed modules, not people who deployed microservices when they needed microservices.

_ea1k 4y ago
TBH, his definition of "module" brings it awfully close to microservice.
- JAlexoid 4y ago
  Common definition of a microservice is basically a module. This is not the first thread on the topic. And considering the number of people actively defending microservices, like it's debates about iPhone vs Android over a decade ago - I'm going to say that too many people can't rationally look at this at this point. Too many emotions flying around.
- gfodor 4y ago
  I thought he was referring to typical in-process encapsulation. If you do that well, you can run those separately “for free” optionally, but I think his definition of module is nothing unique.
  - _ea1k 4y ago
    From the article: "Modules which can be easily be deployed independently - when the need arises." I read this to mean that they would always be deployed independently, but now I think I misread it. He actually meant that they should be really easy to split. In practice, I think people with this view underestimate the difficulty in splitting even seemingly unrelated services from a monolith. Its never completely trivial. Its better not to start that way if it is foreseeable as an undesirable end state.

deleted 4y ago

[deleted]

PaulHoule 4y ago

I get the feeling he really misses the point. The most dangerous thing about microservices is that many people squee when they hear "You can write 45 different microservices in 35 different languages". Writing a new microservice? What a great opportunity to learn a new language! Now it is true that by decoupling the address spaces microservices do let you take advantage of different runtime systems: you might really want access to scikit-learn in Python, for instance, certain libraries available in Java, but also like the speed of Go. That's alright, to a point. If a microservice system is going to be maintainable you need to minimize the excessive complexity of using different libraries and frameworks for build, configuration, serialization, logging, database access, and other cross cutting concern. To the extent that that stuff is standardized the programmer who works on service Q can do some work on service B and be focused on the application instead of having to do a research project on where to put a configuration variable or log a message. It's hard to do because in the microservice environment people seem to get a lot of joy out of not being disciplined, will make endless excuses why they can't update the version of the language they are using, etc. It's the kind of freedom that Orwell warned you about.

jameshart 4y ago
Not having to upgrade in lockstep is great though - the downfall of many monoliths is the ‘forced death match to port to new version of the platform because we put this off so long it’s about to leave LTS’. Being able to use different stacks where appropriate is also great (but needs care). E.g. if you are a Java shop but you want to deploy an ML pipeline you should at least consider carving out a pathway for deploying python microservices.
- PaulHoule 4y ago
  I'm not against having more than one runtime or some variation in component versions. But you've got to be deliberate about it, not blunder into it the way most people do.
- JAlexoid 4y ago
  I'm sorry, but as someone that actually works on ML pipelines - no ML is a microservice. Data space doesn't work well with microservices.

asddubs 4y ago

now I'm not a fan of microservices, but I'll be the first to admit that whenever I finish anything I look at it proudly and mutter "hmm, this sucks"

hot_gril 4y ago

You may not like it, but my nodejs server with nearly all the code in a single file, and most of the business logic in inlined SQL, is what peak swe looks like.

jeffbee 4y ago

Nailed it. This kind of post belongs to a genre where "micro" is tautologically defined to mean "too small". The rest of the post follows logically and could have been written by an automaton.

thatwasunusual 4y ago

Wow. Is there a way to favorite a comment on HN, because this is so spot on. I've worked on _a lot_ of different applications, and all of them have their ups and downs. Knowing when to implement a micro service, and when not to, depends on experience and knowledge of the application(s) at hand. Same goes for _everything else_ in the software world. How many of us hasn't used something wrongly in our dev-life time?

deleted 4y ago
[deleted]
nsomaru 4y ago
Click on the comment time stamp then click “favourite” in the comment header.

csomar 4y ago

What the author or many people miss is that this is still an unsolved problem. We still don’t know how to do this right. Doing it either way results in unmanageable complexity. The same still goes for the front-end. It’s too complex that someone decides to start another JS framework to fix the status quo. What many people miss is that these attempts are the solution to the problem. People will keep trying different ways until they find the “optimal” (or close) solution and the problem space is solved. React, in some sense, made front-end development at this level of complexity accessible to so many people with little engineering know-how.

CuriouslyC 4y ago
We are closer than that. Services are just aggregation layers for functions. The functions are the things of interest, and the aggregation/abstraction is meaningless from a runtime perspective. By creating a function-first architecture (ala Lambda) using a runtime with a common compilation target (e.g. WASM), you can have a single code-base with hints/IDE navigation while also allowing for polyglot execution.
- dagss 4y ago
  I think many (including me) would still consider an application written in Lambda functions a monolith. It's how databases are used etc. that matters for service boundaries. There really isn't that much difference between a stateless monolith deployed in k8s, a Lambda function, and a microservices with one function in each service ... it's all just stateless code anyway.
neffy 4y ago
At some level it both is and it isn't. The problems behind scaling a distributed application are quite well understood at this point, the problem that hasn't been solved is that too many won't accept the answer in terms of development time and discipline. The mess that could be created with micro-services which simply recreated the mess within the monoliths, was both predictable and predicted. At some level it's the Forth Bridge all over again. The Forth bridge was constructed within 10 years of the Tay Bridge disaster. It wasn't that civil engineers of that time didn't know how to build bridges that wouldn't fall down, they just hadn't learned to not go with the lowest bidder.

jacquesm 4y ago

This happens a lot. Otoh, sometimes you come across cases where you wonder if you accidentally landed on a different planet. Mid sized project, 500 microservices, 800 repositories...

jameshart 4y ago
And sometimes when you’re driving you’ll pass a car upside down in a ditch and think ‘glad I’m not that guy’. But you know that can still happen to you, right? Even if you’re careful? The sales team promised a massive contract; the system design has to be able to hit x TPS to make it; we need to pull out the stops and build to scale for that and to allow for all this future expandability. Six months later, that sales director has left, the product has pivoted, and you’re ‘over engineered’.
- jacquesm 4y ago
  > And sometimes when you’re driving you’ll pass a car upside down in a ditch and think ‘glad I’m not that guy’. No, I'd stop and see if I can help.
  - jameshart 4y ago
    For the purposes of my analogy, please assume the police are on the scene already and directing you to continue driving past.
- JAlexoid 4y ago
  This ties into the fallacy that microservice architecture is inherently infinitely scalable. Microservice advocates championed this fallacy, implemented it... but now, when it's time for critical retrospective - it's not their failure.
- candybar 4y ago
  Being able to scale to any specific amount of usage is never a reason to use microservices. Plenty of planet-scale services and apps are powered by monoliths. And you never run into any kind of ridiculous overengineering when you refactor things into services for scaling reasons and that's not a microservices architecture in the first place. The problem has always been about people deciding that different parts of the app that differ mostly in terms of business logic somehow need to be independently deployable. It's like deciding that instead of having a single database cluster and having multiple databases and tables, you need a separate, independently scalable cluster for each database table, because of some bogus reasons like some tables are queries more than others and different teams work on different tables and we can't let people join tables because it breaks boundaries or something.

kemiller2002 4y ago

I don't understand. Why would I build something that isn't correct? (jk, excellent comment.)

Lapsa 4y ago

I don't know... perhaps a bit harsh but article seems reasonable to me. I'm also yet to see "wow, what an engineering!" application that heavily depends on microservices. mostly it does feel like an unnecessary complex pile of mud.

jameshart 4y ago
I’m honestly mainly reacting to the part where they judge interview candidates on the basis that they worked on systems that implemented microservices. It is hubristic in the extreme to sit in judgement over the architectural choices a team has made on a system you don’t know or understand, and just downright rude to conjecture all the worst failure modes of that architecture and then assume that they constitute what your candidate values. The only thing you can extract from talking to a candidate about their past projects is their impression of that project. What did they learn? What architectural choices did they like and why? What choices do they regret? Just because they made a choice you wouldn’t have does not mean they are irredeemably broken. ‘Oh, you worked on microservices. Bet it was a big ball of mud.’ then you ask a bunch of questions to confirm that suspicion - you’re just dumping your prejudice against an approach onto someone who might have learned something useful from their experience of working on that thing! And if they did work on a badly architected micro service system, maybe they learned ‘micro services often turn into a big ball of mud, I’ve seen it happen’. Maybe through that experience they learned something about how to avoid that fate? Or maybe they now share your opinion that microservices are a terrible idea; and if you like hiring people who agree with all your ideas then they would be a great add to your team. We have all worked on systems that had architectural flaws. We have all built systems with architectural flaws. What matters is how we took those lessons and incorporated them into our understanding and taste for what makes good architecture.
- bvrmn 4y ago
  > It is hubristic in the extreme to sit in judgement over the architectural choices a team has made on a system you don’t know or understand, and just downright rude to conjecture all the worst failure modes of that architecture and then assume that they constitute what your candidate values. It's more like a cultural fit. Microservice oriented people brings too much friction into the process.

ThereIsNoWorry 4y ago

Yeah, it's crazy the hate microservices get. I happen to work on a product that needs to scale to handle millions of transactions distributed all over the world and the cloud microservice system is just flawless for this purpose. Is it harder to debug than a monolith? Sure. You need a team that has a good understanding about distributed systems (most coworkers have degrees and the ones without are really good at self-teaching, kudos to them). Could you easily develop our system in a monolith? No, it would be a nightmare, if even feasible given the same availability, security and performance constraints. I totally agree not everyone works on stuff I love to work on (huge scalable systems), but Google and co didn't engineer this tech because they felt like it, but because there was a clear need for it.

brightstep 4y ago
> cloud microservice system is just flawless for this purpose > Is it harder to debug than a monolith? Sure. Doesn’t sound flawless to me
leidenfrost 4y ago
Often the microservices hate is around sole developers ranting about how a waste they are, and how everything would be way better if only everyone was very careful and had good practices totally as second nature. And it's similar in nature as the hate around high level languages: "If only everyone had decades of experience with C, "toy languages" wouldn't exist and programs would be lighter and faster today".
FpUser 4y ago
>"Could you easily develop our system in a monolith?" You have a specific requirement and constraints that call for your system to be distributed. However solutions applicable to majority of regular businesses do not require high scalability and can get easily away with monolith. I've personally built both types of systems: distributed and monoliths. My take is to always stick with the monolith until you can't.
JAlexoid 4y ago
The "hate" is directly proportional to the failure of microservice zealots to deliver on the ultimate, everlasting, universal prosperity and harmony, that they promised.

pammf 4y ago

Nailed it.

zug_zug 4y ago

Uh… the authors point was to achieve isolation by modules, not network boundaries, so I think your point is irrelevant

fckgnad 4y ago

Don't you find it strange that YOU live in a world where everyone else but YOU thinks that everyone else around them is over engineering or under engineering things? You're not the guy who thinks everyone else is a maniac and is driving too fast or too slow. You're the guy who thinks everyone but you is under this delusion of thinking that everyone else is a maniac and you think you are an exception to the delusion because you can see it in other people. I am here to tell you that there is a higher plane of understanding. This higher plane of understanding is this: Even when you are aware that others are prone to biased and fallacies, this awareness does not make you immune to those same biases and fallacies. Because what you understand is also cliche. You are voted up because your awareness is also shared by others. Others observe the biased and fallacies of other people and think that they themselves are above it when in actuality everyone is just looking at each other. We are all mirrors. There is an even higher plane of understanding. I am not on this level and neither are you. This plane of understanding is the realization that one of us is NOT delusional. Someone is actually right. Someone sees the reality of how something should work and he is right and he is ACTUALLY surrounded by straw men. The tragedy of the design of computer programs is that we have no theory of efficiency, no theory of what is most optimal. So if someone is right, we have no way of knowing. We are doomed to forever live in a world of blog posts where one of those blog posts is right but we can't know for sure. You obviously wrote this because you think that the author of the blog post is NOT that man. But because we have no theory to prove otherwise, you simply state common tropes of human fallacies and biases and you use that analogy to discredit his post. It's pointless. Analogies aren't proof, they are themselves delusions but weaponized and used to seemingly prove a point or discredit one. They are convincing but manipulative. Your post can actually discredit every blogpost in the universe and that is why it is useless, pointless and manipulative. Rather then write sweeping analogies of human biases which can actually "disprove" every single blog post on the face of the earth... offer evidence and example scenarios about why you disagree. Because personally I think the blog poster is right. His thoughts on microservices is correct. Convince me about why he isn't that one guy who is actually right, but know that the argument is endless because none of us can actually verify anything.

bradhe 4y ago
If you ask a room full of 100 engineers if they are better engineers than their peers, 80 of the 100 will say yes.

techdmn 4y ago

You should credit the late great George Carlin for this. :-) "Look at this idiot here!" "Whoa, look at that maniac go!"