Considerations for Designing and Running an Application in the Cloud
Applications written in supported application frameworks often run unmodified on Cloud Foundry, if the application design follows a few simple guidelines. Following these guidelines makes an application cloud-friendly, and facilitates deployment to Cloud Foundry and other cloud platforms.
The following guidelines represent best practices for developing modern applications for cloud platforms. For more detailed reading about good app design for the cloud, see The Twelve-Factor App.
Applications running on Cloud Foundry should not write files to the local file system. There are a few reasons for this.
Local file system storage is short-lived. When an application instance crashes or stops, the resources assigned to that instance are reclaimed by the platform including any local disk changes made since the app started. When the instance is restarted, the application will start with a new disk image. Although your application can write local files while it is running, the files will disappear after the application restarts.
Instances of the same application do not share a local file system. Each application instance runs in its own isolated container. Thus a file written by one instance is not visible to other instances of the same application. If the files are temporary, this should not be a problem. However, if your application needs the data in the files to persist across application restarts, or the data needs to be shared across all running instances of the application, the local file system should not be used. Rather we recommend using a shared data service like a database or blob store for this purpose.
For example, rather than using the local file system, you can use a Cloud Foundry service such as the MongoDB document database or a relational database (MySQL or Postgres). Another option is to use cloud storage providers such as Amazon S3, Google Cloud Storage, Dropbox, or Box. If your application needs to communicate across different instances of itself (for example to share state), consider a cache like Redis or a messaging-based architecture with RabbitMQ.
Cloud Foundry supports session affinity or sticky sessions for incoming HTTP requests to applications if a jsessionid cookie is used. If multiple instances of an application are running on Cloud Foundry, all requests from a given client will be routed to the same application instance. This allows application containers and frameworks to store session data specific to each user session.
Cloud Foundry does not persist or replicate HTTP session data. If an instance of an application crashes or is stopped, any data stored for HTTP sessions that were sticky to that instance are lost. When a user session that was sticky to a crashed or stopped instance makes another HTTP request, the request is routed to another instance of the application.
Session data that must be available after an application crashes or stops, or that needs to be shared by all instances of an application, should be stored in a Cloud Foundry service. There are several open source projects that share sessions in a data service.
Applications running on Cloud Foundry receive requests using only the URLs configured for the application, and only on ports 80 (the standard HTTP port) and 443 (the standard HTTPS port).
By default, when you push an application, all files in the application’s project
directory tree, except version control files with file extensions
.darcs, are uploaded to your Cloud Foundry instance.
If the application directory contains other files (such as
files), or complete subdirectories that are not required to build and run your
application, the best practice is to exclude them using a
.cfignore is similar to git’s
.gitignore, which allows you to exclude files
and directories from git tracking.)
Especially with a large application, uploading unnecessary files slows down
Specify the files or file types you wish to exclude from upload in a text file,
.cfignore, in the root of your application directory structure.
For example, these lines exclude the “tmp” and “log” directories.
The file types you will want to exclude vary, based on the application
frameworks you use.
.gitignore templates for common frameworks, available at
https://github.com/github/gitignore, are a useful starting point.
When a DEA is upgraded, the applications running on it are shut down gracefully, or evacuated, on the DEA to be upgraded, then restarted on another DEA. To avoid the risk of an application being unavailable during Cloud Foundry upgrade processes, you should run more than one instance of an application.
Cloud Foundry stages application using buildpacks. Heroku developed the buildpack approach and made it available to the open source community. Cloud Foundry currently provides buildpacks for the several runtimes and frameworks.
Cloud Foundry uses buildpacks to transform user-provided artifacts into runnable applications. The functionality of buildpacks varies, but many of them examine the user-provided artifact in order to properly download needed dependencies and configure applications to communicate with bound services. Heroku developed the buildpack approach and Cloud Foundry embraces it.