https://content.pivotal.io/devops-articles/the-cloud-native-ops-opportunity | spring-framework-cloud-native-01.png | }}

Cloud Native

https://pivotal.io/cloud-native | spring-framework-cloud-native-02.png | }}

The Big Differences: Cloud-Native Versus 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.

VERSUS:

• 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).

VERSUS:

• 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.

VERSUS:

• 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.

Fair Use Source: https://pivotal.io/cloud-native