Live data from Hacker News

Microservices are hard

code-held.com

61–70 of 356 posts

Re: Microservices are hard

#61

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, whil…

Nailed it.

Re: Microservices are hard

#62

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, whil…

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.

Re: Microservices are hard

#64

Earlier quoted context omitted.

Microservices is a collection of independent teams who only communicate using well defined APIs. Those teams may produce libraries, perhaps. That's up to Conway.

That API is usually a web API right. Essentially Library + REST/GraphQL/etc is a microservice.

In practice, likely. The trouble with only communicating by API is that if you want to change the API you can't just tell those who use it that they'd better be prepared for breakage, so you have to juggle both the legacy API and your new API in your work to maintain compatibility.

If you use a linked library, interface compatibility can be a real challenge. Web APIs, as you call them, offer more flexibility in adapting to different callers. It also comes with the added benefit of defining explicitly clear boundaries between teams that something that shares memory doesn't necessarily guarantee (e.g. monkey patching). This oftentimes makes it a good practical choice.

Re: Microservices are hard

#65
post #43

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, whil…

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.

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.

Re: Microservices are hard

#66

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, whil…

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…

I feel the same way about go-to statements. Crazy hate. Harder to debug, sure, but they make things so much easier.

Re: Microservices are hard

#67

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, whil…

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

Re: Microservices are hard

#68

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, whil…

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.

Re: Microservices are hard

#69
Every decade a new set of engineers grows up and we get the same all over again.

Monolith vs services fight has been going on in every decade, that I've been a developer in.

Re: Microservices are hard

#70

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, whil…

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…

And all the post is saying is that it doesn't apply to everyone. It applies to Google and many other companies including your's, but not all. As a matter of fact, it applies to a very small subset of use cases. If your software handles millions of transactions distributed all over the world, there's a good chance it's within that sweet spot. But most software written in the world doesn't fit that category.
Post reply on HN