This is the example process I want to refer to within the article:
You might be familiar with the process. It is the process of serving a dish. You first need to decide about the dish you want to serve. Afterwards you need to make sure to have all groceries in place, before you actually prepare and serve the dish.
If you want to support that process with software, how would you approach it?
Take aside your reflections about whether your software needs to support a private person or a commercial kitchen. Of course this context plays a crucial role, but for now just ignore it.
Approach 1: Backend-Frontend Monolith
Is it the Backend-Frontend Monolith you came up with?
As all other approaches shown within this article, the Backend-Frontend Monolith is based on a three-tier architecture.
In addition to that, the Backend-Frontend Monolith has some specific characteristics.
Characteristics
Single deployment unit
Single frontend/single backend project (maybe in a Monorepo)
One team is responsible for everything (Antipattern: separate backend/frontend in your team setup)
Pros
Very fast, good for startups or to quickly evaluate business concepts
Cheap on a short term
Cons
Limited to a single technology
Everything or nothing (no graceful degradation of service quality)
Does not scale well (overwhelming business scope)
You will probably find more characteristics as well as pros and cons, but the goal here is to quickly outline the approach.
Approach 2: Entity Services
The second approach is what I refer to as “Entity Services”.
It is quite similar to the Backend-Frontend Monolith, with a major difference: components are deployed independently.
Characteristics
Multiple deployment units
Single frontend/multiple backend projects (maybe in a Monorepo)
One team is responsible for everything (Antipattern: separate backend/frontend in your team setup)
Pros
Allows to combine multiple technologies
Improved technical scaling options (e.g. addressing bottlenecks)
Cons
High complexity (because of distributed system with many dependencies)
Does not scale well (overwhelming business scope)
Same here, you will probably find more, but the goal is to superficially outline the concept.
Intermediate Result
Looking back to our first two approaches, what do we have?
Both do not scale well, because they combine the whole business complexity within a single stack. Things are separated on a technical level, but they aren’t on a business level. This is quite ok if you are in a manageable environment where your business needs don’t (or just slightly) grow and where you don’t plan to scale your team setup (e.g. following the two pizza rule applied to teams).
The second approach introduces distribution complexity on a technical layer and I only see rare cases where this could make sense. Therefore, as a general practice I’d denote the “Entity Service” approach as an Antipattern.
As both approaches do not scale very well, the question arises: what does actually scale?
Scaling Approach
To answer the question of “how to build a scalable solution”, we go back to our business process. The thesis is that we find independent technical contexts that we can develop independently, if we align them with the business process.
To find those contexts within the business process, we search for its “natural cuts”. Those cuts can be found where the process itself is asynchronous, where something naturally happens after something else. They can also be found where different departments or professions are involved.
With that in mind, what do you think about the following proposal? Different colours mark different contexts.
Well, as you probably guessed, this does not appear to be a good cut. We could discuss the first cut, but it is obviously not a good idea to end the purchase without storing the groceries.
So let’s give it another try, how about this:
Yes, this looks good from my point of view.
The first context is the one of “dish planning”, it ends with a grocery list that could be input (or a domain event, if you will) to the next context, the purchase. The last context is the dish preparation in this proposal.
Of course, depending on the real world context, it makes sense to even break it further down. In a restaurant for example, it could make sense to cut the dish preparation from the dish serving, but we ignored the real world context in our considerations. Although, one thing becomes clear: There is not only one correct solution.
Approach 3: Microservices
Now that we cut our process into multiple contexts, we can have a look at the next possible approach:
Characteristics
Multiple deployment units
Well separated deployment units (aligned with the business process)
Single frontend/multiple backend projects (maybe in a Monorepo)
One team can be responsible for everything (Antipattern: separate backend/frontend in your team setup)
The api is the integration layer
Pros
Allows to combine multiple technologies
Improved scaling capabilities
Improved business alignment
Enables graceful degradation of service quality
Cons
Less fast development progress compared to the Monolith in the beginning
Requires synchronisation regarding the frontend (the Frontend becomes the new Monolith)
More expensive on a short term
Note: Approach 1 (the Backend-Frontend Monolith) with software modules aligned with the business process is another approach that I didn’t want to cover separately.
Approach 4: Micro Frontend
The Micro Frontend approach tackles the problem Microservices have with the Frontend Monolith, where the whole business complexity comes together in the Frontend. For Microservice teams it is therefore not easy to keep their separation and they do not gain from the major advantage that they only have to cover reduced business complexity. Micro Frontends maintain the separation as well in the Frontend, which consequently accomplishes all the benefits.
Characteristics
Multiple deployment units
Well separated deployment units (aligned with the business process)
Multiple frontend/multiple backend projects (maybe in a Monorepo)
One team can be responsible for everything (Antipattern: separate backend/frontend in your team setup)
The frontend is the integration layer (e.g. the custom element)
Pros
Very good scaling capabilities
Less expensive on a long term (if business requirements constantly grow)
Improved business alignment
Allows to combine multiple technologies
Enables graceful degradation of service quality
Cons
Less fast development progress compared to the Monolith in the beginning
More expensive on a short term
Summary
This article named and outlined some software architectural approaches with their pros and cons. For startups or small business scopes it is often sufficient to not think about scalability at all, but for constantly growing software businesses scalability is an important thing to consider.
Source: Medium - Josch Rossa
The Tech Platform