Cloud-Native Applications

What are Cloud-Native Applications?

Cloud-native app development is a way to speed up how you build new applications, optimize existing ones, and connect them all. Its goal is to deliver apps users want at the pace a business needs.

Importance of Cloud-Native Applications:

Empower organizations to build and run scalable applications
Dynamic environments – Public, private and hybrid clouds
Containers
Services meshes
Microservices
Immutable infrastructure

Declarative APIs

Why Cloud Native?

Some companies who implemented cloud native systems that consist of many independent services – Speed and Agility

Think about the speed, and agility achieved

Example

Netflix: has 600+ services in production. Deploys 100 times per day.
WeChat: Has 3,000+ services in production. Deploys 1,000 times a day.
Uber: Has 1,000+ services in production. Deploys several thousand times each week.

The Pillars of Cloud Native

1. Modern Design
2. Microservices
3. Containers
4. Backing services
5. Automation

Modern Design

• The Twelve-Factor Application
• Codebase
• Dependencies (Container)
• Configurations
• Backing Services
• Build, Release, Run
• Processes
• Port Binding
• Concurrency
• Disposability
• Dev/Prod Parity
• Logging
• Admin Processes

• Microservices
• Provides agility
• Each microservice has an autonomous lifecycle
• Evolve independently
• Deploy frequently
• Less risk of disrupting the entire system
• Scale independently
• Fine-grained scaling – Scale-out services as per need of processing power
• Reduce overall costs

Containers (Dependencies)

• The code, its dependencies, and runtime are packaged into a binary called a container image
• Deploy the container in any environment that hosts the Docker runtime engine
• provide portability and guarantee consistency across environments
• eliminate the expense of pre-configuring each environment

Backing services (Statelessness principle)

• “Should be exposed via an addressable URL. Doing so decouples the resource from the application, enabling it to be interchangeable”
• 

Automation (build, release and run)
It is hard to get right. If there are locks and threads waiting on each other, there is a potential performance problem in your code, along with the possibility of deadlocks. If possible, try to avoid this altogether.

Conclusion

Infrastructure as code or IaC is idempotent – run the same script over and over

automate platform provisioning and application deployment
infrastructure and deployments are automated, consistent, and repeatable.