Deploying Applications

An application is a runnable program that delivers a specific functionality to serve a business need. For example, web applications, API services, or backend processes. Each application is a deployable unit that brings your code to life in the cloud. You build, configure, and deploy applications to the Cloud Foundry environment, where they run on scalable, managed infrastructure.

You manage your applications through the SAP BTP cockpit interface. There, you can monitor their status, configure settings, bind services, and scale resources.

What is an application package?

The application package contains your compiled code, dependencies, configuration files, and deployment instructions. A well-structured package ensures consistent deployments and reduces runtime errors.

You should carefully manage your package because it affects deployment speed, resource usage, and performance. Large packages increase upload times and storage costs, while missing dependencies cause deployment failures.

What to include in the application package?

• Application source code or compiled artifact

• Any configuration files, such as package.json, requirements.txt, including all listed dependencies.

  Note: Exclude the folders node_modules or venv. Cloud Foundry installs them automatically.

These are the most commonly used programming languages:

Which file extensions are supported?

The SAP BTP cockpit interface lets you deploy applications to the Cloud Foundry environment as application archives. The currently supported file extensions are: ZIP, WAR, JAR, EAR.

Here’s a comparison between the cockpit and the CLI:

*This option is covered in the current tutorial.

A correctly deployed and healthy application should have a Started requested state and all instances should be running.

Note: If an application is displayed as Started according to the Requested State column, it doesn’t automatically mean that the application is running. This is the desired state, but there might be an issue with an application instance. For any warning alerts, check the Instances column. When the auto refresh is turned on, the information on the page updates automatically every 10 seconds. This ensures you always see the most current status of your deployed applications and available memory.

1. Check the Available Memory for all spaces. This information lets you know if you have enough memory to deploy new applications. Remember that only started applications use space memory.

2. Check the requested state.

3. Check the number of instances, the memory and disk allocated to each instance of your application, and the total amount of memory for all instances. In this example, there are 2 app instances with memory of 256MB each, which corresponds to total memory of 512MB.

4. You can also stop, start, or delete the application, when needed.

5. You can restage the application. To learn more about it, check out the next step of this tutorial.

To get more detailed information about your application, navigate to the Application Overview page by clicking the name of the application and check out the next tutorial Managing Deployed Applications.

Restaging your application stops it, restages it by compiling a new droplet without updating your app source, and starts it again. Restage your app if you have changed the environment in a way that affects your staging process, such as setting an environment variable that the buildpack consumes.

Caution: Restaging causes application downtime.

To restage an application, do the following:

1. Choose Restage Application.

   

2. Select an application from the dropdown.

   

3. Choose Restage.

Keep your space organized

For better performance, we recommend that you deploy no more than 200 applications in a space.

Use persistent storage

Each application instance runs in a temporary container. This means that any files written to the local file system are lost when the instance stops or restarts — for example, during restaging, scaling, or platform maintenance. To retain data across restarts or across multiple app instances, always use persistent storage services.

In SAP BTP cockpit, some of the options are SAP ASE service and SAP HANA service. For more information, see Service Catalog | SAP Discovery Center.

Plan for high availability

To ensure that your application remains available even if one instance fails, add at least two app instances. Running multiple instances allows requests to be rerouted automatically to healthy instances.

Use the blue-green deployment technique

Blue-green deployment reduces app downtime and risk by running two identical production environments: Blue and Green.

Example:

1. Deploy an application named Blue with the URL https://my-app.cert.cfapps.eu11.hana.ondemand.com. Cloud Foundry sends all traffic to Blue through this URL.

2. Now make a change to the app Blue and deploy the new version under a new name - Green, with the following temporary URL https://temp-app.cert.cfapps.eu11.hana.ondemand.com to validate that your updated app works as expected.

3. Now that both apps are up and running, map https://my-app.cert.cfapps.eu11.hana.ondemand.com to Green (you will learn how to do this in the tutorial Managing Routes).

4. Within a few seconds, Cloud Foundry begins load balancing traffic for https://my-app.cert.cfapps.eu11.hana.ondemand.com between Blue and Green.

5. After you verify that Green is running as expected on https://my-app.cert.cfapps.eu11.hana.ondemand.com, unmap the route from Blue.

6. Now all traffic for https://my-app.cert.cfapps.eu11.hana.ondemand.com is sent to Green.

7. You can now remove the temporary route https://temp-app.cert.cfapps.eu11.hana.ondemand.com.