What is cloud native and 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. When companies build and operate applications using a cloud native architecture, they bring new ideas to market faster and respond sooner to customer demands.
While public cloud has affected the thinking about infrastructure investment in virtually every industry, cloud-like delivery isn’t exclusive to public environments. Cloud native development is appropriate for both public and private clouds; it’s about how applications are created and deployed, not where.
More important is the ability to offer on-demand access to computing power along with modern data and application services for developers. Cloud native development incorporates the concepts of DevOps, continuous delivery, microservices, and containers.
“Cloud native is structuring teams, culture, and technology to utilize automation and architectures to manage complexity and unlock velocity.”
Joe Beda
Co-Founder, Kubernetes and Principal Engineer, VMware
Watch Joe talk about Kubernetes
How do you build cloud native applications?
To build and operate cloud native apps, organizations have to re-think the approach to application delivery and incorporate cloud native architecture principles.
DevOps is the collaboration between software developers and IT operations with the goal of delivering high-quality software that solves customer challenges. DevOps creates 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 the process of moving incremental software changes into production constantly through automation. Continuous delivery makes the act of releasing software dull and reliable, so organizations can deliver software more frequently with less risk—and get feedback faster.
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 same application, typically as part of an automated system, enabling frequent updates to live applications without impacting customers.
Containers offer both efficiency and speed compared with standard virtual machines (VMs). Using operating-system-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.
Security threats to enterprise systems and data have never been greater. Cloud native security offers a transformative way to reduce risk in the enterprise based on three principles: repair vulnerable software as soon as updates are available; frequently repave servers and applications from a known-good state; rotate user credentials often.
“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.”
James McGlennon
Executive VP and CIO, Liberty Mutual Insurance Group
Why do cloud native applications matter?
Cloud native apps are built and deployed in a rapid cadence by small, dedicated feature teams to a platform that offers easy scale-out and hardware decoupling. This approach provides organizations with greater agility, resilience, and portability across cloud environments.
-
Gain a competitive advantage.
Cloud native development means switching from a focus on IT cost savings to seeing the cloud as an engine of business growth. In the age of software, businesses that can quickly build and deliver applications in response to customer needs will achieve enduring success.
-
Enable teams to focus on resilience.
When legacy infrastructure fails, services can suffer. In a cloud native world, teams can focus on architecting for resilience. The rapidly expanding cloud native landscape helps developers and architects design systems that stay online regardless of hiccups in the environment.
-
Achieve greater flexibility.
Public cloud providers continue to offer impressive services at reasonable cost. But most enterprises aren’t ready to choose just one cloud environment. With a platform that supports cloud native development, 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—while avoiding cloud lock-in.
-
Align operations with business needs.
By automating IT operations, enterprises can transform into lean, focused teams aligned to business priorities. This eliminates the risk of failure due to human error as staff focus on automation to replace manual admin tasks. Automated live patching and upgrades at all levels of the stack eliminates downtime and the need for ops experts with ‘hand-me-down’ expertise.
Cloud Native Apps vs. Traditional Enterprise Apps
|
CLOUD NATIVE APPLICATIONS
|
TRADITIONAL ENTERPRISE APPLICATIONS
|
|
Predictable. Cloud native apps conform to a framework or “contract” designed to maximize resilience through predictable behaviors. The 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 application is architected or developed. This type of application often takes longer to build, releases improvement in big, infrequent batches, scales up instead of out, and assumes dependent services provide high availability. |
|
OS abstraction. A cloud native architecture gives developers a means of abstracting away underlying infrastructure dependencies. Instead of configuring, patching, and maintaining operating systems, teams focus on software. The most efficient means of abstraction is a formalized platform. |
OS dependent. Traditional application architecture allows developers to build close dependencies between the application and underlying OS, hardware, storage, and backing services. Versus the cloud native model, these dependencies make migrating and scaling the application across new infrastructure complex and risky. |
|
Right-sized capacity. A cloud native application platform automates infrastructure provisioning and configuration, dynamically allocating and reallocating resources at deploy time based on the 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 with minimum downtime. |
Oversized capacity. Traditional IT designs a dedicated, custom infrastructure solution (“snowflake”) for an application, delaying deployment of the application. The solution is often over-sized and built to satisfy worst-case capacity estimates with little ability to scale beyond design limits to meet demand. |
|
Collaborative. Cloud native architecture facilitates DevOps, a combination of people, process, and tools that increases collaboration between development and operations teams to speed and smooth the transfer of finished application code into production. |
Siloed. Traditional applications utilize an over-the-wall handoff of finished application code from developers to operations. 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 at intervals of weeks or months, despite the fact that many components of a release may have been ready much earlier with no dependencies. 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 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, consistently applying the same set of rules across any size 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 create and manage server, network, and storage configurations. At scale, operators are slow to correctly diagnose issues and fail to correctly implement solutions 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, ideally matched to the microservices architecture. Orchestration dynamically manages placement of containers across a cluster to provide elastic scaling and recovery/restart in the event of app or infrastructure failure. |
Slow recovery. VMs by themselves are a slower and less efficient foundation for microservice-based applications due to slower startup/shutdown and operating system overhead for each VM. |
What to keep in mind if you’re considering cloud native applications
With a cloud native architecture, your operations teams become champions of process improvement and automation, delivering direct value to the business. A cloud native platform takes care of Day 1 release and Day 2 application operations, automatically monitoring and remediating issues that previously would have needed manual intervention.
This list will help you get the most from your cloud native development efforts.
Prioritize workloads for modernization.
Not every application 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 ROI in each case.
Code to a contract.
Developers require more discipline to follow 12-factor principles and must standardize the platform and services. With so many choices available, it’s tempting to embrace new technology and patterns for every app. Smart teams embrace a set of platform constraints and focus on innovative software, rather than reinventing the wheel for each application.
Decide whether to build or buy a platform.
Some teams build their own platform using a combination of open source automation and container technologies. However, component selection, deployment, and integration delays the real work of building applications and a do-it-yourself (DIY) platform requires continuing maintenance. A proven, integrated product like VMware Tanzu Application Service lets teams focus on building applications to drive business from day one with more confidence and less pre-occupation with ops and infrastructure.
Choose between self-paced and immersive skill-building.
Learning through immersion can give a team a solid foundation 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.
