Presentation on Cloud Foundry a Developer's Perspective given by Derek Collison and the Cloud Foundry Team

1. Cloud FoundryFrom A Developer’s Perspective Multi-Language, Multi-Framework PaaS 1

2. Dealing with applications From a Developer’s Perspective 2

3. Application Evolution Start with a great idea for an app Build a typical web app as a prototype, major refactor it into v1 Written using Spring, Rails, or Sinatra with scripting around the edges Allow me to scale, learn by doing, experiment with new approaches, etc. At scale, tons of traffic, pushing some limits Extend my app with a backend processing tier Use some services that are shared between my front end and backend components e.g., messaging, KV store, etc. Use some services that are private to each tier e.g., KV store, document store, SQL database etc. Leverage Cloud Foundry scalability and self healing 3

4. Developer Expectations Write code not tickets… The application is my unit of currency Expect friction free deployment, i.e., the system acts as the architect I manage to the boundaries of my code, no further Don’t force me to learn how to cobble together a middleware stack, and then service it for life I write code because its fun: configuring a kernel, installing packages, writing configs is not fun Choose my own cloud Develop and test on a low cost cloud Deploy into a high SLA cloud Deploy into clouds where my app is needed Don’t want to learn a new model each time I go to a new cloud 4

5. Typical Web Application 5 Spring web app, Rails, Sinatra, Node.js, etc. Elastic pool of app instances, easy to scale Database accessible by all instances database system load balancer elastic pool app instance app instance

8. core/common/**/*[blah] - blah blah blah mvc web app

9. Deploying Web App on Cloud Foundry 7 # to target and login to cloud foundry vmctarget http://api.cloudfoundry.com vmc login # to create and boot the app for the first time vmc push myapp –instances 2 –mem 64M –path ../code # to create the database and bind it to the app vmc create-service mysql –name mydb –bind myapp # update live app with new code vmc update myapp –path ../code mvc web app

10. At Scale – Multi-Node Distributed App 8 system load balancer redis mysql mongodb elastic pool rabbitMQ elastic pool front_end front_end back_end

11. Complex App on Cloud Foundry 9 # create the front end and backend apps # front end is small but multi-instance vmc push fe –instances 8 –mem 64M –path ../fe_code vmc push be –instances 2 –mem 256M –path ../be_code # create the services and bind per spec vmc create-service mysql –name mysql –bind fe vmc create-service mongodb –name mongo –bind be vmc create-service rabbit –name rabbit –bind fe vmccreate-service redis –name redis –bind fe vmc bind-service redis be vmc bind-service rabbit be # to perform an update of code vmc update fe –path ../new_fe_code vmc update be –path ../new_be_code multi-node, distributed app

12. Summary Cloud Foundrylets me start small Learn new approaches, frameworks, and services Develop on my cloud or yours CloudFoundrylets me grow my app Multi node distributed systems Built-in scaling at the node level CloudFoundrylets me deploy & run with no friction There is no learning curve. 0 to cloud in 3 clicks Cloud Foundry is my infrastructure architect Cloud Foundry lets me choose my own cloud 10

13. developer visible architecture From a Developer’s Perspective 11

14. Applications, Instances, Services, Tools 12 Application Concepts Instances make my application scale. The more instances the more load the app can handle All of the code, libraries, and, data that are needed in order to run my code on a system supplied stack My app is URL addressable and can have multiple URLs, some clouds allow custom domains http://www.foo Services are used to extend an application with higher level functions like a KV store or email gateway Application Tools vmc (command line tool) and STS plugin (IDE) are the primary tools used by developers $ vmc update myapp $ vmc apps $ vm my code

15. Logical View of Cloud Foundry 13 Infrastructure Abstraction (Cloud Foundry hides this) Servers, networks, storage delivered as software No more wires, boxes, configuring, cooling Cloud FoundryAbstraction Applications, instances, and services Manage to the boundaries of your code Cloud Foundry is your architect user apps user apps client tools Cloud Foundry infrastructure

16. Cloud Foundry APIs 14 Application Lifecycle API Create, start, stop, update Set URL(s), instance count, memory Get stats, logs, crashes, files Services API Enumerate system services Select and create service instance Bind and unbind service & app(s) Cloud Foundry APIs Also includes Info API for both system and account space Account management API, All APIs are RESTful with JSON payloads. The vmc CLI app exercises the entire API. The STS plugin provides similar functionality within the STS IDE

17. The vmc CLI 15 Create app, update app, control app vmc push [appname] [--path] [--url] [--instances N] [--mem] [--no-start] vmc update <appname> [--path PATH] vmc stop <appname> vmc start <appname> vmc target [url] Update app settings, get app information vmcmem <appname> [memsize] vmc map <appname> <url> vmc instances <appname> <num | delta> vmc {crashes, crashlogs, logs} <appname> vmc files <appname> [path] Deal with services, users, and information vmc create-service <service> [--name servicename] [--bind appname] vmc bind-service <servicename> <appname> vmc unbind-service <servicename> <appname> vmc delete-service <servicename> vmc user, vmcpasswd, vmc login, vmc logout, vmc add-user vmc services, vmc apps, vmc info

18. What’s under the hood From a Developer’s Perspective 16

19. Cloud Foundry Internal View 17

20. Cloud Foundry Logical View 18 vmc client STS plugin browser (user app access) Router Health Manager user apps Cloud Controller user apps DEA: execution environment Services: core, ecosystem, etc. Infrastructure

21. Cloud Foundry: Router The router receives all traffic from the outside world and maintains the mapping from external URL to internal application instance The router performs this job for all Cloud Foundry APIentry points (typically from vmc or STS) as well as for all application specific traffic The router acts as a load balancer, distributing requests evenly across all instances of a given app 19

22. Cloud Foundry: Cloud Controller It is responsible for all state changes in the system Ensuring all dependencies are available Binding the application to services Anything that effects users, apps, or services is controlled by the Cloud Controllers Examples : vmc push, vmc instances, vmc create-service, etc. are driven by the Cloud Controller Once staged, the Cloud Controller is responsible for connecting the application to a DEA execution unit 20

23. Cloud Foundry: Health Manager The Health Manager works closely with the Cloud Controller and DEAs to ensure that applications stay alive and healthy When an app instance crashes, it is the Health Manager that notes this and arranges for a replacement instance If the Health Manager detects rapid and repeated crashes, it declares the app to be in a “flapping” state and does not try to revive the app instances that are sick 21

24. Cloud Foundry: DEA The system maintains a pool of standby DEAs and these act as the VM-level container for an application DEAs support both single and multi-tenant operation (1 app per DEA VM, or n apps per DEA VM) DEAs provide a secure/constrained OS environment running the application’s app-server and the application code 22

25. Cloud Foundry: Services Services are one of the extensibility planes in Cloud Foundry MySQL, Redis, MongoDB, RabbitMQ, etc. are all examples of services Services may be shared across applications Cloud Foundry abstracts the provisioning aspect of services through a uniform API hosted in the cloud controller The net is that its very easy to take an app and add a service to the app in a uniform way 23

26. Questions 24