Serlo Infrastructure
We have a microservice architecture that looks like this:
We made this switch for a plethora of reasons:
- the monolith grew large and unwieldy
- with microservice infrastructure it is much easier to incorporate a new microservice that is suited to a specific problem without refactoring the entire code base (an example: it was no problem to insert a new database layer in Rust)
- in theory, integrating and working together with other learning software will be easier to do in the future
- serlo.org was not fast enough for our needs any longer
The switch has not been made completely yet, so serlo.org is still sticking around for now. Currently, the Cloudfare worker decides which request is routed via serlo.org and which is going through the api. However, we are working on eliminating serlo.org as soon as possible.
Formerly, all requests would go through a monolith written in php (repo serlo.org-legacy). The path of a request would look like this:
