openstack and the future of application centric infrastructure

Lew Tucker

OpenStack and the Future of Application-Aware Infrastructure

VP and CTO, Cloud Computing

November 4, 2013

@lewtucker

© 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2

It’s All About the Apps


Cloud Computing Is Winning Because…Easiest and fastest way to develop and deploy applications

Self-service, on-demand deployment, driven by automation and APIs

Elastic scaling to meet demand— scale up, and scale down

Abstracted resources that hide the complexity of lower-level implementations

Portability for applications across common platforms

Most cost-effective use of infrastructure


Developing and Deploying Applications on Physical Infrastructure

Networks

Physical Servers Storage Systems

Infrastructure

Many systems to learn, high complexity, high costrequires involvement of multiple groups

APPLICATIONSOS

APP

OS

APP

OS

APP

OS

APP

OS

APP

OS

APP

OS

APP

OS

APP


OpenStack Is Becoming the New Software Layer

Networks

Physical Servers Storage Systems

Infrastructure

APPLICATIONSOS

APP

OS

APP

OS

APP

OS

APP

OS

APP

OS

APP

OS

APP

OS

APP

OpenStack Cloud Platform


Infrastructure Delivered as a Service

OpenStack Services Have Grown From Simple Provisioning to Orchestration

NovaCompute Service

SwiftStorage Service

NeutronNetwork Service

GlanceImage Service

KeystoneIdentity Service

HorizonUser Portal

CeilometerMetering Service

HeatOrchestration

Elastic Load Balancing

APPLICATIONSOS

APP

OS

APP

OS

APP

OS

APP

OS

APP

OS

APP

OS

APP

OS

APP

OpenStack Cloud Services


More OpenStack Services Added with Each Release

APPLICATIONSOS

APP

OS

APP

OS

APP

OS

APP

OS

APP

OS

APP

OS

APP

OS

APP

Infrastructure Delivered as a Service

OpenStack Cloud Services

Deployment (TripleO)

Bare Metal (Ironic)

Hadoop (Savannah)

Relational Databases (Trove)

Messaging (Marconi)

IN INCUBATION


NovaCompute

HeatOrchestration

GlanceImage

SwiftStorage

HorizonWeb Interface

KeystoneSecurity

OpenStack Design PrincipleBuilt as a Set of Loosely Coupled, Related Projects Developing Advanced Cloud ServicesCovers compute, storage, and networking

Used to build public or private clouds

Each service driven by community projects with contributions from many companies

Easier for innovation through addition of new services

Small number of core services; Larger number of associated services

NEUTRONNETWORKING


Why Can’t Everyone Get the Benefits of Building on

an OpenStack Cloud Platform

SYSTEM ADMIN

Deploy Services on Virtual Machines (VMs) or Physical Servers Using Cloud Services API

Use Massively Scalable Object Storage Service for State

Elastically Scale Application Both Up and Down

Build on OpenStack Services for faster development and elasticity of infrastructure and network-based management services

WEB DEVELOPER

Cloud computing?


OpenStack Usage

Reaching Beyond Public Cloud Service Providers

On-premise private cloud for enterprise businesses looking to treat infrastructure as a set of scalable services

Major consumer-facing internet services

Ecommerce

Media companies

Mobile networks

New Network-function virtualization (LB/FW/VPN)

Big Data analytics with optimized networking

Management of bare-metal provisioning using cloud-like API


Cisco ONE Physical and Virtual

OpenStack The Operating System for the Data Center

Service Provider or Enterprise: becoming the platform of choice

OpenStack Network Service

OpenStack Compute Service OpenStack Storage Service

User App-1

User App-2UserApp-3

CiscoApplication


OpenStack Is “Too Big To Fail”In three short years, the open source OpenStack initiative has reached broad-based industry support towards an ambitious goal of providing a complete cloud-based infrastructure offering. At this point, while there still is risk of fragmentation…Our takeaway is that support is too broad (nearly 200 tech companies) and there is simply too much momentum behind OpenStack development for the base case to not be at least moderate success.

Initial Traction in Service Providers The large, integrated tech companies (IBM,HP, etc.) are betting with OpenStack to deliver Infrastructure as a Service economics inline Amazon’s AWS. There are also a number of Web/Internet companies using OpenStack to underlie their next-gen apps. Enterprise traction is scant, with most waiting for stability of technology, something that has happened with portions of OpenStack (compute, object storage) but not all. We expect enterprises that will look for hybrid cloud scenarios (private/public) will be early adopters.

