The infrastructure component has the purpose to efficiently run and manage the upper stack components. It is designed in a way to lower the dependency on specific cloud providers. At the same time, the component is designed to easily be deployed and scaled.

What do we use to build it?

Infrastracture-as-code tool
Terraform Wrapper
Managed Kubernetes Service
Container Registry Service

Where do we demo it?

In all use case demos (except the DIY-Version), the same build is being used.

Which conceptual decisions do we follow?

The Sandbox Infrastructure provides the foundation of the Sandbox — an environment for deploying and running compatible building block implementations.
Sandbox infrastructure diagram
The main reason for using Kubernetes is to have a useful abstraction of networking and compute resources to build upon, so that compatible building block applications can remain portable (see also the DevOps chapter). In some sense, the Sandbox Kubernetes cluster simulates a "miniature Internet": Pods are hosts, services running on the "hosts" have names (leveraging the cluster-internal DNS service) and communicate using the same protocols as in the Internet.
Naturally the abstraction is leaky, and it is good to keep in mind that in a real-world implementation the building block applications would be separated and isolated into different environments, which might not even be a Kubernetes cluster. However, a goal of the Sandbox is to make it reasonably easy an efficient to deploy a set of building blocks and start exploring and developing. Therefore, we developed and provide scripting to easily setup new Kubernetes cluster. It focuses on the building blocks and does not try to be a full production environment.
The reference implementation leverages AWS Elastic Kubernetes Service (EKS). More information about the implementation, which uses Terraform and Terragrunt to automate the setup, is available in the Sandbox infrastructure repository.

Further documentation