What it takes to be cloud native?

Interesting question as cloud computing models are firmly established as the new normal for enterprise IT. Every company, if it hasn't already started, is thinking of moving workloads to the cloud.

However, just lifting and shifting monoliths to run on some cloud service provider will not reap the full benefits of this computing model. We can read in the Gartner's "4 Trends Impacting Cloud Adoption in 2020" article that

Through 2024, nearly all legacy applications migrated to public cloud infrastructure as a service (IaaS) will require?optimization to become more cost-effective.

So, what exactly does cloud native mean? I like very much of the Duncan Winn’s definition on his book Cloud Foundry: The Cloud-Native Platform:

Cloud native is a term describing software designed to run and scale reliably and predictably on top of potentially unreliable cloud-based infrastructure.

The term "cloud native" has seemingly emerged within the Cloud Foundry community. Cloud-native apps need to be designed from scratch with scalability, availability and distribution in mind to fully leverage the underlying cloud runtime environment.

Cloud-native software is massively scalable

To benefit from the elastic nature of the cloud infrastructure, cloud-native software need to run as disposable and stateless processes that are designed to maximise robustness through fast startup times and graceful shutdowns.They can cope with huge spikes in workload through:

• Cloning or scaling out
• Functional decomposition the microservice architecture’s way
• Data partitioning or sharding

as prescribed in the scale cube, which first appeared in the book The Art of Scalability.

Source: https://akfpartners.com/growth-blog/scaling-your-systems-in-the-cloud-akf-scale-cube-explained

Cloud-native software is highly reliable

A fundamental trait of cloud-native software is distribution. Distributed systems comprise multiple programs (process) executing concurrently and in a coordinated way on network-connected separate servers to collectively perform a global computation. The crux here being that the overall computation at hand is distributed over multiple processes. The participants may execute the same or distinct code.

Distributed computing may offer many benefits such as higher throughout, scalability, availability, maintainability and evolvability. There are pitfalls though, as such the fallacies of distributed computing, namely:

1. The network is reliable
2. Latency is zero
3. Bandwidth is infinite
4. The network is secure
5. Topology doesn't change
6. There is one administrator
7. Transport cost is zero
8. The network is homogeneous

Another trade-off of distribution is higher failure rates. The greater the number of moving parts (servers, storages, networks), the higher the chances of failure. Therefore, instead of trying to avoid failures, we need to embrace them and design our apps accordingly. The Availability Cube is a model to guide discussions on how to achieve high availability consisting of three major techniques:

• Cloning or replicating everything
• Avoiding deep chaining of synchronous service calls
• ?Defining “blast radius” boundaries or bulkheads

Source: https://akfpartners.com/growth-blog/akf-availability-cube

How to build cloud-native software?

The Twelve-Factor methodology, a set of good practices long ago established by Heroku, has been helping teams to design elastically scalable applications and build their deployment pipelines. Here they are:

1. One codebase tracked in revision control, many deploys
2. Explicitly declare and isolate dependencies
3. Store config in the environment
4. Treat backing services as attached resources
5. Strictly separate build and run stages
6. Execute the app as one or more stateless processes
7. Export services via port binding
8. Scale out via the process model
9. Maximise robustness with fast startup and graceful shutdown
10. Keep development, staging, and production as similar as possible
11. Treat logs as event streams
12. Run admin/management tasks as one-off processes

This original list was augmented by Keven Hoffman in 2016 with three additional guidelines: Security, Telemetry and the concept of "API First".

API first?frees organizations from the waterfall, deliberately-engineered system that follows a pre-planned orchestration pattern, and allows products to evolve into organic, self-organizing ecosystems that can grow to handle new and unforeseen demands.

Reaping the experience of being a heavy adopter of Cloud Foundry in JPMorgan, Allan Beck & John McTeague have created a very interesting model for assessing applications suitability to run in the cloud based on their traits and behaviours.

Source: Developing Cloud-Native Apps on SAP Cloud Platform