Hacker News new | ask | show | jobs
by UK-Al05 1892 days ago
You've broken the microservice abstraction if this a problem.

A team should own a microservice, you release as soon as the team able to.

You version your apis, so you don't break any services which rely on yours.

2 comments

"You've broken the microservice abstraction if this a problem."

I agree, but in practice it seems more companies break it rather than follow it.

I agree people hop on the microservice bandwagon without really understanding the "philosophy" behind it. Then blame microservices when they struggle.
I actually prefer a monolith compared to the way we do microservices. One or two big apps to own vs ten microservices or apps that require coordinating with others. It's really just a duplication of paperwork and other overhead processes.
We don't require any coordination with ours. It's low cost for us.

We may make the occasional announcement that v5 our api is coming soon which has x features based on feedback from other teams. Then announce when we've released it.

Its a product, and we own it.

That sounds nice. My most recent elevation involved coordinating with 5 other services to stop/restart/reprocess items with a couple deploys between the 5. Had to be off-hours too. Sort of normal for us.
You have all the symptoms of a distributed monolith.
> vs ten microservices or apps that require coordinating with others

That's called the "distributed monolith" and it's worse than a monolith.

Although this is true, there is still the additional problem that a lot of customers, specifically government customers, require frozen known versions of everything as a requirement for acceptance testing. Auditing standards for the aerospace industry require that what is running in ops is exactly the same version of everything that was running when an acceptance test was witnessed and signed.

It's a totally impractical standard for modern software development, but the developers themselves have no choice in the matter until the customers change.