Microservices are hard • Hacker News Board

Re: Microservices are hard

#201

Post by mlboss » Wed, Jan 11, 2023, 4:05 PM UTC

esailija wrote: post #134

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…

> It may be the sloppiest, crappiest definition every, with dynamic types Funny you said that since a microservice API is always dynamically typed and its usage cannot be checked by compiler. And the more microservices you use the more dynamically typed the whole project gets overall. While you can opt into a free for all everything importing everything, all languages do also support creating modules which define API…

Something thing like grpc solves this problem.

Re: Microservices are hard

#202

Post by marcosdumay » Wed, Jan 11, 2023, 4:05 PM UTC

robswc wrote: post #157

Worked on both monoliths and micro services. I'd rather work on a good monolith than a bad microservice and vice versa. The problem is, working on a bad monolith is almost impossible. I'd rather work on a bad microservice than a bad monolith. Now... tbh this could be survivorship bias where I've never had to help with a well-running monolith, fair... but at the end of the day, I find microservices much easier to mana…

> I'd rather work on a bad microservice than a bad monolith.

That's not the choice. The choice is between a bad monolith or a bad microservices ecosystem.

And the microservices tend to come with organizational policies too, that may or may not allow you to access, see, or change some subset of them.

Re: Microservices are hard

#203

Post by randomdata » Wed, Jan 11, 2023, 4:06 PM UTC

mwhitfield wrote: post #199

randomdata wrote: post #196

Earlier quoted context omitted.

What's the common understanding? I've honestly never heard of any other definition. The article shares the same definition, at least.

> the situation where those APIs and team boundaries are exclusively (or at least primarily) composed of separate applications communicating over the network

Are you, perhaps, not familiar with Conway's Law?

Re: Microservices are hard

#204

Post by marcosdumay » Wed, Jan 11, 2023, 4:08 PM UTC

ericalexander0 wrote: post #53

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?

The move to microservices is often more about scaling change management when an organization grows from tens to hundreds of engineers. Change management becomes the bottleneck when organizations exceed Dunbar's Number, and a "reverse Conway maneuver" is needed to counter excessive cost of coordination. https://cloud.google.com/architecture/devops/devops-tech-arc...

Interestingly, open source has some change management processes that deal with orders of magnitude more people and pieces of software than you will find on a corporation, and mostly only imposes infrastructure policies when that's the development's goal.

It tends to fail less often than corporations too. And my impression is that it's more efficient for developer time.

Re: Microservices are hard

#205

Post by BSerhere » Wed, Jan 11, 2023, 4:09 PM UTC

sisve wrote: post #158

I really do not understand the debate on monoliths and microservice anymore. Context matters so much. Should you have absolutely everything in 1 system. No. And I think no one thinks that anymore. Should you spilt your system into as many pieces as possible? No, of course not. You are prop. storing files one place and have a data in a database another place. And most likely none are on the webserver receiving request…

[dead]

Re: Microservices are hard

#206

Post by JAlexoid » Wed, Jan 11, 2023, 4:11 PM UTC

randomdata wrote: post #193

JAlexoid wrote: post #186

Earlier quoted context omitted.

Microservices is defined to be extreme decomposition, which is not the same as a service. And the biggest pitfall of microservice architecture, is the creep of loose coupling. Right now I work in an environment, where user account information is copied to every single microservice's internal DB... to minimize access time to that information... Restaurant provides you with a service - one single interface. Imagine if…

> where user account information is copied to every single microservice's internal DB... to minimize access time to that information... In terms of access time, what does that gain you over a bog standard shared database? With careful planning, you can likely achieve the lowest access times using a shared database. There is so much more room for optimization at every level. The reason actual microservices (teams only…

You're not allowed to have a share DB with microservice architecture. Every microservice is completely self contained...

The architecture of my organization was created by ardent microservice advocates, that took the definition of a microservice and treated it like a bible. Based on the conversations I had here, there are still people that treat microservices as sacrosanct.

The more I work with microservices, the more I'm convinced that microservice first architecture is garbage.

The copying of the data is the solution to data access latency.

Re: Microservices are hard

#207

Post by _ea1k » Wed, Jan 11, 2023, 4:11 PM UTC

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…

But he's replying to an article that says "don't use microservices, use independently deployable modules". Your comment has more depth than the article itself.

Re: Microservices are hard

#208

Post by _ea1k » Wed, Jan 11, 2023, 4:12 PM UTC

gfodor wrote: post #80

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…

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.

TBH, his definition of "module" brings it awfully close to microservice.

Re: Microservices are hard

#209

Post by JAlexoid » Wed, Jan 11, 2023, 4:13 PM UTC

hdjjhhvvhga wrote: post #138

JAlexoid wrote: post #96

Earlier quoted context omitted.

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…

While I agree with you, the good part is that each generation is (slightly or significantly) better than the previous one. I remember using static generation in the 90s but the tools we have now are more powerful. Kubernetes is a great piece of software: it is well-designed, easy to work with (at least the managed versions that most companies use; administering the cluster is another thing), it applies a set of simpl…

Each generation goes through the cycle faster.

> I can hardly understand folks running k8s for a 3-container setup.

Why can't you understand them? I understand them - It's cool, that's why they run it. It's not about rational use of resources, it's about being cool.

Re: Microservices are hard

#210

Post by ricardobeat » Wed, Jan 11, 2023, 4:14 PM UTC

pier25 wrote: post #198

Use the best tool for the job. It's stupid to think of monoliths vs microservices. You can use both if the problem requires it. For example I'm currently working on an audio hosting service. The main app is a monolith where 90% of the code resides but there are a couple of ancillary services. Audio encoding (which is heavily CPU bound) is a serverless microservice that can scale up and down as needed. Users don't upl…

This argument is brought forth a lot, but it misses the point. Often people think microservices are the right tool for the job, but they vastly underestimate the complexity that it entails.