Cloud Foundry Application Basics¶

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

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

• All Cloud Foundry applications belong to one Insights Hub application and 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:

  • Only lowercase alphanumeric characters are allowed and special characters such as -, _ and . are not allowed.
  • Starts with a letter
  • Length does not exceed 20 characters
  • The application name should be unique within your tenant environment

• 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. Before you can access your application via the internet, you need to first register it in "Developer Cockpit".
• You must run at least two or more instances to avoid downtime in 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, all of which 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). Meanwhile, you can run cf push and by the time the application is successfully deployed, Cloud Foundry will perform the following tasks:

• Uploading and storing the application files
• Examining and storing app metadata, refer to the 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 a 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 and queuing systems (e.g., RabbitMQ), caching systems (such as Redis) and logging services. A Backing Service can also be described as a factory that produces Service Instances based on Service Plans.

For more information about the supported Backing Services, refer to the Backing Services section.

Scaling¶

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

If one of the application instances crashes, Cloud Foundry automatically routes the traffic to another one and tries to restart the crashed application. Besides, if we update Cloud Foundry, one of your application instances might soon be unavailable as we update the underlying virtual machine.

Monitoring¶

Cloud Foundry applications are automatically monitored by continually checking their 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 the Cloud Foundry, memory consumption is the most important metric for computing resources. 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 to be configured in the Cloud Foundry Manifest or by 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 will get at least 25% of the currently available CPU power. However, the application is not assigned two specific CPUs, as all CPUs are accessible for all applications. An application with a memory limit of 128 MB can utilize all 8 CPUs, if no other application needs CPU power at that moment.
If multiple applications require 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.

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

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

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