Cloud Native
What is Cloud Native?
You’ve most likely heard the term “cloud native,” but what does it really mean? This article explores the five requirements of a true cloud native application.
Save to Folio
As businesses have moved to the cloud and adopted new cloud services, the architectures and methodologies for building software have had to mature to meet these new demands. According to Gartner, “more than 70 percent of companies have now migrated at least some workloads into the cloud.” We can expect this momentum to continue due to COVID-19, which changed the way businesses operated.
The term “cloud native” has grown in popularity, but it has mixed definitions. People often conflate cloud native with technologies like containers and microservices, but leveraging these technologies doesn’t automatically make software cloud native. As the name suggests, cloud native applications run in and developers have architected them for the cloud. In other words, developers have built infrastructure and methodologies optimized for the cloud.
When thinking about a solution as cloud native, it’s essential to think about scaling automation and building infrastructure and software solutions that can adapt and communicate in these dynamic environments. We should treat infrastructure as immutable and tasks as disposable so our software can adjust and scale. We can even physically move our infrastructure at any time, autonomously and with virtually no downtime. Then, we can define our solution as genuinely cloud native.
Let’s explore cloud native software’s anatomy to understand what being cloud native truly means.
Anatomy of Cloud Native Software
A few key factors enable software to become cloud native. The most obvious is that our application runs in the cloud, but simply running on a cloud-based infrastructure isn’t enough.
Let’s say we have an application running on an AWS Elastic Compute Cloud (EC2) instance in AWS. Sure, it’s running in the cloud, but what happens when that EC2 instance goes away, or the system must scale up due to heavy traffic?
If our application can’t handle this, it isn’t yet cloud native — even if it’s running in the cloud. Actual cloud native applications integrate these fundamental cloud capabilities from the start. As a result, people often talk about containers and microservices synonymously with cloud native applications. Containers help make it easier to dynamically scale environments. By building applications as microservices, we can scale each service independently instead of scaling everything simultaneously.
The Cloud Native Computing Foundation (CNCF) documentation states “[c]ontainers, service meshes, microservices, immutable infrastructure, and declarative application programming interfaces (APIs) exemplify [the cloud native] approach.” Let’s break each of these five components down to understand what they are and how they empower cloud native software.
1. Containers
Containers have become synonymous with the term cloud native because using containers helps a solution become cloud native. These software packages contain everything the application needs to run, such as the code, configuration, runtime, system tools, and libraries.
The main benefit of containers is that it’s easy to start, shut down, and restart the application since everything is all in one place. We can also easily port the application as the underlying hardware provides disk space and memory resources. We can manage everything else the application needs within the container. Finally, packaging an application into a container makes it easy to scale. We can simply run multiple containers to increase throughput based on the current workload (if the application architecture supports it).
Each of these features takes an application much closer to hitting the true definition of cloud native. The underlying hardware can be immutable, as we can simply destroy and rebuild the container on different hardware. We can also scale our application by creating more containers or use a containers-as-a-service offering that simplifies deployment, management, and scaling of containerized applications.
2. Microservices
We’ve just discussed the power of containers, but our application architecture must support this modularization in practice. Otherwise, we end up with a monolithic application running inside a container, which negates most of the container’s positives.
A microservice architecture breaks an application down from one extensive system into multiple services that each handle one specific task. Breaking an application up means making each service loosely coupled. Loose coupling makes it quicker to make changes and add a service without impacting the whole codebase. It’s also easier to scale, as now we control which parts of the system to scale and by how much.
For example, instead of sharing a single database across all services in a monolithic application, each microservice can have its own database, ensuring loose coupling.
3. Service Meshes
Breaking your application into smaller chunks makes it easier to manage and scale. Now you have many more services than you can physically separate, but they still need to communicate with each other. Service meshes help solve this challenge.
A service mesh controls how services talk to each other. Managing that communication can be cumbersome if you have many microservices that must speak to specific additional services. Instead of coding how each microservice communicates, you can use a service mesh instead. The service mesh abstracts this communication to a separate infrastructure layer, simplifying the process.
As we’ve already explored, we need to break down our applications into small, self-contained packages to be genuinely cloud native. The simplest way to do this while maintaining inter-service communication is by using service meshes.
4. Immutable Infrastructure
A critical mindset to adopt when making an application cloud native is to consider all infrastructure as immutable. Hosting infrastructure in a cloud provides many benefits. Still, you can realize them only if the infrastructure can die, move physical location, and change size with ease and minimal impact on an application.
This flexibility is one of the main reasons containers and microservices have become synonymous with the term cloud native. Your application must be self-contained and broken into small chunks that make deploying and scaling trivial for the infrastructure to be immutable.
When thinking about immutable infrastructure, one final thing to consider is dealing with failures. If a server fails, your deployments should respond automatically. Technologies like Kubernetes, a container management platform, let you have self-healing containers that you can restart if the container fails a defined health check, which is ideal if a server needs rebooting or replacing.
Rebooting a server with self-healing containers means that you can restore your service when it’s possible. But this doesn’t prevent downtime. For this, you should seriously consider redundancy.
Again, containerized services allow you to run multiple instances anywhere you like. Having a backup service on a different server that you can hot-swap on failure means your service stays online even if there is a server failure. Having the redundancy server in a separate physical location, like using a different AWS availability zone, is also good practice to protect your service from localized cloud service disruption.
5. Declarative APIs
The final point from the CNCF is about declarative APIs. An API is a set of functions or features that perform specific tasks in a particular system. You can build APIs for internal use only or allow other services to interact with them.
The goal of declarative APIs is to allow users to describe what they must do versus how. For example, let’s say you have a use case for creating orders and storing them in a database. You can build an API that exposes this functionality in several ways. A non-declarative example would involve functions that allow the user to describe how to connect to the database and create and save an order. A declarative API, in contrast, would have a single function or endpoint that encapsulates all of this. Now the end-user simply asks your API to create an order, and you control how this happens
The benefit of a declarative API is that now the application controls the business logic and how services communicate with each other. This control enables you to break the components down, ensure they can communicate through service meshes, and build scalable and resilient microservices.
Although these “cloud native” characteristics we’ve just discussed often apply to cloud platforms, you can also apply them to on-premise solutions if you want to have cloud capabilities on your infrastructure. Or, the solution can straddle both in a hybrid cloud environment. If the five points discussed above are built-in, then technically, your solution is cloud native, regardless of your physical hardware’s location.
Conclusion
The term cloud native isn’t just a marketing buzz-term, it’s a method to build resilient and scalable applications.
An application running in a container in the cloud isn’t necessarily cloud native. A monolithic application packaged up in a container and running in a cloud service doesn’t fulfill the core elements of what makes a service genuinely cloud native.
Cloud native really means that an application is scalable and portable. An application should include microservices that run at higher levels of abstraction than virtual machines, such as containers that communicate through service meshes, to be called cloud native. The application must treat any hardware and infrastructure as immutable and be quick to deploy. Finally, any APIs must be declarative to allow users to describe what should happen, not how.
Only when it meets these five requirements can we call an application cloud native.