multi-cloud microservices - devops summit silicon valley 2015

Multi-Cloud MicroservicesJim Bugwadia

http://try.nirmata.io/


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



http://www.cisco.com/c/dam/en/us/solutions/collateral/trends/cloud/cisco-bca-infobrief.pdf


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 infrastructureo 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 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 NetworksService 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 11. Decouple application components from networks

2. Decouple application components from storage

3. Decouple application modules into services (Optional)





Agenda

• Introduction




• Summary



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



Steps for Level 2

1. Containerize the application

2. Evolve to Microservices





An initial motivation for Microservices was scalability

* The Art of Scalability; AKF Scale Cube




X-Axis Scalingscale by replicating the entire application

Client Load Balancer Application

Application

Application




Y-Axis Scalingscale by splitting the application

Client Load BalancerCustomers

Service

Catalog Service

Orders Service

/catalog

/customers

/orders




Z-Axis Scaling

Client Load BalancerCatalog

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 scalingscale by splitting the application & replicating services


Service

Catalog Service

Orders Service

/catalog

/customers

/orders




Microservices combines X-Y axis scalingscale by splitting the application & replicating services


Service

Catalog Service

Orders Service

/catalog

/customers

/orders

Best scalability

Best efficiency




1. Elasticscales up or down independently of other services

2. Resilientservices provide fault isolation boundaries

3. Composableuniform APIs are used for each service

4. Minimalhighly cohesive set of entities

5. Completeloosely coupled with other services

A Microservices application is composed of several cooperating but independent services. Each Service is:




Agenda

• Introduction




• Summary



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 ComputingSpecial 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




ApplicationServices

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 31. 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



http://youtube.com/nirmata


Agenda

• Introduction




• Summary



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 Transformyour 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

Technology