OpenStack Is a Viable AlternativeAmazon’s AWS owns the public cloud and we expect that while OpenStack can offer some of these benefits, AWS is and will likely be more mature and have greater scale than OpenStack competition for some time. Innovation around OpenStack puts VMware’s vCloud initiative in perspective and in our view, VMware is substantially behind. Microsoft’s Azure is more mature than OpenStack…but doesn’t have a comparable ecosystem and less mindshare around next-gen applications that demand cloud-based infrastructure.

OpenStack “Major Cred”

Source: CitiBank report on OpenStacks, July 2013

© 2013 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 13Cisco ConfidentialCisco Confidential© 2013 Cisco and/or its affiliates. All rights reserved. 13Cisco Confidential 13© 2013 Cisco and/or its affiliates. All rights reserved.

How is the Growth of the Internet Effecting Data Centers?


25% CAGR 2012–2017

Global Data Center Traffic GrowthData Center Traffic Triples from 2012 to 2017

2012 2013 2014 2015 2016 20170.0

1,000,000,000,000.0

2,000,000,000,000.0

3,000,000,000,000.0

4,000,000,000,000.0

5,000,000,000,000.0

6,000,000,000,000.0

7,000,000,000,000.0

8,000,000,000,000.0

9,000,000,000,000.0

Ze

tta

by

tes

/ Y

ea

r

7.7 ZB

2.6 ZB

3.3 ZB

4.2 ZB

5.2 ZB

6.4 ZB


2012 2013 2014 2015 2016 20170

20

40

60

80

100

120

140

160

180

200Cloud Data Center (30% CAGR)

Traditional Data Center (6% CAGR)

Ins

tall

ed

Wo

rklo

ad

s i

n M

illi

on

s

Workload Shift: Cloud vs. Traditional Nearly Two-thirds of all Workloads Will Be Cloud-based by 2017

18% CAGR 2012–2017

61%

39%

37%

51%

49%

63%


WithinData Center

76%

Data Center- to-Data Cen-ter7%

Data Center-to-User17%

Global Data Center Traffic by DestinationSounds counter intuitive, but most Data Center Events/Content Stays Within the Data Center

Web, email, internal VoD, WebEx, et al.

Storage, production and development data, authentication

A

B

Within Data Center (76%)

C

Replication, inter-database links

Data Center-to- Data Center (7%)

Data Center-to-User (17%)

Cisco Public 16© 2012 Cisco and/or its affiliates. All rights reserved.


Traditional Data Center Network Topology Designed for N-S Traffic

Aggregation/Access

Compute

Services

Core

WAN Edge/DCI

Storage


Need for Bandwidth is Changing Basic Network Design

Leaf

Spine

Servers

vSwitch

VPNs/Public Internet

Edge Routers

Scale Out Core. .

. .

VM VM

Virtual Access Layer Spline-leaf fabrics for

Any-to-any path

Scale-out design

Extending to VMs


We Now Talk About Overlay and Underlay Networks

Leaf

Spine

Servers

VPNs/Public Internet

Edge Routers

Scale Out Core

. .

. .

Virtual Access Layer

vSwitch

VM VM VM

vSwitch

VM VM VM


Network Functions Virtualization (NFV) Provides Dynamically Scalable ServicesAT&T, BT, DT, Orange, Telecom Italia, Telefonica, Telstra, Verizon...


Why Not Have These Layers Talk to Each Other?Current Cloud Computing model is great for application development, self-service, and automation—but it’s missing real application-driven infrastructure.

We need a better way for two-way communication between apps and infrastructure.

But couldn’t I help! (sigh)

I’m a Cloud. I don’t need you!


OpenStack Evolution (2011)• Compute service (EC2): virtual machines

Launch instance (image, memory size, disk)Suspend, clone, migrate

• Storage service (S3, EBS): virtual disksStore objectCreate/attach block

• Networking

What to do here???

What’s the right abstraction to make it easy for developers?

App Svr

OS

VM

Source: OpenStack Design Summit, April 2011

OpenStack Networking Service (now called Neutron)• Unique to OpenStack• Simple abstractions• Create/delete isolated private networks• Attach VM to network resource• Networking services:

• Routing, IP-address management• Service attachment

?App Svr

OS

VM

App Svr

OS

VM

Neutron


Network Service Plug-In ArchitectureFor Common API, Rapid Innovation, and Vendor Differentiation

Network Service (Neutron) API

Network ServiceNetwork abstraction definition and management

No actual implementation of abstraction

Plug-In API

API Extensions

Cisco Plug-InsNX-OS (VLANs), Linux Bridge

OVS+GRE, XVLAN

Nexus 1000v (VLAN, VXLAN, OVS)

Cisco ONE Controller

Vendor/User Plug-In

Implementation of abstractions

Virtual or physical

