The document discusses Cloud Foundry from a developer's perspective, highlighting its capabilities as a multi-language, multi-framework platform as a service (PaaS) that facilitates application scaling and deployment. It outlines the developer's expectations for seamless deployment, the architecture of typical web applications, and the lifecycle management provided through Cloud Foundry's APIs and command line tools. The platform abstracts infrastructure management to allow developers to focus on writing code rather than configuring environments.

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

2. Dealing with applicationsFrom a Developer’s Perspective2

3. Application EvolutionStart with a great idea for an appBuild a typical web app as a prototype, major refactor it into v1Written using Spring, Rails, or Sinatra with scripting around the edgesAllow me to scale, learn by doing, experiment with new approaches, etc.At scale, tons of traffic, pushing some limitsExtend my app with a backend processing tierUse 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 healing3

4. Developer ExpectationsWrite code not tickets…The application is my unit of currencyExpect friction free deployment, i.e., the system acts as the architectI manage to the boundaries of my code, no furtherDon’t force me to learn how to cobble together a middleware stack, and then service it for lifeI write code because its fun: configuring a kernel, installing packages, writing configs is not funChoose my own cloudDevelop and test on a low cost cloudDeploy into a high SLA cloudDeploy into clouds where my app is neededDon’t want to learn a new model each time I go to a new cloud4

5. Typical Web Application5Spring web app, Rails, Sinatra, Node.js, etc.Elastic pool of app instances, easy to scaleDatabase accessible by all instancesdatabasesystem load balancerelastic poolapp instanceapp instance

6. Deploying Web App the Old Way6[mysqld]user = foobarport = 3306basedir = /usrbind-address = 172.58.77.101key_buffer = 16Mthread_stack = 128Kthread_cache_size = 8…[nginx]http.includemime.types;default_type: application/octet-stream;log_format: main ‘$remote_addr - $remote_user []…’keepalive_timeout 65;[tomcat]<Connector redirectPort=“8443” emptySessionPath…/><bean id=“sessionFactory” class=“org.springframework…/>[frontend]dependencies:mysqlclient

7. rubyfiles:core/app/fe/**/*

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

9. Deploying Web App on Cloud Foundry7# to target and login to cloud foundryvmctarget http://api.cloudfoundry.comvmc login# to create and boot the app for the first timevmc push myapp –instances 2 –mem 64M –path ../code# to create the database and bind it to the appvmc create-service mysql –name mydb –bind myapp# update live app with new codevmc update myapp –path ../codemvc web app

10. At Scale – Multi-Node Distributed App8system load balancerredismysqlmongodbelastic poolrabbitMQelastic poolfront_endfront_endback_end

11. Complex App on Cloud Foundry9# create the front end and backend apps# front end is small but multi-instancevmc push fe –instances 8 –mem 64M –path ../fe_codevmc push be –instances 2 –mem 256M –path ../be_code# create the services and bind per specvmc create-service mysql –name mysql –bind fevmc create-service mongodb –name mongo –bind bevmc create-service rabbit –name rabbit –bind fevmccreate-service redis –name redis –bind fevmc bind-service redis bevmc bind-service rabbit be# to perform an update of codevmc update fe –path ../new_fe_codevmc update be –path ../new_be_codemulti-node, distributed app

12. SummaryCloud Foundrylets me start smallLearn new approaches, frameworks, and servicesDevelop on my cloud or yoursCloudFoundrylets me grow my appMulti node distributed systemsBuilt-in scaling at the node levelCloudFoundrylets me deploy & run with no frictionThere is no learning curve. 0 to cloud in 3 clicksCloud Foundry is my infrastructure architectCloud Foundry lets me choose my own cloud10

13. developer visible architectureFrom a Developer’s Perspective11

14. Applications, Instances, Services, Tools12Application ConceptsInstances make my application scale. The more instances the more load the app can handleAll of the code, libraries, and, data that are needed in order to run my code on a system supplied stackMy app is URL addressable and can have multiple URLs, some clouds allow custom domainshttp://www.fooServices are used to extend an application with higher level functions like a KV store or email gatewayApplication Toolsvmc (command line tool) and STS plugin (IDE) are the primary tools used by developers$ vmc update myapp$ vmc apps$ vmmy code

15. Logical View of Cloud Foundry13Infrastructure Abstraction (Cloud Foundry hides this)Servers, networks, storage delivered as softwareNo more wires, boxes, configuring, coolingCloud FoundryAbstractionApplications, instances, and servicesManage to the boundaries of your codeCloud Foundry is your architectuser appsuser appsclient toolsCloud Foundryinfrastructure

16. Cloud Foundry APIs14Application Lifecycle APICreate, start, stop, updateSet URL(s), instance count, memoryGet stats, logs, crashes, filesServices APIEnumerate system servicesSelect and create service instanceBind and unbind service & app(s)Cloud FoundryAPIsAlso includesInfo API for both system and account spaceAccount 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 CLI15Create app, update app, control appvmc 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 informationvmcmem <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 informationvmc 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-uservmc services, vmc apps, vmc info

18. What’s under the hoodFrom a Developer’s Perspective16

19. Cloud Foundry Internal View17

20. Cloud Foundry Logical View18vmc clientSTS pluginbrowser(user app access)RouterHealth Manageruser appsCloud Controlleruser appsDEA: execution environmentServices: core, ecosystem, etc.Infrastructure

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

22. Cloud Foundry: Cloud ControllerIt is responsible for all state changes in the systemEnsuring all dependencies are availableBinding the application to servicesAnything that effects users, apps, or services is controlled by the Cloud ControllersExamples : vmc push, vmc instances, vmc create-service, etc. are driven by the Cloud ControllerOnce staged, the Cloud Controller is responsible for connecting the application to a DEA execution unit20

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

24. Cloud Foundry: DEAThe system maintains a pool of standby DEAs and these act as the VM-level container for an applicationDEAs 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 code22