About

What is the Apeiro-Reference-Architecture?

Public clouds, in contrast to classic Enterprise IT datacenter, introduced on-demand, fully API-driven, ticket-free, control over software and hardware resources. In consequence, clouds dramatically changed how software products are built, deployed, and managed. All relevant investments in software today target a cloud-centric future. ApeiroRA captures this momentum across our industry and offers a cloud-native and next gen opinion for materializing important segments of the cloud-edge continuum.

The reference and its construction kit are composed of multiple projects that each serve a focused function, often adhering to distinctive domains of upstream open-source standards or projects (like Gardener and IronCore with Kubernetes, CobaltCore with OpenStack, or Garden Linux which is based on Debian Linux). ApeiroRA serves as an umbrella project. Many associated components of ApeiroRA, that perform a particular functionality, are developed in their individual open-source project and by their dedicated community. These components are individually usable or as aggregate (construction kit) with built-in best practices and blueprints that we classify as ApeiroRA.

What is in Apeiro-Reference-Architecture?

ApeiroRA breaks down the IPCEI-CIS’ cloud-edge continuum target vision into three domain challenges:

  • Data Fabric (DF), a crucial service capability for all products that work with data (discovery, exchange, and integration) across the continuum. DF focuses on common denominators for data & metadata conventions, which allow more flexibility in the creation & connectivity of processes, applications and the underlying data. In other words: a fabric in which data can flow freely and the assembly of processes can be simplified, even automated.
  • Cloud Operating System (COS), using Kubernetes as a lingua franca across the distributed clouds, offering participants the chance to use and adapt to their in-house infrastructure (e.g. OpenStack) or operate on supported cloud-providers. Software qualified on COS can be ported easily or even natively run across the continuum. Best practices, tools and automation for secure development, life cycle management, and infrastructure/configuration as data are provided as well.
  • Baremetal Operating System (BOS) empowers partners with their own infrastructure to independently operate compute, storage, and networking hardware. It leverages Kubernetes as a unified automation control plane for managing the physical lifecycle of hardware resources. Also included will be a seamlessly integrated OpenStack distribution (managed in containers) for non-cloud-native workloads.

ApeiroRA is not released as turnkey solution with a big bang. SAP will iteratively develop the project in collaboration with other IPCEI-participants/industry adopters and extend the ApeiroRA functionality over the course of the IPCEI-CIS program timeline. The foundational input and best practices are derived from hardened components and projects with which SAP and other adopters run their secure, compliant, and productive cloud. ApeiroRA hence means business with strong emphasis on innovation.

What Challenges does Apeiro-Reference-Architecture address?

Software providers today struggle with the heterogeneity of European cloud infrastructure. Consequently, this high fragmentation lowers the addressable market and each local infrastructure champion with a differentiated offering, adds additional qualification and operations costs to software providers who just want to serve customers with a uniform offering spanning all regions with the cloud to the edge.

Interoperability between services on disparate providers is often reduced to the least common denominator: services can communicate via the internet. Remarkably, this fallback depends on the open standard of the Internet Protocol governed by IETF and it’s astonishing to think that a few decades ago, a similar fragmentation with network technologies existed due to competing technical and commercial offerings, leading industry users into interoperability difficulties. We’ve surely come a long way.

The IPCEI-CIS, along with our contribution of ApeiroRA, helps address and overcome the natural competing interests of individual participants in the envisioned cloud-edge continuum. Currently, market forces have not led towards interoperability across the tech-stack. In Europe, they rather have led to higher fragmentation, resulting in a few platforms with economies of scale which further attract customers due to their global uniformity, scale, and breadth of offerings.

How does Apeiro-Reference-Architecture aim to solve the challenge?

