[EPIC] SCS PaaS track

[depressiveRobot]

In order to further develop SCS, we want to introduce a standardized Platform-as-a-Service (PaaS) track. During the first workshop, we worked out two different user stories that define possible needs of PaaS customers.

However, before we can begin developing a PaaS track, we need to agree on a single definition of what PaaS means in the context of SCS. This epic is intended to serve as a central location to develop a common PaaS definition based on the work from the workshop. In addition, subtasks for the further development will be recorded here.

The minutes of the first SCS PaaS workshop can be found here: https://input.scs.community/s/bB09rAl0mT

Agreements from the workshop

• Certifiable PaaS: Certifications based on PaaS should be possible.
• Independent PaaS: The existing IaaS or KaaS tracks should not be a dependency for a PaaS track. Implementations should be stackable.
• Modular PaaS: There should be many granular PaaS standards as some kind of sovereign Lego blocks that can be bundled in scopes for certification.
  • One could think towards a model like with the integrator certification (e.g. various tiers bundling a specific (sub)set of standards/services).
• No automated migration: The migration of applications/workloads between clouds in an automated way seems not feasible at this stage. Several providers think it's not possible to do that in a fully automatic way (which would also include data migration and so on), which is why we have agreed on standardized interoperability ("migrate in the same way").

User stories worked out in the workshop

1. Minimal user story

As a PaaS customer,
I want to be able to order services like a database or a cache via an API and not have to worry about the operations of these services.

2. Extended user story

In order to be compatible and have interchangeability between providers,
As a PaaS customer,
I want to be able to migrate my application from one SCS PaaS cloud to another SCS PaaS cloud in the same way.

Open definition of "PaaS"

Looking at the two user stories, there are currently two different interpretations of PaaS. We have to agree on one. Or maybe there is a third option?

• Managed Services: Provisioning of cloud-managed services like Database-as-a-Service, Monitoring-as-a-Service, Logging-as-a-Service and so on similar to traditional hyperscaler offerings.
• Developer platform: A code-centric platform where developers can "push code" without any awareness of underlying infrastructure similar to Cloud Foundry or Heroku.

[depressiveRobot]

Let's continue the discussion from our PaaS workshop here: @horazont, @janiskemper, @schnatterer, @josephineSei, @KekMuzaffer, @jschoone, @MichelleFuchs, @dtoups, @theSilverFisch, @benedikt-haug, @garloff, @gerbsen

[janiskemper]

I think there is one more option on what to "promote": self-hosting platform services. This is the most sovereign approach for anyone on the platform layer. Of course, it is not the best idea for everyone and people might prefer a "commercial product". However, since it is the most sovereign option I would for sure add that option to the list.

One example of what providers can do here: Have an unreplicated, fast storage that can be used for running databases in Kubernetes.

An easy way of complying to this as a provider can just be "basic documentation on self-hosting certain components and providing all necessary foundational pieces" to make it possible.

Here I'm talking from a user perspective though. If we, for now, only wanna talk about how to standardize commercial SCS PaaS offering, then this is maybe not relevant.

Summary: The case of pure self-hosting should be included IMO - as long as we look at "how can SCS benefit users". If we take the other perspective of "how can SCS certify PaaS providers, this is maybe less relevant.

[gerbsen]

Thank you @depressiveRobot for writing this down! Since there are still some parts missing in my understanding, I comment them here:

No automated migration: The migration of applications/workloads between clouds in an automated way seems not feasible at this stage. Several providers think it's not possible to do that in a fully automatic way (which would also include data migration and so on), which is why we have agreed on standardized interoperability ("migrate in the same way").

• I have not been part of this discussion in working group 1. IMHO disregarding the use-case (Wechselfähigkeit) which we promote everywhere before even starting seems premature to me. I understand this is difficult, but we should make all our decisions with this goal in mind.

Regarding the user stories

• What is the goal with these? Should there be a complete list of stories/personas somewhere? It feels to me, that we now have chosen two at random for a PaaS-Customer. But there are also PaaS-providers, self-hosters, software-vendors, public administrations etc. So where do we draw the line? Also I've re-read the extended one now many times and I keep stumbling over the in the same way part. I don't understand to what this refers to. I think this refers to a process (that I can do in the same way), but this process is not mentioned before. Maybe in a standardised way is makes things clearer?

Regarding what @janiskemper wrote.

• I think this is a very typical use case and a good option to promote SCS in a none-business universe. Lots of organisations (like universities, associations) would benefit from this. One question though: we would provide a reference architecture again right? Wouldn't it be possible to use this as a self-hosting option and be compliant automatically? On the definition: how do we come to a consensus, do we vote?