Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microservices are hard

code-held.com

Post reply on HN
Print view View original

91–100 of 356 posts

Re: Microservices are hard

#91

Post by bradhe »

fckgnad wrote: post #68
jameshart wrote: post #16

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 b…

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

Re: Microservices are hard

#92

Post by quonn »

jameshart wrote: post #41
quonn wrote: post #23

Earlier quoted context omitted.

We learned in the 90s to not distribute the objects and instead just spin up more copied of the whole application. And if only scalability is the point this is still valid.

Weird flex to claim not to have learned anything new since the nineties though.

Where did I say this? All I said is that it's usually effective to spin up more instances of the system - a conclusion we arrived at long ago.

Regarding your point, most other disciplines gain knowledge over time, such as civil engineering, chemistry or biology and we don't discard results from the past with this kind of strawman argument of there supposedly not being anything to learn since. If things were like that, any progress would be impossible.

Re: Microservices are hard

#93

Post by bradhe »

monero-xmr wrote: post #10

Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer. Why call a function when you can wrap that function in an entire application and call it via API? Why have a single database when we can silo our data across 200 mini databases? Why have a single repo when we can have 200 tiny repos?

> Microservices - let’s replace as many interfaces as possible with the slowest, flakiest, most complex mechanism - the network layer

You do realise that most calls to block storage in AWS result in network traffic, right?

The point is, abstraction is your friend.

Re: Microservices are hard

#94

Post by BulgarianIdiot »

I just sit back, sipping coffee and chuckle.

We went from "services should be no more than 100 lines of code" to "testing and maintaining thousands of interconnected microservices is TERRIBLE IT TURNS OUT".

The secret here is that all simple answers are wrong. Your services are too small and too big at the same time. Finding balance is hard. Zen Buddhists call it the "Middle Way".

The best design is always an uneasy intersection of many approaches and concerns, and also it's the concept of what you decide NOT to do, so you have more resource to focus on what TO DO.

Also we keep overanalyzing how we do services in isolation, when the complexity comes not from each of them alone, but how they interact. To solve this complexity you need clear, aligned flows. More like laminar flow. Less like turbulence.

Re: Microservices are hard

#95

Post by dahfizz »

jameshart wrote: post #41
quonn wrote: post #23

Earlier quoted context omitted.

We learned in the 90s to not distribute the objects and instead just spin up more copied of the whole application. And if only scalability is the point this is still valid.

Weird flex to claim not to have learned anything new since the nineties though.

And Calculus was invented 300 years ago. It still works.

This attitude is extremely toxic to the development community.

"Its old" is NOT valid criticism.

"Its new" is NOT valid praise.

Re: Microservices are hard

#96

Post by JAlexoid »

jameshart wrote: post #41
quonn wrote: post #23

Earlier quoted context omitted.

We learned in the 90s to not distribute the objects and instead just spin up more copied of the whole application. And if only scalability is the point this is still valid.

Weird flex to claim not to have learned anything new since the nineties though.

What I learned since the 90ies, is that software engineers don't learn from previous years... let alone from previous decades.

This "microservices are better" argument was made in the 90ies and top dog is still Linux kernel (the one that was on the monolith side of that debate).

So yeah - microservice advocates haven't learned anything since the 90ies, or from the SOA era, etc... (but I suspect they were in secondary/high school then)

An anecdote: When I joined my current company had more code to orchestrate services, than the actual business value generating code in the services. We still produce an inordinate amount of code that exists just to facilitate microservice architecture. (it's also untested code, because we just don't have the money to spend time on testing it)

Re: Microservices are hard

#97

Post by jasonhansel »

jerf wrote: post #78

No, they aren't. The entire point of the big ball of mud is that there are no meaningful divisions in the code. Everything uses everything willy-nilly, at the smallest possible level of abstraction. There is, metaphorically if not always entirely literally, not a single line of code in the system that you can change without fear of bringing something else down that you may not have even known they existed. Microservi…

> if the boundaries are not drawn correctly to start with, fixing that can be much harder in a microservice architecture (with corresponding separation of teams) than a monolith.

Therein lies the problem. Nobody draws these boundaries correctly on the first try, and the correct boundaries can shift rapidly over time as new features are added or requirements change.

Re: Microservices are hard

#98

Post by jameshart »

jacquesm wrote: post #37
jameshart wrote: post #16

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…

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...

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’.

Re: Microservices are hard

#99

Post by layer8 »

phyzome wrote: post #45
layer8 wrote: post #39

Earlier quoted context omitted.

I'd argue they should just do services.

Wrong, milliservices are the way to go! Maybe centiservices, but no further!

There’s also the spectrum of decaservices, hectaservices, kiloservices, and so on to consider. It tops out at the infinityservice aka monolith.

Re: Microservices are hard

#100

Post by JAlexoid »

randomdata wrote: post #7

Microservices is a team organization technique, whereby disparate teams only communicate by well defined APIs. Any technology choices that come out of that are merely the result of Conway's Law. Any time you lean on code in a random GitHub repository, where you never speak to the author and just use the API you're given, you're doing microservices. This works well enough so long as the product does what you need of i…

No. That's not what microservices means. You're intentionally equating all services to microservices, which is not the case.

This substitution is what is commonly known as a Strawman argument. You misrepresented an argument, to discredit it easier.

Post reply on HN