HypeTeq

Cloud-Native Applications

Blog

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 

Tagged:

SAY HELLO

Follow Us on Social Media

en_USEnglish