Going Cloud Native with Cloud Foundry @chipchilders Chip Childers, - - PowerPoint PPT Presentation

@chipchilders Chip Childers, VP Technology Cloud Foundry Foundation

Going Cloud Native with Cloud Foundry

Why does Cloud Native matter?

Since 2000, 52% of the Fortune 500 are no longer on the list

Continuous Innovation

There is a rough consensus on many Cloud Native traits. Containers as an atomic unit, for example. Micro-services as the means of both construction and communication. Platform independence. Multiple language support. Automation as a feature of everything from build to

• deployment. High uptime. Ephemeral infrastructure (cattle

not pets). And so on. Stephen O’Grady, Redmonk

http://redmonk.com/sogrady/2015/07/24/cloud-native-implications/

There is a rough consensus on many Cloud Native traits. Containers as an atomic unit, for example. Micro-services as the means of both construction and communication. Platform independence. Multiple language support. Automation as a feature of everything from build to

• deployment. High uptime. Ephemeral infrastructure (cattle

not pets). And so on. Stephen O’Grady, Redmonk

http://redmonk.com/sogrady/2015/07/24/cloud-native-implications/

There is a rough consensus on many Cloud Native traits. Containers as an atomic unit, for example. Micro-services as the means of both construction and communication. Platform independence. Multiple language support. Automation as a feature of everything from build to

• deployment. High uptime. Ephemeral infrastructure (cattle

not pets). And so on. Stephen O’Grady, Redmonk

http://redmonk.com/sogrady/2015/07/24/cloud-native-implications/

There is a rough consensus on many Cloud Native traits. Containers as an atomic unit, for example. Micro-services as the means of both construction and communication. Platform independence. Multiple language support. Automation as a feature of everything from build to

• deployment. High uptime. Ephemeral infrastructure (cattle

not pets). And so on. Stephen O’Grady, Redmonk

http://redmonk.com/sogrady/2015/07/24/cloud-native-implications/

There is a rough consensus on many Cloud Native traits. Containers as an atomic unit, for example. Micro-services as the means of both construction and communication. Platform independence. Multiple language support. Automation as a feature of everything from build to

• deployment. High uptime. Ephemeral infrastructure (cattle

not pets). And so on. Stephen O’Grady, Redmonk

http://redmonk.com/sogrady/2015/07/24/cloud-native-implications/

There is a rough consensus on many Cloud Native traits. Containers as an atomic unit, for example. Micro-services as the means of both construction and communication. Platform independence. Multiple language support. Automation as a feature of everything from build to

• deployment. High uptime. Ephemeral infrastructure (cattle

not pets). And so on. Stephen O’Grady, Redmonk

http://redmonk.com/sogrady/2015/07/24/cloud-native-implications/

There is a rough consensus on many Cloud Native traits. Containers as an atomic unit, for example. Micro-services as the means of both construction and communication. Platform independence. Multiple language support. Automation as a feature of everything from build to

• deployment. High uptime. Ephemeral infrastructure

(cattle not pets). And so on. Stephen O’Grady, Redmonk

http://redmonk.com/sogrady/2015/07/24/cloud-native-implications/

The Cloud Native Advantage: Simple Patterns Highly Automated Scaled with Ease

Fast, Safe, Scalable… Pick 3

Fast – Focus on Takt Time

Definition: the desired time between units of production output, synchronized to customer demand

http://www.strategosinc.com/takt_time.htm

Safe

A.B.T. - Always Be Testing (automatically)

Safe – Runtime Characteristics Matter

• Visibility – Measure all the things. Translate data into knowledge. (see:

OODA loop)

• Fault Isolation – Smaller applications, released independently, isolate the

scope of a fault condition.

• Fault Tolerance – Failures happen (see: Circuit Breaker Pattern / Design

for Failure)

• Autonomic Recovery – Humans have better things to do at night

Scale – Prepare (as best you can) to Succeed

• Demand elastic infrastructure
• Separate concerns - Isolated ephemeral services, Solve persistence

independently

• Accept that the scalability of a system can be a series of plateaus

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the

• rganization's communication

structure.

Melvyn Conway, 1967

Microservices are great, but they require: rapid provisioning basic monitoring rapid application deployment devops culture

Martin Fowler

• Use declarative formats for setup automation, to minimize time

and cost for new developers joining the project;

• Have a clean contract with the underlying OS, offering maximum

portability between execution environments;

• Are suitable for deployment on modern cloud platforms, obviating

