Going Cloud Native with Cloud Foundry @chipchilders Chip Childers, VP Technology Cloud Foundry Foundation
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 organization'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 • Add and remove resources: scaling is a • people should be able to do things and the great problem to have, but still wrong people shouldn’t Isolate resources and failures without • Run specified bits on demand: take code, • isolation and decoupling, that is one big put it together with all the rest of the things distributed single point of failure it needs and and get it running Coordinate cross service configurations: in • Measure performance/health: can’t manage • a service oriented world, services need to what you don’t measure be configured to connect with each other Detect and determine failure: sometimes, • Route public requests to running bits: the • things get real… but how do you know next big thing needs access to the internet Read and write persistent data: data has to • Recover failures: someone is going to have • live somewhere 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 App Platform == Application Opaque to the system • Containers are transparent • Orchestration is post-hoc • Lifecycle is fully managed • System changes are • imperative (“launch” stuff) System changes are • declarative (manifest.yml)
Unit of Value IaaS == Virtual Machine App Platform == Application Time to release a feature or App Opaque to the system • Orchestration is post-hoc • Containers are transparent • System changes are • Lifecycle is fully managed • imperative (“launch” stuff) 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
End Users Browser Mobile IoT Devices Elastic Runtime Buildpack Docker Rocket Core Services Provider-Specific User Provided Services (MySQL / RiakCS) Services Service Instances Platform Health Operations Logging Scaling Deployment Monitoring Infrastructure VMware AWS OpenStack Other… vSphere
Turning this: Into this: .war .jar LB .tar.gz App App App dependencies libraries DB Multi-‑server ¡run ¡time ¡ service ¡manifest environment(s)
Or even this… https://blog.appdynamics.com/devops/the-future-of-ops/
• Auto-detect frameworks BUILD • Link to App Platform APPLICATION • Self-service deploy RETIRE PUSH FIRST • Dynamic routing • Self-service APPLICATIONS RELEASE removal • Elastic scale • Integrated HA • A/B versioning • Log aggregation UPDATE MAINTAIN • Live upgrades • Policy and Auth APPLICATIONS APPLICATION
cf target <mycf> push <myapp> LB create-service <myservice> bind <myapp> <myservice> App App App start <myapp> scale <myapp> -i 100 DB …
Where’s the container in this story?
What is a “Container”? PID ? User = ? + + cflinuxfs2 cgroups Network Isolation Rules Contents Processes
Let’s talk about Buildpacks / Staging • Ruby code that detects language, frameworks, whatnot… • Compiles the code into executable binaries (*) cflinuxfs2 /bin/detect < Am I supposed to run? /bin/compile < Build the thing /bin/release < Pass along potential metadata
container.next scheduler.next CHRONOS Assembly Prescriptive
runC container.next scheduler.next CHRONOS Assembly Prescriptive
gorouter runC container.next Auth Garden Cloud Controller Loggregator scheduler.next Core CHRONOS Services Staging Diego Buildpacks etcd Service Broker BOSH Assembly Prescriptive
gorouter runC container.next Auth Cloud Controller Loggregator scheduler.next Core CHRONOS Services Staging Diego Buildpacks etcd Service Broker BOSH Assembly Prescriptive
Recommend
More recommend
