Cloud native is a phrase we are beginning to hear more and more in recent days. From a language standpoint, “cloud native” seems to imply that some applications do not fit very well in the cloud (like a tourist in a foreign land), while other cloud native applications are very much at home and thriving in the cloud (like a citizen of a country). In fact, cloud native applications (citizens) are most at home in cloud native infrastructures (countries).
Let’s stretch this citizen-country analogy a bit further. There are many countries, and many citizens who, in most cases, belong to only one particular country. Not all countries are the same, though generally they share certain characteristics that make them a country: flag, immigration, government, shared culture/language. Likewise there are probably many ways to do cloud native infrastructure, and while there may be differences in implementation and details, they share the same distinctive set of characteristics and principles.
Secondly, a citizen of a particular country may visit another country and live there for many years. However, even after being in another country for a decade, that citizen would probably still say that he is more at home in his home country, and able to better take advantage of the benefits of citizenship that are bestowed to him at home. Likewise, a particular cloud native application is always written in such a way that the application is more at home and able to take fuller advantage of the infrastructure in a certain native infrastructure than in another infrastructure.
In essence, when we talk about cloud native, we need to address what it means for both infrastructure and applications to be cloud native.
There is actually a foundation called the Cloud Native Computing Foundation (CNCF) that champions cloud native technologies to “enable cloud portability without vendor lock-in” (CNCF FAQ). Its mission is “to make cloud native computing ubiquitous.”
The CNCF Cloud Native Definition v*0 says (words in bold are mine for emphasis):
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.
I think the “official definition” is helpful to us to clarify what cloud native is and isn’t. Let’s take a look at what traits are non-negotiable from this definition:
- Non-negotiable: Scalable applications, public/private/hybrid clouds, loosely coupled systems, resilient & manageable & observable, automation, open-source & vendor-neutral
- Negotiable: Containers, service meshes, microservices, immutable infrastructure, declaractive APIs (although these are “exemplary”)
Many of the points that follow borrow heavily from many of the points made from Chapter 1 of the book, Cloud Native Infrastructure, by Kris Nova and Justin Garrison, which can be found here.
What Cloud Native Isn’t
It is often instructive, when trying to understand a complex subject, to first start off by exploring what the subject isn’t.
- Cloud native isn’t just about running applications in a public cloud. After all, you could simply “lift and shift” VMs from your own datacenter to EC2 or Compute Engine in the cloud (infrastructure-as-a-service), and virtually nothing was gained from it .
- Cloud native is not about running applications in containers. For instance, running applications in containers per se (e.g. via
docker run) is not really that much of a gain compared to running the application straight in the VM itself.
- Cloud native doesn’t mean you only run a container orchestrator, e.g. Kubernetes. After all, it is possible to use a container orchestrator in a way that is not intended, locking in applications to a specific set of servers. It is, however, a big step forward in the right direction.
- Cloud native is not about microservices. While microservices have benefits such as allowing shorter development cycles on a smaller feature set, monolithic applications can also have the same benefits when done properly, and can also benefit from cloud native infrastructure.
- Cloud native is not about infrastructure as code. Infrastructure as code, such as Ansible, Chef, and Puppet, automates infrastructure in a particular domain-specific language (DSL). However, using these tools often merely automate one server at a time, and do not actually manage applications better.
What Cloud Native Is
Since cloud native applications and cloud native infrastructure are separate but related concerns, I’ll discuss them separately.
What Cloud Native Infrastructure Is
- Cloud native infrastructure is hidden behind useful abstractions. There would not really be a “cloud” if all you get is access to bare metal APIs.
- Cloud native infrastructure is controlled by APIs. As above, the abstractions are to be provided for via an API.
- Cloud native infrastructure is managed by software. Cloud native infrastructure is not user-managed, it is self-managing by software.
- Cloud native infrastructure is optimized for running applications. The chief aim of cloud native infrastructure is to run applications for the user.
In other words, cloud native infrastructure behaves very much like a platform-as-a-service (PaaS) offering.
While the CNCF would like to advocate for “open-source” and “vendor-neutral” solutions as its definition of cloud native (see above), I think that such a definition would preclude what many in industry already consider to be cloud native. Examples of this are AWS Lambda, AWS Elastic Container Service (ECS), AWS Fargate, which are all decidedly proprietary with no open source equivalents, but many still consider them to be cloud native. Hence I think the list is a good guiding principle on what is cloud native in general.
Kubernetes is the poster child of cloud native infrastructure which checks all the boxes above while being open-source and vendor neutral. However, we would be very wrong to conclude that Kubernetes is the only way to having a cloud native infrastructure. In fact, I would even dare to say that trying to manage your own Kubernetes is not in line with the principles of cloud native, because in many ways you are managing it yourself.
What Cloud Native Applications Are
A cloud native application is designed to run on a cloud native infrastructure platform with the following four key traits:
- Cloud native applications are resilient. Resiliency is achieved when failures are treated as the norm rather than something to be avoided. The application takes advantage of the dynamic nature of the platform and should be able to recover from failure.
- Cloud native applications are agile. Agility allows the application to be deployed quickly with short iterations. Often this requires applications to be written as microservices rather than monoliths, but having microservices is not a requirement for cloud native applications.
- Cloud native applications are operable. Operability concerns itself with the qualities of a system that make it work well over its lifetime, not just at deployment phase. An operable application is not only reliable from the end-user point of view, but also from the vantage of the operations team. Examples of operable software is one which operates without needing application restarts or server reboots, or hacks and workarounds that are required to keep the software running. Often this means that the application itself should expose a health check in order for the infrastructure it is running on to query the state of the application.
- Cloud native applications are observable. Observability provides answers to questions about application state. Operators and engineers should not need to make conjectures about what is going on in the application. Application logging and metrics are key to making this happen.
The above list suggests that cloud native applications impact the infrastructure that would be necessary to run such applications. Many responsibilities that have been traditionally handled by infrastructure have moved into the application realm.
Cloud native is a loaded term which is easily misused by many marketing departments. Everyone claims that their infrastructure solutions are cloud native, but I believe that a guiding rule of thumb (in line with everything that has been mentioned above) is that being cloud native should enable your organization to leverage cloud infrastructure in a way that is cost-effective and resource-effective, that is to say, waste and spend as little (time, effort, and money) as possible while achieving more optimum and faster results, compared to the most optimal state and performance that today’s technology allows; it is a continuum rather than a binary state. In my view, that is really what it means to be cloud native.
- Cloud Native Infrastructure (Chapter 1) https://www.oreilly.com/library/view/cloud-native-infrastructure/9781491984291/ch0*html
- What is Operability? https://blog.softwareoperability.com/what-is-operability/