1.
Cloud FoundryFrom A Developer’s Perspective <br />Multi-Language, Multi-Framework PaaS<br />1<br />

2.
Dealing with applications<br />From a Developer’s Perspective<br />2<br />

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

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

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

6.
Deploying Web App the Old Way<br />6<br />[mysqld]<br />user = foobar<br />port = 3306<br />basedir = /usr<br />bind-address = 172.58.77.101<br />key_buffer = 16M<br />thread_stack = 128K<br />thread_cache_size = 8<br />…<br />[nginx]<br />http.includemime.types;<br />default_type: application/octet-stream;<br />log_format: main ‘$remote_addr - $remote_user []…’<br />keepalive_timeout 65;<br />[tomcat]<br /><Connector redirectPort=“8443” emptySessionPath…/><br /><bean id=“sessionFactory” class=“org.springframework…/><br />[frontend]<br />dependencies:<br /><ul><li>mysqlclient

7.
ruby</li></ul>files:<br /><ul><li>core/app/fe/**/*

8.
core/common/**/*</li></ul>[blah]<br />- blah blah blah<br />mvc web app<br />

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

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

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

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

13.
developer visible architecture<br />From a Developer’s Perspective<br />11<br />

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

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

16.
Cloud Foundry APIs<br />14<br />Application Lifecycle API<br />Create, start, stop, update<br />Set URL(s), instance count, memory<br />Get stats, logs, crashes, files<br />Services API<br />Enumerate system services<br />Select and create service instance<br />Bind and unbind service & app(s)<br />Cloud Foundry<br />APIs<br />Also includes<br />Info API for both system and account space<br />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<br />

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

18.
What’s under the hood<br />From a Developer’s Perspective<br />16<br />

19.
Cloud Foundry Internal View<br />17<br />

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

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

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

23.
Cloud Foundry: Health Manager<br />The Health Manager works closely with the Cloud Controller and DEAs to ensure that applications stay alive and healthy<br />When an app instance crashes, it is the Health Manager that notes this and arranges for a replacement instance<br />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<br />21<br />

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

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

26.
Questions<br />24<br />