Extended APIs


Now Application Developers Can Define Their Own Logical Topologies (Virtual Networks, Routers, Etc.)

Cisco Developed Visual Designer Interface for Networks and Containers


Extension to Define and Apply Policies with Cisco’s Nexus 1000v


Innovation Both Above and Below the Cloud PlatformCloud Provider Network-Centric Services

Classic Networking Services

VPN

WAAS

Firewall

App-Management Services

Monitoring

App/Service Catalog

Service Assurance

Identity Management

Other Services

Analytics

Location

Video Services

MobilityLoad Balancer

User and System Admin

ComputeServiceServers

StorageService

Disks

NetworkService

Networks

Customer’s ApplicationVirtual VPN

Virtual WAAS

VirtualFirewall

AppOS

VM

DatabaseOS

VM

AppOS

VM

OpenStack Cloud Platform• Bridges the virtual and physical layers

a

Programmable Infrastructure

Controllers and Agents

Cisco ONE Controller SWOpenFlow Agents

Virtual Overlays

VXLAN Gateway, OpenStack, Service Chaining

CSR 1KV

PlatformAPIs

Cisco One Platform Kit (onePK)on ISR G2, ASR 1K

RESTAPI

API

API

APIAPI

API

API

API

API

API

API

APIAPI


Example:

OpenStack Load Balancing as a Service


OpenStack is Evolving from Virtual machines to an Application-Centric View

Apps no longer run on a single VM

Multiple sets of VM’s acting together to deliver a resilient, scalable service

Effective Orchestration needs:

• Monitoring, load balancing

• Templates for launching VM’s

• Policies for adding to networks and for auto-scaling

PublicInternet

MyNewApp.com

Result: an easier, less error-prone way to deploy a resilient, scalable service


Application Orchestration in OpenStack

OpenStack Heat, based on AWS Cloud Formation, for managing entire lifecycle of multiple VM applications

Template-driven application orchestration engine

Is compatible with AWS Cloud Formation templates

Enables text-file storage with application code in source repositories

Describes application resources and relationships

Provides API consistent with other OpenStack processes

Resources include

Servers, floating IP addresses, volumes, security groups, scaling groups

Easy extensibility

Designed to provide auto-scaling for apps

Integrated with Ceilometer

Works well with other configuration management tools (Puppet, Chef)


Isn’t there a better way?

Applications running in production still have a lot elements to configure and manage


Applications start simple on a Whiteboard


Basic Three-Tier Web Application

Web Tier

Web Server

VM

Web Server

VM

Web Server

VM

PublicInternet

App Server

VM

App Server

VM

Memory Cache

VM

App-Server Tier

Database

VM

Database

VM

Database Tier

Want to connect web servers to public Internet, while blocking outside access to application and database servers

Load Balance Across Web Servers

Protect VM’s with Security Group rules


OpenStack API’s allow Tenants to Create Their Own Virtual Data Center with Networks, Routers, Security Groups, and VM’s

Web Tier

Web Svr

VM

Web Svr

VM

Web Svr

VM

PublicInternet

App Svr

VM

App Svr

VM

MemCache

VM

App Server Tier

DataBase

VM

DataBase

VM

Database Tier

Security Group “Web” Security Group “AppSvr” Security Group “DB”


Wouldn’t it Be Easier to Specify as Policy?

Web Tier

Web Svr

VM

Web Svr

VM

Web Svr

VM

PublicInternet

App Svr

VM

App Svr

VM

MemCache

VM

App Server Tier

DataBase

VM

DataBase

VM

Database Tier

Policy PolicyPolicy

Application Centric Infrastructure(physical or virtual)

PerformanceSecurityScalabilityAvailability



ConsistencyRepeatability


“Group-based Policy Abstractions for Neutron”

a new Neutron blueprint for Icehouse

Cisco, IBM, Juniper, Red Hat, Nuage, Plexxi….

Contributors:


OrchestrationAt both the Application and Infrastructure Layers (both physical and virtual)

Application OrchestrationDescribes what the components are, how they are connected, and how they elastically scale

Resource ProvisioningVirtual/Physical Nova

APIs

Swift/Glance

APIs

Neutron

APIs

Network Orchestration(ACLs, QoS, Load Balancing,

Service Chaining, etc.)

Network Controller(Cisco Application-Centric Infrastructure)

APIs

AppTemplate

Heat

APIs

Thank you.Thank you.

Onward to Icehouse!

@lewtucker

openstack and the future of application centric infrastructure

Technology

cisco andor

cisco confidential2

cisco confidential3

cisco confidential4

cisco confidential5

cisco confidential6

cisco confidential7

cisco confidential9