We believe that cloud-centric investment priorities along with the development of reference implementations using open-source standards and concrete cloud-native practices already clearly point us to an industry-wide accepted solution:

  • Software builders architect their products using microservices, with discoverable ports for APIs and meta data, based on aligned process models, meta data structures and data models. With such foundational framework, individual products - even from different vendors - can be automatically composed as integrated software solution that meets the business needs. The technological cloud-native underlay greatly supports and can be steered by the business perspective: resiliency, scalability, portability/mobility, and many more.

  • Application developers package their computational workloads (stateful or stateless) in immutable containers, targeting cloud-native deployments often using the Kubernetes orchestrator, particularly when considering the qualification across heterogeneous multi-clouds and on-premises.

  • Service providers design platforms, microservices, maybe with event sourcing concepts, SaaS solutions, and more. They internally build with containers, source other products from the rich cloud-native ecosystem, and ultimately target their offering for flexible deployment on Kubernetes; for containerized workloads and also for the necessary automation and management control plane.

  • Infrastructure providers offer differentiating and specialized Infrastructure-as-a-Service (IaaS). But customers (see above) nowadays also demand compatibility with Kubernetes. Providers therefore often also offer a managed Kubernetes service.

We are well aware of other forms of prevalent deployment-, service-, and infrastructure technologies. Nevertheless, just like with Linux, we argue for cloud-native and Kubernetes principles as the de-facto accepted industry standard and future-proof technology of choice as solution for the common baseline of the cloud-edge continuum. ApeiroRA offers a digital commons to jump start or enhance own existing or new offerings with components and practices ready for production.

How to apply Apeiro-Reference-Architecture?

The “reference” in ApeiroRA and its practical construction kit enables providers to construct an interoperable virtual mesh forming the essentials for a cloud. ApeiroRA uses well accepted cloud-native open standards that all modern software builders have eagerly adopted: Linux, Containers, Kubernetes, and more. Anything (stateless or stateful, batch or AI training jobs) that can be packaged into containers can roam across this mesh, finding API - or even ABI - compatible underlays at every participating node, from cloud to edge. While Kubernetes is associated with container orchestration, its architecture and declarative API machinery (with the Kubernetes Resource Model) are truly general purpose. With Kubernetes we achieve a level of uniformity required for the cloud-edge continuum, it is even possible to incorporate existing platforms and infrastructures.

This way, software providers adhering to cloud-native standards can design their solutions (potentially consisting of multiple products) based on common architectural patterns, and homogeneously deploy their products across the cloud-edge continuum materialized by components adopted from ApeiroRA. Infrastructure providers can adapt and offer their value proposition also via ApeiroRA, without losing specialization or differentiation. ApeiroRA by utilizing Kubernetes is not automatically a Write-Once-Run-Anywhere (WORA) platform nor an opinionated Platform-as-a-Service (PaaS). Instead, it promotes a common baseline for users on ApeiroRA to achieve WORA and PaaS objectives, using e.g. further technologies such as Java or WebAssembly in containers or deploying platforms like KNative or Korifi.

Yes, Apeiro-Reference-Architecture is created open!

ApeiroRA’s development mode is not the Cathedral, but is characterized by decentralized collaboration, open transparency, and rapid iteration in open source. Projects developed in ApeiroRA are made available under enterprise friendly open-source licenses and standards, and where appropriate, the projects are planned to be moved under neutral community governance. All projects aim to contribute and collaborate with other accepted and defining open-source projects, for example from the Linux Foundation, Cloud Native Computing Foundation, Eclipse Foundation, Apache Software Foundation, or GAIA-X, which together form a de-facto (EU-wide) digital commons.

ApeiroRA produces digital sovereignty at scale by offering a common baseline of well-accepted open standards without boiling the ocean or re-inventing the wheel. The ApeiroRa project is investing and providing the first step. You can shape the next step with us!

Why is SAP investing in Apeiro-Reference-Architecture?

As the market leader in enterprise application software, we’re helping companies of all sizes and in all industries run better by redefining ERP and creating networks of intelligent enterprises that provide transparency, resiliency, and sustainability across supply chains. SAP is striving to become a truly cloud-based enterprise helping customers to successfully move to the cloud.

As a European company supporting European values, with ApeiroRA we assist the EU initiative to shape a cloud-edge continuum with a concrete useable reference proposal.