the need for servers and systems administration;

• Minimize divergence between development and production,

enabling continuous deployment for maximum agility;

• And can scale up without significant changes to tooling,

architecture, or development practices.

But even that’s not enough…

• Role based access to resources: the right

people should be able to do things and the wrong people shouldn’t

• Run specified bits on demand: take code,

put it together with all the rest of the things it needs and and get it running

• Coordinate cross service configurations: in

a service oriented world, services need to be configured to connect with each other

• Route public requests to running bits: the

next big thing needs access to the internet

• Read and write persistent data: data has to

live somewhere

• Add and remove resources: scaling is a

great problem to have, but still

• Isolate resources and failures without

isolation and decoupling, that is one big distributed single point of failure

• Measure performance/health: can’t manage

what you don’t measure

• Detect and determine failure: sometimes,

things get real… but how do you know

• Recover failures: someone is going to have

to clean this mess

• Work tomorrow: when everything you’ve

thought to be true has been shown not to

You must be this tall…

We’re going to need a platform

Unit of Value

IaaS == Virtual Machine

• Opaque to the system
• Orchestration is post-hoc
• System changes are

imperative (“launch” stuff) App Platform == Application

• Containers are transparent
• Lifecycle is fully managed
• System changes are

declarative (manifest.yml)

Unit of Value

IaaS == Virtual Machine

• Opaque to the system
• Orchestration is post-hoc
• System changes are

imperative (“launch” stuff) App Platform == Application Time to release a feature or App

• Containers are transparent
• Lifecycle is fully managed
• System changes are

declarative (manifest.yml)

Platforms make promises Constraints are the contract that allows a platform to keep promises

Here is my source code Run it on the cloud for me I do not care how

Cloud Foundry Haiku Onsi Fakhouri

Buildpack Docker Rocket Browser Mobile IoT Devices

End Users Services

Core Services (MySQL / RiakCS) Provider-Specific Services User Provided Service Instances

Operations

Logging Scaling Platform Deployment Health Monitoring

Infrastructure

AWS OpenStack VMware vSphere Other…

Elastic Runtime

.war .jar dependencies libraries service ¡manifest App App App LB DB Multi-­‑server ¡run ¡time ¡ environment(s) .tar.gz

Turning this: Into this:

https://blog.appdynamics.com/devops/the-future-of-ops/

Or even this…

BUILD APPLICATION PUSH FIRST RELEASE MAINTAIN APPLICATION UPDATE APPLICATIONS RETIRE APPLICATIONS

• Auto-detect frameworks
• Link to App Platform
• Self-service deploy
• Dynamic routing
• A/B versioning
• Live upgrades
• Self-service

removal

• Elastic scale
• Integrated HA
• Log aggregation
• Policy and Auth

target <mycf> push <myapp> create-service <myservice> bind <myapp> <myservice> start <myapp> scale <myapp> -i 100 … cf

App DB LB App App

Where’s the container in this story?

= + +

Contents Processes

?

?

Isolation Rules

PID User Network cgroups

cflinuxfs2

What is a “Container”?

Let’s talk about Buildpacks / Staging

• Ruby code that detects language,

frameworks, whatnot…

• Compiles the code into executable

binaries (*)

/bin/detect < Am I supposed to run? /bin/compile < Build the thing /bin/release < Pass along potential metadata

cflinuxfs2

Prescriptive

CHRONOS scheduler.next

container.next

Assembly

Prescriptive

CHRONOS scheduler.next

container.next

Assembly

runC

Prescriptive

CHRONOS scheduler.next

gorouter Cloud Controller Auth Loggregator Staging

Buildpacks

BOSH

Service Broker

Diego

Garden etcd Core Services

container.next

Assembly

runC

Prescriptive Assembly

CHRONOS scheduler.next

gorouter Cloud Controller Auth Loggregator Staging

Buildpacks

BOSH

Service Broker

Diego

etcd Core Services

container.next

runC

That was all about 12 factor apps… What about services?

CF and Services

• Development infrastructure components

(DBs, Cache, Queue, etc…)

• Loopback to other CF hosted apps
• Reaching out to your “legacy”
• External providers

.war .jar dependencies libraries service ¡manifest App App App LB DB Multi-­‑server ¡run ¡time ¡ environment(s) .tar.gz

Turning this: Into this:

The Cloud Native Advantage: Simple Patterns Highly Automated Scaled with Ease

cloudfoundry.org