Live data from Hacker News

Microservices

basho.com

1–10 of 152 posts

Re: Microservices

#2
I swear, the HN front page algorithm is easily gamed, this gets a few points quickly and it rises straight to the front page. I don't know if HN is accounting for vote rings but some penalizing should be implemented.

Re: Microservices

#3
Raises some good points, but I think the title isn't really correct. It's not "don't use microservices" - it's more about making sure you understand the implications of having a microservice architecture, and making sure it's not an excuse for not writing a monolith (or SOA) properly.

Re: Microservices

#4
From personal experience Microservices enforce a clear interface and isolation pattern. This is achievable many ways, but having discrete deployed code makes it very hard to violate rather than being disciplined.

Licensing costs can go drastically up as most modern licensing is node/core based. As can deployment procedures get more complicated.

I would love to understand how this article believes that the modules in a monolithic system can be scaled horizontally if they are actually a single code base in a single system. Either the system isn't monolithic, or it they have never really done it. Sticking a load balancer in front of a micro service and scaling based on measured load requires tools and technologies, but is very scalable. It also allows you to do rolling deployments of draining/rotate out/update/rotate in that allows you to get near no planned downtime.

Distributed transactions are the devil, but you don't need to do them in a microservice design. It requires design work on the front end to clarify what the system of record is, but if each service has a domain it controls, and all other services treat it as the truth, it's rather simple. I say this having researched doing payment transactions across geographically diverse colo's and we treated that as a sharding/replication/routing issue very successfully.

Ninja edit: Starting with a microservice design is most likely overkill for a lot of systems, but either way, clear interface/boundaries in your system are good and healthy

Re: Microservices

#5
The problem is to define the scope of each service. And it is still possible to create spaghetti out of how the services interact and how coupled they are with each other.

If done poorly it is like trading one problem with another problem.

Re: Microservices

#7
One suggestion I would make if you are going to use microservices is to consider using gRPC rather than REST. You can save yourself a lot of the hassle involved in the communication that way AND make things quite a bit faster.

Re: Microservices

#8
As someone working with this setup right now, coming from what is fondly referred to around here as the God-Monolith of our 1.0 version, I couldn't disagree more....

But as always, this is an artform, writing and designing, not laying down pavement.

There's no "right" way, and any blanket statement about anything is false.

Don't use microservices where they don't make sense, make educated decisions, and choose the best option for your situation.

It made sense in our situation, because all our services have very very very specific rules and boundaries and there's no overlap anywhere.

Re: Microservices

#9
post #6

The title should be "I've never implemented microservices properly, so you should avoid them."

I think a lot of people don't implement them properly. And if you're an individual or a small team trying to build something it's usually overkill.

Re: Microservices

#10
I for one, feel the same way when someone tells me they are building "microservices" for a small application that they don't ever plan to scale to that levels. IMO, amongst us, there is a wide-spread issue of "Here's the new cool thing - My application/system has to do it". The other day, a friend was talking on and on about setting up a Hadoop cluster for what I saw as a one-time use batch script.
Post reply on HN