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

191–200 of 356 posts

Re: Microservices are hard

#191

Post by bvrmn »

jameshart wrote: post #65
Lapsa wrote: post #43

Earlier quoted context omitted.

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…

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

Re: Microservices are hard

#192

Post by mwhitfield »

randomdata wrote: post #163
JAlexoid wrote: post #104

Earlier quoted context omitted.

Everything is a microservice, even Linux kernel modules are... apparently. And also - nothing is a microservice, because it's not separated strongly enough.

> Everything is a microservice, even Linux kernel modules are... apparently. A microservice is comprised of people. Not a whole lot different than a service, but narrower in what is offered such that the service doesn't provide something useful on its own and is meant to be integrated with other services to achieve its full utility, hence the 'micro' moniker. In the world of physical products we often call these peop…

Sure, I guess if you completely redefine the word "microservice" to something completely different from the common understanding, it makes more sense.

If someone is writing about "microservices," they are generally talking about the situation where those APIs and team boundaries are exclusively (or at least primarily) composed of separate applications communicating over the network. Not what you're talking about.

Re: Microservices are hard

#193

Post by randomdata »

JAlexoid wrote: post #186
randomdata wrote: post #135

Earlier quoted context omitted.

> That's not what microservices means. You're intentionally equating all services to microservices, which is not the case. Eventually everyone provides a service to someone, I guess, but there is a clear division between those who serve end users and those who serve the servers. The service that places your food down on the table at the restaurant is not thought of in the same was as those who get to the food to the…

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 communicating via API contracts) must carry out this practice of duplicating data is because a shared database requires non-API communication for various things, like enabling schema changes. If you can call up someone on another team to talk about how to upgrade the database and reach a shared understanding, what do you need API-only communication for?

Did your organization become confused about why they are doing that and then invented a performance argument to justify it?

Re: Microservices are hard

#194

Post by __MatrixMan__ »

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…

You're right, and I think most engineers know it. The debate persists as a proxy for a separate debate:

E > I want to reorganize this because it's ugly and hard to work with as it is

M > I want you focusing on this list of features/bugs and not introducing risk by making changes for other reasons

Something doesn't feel right about:

E > I'm the expert, you have to take my word that this change is necessary

So if depending on whether E wants to join or separate, they put on their I-hate/heart-microservices hat and rehash whichever side of the tired old debate serves them.

People who agree or disagree dust off their I-hate/heart-microservices hats, and we go to town for a while.

We're not actually arguing for micro vs macro, we're talking about the context specific details, we just dress it up in those terms because M is in this meeting and M isn't close enough to the code to keep up with a conversation about the details.

If enough energy is not expended in this process, whoever lost the debate goes and writes a blog about why they were right. Except nobody will read a blog about their specific codebase, so it ends up being about whether they heart/hate microservices.

Re: Microservices are hard

#195

Post by FpUser »

ThereIsNoWorry wrote: post #62
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…

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…

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

Re: Microservices are hard

#196

Post by randomdata »

mwhitfield wrote: post #192
randomdata wrote: post #163

Earlier quoted context omitted.

> Everything is a microservice, even Linux kernel modules are... apparently. A microservice is comprised of people. Not a whole lot different than a service, but narrower in what is offered such that the service doesn't provide something useful on its own and is meant to be integrated with other services to achieve its full utility, hence the 'micro' moniker. In the world of physical products we often call these peop…

Sure, I guess if you completely redefine the word "microservice" to something completely different from the common understanding, it makes more sense. If someone is writing about "microservices," they are generally talking about the situation where those APIs and team boundaries are exclusively (or at least primarily) composed of separate applications communicating over the network. Not what you're talking about.

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

Re: Microservices are hard

#197

Post by nerdix »

0x445442 wrote: post #167

There are a few gripes I have with microservices. I think most places rearchitect to microservices because it’s the new shiny. They don’t do the engineering necessary to create a detailed cost/benefit analysis, they just feel it will be better and so they jump in. For the same reasons the companies don’t do the cost/benefit analysis they don’t spend much time thinking about how they could benefit from rearchitecting…

In my experience, most places rearchitect to microservices because they have a shitty monolith that they are dealing with.

The monolith has been built over a span of 10+ years. It is fragile, brittle, no one understands how the whole thing works, and large scale refactoring without widespread breakage is near impossible. No one wants to touch it because no one understands how the whole thing works. Because of this the codebase is also falling behind and isn't staying current with language updates (I know everyone here likes working with 10 year old tech but it does affect hiring when you have to say that you're using Java 8)

But it is true that distributed monoliths are very common. One problem is that it's hard to get everyone on board with going "all the way". The question "Do we really need multiple databases" is one of the main culprits that spawn distributed monoliths.

Re: Microservices are hard

#198

Post by pier25 »

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 upload content constantly, but when they do, you want to be able to encode stuff concurrently without blocking the main app. Audio streaming is also a serverless microservice because hey for every user uploading content you can have 1000x consumers (or more).

Re: Microservices are hard

#199

Post by mwhitfield »

randomdata wrote: post #196
mwhitfield wrote: post #192

Earlier quoted context omitted.

Sure, I guess if you completely redefine the word "microservice" to something completely different from the common understanding, it makes more sense. If someone is writing about "microservices," they are generally talking about the situation where those APIs and team boundaries are exclusively (or at least primarily) composed of separate applications communicating over the network. Not what you're talking about.

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

Re: Microservices are hard

#200

Post by nicoburns »

jerf wrote: post #172
naasking wrote: post #152

Earlier quoted context omitted.

> 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. This is…

Funny, I was thinking of linking to that page myself in support and decided against it. I particularly was thinking of: "What does this muddy code look like to the programmers in the trenches who must confront it? Data structures may be haphazardly constructed, or even next to non-existent. Everything talks to everything else. Every shred of important state data may be global. There are those who might construe this…

> which is actually unlikely, sarcasm aside, even the absolute worst systems have more structure than that in a microservice architecture

Nope, the absolute worst systems have the same complex circular dependencies as monolithic BBOMs, the microservices just call into each over the network rather as function calls (imagine for example an API request into service A that calls into service B that calls back into service A). You may argue that makes it not a true microservices architecture, but one could make the same claim about a modular monolith.

Post reply on HN