Serlo Infrastructure

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

List of repositories belonging to this project

• frontend
• api.serlo.org
• cloudflare-worker
• database-layer

How we publish our services? Where can I find a changelog?

frontend / cloudflare-worker

Both the frontend as well as the cloudflare-worker are published continuously. This means that always the most recent version on GitHub for each repository is also deployed in our infrastructure. Particularly:

• frontend: The current version of the staging branch is deployed in our staging environment at https://serlo-staging.dev/. The current version of the production branch is deployed on our production environment at https://serlo.org. At https://github.com/serlo/frontend/compare/production...staging you can see the differences between both branches.
• cloudflare-worker: The current version of the main branch is in general deployed in our staging and in our production environment. In case we need a different version for our staging environment in order to test features we create a temporary branch for it.

Thus both repositories do not have a changelog. The list of merged pull requests already reflect the list of last changes. For the repositories you can find them at:

• frontend:
  • Last changes to the staging environment
  • Last changes to the production environment (Note that each PR in general already contain a short description of the main changes)
• Last changes to the cloudflare-worker

api.serlo.org / database-layer

For our backend micro services we use semantic versioning. Both repositories contain a changelog for each version:

• Changelog of api.serlo.org
• Changelog of database-layer

In order to check which version is currently deployed you can have a look at the following files (server stands for api.serlo.org):

• Current version in the staging environment
• Current version in the production environment

Legacy Infrastructure (not used any more)

Formerly, all requests would go through a monolith written in php (repo serlo.org-legacy). The path of a request would look like this:

Overview of repositories

We have many repositories in our organization. They serve different purposes:

• Repositories for a service on our infrastructure (tagged with service)
• Repositories for setting up our infrastructure (tagged with infrastructure)
• Repositories for evaluation / data-analysis (tagged with data-analysis)
• Repositories for project management (tagged with project-management)
• Repositories for documentation (tagged with documentation)
• Repositories with proof of concepts / prototypes / concepts (tagged with poc)
• Repositories with tools for development (tagged with developer-tools)