Is it possible to capture the entire Cloud Native universe on a single web page? The CNCF did it with the Cloud Native Landscape: let’s see how to interpret it and what it includes.
When entering the Cloud Native world, it’s impossible not to come across the CNCF Cloud Native Landscape. It is a sort of extremely detailed and dense map, enormous in size and difficult to read, that constantly changes its profile at impressive speed. And indeed, the instinctive reaction is to close it and run away.
So how do you approach it? And why should you? What is it for, after all?
Let’s try to break it down and interpret it in this post.
What is the CNCF?
The Cloud Native Computing Foundation aims to make Cloud Native universal and sustainable, promoting applications and services built natively for the cloud, with a strong preference for open source and positioning itself as a vendor-neutral space.
It operates within the Linux Foundation, a non-profit foundation. SparkFabrik was among the first of the current six Italian silver members to join.
What is the Cloud Native Landscape for?
The Cloud Native landscape map aims to collect all existing Cloud Native solutions, whether open source projects or proprietary products, and organise them by category.
The CNCF, among other things, acts as an open source project incubator, which are represented on the map by larger tiles. Some are still in the incubation phase, while others have been fully promoted (graduated). The other smaller tiles represent open source projects if they have a white background and proprietary products if they have a grey background.
How is the CNCF Landscape structured?
The map is organised according to specific categories and subcategories. Let’s list them and explain each one briefly.
A fun fact before we begin. At the time of writing this article, the map contains 941 entries, with a total of over 2.6 million stars (a way to value a project on the development platform par excellence, GitHub) and global funding of 17.3 billion dollars.
PROVISIONING
- Automation and Configuration
- Container Registry
- Security & Compliance
- Key Management
RUNTIME
- Cloud Native Storage
- Container Runtime
- Cloud Native Network
ORCHESTRATION & MANAGEMENT
- Scheduling & Orchestration
- Coordination & Service Discovery
- Remote Procedure Call
- Service Proxy
- API Gateway
- Service Mesh
APP DEFINITION AND DEVELOPMENT
- Database
- Streaming & Messaging
- Application Definition & Image Build
- Continuous Integration & Delivery
Let’s look at these categories one by one.
PROVISIONING
Provisioning aims to lay the foundations for Cloud Native platforms and applications. This area includes tools that enable:
- the creation, configuration and management of infrastructure;
- the scanning and storing of container images;
- security management with embedded authorisation and authentication;
- the distribution of secrets.
RUNTIME
Moving up one level, we find runtime solutions that include everything a container needs to run in a Cloud Native environment. After all, the container believes it is alone in the environment it runs in and is unaware that it shares resources with others.
This category therefore includes all the tools needed to manage the lifecycle of a container, to allow it to store data that persists even when the app is restarted (making data persistent) and to help it communicate with other containers (overlay network, a network on top of a network).
ORCHESTRATION & MANAGEMENT
We have laid the foundations with a solid and secure infrastructure, we have helped containers define themselves, have the necessary resources to function and communicate with other containers: at this point it becomes necessary to manage multiple independent containerised services.
Moving up one level on the landscape map, you find all the tools for orchestrating and scheduling containers in clusters (a set of physical or virtual machines connected in a network). This area also includes all the discovery, coordination, proxy and mesh services. Their function is to ensure that services can find each other and communicate effectively so that they work as a single cohesive application.
Completing the picture are the API gateways that increase control over communication, especially with external applications.
APPLICATION DEFINITION AND DEVELOPMENT
The first three levels of the landscape aim to build a solid, secure environment complete with all the necessary dependencies. We are now ready to explore the tools that allow developers to actually build their applications.
From databases to streaming and messaging between services in decoupled or choreographed architectures, to application definition and image build technologies that provide an improved developer experience. Not to mention the revolutionary CI/CD that surfaces potential errors to engineers early, so they can intervene continuously, raising the quality of deployed code.
But the map doesn’t end here.
We have additional columns on the right: Observability & Analysis and Platform.
OBSERVABILITY AND ANALYSIS
Observability is the property of a system that describes the degree to which it can be observed and understood based on its outputs and results. We’re talking about CPU time, memory, disk space, latency, errors, etc. Depending on how measurable these data points are, a system is more or less observable.
Analysis is the activity that makes sense of and interprets the collected and observed data. A high degree of observability and constant, careful analysis are two factors that enable detecting anomalies in a timely manner and remedying them immediately to avoid service interruptions.
This category of the landscape includes logging, monitoring, tracing and chaos engineering tools and services.
PLATFORM
Platforms don’t offer anything more than what individual tools do on their own, but they undoubtedly make development teams’ work easier by grouping all the necessary tools for the different levels of the creation process in a single space. Many companies opt to build this type of platform in-house, but it is a significant undertaking that requires a dedicated team and know-how.
For most organisations, however, especially those with small development teams, adopting existing platforms turns out to be the only way to pursue a sustainable Cloud Native journey.
You will notice that virtually all platforms are based on Kubernetes, and this is no coincidence: Kubernetes is and remains the heart of the entire Cloud Native stack.
