One platform — standardized, built and operated by many.
One platform — standardized, built and operated by many.
To better align the development efforts within our community we started working with outcomes. We began with this in the R4 cycle and even though we never published the outcomes for R5 - we did have them for R5 as well ;)
These outcomes intend to outline what our development work aims to enable our users (Operators, Integrators and End-Users) to gain more value from SCS. This outlines our direction much better than talking about the next features that are planned and worked on. Furthermore, the outcomes assist us in our development work to ensure that every single epic and story we work on actually pays into the greater idea.
SCS delivers building blocks for digital sovereign cloud infrastructure. We change the way infrastructure is operated and by doing this we want to enable operators to become more efficient and be able to scale better.
The outcomes allow us to look from various angles on our development efforts. Each outcome is reflected through a label within our GitHub repositories so that issues and pull requests can be labeled accordingly. Furthermore in the projects view we’ve added various filtered views to be able to quickly see which issues and working items play into which outcomes.
An overall board summarizes all of them.
While the S in SCS (at least the first ;)) stands for Sovereign it could also stand for Standardized. SCS standardizes. Creating Standards within the community, reaching out to surrounding communities, and working with upstream as well as other players in our ecosystem to make sure we don’t “just reinvent the wheel” or stew in their own juice is a fair share of our work within the project. The recent joint-efforts with ALASCA emphasize this even more.
Alongside the standardization work that has happened in the container and IaaS teams the tender 10, an important tender package for the standardization work, was kicked off at the beginning of the R5 cycle. Through the work in the SIG Standardization, a lot of the topics have gained pace in the last months, yet this is one of the major topics for the R6 cycle.
Two issues summarize the current efforts quite well:
In the last year the documentation page came to life and is already very good in being the guide for the first steps into the SCS world. Due to the efforts of the SIG Documentation, it is not just a pile of documents but has a solid concept. However, for SCS to be understandable more than just awesome docs are needed. Collecting feedback from SCS integrators just as much as people and organizations that have their first touchpoint with SCS plays an important role in ensuring SCS is continuously becoming more understandable. Furthermore, deployment guides and architectural blueprints will be added.
The planned SCS lab environment will be built up following these documentation guidelines (this refers to the IaaS reference implementation). This will be a comprehensive examination of the validity and usability of this documentation.
For the R4 development cycle one of the outcomes we proclaimed was SCS enables Operators with an excellent toolbox. An excellent toolbox is part of what is needed for operating cloud infrastructure as a commodity. Looking at what we’ve done in the past year this outcome however is much too narrow. SCS enables - on a variety of levels and not just operators, but also integrators, developers, and most importantly consumers of cloud infrastructure built upon SCS who want to run on top of fully digital sovereign infrastructure.
With Cluster Stacks, the V2 KaaS reference implementation, we provide an opinionated optimized configuration of Kubernetes clusters. Through better packaging, integrated testing, and bundled configuration SCS-based Kubernetes clusters can be individualized much easier. Throughout the R6 development cycle Cluster Stacks are taken from a technical preview to be functional and available on top of the IaaS reference implementation as well. An overview to Cluster Stacks can be found in this blog post. The Cluster Stacks can already be tried out in a demo. Although this is based on the non production ready provider Docker, the usage is the same for every provider.
Early in the R6 development cycle, the software defined networking tender VP04 was kicked of. As part of this work, we want to make sure that networking not only scales superior in the IaaS reference implementation but also enables inter-cloud connectivity between workloads on all layers.
Through GitHub, the list of network-related epics and user stories that are part of VP04 can be viewed.
With our work on the domain manager role we’re addressing a topic that has been a hurdle for public clouds and self-management by customers. Lots of public clouds, built on top of OpenStack, have developed their own ways to work around the missing possibility of domain management.
Transparency is one of the core values embedded in our project - yet we want to make sure our development efforts throughout the R6 cycle are actively working towards being transparent. This ranges from our development culture (which needs to be transparent not only to be trustworthy but also to lower the barrier to join the community) to the open operations movement, the future of the SCS project, and all the way to technical items such as SBOMs for our complete stack. Transparent projects can be audited easily and trust can be built up more easily.
Another important factor that plays into transparency is being transparent about security aspects, and incidents and proactively pursuing providing a secure reference implementation.
For our status page initiative, an initial MVP was done in the R5 development cycle. In the R6 development cycle we finalize what we’ve evaluated with the MVP and are going to ship a modern status page application. The release of the status page application (which itself is divided into frontend, backend as well as the OpenAPI spec and a repository holding the deployment logic) is de-coupled from the SCS Releases.
With our Zuul in place (thanks to the efforts throughout the R5 development cycle) it is now time to shift a lot of our test runs from GitHub actions to the Zuul instance. As part of the tender VP01 the test coverage of the foundations the IaaS reference implementation builds upon is continuously being extended.
While the SCS projects provide a modular stack and strongly work towards interoperability, we want to be opinionated in our reference implementation. Being opinionated on that level leads to focus and avoids having too many loose ends. Good examples of this is how we address verticals such as our IAM or observability stacks.
While a lot of our activities involve working upstream with the various communities doing our part of ensuring the components that SCS is built upon are staying healthy, we do want to push the boundaries of what is possible further and see where we can find ways to provide better cloud infrastructure. This does mean to sail into unchartered waters - sometimes having to turn around, hit rock bottom or actually find a new cool passage. Endeavors like the evaluation of building community SONiC images, revisiting the topic of cloud observability and testing and engaging into the discussion about the discoverability of flavors and functionality of OpenStack clouds.