What are cloud-native applications?
Cloud-native is an approach to building and running applications that exploits the advantages of the cloud computing delivery model. Cloud-native is about how applications are created and deployed, not where. While today public cloud impacts the thinking about infrastructure investment for virtually every industry, a cloud-like delivery model isn’t exclusive to public environments. It's appropriate for both public and private clouds. Most important is the ability to offer nearly limitless computing power, on-demand, along with modern data and application services for developers. When companies build and operate applications in a cloud-native fashion, they bring new ideas to market faster and respond sooner to customer demands.
Organizations require a platform for building and operating cloud-native applications and services that automates and integrates the concepts of DevOps, continuous delivery, microservices, and containers:
DevOps is the collaboration between software developers and IT operations with the goal of constantly delivering high-quality software that solves customer challenges. It has the potential to create a culture and an environment where building, testing and releasing software happens rapidly, frequently, and more consistently.
Continuous Delivery, enabled by Agile product development practices, is about shipping small batches of software to production constantly, through automation. Continuous delivery makes the act of releasing dull and reliable, so organizations can deliver frequently, at less risk, and get feedback faster from end users.
Microservices is an architectural approach to developing an application as a collection of small services; each service implements business capabilities, runs in its own process and communicates via HTTP APIs or messaging. Each microservice can be deployed, upgraded, scaled, and restarted independent of other services in the application, typically as part of an automated system, enabling frequent updates to live applications without impacting end customers.
Containers offer both efficiency and speed compared with standard virtual machines (VMs). Using operating system (OS)-level virtualization, a single OS instance is dynamically divided among one or more isolated containers, each with a unique writable file system and resource quota. The low overhead of creating and destroying containers combined with the high packing density in a single VM makes containers an ideal compute vehicle for deploying individual microservices.
“One of the things we've learned is that if you can't get it to market more quickly, there is no doubt that the market will have changed and no matter how well you've engineered it or built it or deployed it or trained your folks, it's not going to be quite right because it's just a little too late.“
Executive VP and CIO, Liberty Mutual Insurance Group
Why cloud-native applications matter
Cloud-native applications are purpose built for the cloud model. These applications—built and deployed in a rapid cadence by small, dedicated feature teams to a platform that offers easy scale-out and hardware decoupling—provide organizations with greater agility, resilience, and portability across cloud environments.
Cloud as competitive advantage.
Cloud-native means switching cloud goals from IT cost savings to the engine of business growth. In the age of software, businesses that can quickly build and deliver applications in response to customer needs will build enduring success.
Enable teams to focus on resilience.
When legacy infrastructure fails, services can suffer. In a cloud-native world, teams focus specifically on architecting for resilience. A cloud-native focus helps developers and architects design systems that stay online regardless of hiccups anywhere in the environment.
Gain greater flexibility.
Public cloud providers continue to offer impressive services at reasonable costs. But most enterprises aren’t ready to choose just one infrastructure. With a platform that supports a cloud-native approach, enterprises build applications that run on any (public or private) cloud without modification. Teams retain the ability to run apps and services where it makes the most business sense—without locking into one vendor’s cloud.
Align operations with the overall business.
By automating IT operations, enterprises can transform into a lean, focused team aligned with driving business priorities. They eliminate the risk of failure due to human error as staff focus on automated improvements to replace routine, mundane admin tasks. With automated live patching and upgrades at all levels of the stack, they eliminate downtime and the need for ops experts with ‘hand-me-down’ expertise.
The Big Differences: Cloud-Native Versus Traditional Enterprise Applications
Traditional Enterprise Applications
|Predictable. Cloud-native applications conform to a framework or “contract” designed to maximize resilience through predictable behaviors. The highly automated, container-driven infrastructure used in cloud platforms drives the way software is written. A good example of such a “contract” is illustrated by the 12 principles first documented as the 12-factor app.||Unpredictable. Traditional applications can’t realize all of the benefits of running on a cloud-native platform due to the unique way each one is architected or developed. This type of application often takes longer to build, is released in big batches, can only scale gradually, and assumes high availability of dependent services.|
|OS abstraction. A cloud-native application architecture lets developers use a platform as a means for abstracting away from underlying infrastructure dependencies. Instead of configuring, patching, and maintaining operating systems, teams focus on their software. The most efficient means of abstraction is a formalized platform, for example, Pivotal Platform which is ideal for operating on cloud-based infrastructure such as Google Cloud Platform (GCP), Microsoft Azure, or Amazon Web Services (AWS).||OS dependent. Traditional application architecture allows developers to build close dependencies between the application and underlying OS, hardware, storage, and backing services. These dependencies make migrating and scaling the application across new infrastructure complex and risky, working against the cloud model.|
|Right-sized capacity. A cloud-native application platform automates infrastructure provisioning and configuration, dynamically allocating and reallocating resources at deploy time based on the ongoing needs of the application. Building on a cloud-native runtime optimizes application lifecycle management, including scaling to meet demand, resource utilization, orchestration across available resources, and recovery from failures to minimize downtime.||Over-sized capacity. Traditional IT designs a dedicated, custom infrastructure solution (“snowflake”) for an application, delaying deployment of the application. The solution is often over-sized based on worst-case capacity estimates with little capability to scale beyond to meet demand.|
|Collaborative. Cloud-native facilitates DevOps, a combination of people, process, and tools, resulting in a close collaboration between development and operations functions to speed and smooth the transfer of finished application code into production.||Siloed. Traditional IT operates an over-the-wall handoff of finished application code from developers to operations, which then runs it in production. Organizational priorities take precedence over customer value, resulting in internal conflict, slow and compromised delivery, and poor staff morale.|
|Continuous delivery. IT teams make individual software updates available for release as soon as they are ready. Organizations that release software rapidly get a tighter feedback loop and can respond more effectively to customer needs. Continuous delivery works best with other related approaches including test-driven development and continuous integration.||Waterfall development. IT teams release software periodically, typically weeks or months apart, when code has been built into a release despite the fact that many of the components of the release are ready earlier and have no dependency other than the artificial release vehicle. Features that customers want or need are delayed and the business misses opportunities to compete, win customers, and grow revenue.|
|Independent. Microservices architecture decomposes applications into small, loosely coupled independently operating services. These services map to smaller, independent development teams and make possible frequent, independent updates, scaling, and failover/restart without impacting other services.||Dependent. Monolithic architectures bundle many disparate services into a single deployment package causing unnecessary dependencies between services and leading to a loss of agility during development and deployment.|
|Automated scalability. Infrastructure automation at scale eliminates downtime due to human error. Computer automation faces no such challenge, consistently applying the same set of rules across any size of deployment. Cloud-native also goes beyond the ad-hoc automation built on top of traditional virtualization-oriented orchestration. A fully cloud-native architecture is about automating systems, not servers.||Manual scaling. Manual infrastructure includes human operators that manually craft and manage server, network, and storage configurations. At scale, operators are slow to correctly diagnose issues and easily fail to correctly implement at scale due to the level of complexity. Hand-crafted automation recipes have the potential to hard-code human errors into the infrastructure.|
|Rapid recovery. The container runtime and orchestrator provides a dynamic, high-density virtualization overlay on top of a VM, ideally matched to hosting microservices. Orchestration dynamically manages placement of containers across a cluster of VMs to provide elastic scaling and recovery/restart in the event of app or infrastructure failure.||Slow recovery. VM-based infrastructure is a slow and inefficient foundation for microservice-based applications because individual VMs are slow to startup/shutdown and come with large overhead even before deploying application code to them.|
What to keep in mind if you're
considering cloud-native applications
Operations will be transformed in a cloud-native world.
Your operations team will graduate from keepers of the status quo to champions of process improvement and automation, delivering value direct to the business. A cloud-native platform takes care of day 1 release and day 2 operations of applications, automatically monitoring and remediating issues that previously needed manual intervention.
Your workloads will need to be prioritized.
Not every workload should be converted to cloud-native. Business and IT professionals need to work together to prioritize legacy and greenfield workloads to determine the technical feasibility, strategic importance, and hence the ROI on a cloud-native direction in each case. In addition to greenfield development, a variety of replatforming patterns are available to help with this assessment.
Developers will need to code to a contract.
To reap the benefits of a cloud-native platform, developers will likely require more discipline to follow the 12-factor principles and standardize their platform and services. With so many choices available today, it’s tempting to embrace new technology and patterns for every app. Smart teams embrace a purposeful set of constraints so they are free to focus on innovative software, not reinventing the wheel for basic capabilities.
Stay current on important topics
You will need a platform; build or buy?
Many teams explore building their own platform from a combination of open-source automation and container technologies. However, they soon discover they need more components than they thought—all of which weren’t designed to work together and their effort will delay starting the real work of building applications. Add to this to the fact that once teams have a working platform, they have to maintain it. Compare this experience to using a proven, integrated product like Pivotal Platform. From day 1, teams can focus on building applications that drive the business, confident in the platform’s ability to take care of ops and infrastructure.
You don’t have to go it alone.
Learning through immersion, for example, by working with Pivotal Labs, can thoroughly soak a team in Agile product development practices such as continuous delivery, and reinforce new development habits. There’s a wealth of information out there about this model: consume it and try it out. It’s a chance for teams to try something new if they’re in that 75 percent that feel like their organizations are not agile enough.