4 ms·

>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

>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.

ljm 8y ago
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.
- cc81 8y ago
  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?
  - darkr 8y ago
    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.
  - ljm 8y ago
    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.
herval 8y ago
> 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 :(
- Gibbon1 8y ago
  That's a common thing, trying to solve the problem by moving it from one place to another.
int_19h 8y ago
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?
- ivanbakel 8y ago
  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.
avinium 8y ago
Can you explain what you mean by "request glue"?
- HatchedLake721 8y ago
  I believe they meant network request glue

ljm 8y ago

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.

cc81 8y ago
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?
- darkr 8y ago
  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.
- ljm 8y ago
  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.

herval 8y ago

> 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 :(

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

int_19h 8y ago

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?

ivanbakel 8y ago
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.

avinium 8y ago

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

HatchedLake721 8y ago
I believe they meant network request glue