Cloud Foundry(CF) is an open source PaaS platform which supports the full life cycle of software development right from initial development, testing, and deployment. It is suited for continuous delivery strategy. Applications deployed on Cloud Foundry use external resources called as services. These services may include application dependencies such as databases (AWS Aurora,Superior Cloud Database), messaging system, log monitoring etc. In this blog, we will look at the basic working of CF and the services available with it.
Cloud Foundry provides applications the flexibility to scale and use its services as required. Cloud Foundry achieves scaling by running the application over multiple machines to optimize workload and achieve efficiency.
The architecture of Cloud Foundry has seven layers. The flow of activity starts from Router and goes down to the application after correct authentication. The application is controlled and run as required with supporting services. The communication between components is carried out using the messaging layer. Monitoring and reporting is done through matrix and logging layer.
Below is the component level working:
BOSH – It creates VMs on top of physical machines and runs Cloud Foundry on it.
Router – routes incoming traffic to appropriate component which may be either Cloud Controller or hosted application.
Authentication – Identity management is taken care by Oauth2 Server and login server together.
Cloud Controller – runs and controls applications on VMs and manages them. The number of required instances are sorted and compared with the actual number of instances. The application is scaled in or scaled out based on the difference in value of these parameters.
Application storage happens in Blobstore in form of application binaries. Blobstore could either be internal or external S3 endpoint.
Diego cell manages the application VM with start and stops action on the application.
Services – The running applications are dependent on Cloud Foundry for required services. The services are bound to the application through a process called application binding where the application uses the credentials to access the services.
Messaging – Cloud Foundry component VMs communicate internally through messages. Consul servers are used to store data for a longer period whereas Bulletin board system(BBS) stores short-term data.
Logging and monitoring – the aggregator stream the logs to channels requiring them.
Below are some of the terminologies used with Cloud Foundry services.
Service Instances: The provisioned resources for services are called service instances.
User-provided Service Instances: To leverage services that are not available in the marketplace Cloud Foundry provides
Service Instance Credentials: Users can provision credentials to interact with their service instances.
Application binding: User can bind these credentials with the Cloud Foundry app to enable access to the service instances.
Service keys: Credentials managed manually are called service keys. It can be of use for external or local clients to access service instances. All services do not support service keys.
Provision: reserves resources on a service
Binding delivers information to an application necessary for accessing the resource.
Services communicate with Cloud Foundry using Service Broker APIs. Service broker is the component of service, that implements service broker API. It interprets calls for provision, bind, unbinds or provision services. The tasks available with broker varies with different services.
Based on the type of call a broker can provision a service instance and can provide its information to application to bind the application to the service.
Cloud Foundry benefits organisation by providing speed in application development and a better control over it. Cloud Foundry also supports production level infrastructure by use of scalable microservices and quicker deployments. Following are some of the highlighted benefits: