Pivotal Cloud Foundry is a Platform as a Service unlike AWS or Azure, which are Infrastructure as Services. There are some great benefits with using PCF, especially in a Hybrid environment. PCF provides a layer of abstraction on top of the underlying infrastructure and can run on both public cloud and on premise while development teams interact with the same interface to deploy and monitor their applications. But be aware that if you are running PCF in a public cloud environment, you will not only pay for PCF, you will also be paying for the public cloud.
Keeping the costs aside, this is a brief introduction to PCF concepts.
Orgs and Spaces
PCF organizes infrastructure hierarchically. At the top of the hierarchy is Organization (or Org). Generally speaking, a company will have multiple Orgs and each Org is for a team.
Org can have multiple Spaces. Spaces are environments such as Dev, Integration, Production. You will be running your application inside a space.
Apps are applications that we build. An application can be deployed using below command
cf push YOUR-APP -p YOUR-APP-VERSION.jar
Apps Manager is a console to view or modify Orgs, Spaces, Apps and everything else we discuss in this blog.
Services are infrastructure such as Mysql, RabbitMQ, Redis.
When a service is bound to an app, its connections params such as url, username and password are supplied to the app during runtime.
Services can be obtained from PCF’s marketplace as a self service.
Route is an address to your app. When you create a route, CF router (PCF’s load balancer) maps the app instance to the address and starts to load balance across the instances. App has to have a route, otherwise it cannot be accessed.
Applications logs can be viewed, searched and downloaded via Apps Manager. Your application is expected to write logs to console, which is a 12 Factor App recommendation anyways.
PCF makes metrics such as request latency, CPU usage, disk, requests per minute and memory available by default.
User Provided Service
If you build an application and would like other applications to connect to it, the other applications can create a User Provided Service in their space and store the connection information to your service such as URL in it. This is a general usage pattern for User Provided Service, but it is can also be used wherever you want to pass additional info to your application.
If your app needs credentials during run time, for example OAuth2 client credentials to connect to an external service, Credhub is where they should be stored.
PCF’s SSO service can take care of Federated Single Sign On and also OAuth2 based authorization to your app. Behind the scenes, it can integrate with an authentication service such as ADFS.
Autoscaler can automatically scale the application by adding or removing app instances based on metrics such as CPU usage.
When we deploy an app, we can specify a manifest file as below
cf push YOUR-APP -p YOUR-APP-VERSION.jar -f manifest.yml
Using a manifest file you can declare things such as number of instances, services to bound, memory, etc. A sample manifest file:
- name: my-app
PCF injects two environments variables to a deployed app: VCAP_APPLICATION and VCAP_SERVICES. Both these variables have JSON values, inside which there is information such as HOST, PORT, DATABASE_URL, etc. You can provide your own environment variables using the Apps Manager or using the Manifest.yml.
PCF has a number of concepts and terms, I have covered the basic ones here especially from a developer standpoint.