Multi-Cloud Microservices - DevOps Summit Silicon Valley 2015

Multi-Cloud Microservices
Jim Bugwadia

11/6/2015 Multi-cloud Microservices, DevOps Summit 2015 Nirmata
Greater Cloud Adoption Leads to
Millions of $$ in Benefits
Source: IDC Business Cloud Advisor, Info Brief, Aug 2015

Cloud Application Maturity Model
You are
here
ODCA Best Practices: Architecting Cloud-Aware Applications Rev. 1.0

Agenda
• Introduction
• CAMM Level 1: Loosely Coupled
• CAMM Level 2: Abstracted
• Summary

About me
• Founder at Nirmata
• Software Developer (C++, Java, Javascript, Go)
• Large-scale distributed systems

Cloud native applications are crafted to
run optimally on cloud infrastructure

CAMM Level 0: Virtualized
• Monoliths in VMs
o Application runs on virtual infrastructure
o Application can be deployed using an image or script
• Dev  QA  Ops
OS
App
VM
OS
App
VM
OS
App
VM

Agenda
• Introduction
• CAMM Level 1: Loosely Coupled
• CAMM Level 3: Adaptive
• Summary

CAMM Level 1: Loosely Coupled
• Application is composed of loosely coupled services
• Application services are discoverable by name
• Application compute and storage are separated
• Application consumes one or more cloud services
(compute, network, storage)
11/6/2015 Multi-cloud Microservices, DevOps Summit 2015

“Coupling refers to the degree of direct knowledge
that one component has of another”
great interfaces are minimal but complete!

Decoupling from Networks
Service Naming, Registration, and Discovery
e.g. Eureka, Consul, Nirmata, Zookeeper
• Each Service Instance
registers its availability
• Other services can resolve
a well known name to a
Service Instance locations
connect with me at:
orders.shopping.com
192.168.100.23:9065
192.168.111.12:9121
192.168.213.121:8131192.168.121:6425

Decoupling from Storage
• Data Services
• Inject (or lookup) data service addresses
• Application Configuration
• Environment variables
• INI files
• Application Logs
• Logging service
• Logs as streams - collectors and aggregators

Decoupling a Monolith
Module A Module B
Web
Service A Service B
Web
DB DB DB

Steps for Level 1
1. Decouple application components from networks
2. Decouple application components from storage
3. Decouple application modules into services
(Optional)

CAMM Level 2: Abstracted
1. Services are stateless
2. Application is unaware and unaffected by failure
of dependent services
3. Application is infrastructure agnostic and can run
anywhere

Steps for Level 2
1. Containerize the application
2. Evolve to Microservices

Containers are a key building block
Immutable application images
Standard units of operations
Separation of DevOps concerns

Server
Hypervisor
Virtual Machine Containers
Guest OS
Libs/Bins
App
Libs / Bins
App App
Libs / Bins
App
Guest OS
Libs/Bins
App
Server
Host OS
Docker / RunC / Rocket

http://blog.octo.com/en/docker-registry-first-steps/
Container Lifecycle

https://docs.docker.com/v1.7/terms/images
• Common image layers can be shared
• Only deltas need to be pulled / updated
Container Image Layers

An initial motivation for
Microservices was scalability
* The Art of Scalability; AKF Scale Cube

X-Axis Scaling
scale by replicating the entire application
Client Load Balancer Application
Application
Application

Y-Axis Scaling
scale by splitting the application
Client Load Balancer
Customers
Service
Catalog
Service
Orders
Service
/catalog
/customers
/orders

Z-Axis Scaling
Catalog
Service 3
Catalog
Service 1
Catalog
Service 3
/catalog [A – I]
/catalog [J – R]
/catalog [S – Z]
scale by splitting the data

Microservices combines X-Y axis scaling
scale by splitting the application & replicating services
Customers
Service
Catalog
Service
Orders
Service
/catalog
/customers
/orders

Microservices combines X-Y axis scaling
scale by splitting the application & replicating services
Customers
Service
Catalog
Service
Orders
Service
/catalog
/customers
/orders
Best scalability
Best efficiency

1. Elastic
scales up or down independently of other services
2. Resilient
services provide fault isolation boundaries
3. Composable
uniform APIs are used for each service
4. Minimal
highly cohesive set of entities
5. Complete
loosely coupled with other services
A Microservices application is composed of several
cooperating but independent services. Each Service is:

CAMM Level 3: Adaptive
1. Application can dynamically migrate across
infrastructure providers without interruption of
services
2. Application can elastically scale out/in
appropriately based on stimuli

Why Enterprises choose Multiple Clouds?
1. Hybrid Cloud
2. Privacy and Data Locality
3. Avoid application lock-in
4. Resiliency and Availability
5. Flexibility

Application Management
• Is my application management coupled to a cloud
provider?
• Is my application management cloud-native?
• What is the right architecture for application
management?

IaaS
PaaS
SaaS
The NIST definition of Cloud Computing
Special Publication 800-145

IaaS
PaaS
SaaS
“The popular wisdom that cloud computing comes in three
flavors - SaaS, IaaS and PaaS no longer describes reality,”
-- Forrester Wave

Application
Services
Infrastructure
Services
Cloud Native Applications
• Composable Services
• Complement, not hide, infrastructure services
• Offer full visibility and control
Application (management) Services

deploy operate optimize
Complete application container lifecycle management
Single management and control plane across any cloud
Highly scalable cloud-native service
The Nirmata Approach

Policy Based
Orchestration
Real time
Analytics
Application
Blueprints
DevOps
Pipeline
Nirmata Control Plane
Host
Agent
The Nirmata Solution
Service
DB
Service
Gateway
Data Plane:
• Secure agents
• Seamless Service Discovery
• Distributed Load-balancing
• Programmable routing
Host (or VM)
DNS / LB

Steps for Level 3
1. Automate application and infrastructure management
Automated deployment, auto-recovery, auto-scalability, etc.
2. Deploy and operate on any cloud
3. (Optional) Plan for active-active cloud deployments

Solution demos
http://youtube.com/nirmata

Cloud Native Test
Level 0: Virtualized
 Can you redeploy your entire application in minutes?
Level 1: Loosely Coupled
 Is your application decoupled from specific IP
addresses, ports, file systems and paths?
 Can your application survive, and auto-recover from,
infrastructure (compute, network, storage) failures?

Cloud Native Test
 Can you upgrade and downgrade, your application
(or parts of the application) without any impact to
users?
 Can you run multiple versions of your application
services, in the same environment at the same time?
 Can you safely test in production?
 If a part of an application fails, will other parts
continue to operate?
Level 2: Abstracted

Cloud Native Test
 Can parts of your application scale-up and scale-
down automatically, based on user load or other
factors?
 Can you deploy application components across
cloud providers?
 Can you deploy an application component on a
different cloud provider?
Level 3: Adaptive

Containerize Automate Transform
your applications deployment & operations DevOps - Microservices

Summary
1. Cloud adoption results in cost
savings and agility
2. Containers and Microservices are
key technologies for cloud-native
applications
3. Application services, like Nirmata,
will expedite your journey

Start your journey to Multi-cloud Microservices at:
http://try.nirmata.io
Thank you!

Multi-Cloud Microservices - DevOps Summit Silicon Valley 2015

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Multi-Cloud Microservices - DevOps Summit Silicon Valley 2015

Similar to Multi-Cloud Microservices - DevOps Summit Silicon Valley 2015 (20)

More from Jim Bugwadia

More from Jim Bugwadia (10)

Recently uploaded

Recently uploaded (20)

Multi-Cloud Microservices - DevOps Summit Silicon Valley 2015