Requirements for applications

Cloud Foundry places some special requirements on applications hosted on the platform. So, when is an application ready for Cloud Foundry?

To answer this, we provide a general overview of considerations for designing and operating applications so that they are highly cloud-optimized and can leverage the full potential of STACKIT Cloud Foundry.

For more details on this topic, see the official Cloud Foundry documentation on considerations for designing and running an app in the cloud.

Cloud native workload

STACKIT Cloud Foundry is a cloud native platform as a service (PaaS), so your application works best if it is also cloud native.

Why is this important?

The Cloud Native Computing Foundation’s definition of cloud native is as follows:

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

[…]

In a scaling cloud environment, your application must expect to be started and stopped at any time—because new instances can be created and destroyed to handle load spikes. If you design your application to handle this, you gain the mentioned benefits: it is scalable and thus more resilient, as your application can easily spawn multiple new instances. It is also easier to manage and observe applications that don’t have various complex states. The simple and predictable creation of new applications also gives you the ability to automate deployment, etc.

What is cloud native?

In general, you need to consider a few things when designing your app. A common pattern for cloud native apps is the Twelve Factor App. It lists twelve key factors around the development lifecycle of your software and is also a recommended pattern for use with STACKIT Cloud Foundry.

Some points on the list are more important when it comes to running your application in the cloud, others less so. For example, it is not necessary to store your application’s code in version control in order to deploy it on Cloud Foundry. On the other hand, it is very important that your application is stateless.

Therefore, your application does not have to be strictly cloud native or follow all recommendations of the Twelve Factor App, but it must be at least cloud ready to run on Cloud Foundry.

Cloud ready

To make your application cloud ready, you need to consider a few things during development. It does not have to follow all points of the Twelve Factor App pattern. But at the very least, the application must follow a few simple guidelines. This way, the application can be deployed not only on Cloud Foundry, but also on other cloud platforms.

Limitations of application instances

Individual instances of application processes or executions (tasks) can consume up to 32 GB RAM and up to 6 GB ephemeral local disk storage, including additional processes (sidecars).

If nothing else is specified, a single web process with 256 MB RAM and 512 MB ephemeral local disk storage is assumed. These values can be changed, for example, using the manifest file.

Don’t write to the local filesystem

Since your applications run in containers, their local filesystem is not persistent. As soon as the container is stopped or crashes, the storage is assigned to other containers. This means that if an application writes data to the local filesystem and the container is redeployed due to an update or crash, all locally stored data is lost.

Also, the local filesystem of a container is not shared between all instances. So if an application keeps data on the local filesystem, only that one instance knows about it. If the user then refreshes the page and is routed to another instance, access to the data is no longer possible.

Instead of persisting data on the local filesystem, you can use data services from the marketplace or volumes as a service from the STACKIT portal. Learn more at Create a service instance.

Don’t use top-level domains for cookies

Cloud Foundry uses wildcard domains as routes for your application. If you use cookies in your application and make them accessible at the highest domain level, any other application in that shared domain can access them.

For example, you might use tracking tools like Google Analytics and expose your application via the URL my-app.apps.01.cf.eu01.stackit.cloud. If you now set the domain attribute of your cookie to *.stackit.cloud, any application hosted at another-app.apps.01.cf.eu01.stackit.cloud can access it. Therefore, you must set the cookie domain to the most specific domain assigned to your application, not a broader shared domain.

Port considerations

All applications run on isolated containerized processes orchestrated by the Cloud Foundry component Diego. Users can only access your applications via an assigned route. Cloud Foundry allows HTTP requests to these routes on ports 80 and 443. Diego then forwards all incoming requests via the routes to the application containers on port 8080. Therefore, you must expose your application inside the container on port 8080.

You can learn more in the official Cloud Foundry documentation about routes and domains.

Expect your application instances to be stopped

When shutting down or rolling out updates, Cloud Foundry may need to stop or restart your application instances. In these cases, Cloud Foundry sends a single termination signal and waits 10 seconds for your application to shut down gracefully. After the 10 seconds, the application is forcibly terminated.

Your application should accept the termination signal and handle it accordingly to shut down properly within the 10-second grace period.

During updates and scaling down, Cloud Foundry ensures that a new instance of your application is started before the termination signal is sent to the old instances.

Use a .cfignore file when pushing source code

When you push your source code to Cloud Foundry, all files in the directory from which you perform the push are automatically uploaded. Use the path argument when uploading a build artifact to Cloud Foundry to upload only the artifact you need for deployment. If you want to upload source code, you can use the .cfignore file. This is a regular text file listing all files or subdirectories you want to exclude from the upload. It works just like the usual .gitignore files.

Run multiple instances of your application

During updates or unexpected platform errors, Cloud Foundry may need to forcibly shut down your application instance. To increase the availability and resilience of your application and ensure it is not temporarily unreachable for your users, you should always run multiple instances of your application.

With our App Autoscaler Service, you can also define a range of minimum and maximum instances of the application and set rules for when it should scale up and down.

Containerize with buildpacks

Buildpacks can package your application into a container. As they are part of the Cloud Foundry ecosystem, they are highly optimized for use within Cloud Foundry and reliably detect and configure your application’s framework and runtime. They follow Cloud Foundry’s extensively tested, opinionated approach and are therefore the recommended containerization method.

You can also create and use custom buildpacks that meet your specific requirements. Learn more in Containers and buildpacks.

Further information

• Considerations for designing and running an app in the cloud
• The Cloud Native Computing Foundation’s definition for cloud native
• Twelve Factor App pattern
• The Cloud Foundry documentation on routes and domains
• The Cloud Foundry documentation on Diego
• The Cloud Foundry documentation on app container lifecycle
• Containers and buildpacks