Cloud native architecture-an overview

Any infrastructure has two main components: compute & storage. Software needs compute to run & storage to read/write.

You can have your own local server farm to provide compute & storage. Or use a cloud provider & simply decide how much compute & storage you want, allowing them to manage the server farm. If your needs are variable, you may overprovision or underprovision your local server farm. Or outsource the planning to cloud providers who can optimize with economies of scale. Use cloud elasticity to quickly provision & deprovision as needed.

A cloud has two main requirements. Agility & Resiliency.?

Agility: The ability to keep iterating & changing rapidly. A popular way to achieve it is using Micro-services. Micro-services can allow isolated parts of a system to be updated quickly. Have continuous integration & delivery.?

Resiliency: Mistakes are not completely unavoidable because avoiding errors completely could have a heavy process & slow down agility. Make mistakes cheap. Mean-time between failures (MTBF) used to be a measure. Now, the goal is a quick mean-time to recovery (MTTR). Good isolation can enable a system to not go down even if parts of a system go down. The failure should be restricted to the domain. The design goal is loose coupling & high cohesion. But in practice, this can be hard to achieve. The way to achieve resiliency is observability. Changes to one sub-system shouldn't require changes to another sub-system (loose coupling). Relative functionality should be in the same module (cohesion). With observability, we can have canary hosts such as some production servers to monitor for errors.

Agility & Resiliency are opposing forces & need to be balanced.?

Micro-services are popularly deployed on containers, such as with Kubernetes. Needs a trace-id across micro-services to track calls. Needs metrics & error handling. Containers are light-weight & faster to deploy than VMs, unless the use-case requires VMs. Rarely, bare-metal physical servers would be required. The other extreme is using a compute lambda function as a service on 'server-less' services where all infrastructure is taken care of my the provider. Similarly, for storage, you can manage your own database or use a 'server-less' cloud fully managed database.

Scaling can be scaling-out (multiple copies of the app with a load balancer) or scaling by functionality (functional decomposition including the data), also called scaling vertically or scaling by data partitioning (vertically such as through sharding or storing columns separately; or horizontally by dividing the data by say, a name).

Cloud services can be Infrastructure-as-a-service (IaaS: provide only the compute/storage), Platform-as-a-service (PaaS: provide some software on top of compute/storage) or Function-as-a-service (FaaS-Serverless lambda functions: provide a full software stack on top compute/storage).

Co-authored with Srinivasan Varadharajan