What is cloud-native?

When applications are designed and architected to take advantage of the underlying IaaS and PaaS services supported by the cloud computing platform, they are called cloud-native applications.

This means building reliable system applications, such as five nines (99.999%), that run on a three nines (99.9%) infrastructure and application components. We need to design our application components to deal with failures. To handle such failures, we need a structured approach for scalability and availability. To support the entire scale of applications, all the pieces need to be automated.

Cloud adoption typically happens in a series of steps, where the enterprise starts exploring the services before they start building cloud-native applications. The adoption starts with the movement of Dev/Test environments to the cloud, where rapid provisioning is the key ask from the business and developer community. Once the enterprise is past the environment provisioning stage, the next step/models in which the enterprise applications are migrated to the cloud-native model will be discussed in the following sections.

Lift and shift

Traditionally, enterprises started on their cloud computing journey with IaaS services. They did a lift and shift of the business application workloads from on-premises data centers and moved to the equivalent rented capacity on the cloud computing platform. This is the first wave of adoption of cloud computing platforms, where enterprises are shifted from a capital expenditure model to an operating expenditure model.

IaaS, as the names suggests, is focused on infrastructure—compute nodes, network, and storage. In this model, enterprises can take advantage of the elasticity of the cloud, where compute nodes can be added or removed based on the incoming demand or load. The virtual machine (VM) abstracts out the underlying hardware and provides the ability to scale the number of VMs up or down with just a few clicks.

Enterprises typically make use of IaaS in the first wave because of the following:

• Variability of resources: The ability to add/remove resources at will, which in turn allows more business agility
• Utility model: IaaS provides basic resources that are rented out on an hourly basis, allowing more predictability and an opex model

Going native

Once the enterprises start becoming comfortable with the IaaS, the next wave of adoption comes in terms of adoption of PaaS as part of the application workloads. In this stage, the enterprises start discovering services with the following benefits:

• Platform services replacement: This involves the identification of potential platform features of the enterprise, lifting and shifting the workload, and replacing it with equivalent platform services from the cloud provider. For example:
  • Replacing application messaging systems with queuing systems provided by the cloud provider (such as AWS SQS)
  • Replacing data stores or relational database management systems (RDMBS) with equivalent managed data services (such as AWS RDS)
  • Replacing security or directory services with a managed directory or security services (such as AWS Directory and AWS IAM)
  • These services allow the enterprise to do away with all the operational efforts, such as data store backup, availability, scalability, and redundancy, and replace them with a managed service that provides all these features

• Application services replacement: Enterprises discover new services that can replace their own platform or utility services. For example:
  • Replacing build and release services or products with equivalent DevOps services from the cloud provider (such as AWS CodePipeline, AWS CodeCommit, or AWS CodeDeploy)
  • Replacing application services or products with equivalent application platform services (such as AWS API Gateway, AWS SWF, and AWS SES)
  • Replacing analytics workload services with equivalent application analytics services (such as AWS Data Pipeline and AWS EMR)

Once the applications start adopting the platform services, the applications start abstracting out features or functionalities provided by commercial off-the-shelf (COTS) products (such as messaging, notification, security, workflow, and API Gateway) and replacing them with equivalent feature platform services. For example, instead of hosting and running the messaging IaaS, movement to an equivalent platform service means moving to a model where you pay only for the number of messages sent, without incurring any additional operational costs. This model brings significant savings, as you move from renting and operating the product to a model where the product is rented only for the time it is utilized.

Going serverless

Once the enterprise has adopted the PaaS to build the application, the next step is to abstract out the application logic as a series of smaller functions and deploy them. These functions are invoked as a reaction to an event from the user or agent, which results in these functions computing the incoming events and giving a result back. This is the highest level of abstraction, where the application has been divided into a series of functions and these functions are deployed independently of each other. The functions communicate with each other using asynchronous communication models. Cloud computing platforms provide features such as AWS Lambda and Azure Functions for going serverless.