It’s the App, Stupid!Orchestration, DevOps Automation

& What’s in Between

Uri Cohen Head of Product @ GigaSpaces @uri1803#openstackIL

Some Background

OpenStack Is Doing Great,

Thanks

• 2013: “The year of the user”

• 166 contributing entities

• A few big public clouds• Many public customer

use cases– “2013 - Year of the User”

And We All Know the

PayPal Story (or Do We?)

Platform Is More Well-

Rounded than Ever

But Then Again, It’s

about Services &

Apps

Automation Is Key for:• Testability• Consistency• Agility• Stability

What It Really Takes to

Deploy and Manage Apps

Provision

Install

Configure

Deploy

Monitor

Scale

The Automation Continuum

Environment Creation

SW Infra. Setup & Config

Code Push Monitoring & Alarming

Repairing Scaling

The Automation Continuum

• VMs / Bare Metal Servers• Network (Firewall, NAT, VPN, etc.)• LB Groups • Storage (Block / Blob)

Environment Creation

The Automation Continuum

SW Infrastructure Setup & Configuration

• OS Configuration (e.g. ulimit, useradd, permissions, etc.)• Installation of packages and middleware components • Startup orchestration• Update (not very frequent)

The Automation Continuum

Code Push

• User code installation on software infrastructure – e.g. jar, war, rails sources, PHP sources, DB scripts, etc. – After setup– On going - can be very frequent

• Push policies (canary, red/black, a/b)

The Automation Continuum

Monitoring & Alarming

• What should be monitored? – Availability: are my services up or not?– Performance (OS &services level metrics). How are my services doing?– State: What’s running where, state of system resources (e.g. quota

utilization)

• Alarms upon failure or when reaching certain thresholds– Simple (a-la CloudWatch) or complex (CEP driven)

The Automation Continuum

Repairing

• Various types of failures– Service level – service not responding, process failed– VM / Node failure – Infrastructure failure (disk, network)

• Automation tools can go a certain way – Resiliency should also be part of the SW stack

The Automation Continuum

Scaling

• Manually or Automatically (alarm triggered) • Scaling by

– Adding / removing instances (AKA out / in)– Adding / removing resources to / from an existing instance (AKA up /

down)

• For both, it needs to be supported by the SW stack

What’s Available for

Today’s Stackers

http://transferium.files.wordpress.com/2010/11/hipster-1.jpg

Orchestration Tools

Environment Creation

SW Infra. Setup & Config

Code Push Monitoring & Alarming

Repairing Scaling

Grizzly, HavanaV1

CM Tools

Environment Creation

SW Infra. Setup & Config

Code Push Monitoring & Alarming

Repairing Scaling

Monitoring

Environment Creation

SW Infra. Setup & Config

Code Push Monitoring & Alarming

Repairing Scaling

PaaS Frameworks

Environment Creation

SW Infra. Setup & Config

Code Push Monitoring & Alarming

Repairing Scaling

Tying The Pieces

Together Usually

Looks Like This

AWS OpsWorks,

AKA DevOps

Automation

http://www.allthingsdistributed.com/2013/02/aws-opsworks.html

He-Who-Must-Not-Be-Named(At least not in an OpenStack conference)

Urquhart Called it

The Composable

PaaS

James Urquhart

http://bit.ly/12GpwKb

And Some Called It

The PaaS Jail Breaker

or DevOps Meets

Paas(Yours truly included)

http://bit.ly/12Gor4W

Nati Shalom

DevOps Automation

Gives You Control

• A Way to tie all the pieces on the Automation Continuum together– Use what works nest, not

reinvent each piece from scratch

So You Can Have This

Environment Creation

SW Infra. Setup & Config

Code Push Monitoring & Alarming

Repairing Scaling

DevOps Automation, High Level

Orchestrator

CI

Monitoring & Alarming

CM Infrastructure

API

OpsWorks is Cool, but

What About OpenStack?

TOSCATopology and Orchestration Specification for Cloud Applications

Heat (Probably

After Havana)

• New DSL, more than just cloud resources - complete aplication stack orchestration

• Inspired by TOSCA and CAMP

• Looks quite promising• Current state: DSL proposal

• Still not covering post deployment aspects as part of the DSL

Donabe (Not Yet Public)

• Started by Cisco to handle network configuration • Quickly evolved to

handle application stack configuration • Not much public

info, will be release as OSS soon (?)

• Open source• Does most of this stuff

on OpenStack today• Integrates with Chef,

Puppet, Jenkins OOTB• Still proprietary API

– TOSCA and Heat, stay tuned…

Thank You!