Going Cloud Native with Cloud Foundry
-
Upload
chip-childers -
Category
Technology
-
view
769 -
download
1
Transcript of Going Cloud Native with Cloud Foundry
@chipchildersChip 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, Redmonkhttp://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, Redmonkhttp://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, Redmonkhttp://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, Redmonkhttp://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, Redmonkhttp://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, Redmonkhttp://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, Redmonkhttp://redmonk.com/sogrady/2015/07/24/cloud-native-implications/
The Cloud Native Advantage:
Simple PatternsHighly AutomatedScaled with Ease
Fast, Safe, Scalable… Pick 3
Fast – Focus on Takt TimeDefinition: the desired time between units of production output,
synchronized to customer demand
http://www.strategosinc.com/takt_time.htm
SafeA.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 organization's communication structure.
Melvyn Conway, 1967
Microservices are great, but they require:
rapid provisioningbasic monitoring
rapid application deploymentdevops 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 codeRun it on the cloud for meI do not care how
Cloud Foundry HaikuOnsi Fakhouri
.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
PIDUser
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
CHRO
NO
S
sche
dule
r.nex
t
container.next
Assembly
Prescriptive
CHRO
NO
S
sche
dule
r.nex
t
container.next
Assembly
runC
Prescriptive
CHRO
NO
S
sche
dule
r.nex
t
gorouter
Clou
d Co
ntro
ller
Auth
Loggregator
Staging
Buildpacks
BOSH
Service Broker
Diego
Garden
etcd
Core Services
container.next
Assembly
runC
Prescriptive Assembly
CHRO
NO
S
sche
dule
r.nex
t
gorouter
Clou
d Co
ntro
ller
Auth
Loggregator
Staging
Buildpacks
BOSH
Service Broker
Diego
etcd
Core Services
container.nextrunC
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 PatternsHighly AutomatedScaled with Ease
cloudfoundry.org