Hacker News Reader

Comment by marcosdumay | Hacker News Reader

I kind of feel that every single person that has had good experiences with microservices actually experienced something that doesn't fit the "micro" description, and often enough not even "service".

If the thing can encapsulate an entire transaction, then it's taking care of an entire business vertical. What I do agree, it's one of the best ways to partition your services (just after not doing it). But calling this a "microservice" only serves to confuse people.

View on HN

Or get the project approved. Sometimes you dont work with reasonable people: they want micro services, they cannot forgive you for doing one and then not having transactional correctness. So you have to call your business service a micro service, a small lie that saves a lot of pain and money.

It's like finishing a migration by renaming your initial project with the new name of the target project: everyone is happy, the software is still working, the various political stakeholders now feel the warm embrace of ownership from the old bad domain to their turf, and you saved years of reinventing the wheel to end up in the same place.

Is it the word micro that causes the issue? Services are way easier and more logical when they are verticals - this is how it's largely meant to be. How many people have read the supporting books and literature that say as much? That would be a good question.

Almost everywhere you go, you see the same mistakes. Almost every one can be found in Sam Newman's 2nd edition. The conclusion I draw is that a very large number of developers ran with it without understanding the pros and cons. Services are only worth it if your organization benefits more from the pros. Many orgs don't, so it makes no sense for them to adopt it over monolithic architecture that is way easier to implement transactions with.

Designing "transactions" across services and databases is an insane endeavour. It's best if each service is split on a line that it can deal with incomplete states in other services.

> Is it the word micro that causes the issue? Services are way easier and more logical when they are verticals

I think that the word micro is indeed the issue. Once they stop being micro and just become services, it pretty much becomes a Service Oriented Architecture. So why keep calling it microservices?

The "micro" was specifically coined to mean breaking a vertical into several smaller services. So, if you go look online how to create microservices, you will get most of the material biased into that. Even though most people pushing those describe something saner, what the docs say is what you will get.

Before that, we had "SOA", that was coined to mean exactly breaking your system into full verticals. But then the term was hijacked by some very loud companies selling tools for microservices, and now if you go search for it you will mostly find stuff like how to set distributed transactions.

Overall, humanity currently has a pretty hard time communicating, due to the sheer number and size of bad actors actively and purposefully polluting our communication infrastructure. We get to feel the effects when talking about software too.

Yeah can't we just have services without making them tiny. Just because I don't think having 7 services is an appropriate architecture for a team of 3 doesn't mean I don't think it's an appropriate architecture for a team of 100.

Transaction usually refers to the atomic but of what needs to be done which is certainly not guaranteed to be a business vertical.

You should never have a microservice that doesn't own something unique and the best ones are interesting enough to have a proper owner.

It has always been that except for the constant onslaught of misinformed idiots who have no clue about architecture (especially here on hackernews) trying to convince people otherwise.

Reply on news.ycombinator.com