Hacker News Reader

Comment by ivanbakel | Hacker News Reader

>I’m sure our specs were good enough that APIs are clean and service failure is isolated and won’t impact others.

Surely if you're building microservices, this line of thinking would be a failure to stick to the design? If your failures aren't isolated and your APIs aren't well-made, you're just building a monolith with request glue instead of code glue.

I appreciate the point is more that this methodology is difficult to follow through on, but integration tests are a holdover - you can test at endpoints: you should be testing at endpoints! That's the benefit.

View on HN

> If your failures aren't isolated and your APIs aren't well-made, you're just building a monolith with request glue instead of code glue.

That’s pretty much every single microservice architecture I’ve ever seen, and I’ve seen a lot of them :(

That's a common thing, trying to solve the problem by moving it from one place to another.

I've had this feeling in some place that 'SOA' is a bit of a dirty word because it connotes a certain style of systems architect, or working like you do in Java or enterprise-scale PHP.

Many monolithic apps would benefit from a refactoring towards that rather than distributing a call stack across the network. The microservices can come later on if there's a need for it. If nothing else, it'll present a clearer picture of how things fit together when you start enforcing boundaries.

SOA also brings up memories of soul destroying ESB's.

I would love a resurgence of discussions about services and how to best build and govern those without always resulting in a focus on the micro versions.

How are people building a modern IT landscape consisting of different services and system?

The problem with ESBs in my opinion is one of tight coupling; all of these distributed systems that know about and depend upon each other. The solution to this is to loosen coupling whilst formalising interfaces/contracts/schemas, with a design that enables versioning and mandates graceful evolution. The modern version of ESB is an event based (note: this does not necessarily and probably does not mean event sourced) architecture built upon a distributed, append-only log that is ideally fed directly from a database transaction log.

ESB is new to me but just casting a glance on it makes me think... Kafka.

You can't avoid the centralisation unless you want infinite repetition.

The human spine is composed of multiple vertebrae and forms a consistent network with the brain and CNS and the rest of your body. The spine itself is the centralism, no matter how much you separate the bones into vertebra.

A service bus is basically putting all of your eggs into one wire. Or so it seems... it's so easy to strawman yourself to microservices.

But conversely, how much of the purported benefits of microservices are really the benefits from having well-defined contracts between components? Are microservices mostly a forcing function for good architectural practices, that could be applied equally in a monolithic design (with internal component boundaries) with enough discipline?

I think that's a fair starting point, but once you start enforcing better boundaries, you are actually able to access the microservice benefits (i.e. independent failure, component-variant scaling, independent update deployments, etc) because there's no risk of failure from a boundary break - and those benefits are definitely inaccessible to even the best-designed monolith.

Can you explain what you mean by "request glue"?

I believe they meant network request glue

Reply on news.ycombinator.com