Pivotal Cloud Foundry Developer Certification - Cloud Foundry Overview - Concepts

Cloud Foundry Concepts

Cloud Foundry is the cloud native platform or PaaS i.e. Platform-as-a-service infrastructure which is basically PCF(Runtime & Middleware) + IaaS, where you just manage your application and data. Below diagram will help understanding it more.

Deploying an application in IaaS vs PaaS

IaaS deployment:
1. Provision a VM
2. Install application runtime
3. Deploy application
4. Configure load balancer
5. Configure SSL termination
6. Configure Service connectivity
7. Configure Firewall

PaaS deployment:
1. cf push (CLI command), which will push your application and you do not need to take care of IaaS deployment steps.

Scaling an application in IaaS vs PaaS

IaaS: Same steps as deployment
PaaS: cf scale

Cloud Foundry is the open source platform that you can deploy to run your apps on your own computing infrastructure, or deploy on IaaS like AWS, vSphere, or OpenStack.

How cloud foundry works
CF has subsystems that perform specialized tasks or functions. 

BOSH: creates and deploys VM's on top of physical infrastructure, deploys and runs CF on top of cloud.

Cloud Controller: runs the apps and processes on cloud's VM, balancing demands and managing app lifecycles. It stages the app for delivery by combining stack, buildpack and source code into a droplet that the VM can unpack, compile (optional step) and run.

Router: routes incoming traffic to the VMs that are running that app with customer provided load balancer.

Component VM: constitute the platform infrastructure

Host VM: hosts application for outside work. VMs have everything to run and compile the apps locally. It includes OS Stack that app run on and a buildpack containing all languages and libraries and services that the app uses.

OS Stack: It is a prebuilt root filesystem that supports specific operating system.

Buildpacks: provides framework and runtime support for apps. It examines apps to be deployed for dependencies to download and configure apps to communicate with bound services.

Diego system: it distributes the hosted app load over all of the host VM's, and keeps it running & balanced through demand surges and outages, by using an auction algorithm.

Droplet:A droplet is a tarball that includes:

• stack
• buildpack
• application source code

How CF organizes Users and Workspaces:
PCF uses role-based access control (RBAC) system to grant runtime users permissions appropriate to roles within an org or space.

Orgs: is a development account that an individual or multiple collaborators can own and use. All collaborators access an org with user accounts. Collaborators in an org will share a resource quota plan, applications and services availability and custom domains. Each org contains at least one space.

User account: individual person within the context of installation. User can have different roles in different spaces within an org, governing what level and type of access they have within that space.

Spaces: Every application and service is scoped to a space. It's a shared location for application development, deployment and maintenance. 

Quota Plan: are named set of memory, service and instance usage quota. Eg. one quota plan might allow 20 services, 10 routes, 2Gb RAM etc... Quota plans are associated with Orgs. Everyone in the org share the quota described by the plan. Only plan can be assigned at a time. Org manager can create space quota out of org quota.

Roles and permissions: User can have one or more roles. Combination of roles defines the users the overall permissions in that org.

cloud_controller.read: scope required by non-admin users to view resources.

cloud_controller.write: scope required by non-admin users to create, update and delete resources

cloud_controller.admin: scope required by admin. Admin can perform operational actions using cloud controller api.

cloud_controller.admin_read_only: admin scope with read only access. have read only access to all cloud controller api resources.

cloud_controller_global_auditor: This role has read only access to the all cloud controller api resources except for secrets i.e. environment variables.

Few other roles are: org managers, org auditors, org users, space managers, space developers, space auditors.

CF Resources:
CF uses git hub to version control the source code, build packs, documentation, etc...

CF Component Communication:
Http, Https and NATS messages.

NATS: it is a lightweight publish subscribe and distributed queuing messaging system written in Ruby.

CF Services:
CF apps depends on free or metered services i.e. databases or third party api's. To incorporate services into the app, application implements service broker, an api that publishes to the cloud controller the ability to list service offerings, provision the service and enables apps to make call out to it.