Hacker News Reader

Comment by johnwheeler | Hacker News Reader

i don’t understand how microservices solves the problem of broken interfaces. if an api changes or disappears, how is that different from the locations.txt file changing or disappearing?

i think it’s just another instance of humans making things more complicated than they need be. Same line of reasoning Linus went with a monolith vs a micro kernel.

View on HN

Microservices set out to do the same thing as Object Oriented programming set out to do. You define an {object,microservice} by exposing methods, and other services and clients interact by calling those methods. Theoretically, if your API remains stable, your internal implementation can change drastically and the system will continue to function as it should. There's no reason you can't draw these boundaries inside a monolith, but with microservices you'd have to go out of your way to not have those boundaries.

IMO by using HTTP to communicate, they ended up being significantly closer to the original concepts behind OOP and message passing.

http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...

Now, whether microservices are successful in dealing with the problems they set out to solve, and are worth the tradeoffs they entail is still up for debate.

Absolutely right. locations.txt is an API. And there's nothing monolithic about the example. It involves two completely separate apps with an API in between!

I think you have missed the point. I think the point of that section actually has nothing to do with the locations.txt interface between the maps app and locolist. It's actually about the fact that, with microservices, any piece of the system only depends on it's dependency graph, not on every piece of the system working.

"... on a huge service like Netflix the entire application going down because a change was made to one part of it..."

To extend your OS example, just because there was a kernel panic in the Bluetooth stack is no reason to stop servicing requests over the Ethernet NIC which is already bound by the web server. There's also no need to edit or recompile the Ethernet driver because of a Bluetooth problem; see others posts about encapsulation.

You might change the location of locations.text or store the locations in a database, or on the cloud, etc. You shouldn't change the commitment your service has to vend data about locations etc. You make a contract saying you will do X when given Y but you don't commit to anything about how you will do it, and that can change as necessary.

They don’t, they just let the trendy nerds beat off over unnecessarily complex software. C.f. The entirety of the JavaScript ecosystem.

Reply on news.ycombinator.com