Cloud-Native

What Is Cloud-Native?

Cloud-native is an architecture and development approach where applications are designed from the ground up for the cloud. Instead of simply moving existing applications to the cloud (lift-and-shift), cloud-native applications are built to fully exploit the elasticity, scalability, and managed services of the cloud.

The Cloud Native Computing Foundation (CNCF) defines cloud-native as an approach using containers, service meshes, microservices, immutable infrastructure, and declarative APIs. For mid-market companies, this means applications that automatically adapt to changing loads, can be developed faster, and require less operational effort.

Cloud-Native vs. Cloud-Ready

These two terms are often confused but differ fundamentally:

• Cloud-Ready: An existing application that can run in the cloud but is not optimised for it. Typical example: a monolithic Java application on an EC2 instance. It runs in the cloud but does not leverage cloud-specific advantages.
• Cloud-Native: An application architecturally designed for the cloud. It uses containers, scales horizontally, leverages managed services, and is deployed via CI/CD. It would be difficult to operate on-premises.

The CNCF and Its Ecosystem

The Cloud Native Computing Foundation (CNCF) is the organisation behind Kubernetes and hundreds of other cloud-native projects. The CNCF Landscape encompasses over 1,000 projects in categories such as container runtime, orchestration, service mesh, observability, messaging, and storage. For mid-market companies, the CNCF Landscape serves as a guide for tool selection.

The 12-Factor App Methodology

The 12-Factor App is a set of rules for developing modern, cloud-native applications. The key factors are:

• Codebase: One codebase, many deployments. Every environment (dev, staging, prod) uses the same code.
• Dependencies: Explicitly declare all dependencies. No assumptions about installed system tools.
• Config: Configuration via environment variables. Never credentials or configuration in code.
• Backing Services: Treat databases, message queues, and caches as interchangeable, attached resources.
• Build, Release, Run: Strict separation between build (compile), release (build + config), and run (start process).
• Processes: Run applications as stateless processes. Session data belongs in backing services.
• Port Binding: The application exposes itself via port binding, not through external web servers.
• Concurrency: Scale via processes (horizontal), not threads (vertical).
• Disposability: Processes can be started and stopped at any time. Fast start times, graceful shutdown.
• Dev/Prod Parity: Minimal difference between development and production environments.
• Logs: Treat logs as event streams. The application does not concern itself with routing or storing logs.
• Admin Processes: Run one-off administrative tasks as separate processes.

Microservices as Cloud-Native Architecture

Microservices are a central element of cloud-native architecture. Instead of a monolithic application, individual business functions are developed, deployed, and scaled as independent services. Each microservice has its own database, its own deployment, and its own team.

When Do Microservices Make Sense for the Mittelstand?

Microservices are not a silver bullet. For many mid-market companies, a "Modular Monolith" is the better start: a monolithic application with clearly defined modules that can be individually extracted into microservices as needed. Microservices make sense when:

• Different parts of the application need to scale differently.
• Multiple teams want to develop and deploy independently.
• Individual components need to be developed in different technologies (languages, frameworks).

Containers as the Foundation

Containers – particularly Docker – are the basis of every cloud-native architecture. They package an application with all dependencies into a portable image that runs identically everywhere: on the developer's laptop, in the CI/CD system, and in production. Kubernetes orchestrates these containers in production.

For the Mittelstand, getting started with containers is often the first step towards cloud-native: existing applications are containerised, stored in a container registry, and deployed via a CI/CD pipeline. Building on this, further cloud-native practices can be gradually introduced.