SCS Layers
ewolff opened this issue · 13 comments
SCSs might have layers - but SCS make no assumptions about the internal design of an SCS. This is somewhat confusing in the presentation - in particular concerning the internal layers and where specific interfaces (REST, UI etc) are located in the layers. We should explicitly say that we make no assumptions about the internal design of an SCS.
Absolutely agreeing to that, but we should consider to give a recommendation like
"a User Interface, is a part of the Application Programming Interface, just in a representation format that is optimised for humans".
Here's an argument why SCS maybe should have a stance – or at least a recommendation – on the internal design: as they promote primary slicing by business domain, they implicitly position a layer split up second. I'd even go further and would recommend to avoid the layer split up until the split measurably outweighs the following consequences of a horizontal split:
- Latency accumulated by the network hops
- The addition accidental complexity introduced by the tech to safeguard the remote communication (bulkheads, timeouts, fallbacks, retries)
- The strong coupling resulting from the low abstraction levels of the intermediate APIs
Primarily splitting by layers in combination with these three aspects are the main factors I see classical microservice projects degrade to distributed monoliths pretty quickly. That the horizontal split is such a commonly used pattern probably stems from the fact that layers are usually the most concise structure that's left in a (big ball of mud) monolith and thus deceptively look like a good candidate for a first-level split up.
It would be cool if the deemphasizing of that adds to the counterposition that SCS take here and actually helps them to distinguish themselves from (traditional) microservices.
Completely agreed, I think that’s an excellent point.
I couldn't agree more! Would you like to do a PR with changes reflecting this? Or can we add a link to some document, blog post, etc that explains this is more detail?
I am unsure where to put that recommendation. It'd best fit in 1, but at the same time that point already mixes a couple of concerns: autonomy and web frontend. Maybe that point can be subdivided into three requirements
- Autonomy – Self-contained, contains data and logic, does not require other systems to run (how about 3rd party integrations?)
- Full-stack (although I hate that term) – contains some form of UI, recommend web UI, although I think a sole high-level REST API could be an adequate alternative as it provides the same characteristics in terms of the ability to integrate with other systems (links and transclusion). I.e. it's the high-level, business flow, easy to integrate UI that's the important aspect here, not the fact that it's a human consumable web UI, isn't it?
- Avoid layer split ups – basically the arguments above. Maybe add a few reasons in which such a split up might be justified: highly different scalability requirements between reads and writes.
Another way to phrase the third requirement could be to draw the analogy to DDD aggregates: if a system is split up internally, those internal components must not be referred to by other SCS, just like an aggregate must only refer to other aggregate not other aggregate's internals. That kind of thinking prevents "shared services" being built that expose low level APIs. Might be a bit of a stretch, but yeah…
1 - I think this is expressed in https://scs-architecture.org/#data-and-logic
2 - actually we talk about a UI, see https://scs-architecture.org/#no-shared-ui
3 - that is a good point. I'll put something in the FAQ
I'm not completely sure if I understand the argument completely.
they implicitly position a layer split up second. I'd even go further and would recommend to avoid the layer split up until the split measurably outweighs the following consequences of a horizontal split
While I agree in general and I certainly favour this myself I don't really see a strong argument why e.g. a layered microservice architecture shouldn't be totally fine. With totally fine I mean that all the benefits promised by SCS design can completely be fulfilled.
I see a broad variety of reasons why a µ-Service architectue might be beneficial for certain SCS beside those three you mentioned. Imagine a Profile SCS that is build up on an existing modular service set as it is provided by Ory.sh (Hydra, Kratos, or similar).
However, if an SCS is split into microservices, the
microservices should not be implemented by layer. Our experience is
that such a split leads to a lot of dependencies between the
microservices - hurting maintainability as well as performance.
As I wrote above already, I don't see that really related to the SCS concept. IMHO it is more of a personal opinion (that we share)
IMHO it is related to SCS. SCS provide a split by domain i.e. vertically. That is the core of the concept. To warn against horizontal split into microservices inside an SCS fits this concept nicely. I am open to suggestions, of course.
The SCS info deck suggests SCS can consist of multiple systems internally and given that, I think it's worthwhile leaving a note on what this should look or not look like. Also, fundamental to SCS is avoiding synchronous interaction between SCS. Split by layers – even if internal – breaks that fundamental concept.
I totally see your point in that what's asked for here is not necessarily a constraint for something to be considered an SCS. However, there are some fundamental design principles that SCS follow and expose. Following the same design principles for the inside of an SCS just makes the entire concept more wholistic and consistent.
fyi: I have merged the related #39 and its predecessor #36 as they had been approved by two persons. However, the discussion here is deeper, e.g. also addressing the slide deck. Hence, I keep this issue for now open. Maybe, we should define the goal of this issue more precisely (is the adaptation of the FAQ sufficient or do we want to adapt the slide deck as well).
Ok, since the topic has been covered in the FAQ and there have been no further remarks, I close this issue now. If you disagree, you may re-open it. In that case, please provide acceptance criteria for this issue as well. Thank you!