Knowledge quiz

Containerization

Centralized Systems

Dynamic Scheduling

Communication Through APIs

Containers are easily deployable, since the program to be run does not need to be pre-installed on a machine

Containers provide a sandbox and thus improve process isolation

Containers do not need a host or VM

Containers can never crash

Kyma / Kubernetes

Cloud Foundry

ABAP Steampunk

Sequel Script Fusion

Repository for Source Code

Registry for Binary Artefacts

Runtime Environment for Deployed Instances

Purgatory for Failed Builds

Discriminator column

Schema separation

Separate database instances

Round robin of attributes

It is possible to support customers in the cloud environment they are already using

One does not risk a so-called vendor-lock-in

One achieves a better global coverage concerning geographical locations

It is easier to support vendor-specific features in applications

In-App Extensibility

Side-by-Side Extensibility

Inside-Out Extensibility

Autonomous Extensibility

You get repeatable outcomes regardless of the starting state.

As a user, you do not need to specify (or even know) how to reach a target state. You just specify how the desired state looks like.

You can specify whatever you wish for, and the API will make it work.

There will never be resource shortages, as a scheduler in the background will solve them.

Composable Business Applications and Integrated architecture

Best-of-Breed and separated architecture

Virtual processes and hyperscaled architecture

Back-to-Monolith and stabilized architecture

It is a unified semantic data model abstracting from the phyiscla data representation and is based on CDS.

It is a layer used for data visualization in virtual reality and is based on OpenGL

It is a replacement for the physical data model and speeds up read operations by pushing them up to the application layer.

It is a separated semantic data model that is updated asynchronously to improve fail-overs and is based on NVMe.