Cloud Native vs Traditional IT
Most Cloud Platforms are trending towards breaking down monolithic services into ‘micro’ or discrete services. An example would be a large monolithic Java application which is rewritten into modules providing discrete functionality and services. This becomes a loosely coupled architecture with the database services, abstracted from middleware and application services, which themselves are partitioned into providing containerised, or modularised functionality. This means that if the database or web-server is modified, the entire set of services do not need refactoring or intervention.
Table: Cloud Native vs Traditional
|
Cloud Native |
Traditional |
| Immutability and Predictability. Cloud-native applications conform to a framework or “contract” designed to maximize resilience through predictable behaviours. For example, you can move applications from on-premise into the Cloud using highly automated, container-driven infrastructure, which encapsulates older applications and code, re-platforms them to take advantage of network improvements from the public cloud provider and provides a period of time while you rewrite or update the application with new code and frameworks, and then redeploy as an immutable infrastructure using a pattern of dev-test and production environments using automation.
|
Not Immutable, hard to Predict. Traditional applications suffer from being customised in how they are architected or developed. Many of these older systems are monolithic and it takes longer to build, upgrades are released in painful waterfall-batches, which can only scale gradually, and the app has a high availability of dependent services. Most of these systems do not replicate production in a dev or test environment, which ensures breaks and failures when new releases are deployed. They are highly manually and interventionist and prone to single points of failure. |
| Abstraction of the OS. 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 Cloud Foundry 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. |
| Capacity utilisation. 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 will miss 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. |
| Automated Backup and 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. | Usually poor Backup and Recovery. Most traditional architectures suffer from a lack of automated backup, disaster-recovery, or concepts around Business Continuity. Mis-placed code, intermittent production data backup, and missing documentation are legion. |
The ‘Cloud Native Landscape’ is supported by most major firms. Important domains include Applications, Orchestration, Runtime, Provisioning, Platform models, Analysis and Monitoring, Public and Private and of course IaaS, PaaS and SaaS. Github.com/cncf/landscape
