Impact
Apeiro Cloud Operating System (COS)
Application teams that battle with the technicalities of their software deployed in the cloud also face an additional business predicament: which infrastructure provider(s) should be qualified and supported? If more than one provider is necessary to reach the desired market, the application needs to be adjusted, qualified, maybe even re-written, for every infrastructure provider that must be supported. Obviously, abstractions for dealing with multiple providers are advantageous.
In general, an Operating System is the body of software that abstracts the hardware platform, multiplexes or orchestrates workloads dynamically across available resources, and protects/isolates software principals (tenants) from each other. Historically, the invention of the OS as abstraction layer was instrumental to separate software’s tight coupling with hardware. Similarly, a distributed cloud OS with reasonable abstractions will be instrumental to enable the multi provider cloud-edge continuum.
Fortunately, the cloud-native paradigm is accompanied with well-accepted technologies and practices that assist with multi-provider portability. The Apeiro Cloud Operating System (COS) includes a reference implementation for a coherent multi-provider approach. It pragmatically utilizes Kubernetes as a lingua franca across the distributed provider resources. COS does not attempt to span a single cluster over incompatible providers. Instead, COS endorses a multi-cluster approach (divide & conquer), with project Gardener providing an enterprise-ready Kubernetes-as-a-Service.
Modern applications, including any associated Application-as-a-Service canopy, are typically built and run using a combination of cloud-native technologies, microservices, preferably using event-driven architectures, and operated with progressive release and lifecycle management. Almost all software (from stateful databases, stateless algorithms, AI workflows, …, to distributed messaging systems) is packageable in immutable containers and is often qualified or even developed specifically for deployment using the Kubernetes container orchestrator. Therefore, for most software builders, the entry point for value creation is the Kubernetes cluster, which utterly leapfrogs the infrastructure centricity. Often, Kubernetes is leveraged as platform to create domain specific platforms, thereby even abstracting away any Kubernetes-centric implementation details. Following the Dependency Inversion Principle, as application teams move up the stack, the machine-centric provider underlay (with its infrastructure-as-a-service) becomes a negligible side aspect, albeit for the lowest layer in the stack (including Kubernetes itself).
Gardener is extensible, offering participants the chance to use and adapt to their in-house infrastructure (e.g. OpenStack) or operate on various, supported cloud-providers. With the help of COS and Gardener, software qualified on Kubernetes can be ported easily or even natively run across the cloud-edge continuum. Best practices, tools and automation for secure and compliant development, lifecycle management, and infrastructure/configuration as data are part of ApeiroRA as well.
