More than mere technical qualities, most commentators also tie cloud native down to the implementing organization’s working practices and mindset. Cloud native organizations will actively embrace the cloud for their entire stack, viewing it as a distinguishing feature of their offering. This stands in contrast to suppliers which see the cloud merely as a datacentre that runs their services.
Varying Definitions
As with many common cloud buzzwords, you’ll get different answers on what constitutes cloud native depending on who you ask.
Microsoft says the term describes systems which “embrace rapid change, large scale, and resilience.” To VMWare, it’s “an approach to building and running applications that exploits the advantages of the cloud computing delivery model.” Oracle highlights how cloud native is founded on “distributed computing.”
RedHat is more specific, stating that cloud-native apps are “a collection of small, independent, and loosely coupled services” that deliver “well-recognized business value.” The last part acknowledges that cloud native is about more than software. A successful cloud native system should deliver tangible results for your business, whether that’s increased customer satisfaction or reduced time to launch.
The Cloud Native Computing Foundation’s charter defines the concept as a paradigm of “loosely coupled systems that are resilient, manageable, and observable.” They facilitate “high-impact changes [made] frequently and predictably with minimal toil.”
Cloud Native Traits
There’s no single pathway to becoming cloud native. The terminology is flexible and based on qualitative characteristics. Cloud native systems will usually be founded on microservices deployed with a container orchestrator, utilizing automated deployment flows to move code through the pipeline. The actual implementation is down to each organization to decide.
This model enables new changes to be launched rapidly without loss of control. Developers commit changes, push them to a repository, and let their CI pipeline deploy a new release out to production. Automation reduces the risk of errors and gives developers greater opportunity to concentrate on writing new code.
The resulting speed-up in the development cycle increases overall productivity, delivering more features to users in a shorter timeframe. This aids customer satisfaction and engagement, projecting an image of a constantly evolving codebase where bugs are patched soon after discovery.
Cloud native isn’t quite “let the machine do the work” though. Another core tenet is observability, the notion that systems should surface their internal state in a way that’s readily accessible to operations teams.
Effective monitoring, tracing, and logging gives you visibility when problems do occur. An observable system surfaces the information you need to resolve issues. You use the introspective capabilities of your infrastructure to uncover the lifecycle of requests, from your mesh to individual services and back again.
Separation of Concerns
A critical characteristic of cloud native systems is strong decoupling. This goes hand-in-hand with the microservice model. Services must be able to standalone without hard dependencies on each other. This increases resilience and makes it easier to swap out parts of your stack in the future.
Each functional unit becomes its own microservice that communicates with the others through clearly-defined APIs. It lets you separate out individual parts of your system, helping developers to focus on their specific area and allowing you to place stronger safeguards around critical services in production. Your authentication service might benefit from a greater degree of isolation than your general purpose web containers.
Decoupling services makes them more scalable so your system’s better equipped to respond to changes in user demand. If media coverage causes a surge in user sign-up numbers, you can quickly add more instances of your registration service backend to handle the extra traffic. A conventional approach with a monolithic app on a VM or bare-metal server couldn’t adapt in this way.
The Business Advantages
Becoming cloud native often has significant impacts on the organization as a whole. Improved scalability can lower costs, increase service uptime, and keep infrastructure a step ahead of users. It all leads to a more competitive platform that’s agile enough to respond to market changes.
Legacy systems might have no established deployment procedures, instead relying on a periodical roll-up of recent changes into production. This renders rapid response to customer concerns impossible. In a cloud native system, you can react to tickets as they come in. Code usually ships straight after a merge, letting you making improvements in minutes instead of days.
Cloud native systems can be more attractive to developers too, making it easier to hire top talent. Using technologies like Docker and Kubernetes in production demonstrates a commitment to modern workflows that make day-to-day development less demanding. The ability to access highly skilled engineers usually results in better products built in less time, creating a self-sustaining cycle that starts an upturn in the organization’s growth.
Cloud Native and DevOps
Cloud native systems are often the result of good DevOps practices. Whereas DevOps describes the interaction between development and operations teams, cloud native focuses on the result of that interaction and its impact on the broader business.
The DevOps cycle maintains a tight loop between planning, building, testing, releasing, and monitoring. It increases development velocity by clearly defining the sequence of events in a new feature’s lifecycle. Respecting DevOps principles increases the probability that a system will be an effective cloud citizen.
The two have a tendency to arise from each other. If you’re knowingly practicing one of the terms, you’re probably already riding on the benefits of the other too. Cloud native systems are automatically deployed on a regular cadence; effective use of DevOps tools such as CI/CD pipelines is the logical way to implement fast development flows.
What About “Cloud Enabled?”
You may come across systems described as “cloud enabled” instead of cloud native. This term usually refers to applications which are transitioning from traditional development and deployment models to cloud alternatives.
A cloud enabled system will run using cloud infrastructure but may not be fully decoupled and modularized. If you’ve got a legacy monolith, it’s usually relatively straightforward to package it as a Docker container and launch it into the cloud. This provides some immediate benefits including the prospect of automated deployments and a degree of scalability.
The application layer is still a monolith though. A refactoring period will be needed to split the stack into decoupled microservices capable of scaling individually of each other. A containerized monolith can’t offer the same degree of resiliency as a system that’s been designed and built for the cloud.
Cloud enabling a system is the first step in making it into a native cloud citizen. It can be followed by a “cloud based” approach, where the application predominantly runs in the cloud with a high degree of separation of services. There may still be some mandatory ties between components, or links back to legacy infrastructure. The architecture can be called “cloud native” once these have been eliminated.
Summary
A cloud native system is one which utilizes everything the cloud can offer to accelerate development, automate deployments, and increase resiliency and observability. It’s the result of an organizational investment in modern tooling and practices, enabling teams to ship code faster and bring additional value into the business.
Becoming cloud native doesn’t happen overnight. Depending on the size of your system, it might be acceptable to aim for a “cloud enabled” or “cloud based” approach first. Gradually evolving your architecture lets you pick low-hanging fruit and monitor the impact of individual changes, giving you insight into whether your efforts are paying off.
