Cloud Foundry Application Basics¶

Cloud Foundry is a platform as a service (PaaS) providing a development and deployment environment within Insights Hub. This platform enables you to create everything from a simple cloud-based IoT dashboards to sophisticated enterprise applications.

This section covers the basics for developing a Cloud Foundry application for Insights Hub. The following points summarize the most import aspects:

• All Cloud Foundry applications belonging to one Insights Hub application must be deployed within the same Cloud Foundry Space.
• You must use a single [Cloud Foundry Manifest] file for your Insights Hub application.

• The name of Cloud Foundry applications must fulfill the following requirements:

  • Contains only lowercase alphanumeric characters and special characters -, _ and . are not allowed
  • Starts with a letter
  • Length does not exceed 20 characters
  • Is unique within your tenant

• Random routes are recommended. Otherwise, use the following scheme for Cloud Foundry routes: {appName}-{tenantName}.apps.{region}.mindsphere.io.

• Cloud Foundry routes are not internet exposed. It is necessary to register your application in the Developer Cockpit before you can access it via the internet.
• You must run at least 2 or more instances to avoid downtimes of your Cloud Foundry application.

Applications¶

Cloud Foundry supports applications that consist of one or more micro services. Each micro service is represented by a Cloud Foundry application that all must be run within a single Cloud Foundry Space. Currently, only Cloud Foundry applications that have a single [Cloud Foundry Manifest] configuration are supported. You are required to use the following scheme for Cloud Foundry hosts {appName}-{tenantName} in [Cloud Foundry Manifest] files.

To deploy an application to Cloud Foundry you need to run a cf push command from the Cloud Foundry Command Line Interface (cf CLI). Between the time that you run cf push and the time that the application is successfully deployed, Cloud Foundry performs the following tasks:

• Uploading and storing application files (see [Prepare to Deploy Hints])
• Examining and storing app metadata (see [Cloud Foundry Manifest])
• Creating a droplet (the Cloud Foundry unit of execution; comparable to a container) for the application
• Selecting an appropriate Diego cell to run the droplet (a Diego cell is a virtual machine for executing droplets)
• Starting the application

Applications that use services, such as a database, messaging, or email server, are not fully functional until you provision the service and, if required, bind the service to the applications.

Buildpacks¶

Buildpacks provide framework and runtime support for applications. Buildpacks try to examine your applications to determine what dependencies to download and how to configure the applications to communicate with bound services (Backing Services).

When you push an application, Cloud Foundry automatically detects an appropriate buildpack for it. This buildpack is then used to compile or prepare your application for deployment and launch. However, you can also specify the buildpack explicitly in the [Cloud Foundry Manifest].

Cloud Foundry currently supports the following buildpacks:

• Java: Grails, Play, Spring, or any other JVM-based language or framework
• Node.js: Node or JavaScript applications
• .NET Core: .NET Core applications
• staticfile: HTML, CSS, JavaScript, or Nginx
• python: Python 2.x or Python 3.x
• ruby: Ruby and JRuby
• php: PHP and support for multiple runtimes
• Go: Go and support for glide and godep

Backing Services¶

A Backing Service is any service an app may consume over the network as part of its normal operation. Examples include data stores (such as PostgreSQL), messaging/queuing systems (e.g. RabbitMQ), caching systems (such as Redis) and logging services. A Backing Service can be also described as a factory which produces Service Instances based on Service Plans.

For more information about the supported Backing Services see section Backing Services.

Scaling¶

Run multiple instances to increase availability of your application. You must run at least 2 or more instances of your application in Cloud Foundry to avoid any downtimes during updates. Cloud Foundry automatically distributes those instances across the three availability zones and on multiple virtual machines.

In cases one of the application instances crashes Cloud Foundry automatically routes the traffic to another one and tries to restart your crashed application. Besides, if we update Cloud Foundry it might happen that one of your application instances is shortly unavailable as we update the underlying virtual machine.

Monitoring¶

Cloud Foundry applications are automatically monitored by continually checking the status via a health endpoint. If the application crashes, Cloud Foundry automatically tries to restart it.

You can configure a health check for your application using the Cloud Foundry Command Line Interface (cf CLI) or by specifying the health-check-http-endpoint and health-check-type fields in the [Cloud Foundry Manifest].

Compute Resources¶

In Cloud Foundry the most important metric for computing resources is the memory consumption. Cloud Foundry utilizes multiple virtual machines that provide an environment for executing applications. To manage this huge amount of memory, Cloud Foundry uses the following logical separations:

• Orgs represent a complete organization like a company.
• Spaces are an environment for a number of micro services that form an application.
• Applications run a process with a specified amount of memory.

The maximum amount of memory (RAM) an application needs is configured in the [Cloud Foundry Manifest] or using a CLI command. As every application runs within a container, it is not possible to assign a specific CPU to an application. Instead, the CPU power is distributed according to the memory requested for your application.

For example, if the underlying virtual machine offers 32 GB of RAM and your application needs up to 8 GB, the application gets at least 25% of the currently available CPU power. However, the application is not assigned 2 particular CPUs as all CPUs are available for all applications. An application with a memory limit of 128 MB can use all 8 CPUs, if no other application needs CPU power at that moment.
If more than one application requires CPU power, the total available CPU power is distributed based on the [Cloud Foundry CPU shares] an application is allocated. The number of allocated CPU shares scales linearly based on the memory limit configured for an application. Theses shares are

The following table shows how many CPU shares an application is allocated based on its configured memory limit.

This means that the highest CPU shares (and therefore the highest priority) your application can get is 1024. It will get these shares if its memory limit is 8GB and above.

Except where otherwise noted, content on this site is licensed under the Development License Agreement.