The Open Source Business Alliance (OSBA) Sovereign Cloud Stack (SCS) project was launched in 2019 to enable federation-capable cloud environments. In close collaboration between the community and OSBA's SCS team, the project uses an agile approach to create the appropriate standards and a reference implementation. SCS [1] is an open, federation-capable modular cloud and container platform based on open source software. It builds on proven open source components such as OpenStack and Kubernetes in the reference implementation (Figure 1). As a platform, SCS provides the foundations for creating offerings that deliver full digital sovereignty.

Figure 1: Visualization of the relationships between Sovereign Cloud Stack components.

SCS Community

The community comprises a wide variety of cloud service providers (CSPs) and their employees, people from the OpenStack community, and companies working on deliverables that are awarded through open tenders. Collaboration between the different providers creates a level of cooperation that rarely exists elsewhere. Various teams and special interest groups (SIGs) work together on the topics, coordinating standards and requirements in terms of content. The primary goals of SCS are for teams to take an active part in the respective upstream projects, to be involved in the creation of content, and not to allow a parallel world to develop.

The first such group to be formed out of the Operations and Identity and Access Management team was the Monitoring SIG, which is dedicated to the topics of monitoring and observability.

Observability

Observability does not just mean plain vanilla state analysis (i.e., information on whether or not a service feature is available). Monitoring in line with contemporary standards also includes collecting, storing, and visualizing metrics and aggregating log messages. The overall system enables the operator to get a comprehensive picture of their system to locate problems, their origins, and causes quickly.

In the CSP environment, additional requirements to delete accruing data are based on appropriate specifications. Additionally, for compliance reasons, certain system messages need to be logged or billing data generated from the metrics that occur.

Architecture

When the SIG was founded a year ago, it first collected the requirements of the participating CSPs and contrasted them with the individual components already covered in the reference implementation.

To avoid getting lost in discussions relating only to the tool right from the outset, the first step was to take a tool-agnostic look at the architecture. Figure 2 shows the intended architecture. First, the various roles were defined. The SCS Operator is the system operator (e.g., the CSP), whereas the SCS Integrator describes the companies that assist the operator in setting up and commissioning the system, if needed.

Figure 2: The tool-agnostic architecture of SCS.

For several reasons, the developers made a deliberate decision to ignore the container layer in the first step and focus instead on the infrastructure-as-a-service (IaaS) layer. On the one hand, this approach reduced complexity and the number of decisions. On the other hand, observability was part of an award package that was not scheduled until 2022. At the IaaS level, the focus is on OpenStack with its various components (Figure 3).

Figure 3: The IaaS monitoring components of SCS.