Introduction to Cloud Foundry

Introduction to Cloud Foundry

What is Cloud Foundry?

Cloud Foundry is an open-source platform as a service (PaaS) that provides you with a choice of clouds, developer frameworks, and application services.

What is a PaaS? 

The latest requirements of developers 

• increase developer productivity - new frameworks and languages
• reduce the time to market 
• run the application on multiple devices and multiple platforms
• scale and maintain the application with exclusively growing data
• access data in real time
• run the application on any infrastructure

If a developer want to have these requirements it is going to add lot of complexity in building, maintaining and deploying the applications. It will need mutiple load balancers, messaging centers, databases, app servers etc. But a developer is not expecting to wire all these middle-ware components. 

This complexity is not what developers except, they want to manage all these complexities in few API calls. i.e. deploy, manage, update, scale up and down in few API calls, the code of the application is not affected by where it is deployed, how it is scaled etc.

That is where Platform as a Service (PaaS) is introduced, as a solution to these complexities for a friction free application deployment and management. 

Characteristics of a PaaS

• Integrated software stack- abstract all these connections between nodes and roles to a simple software stack resolving all the complexities.
• application execution engine - developer just writes the code and push it into the PaaS environment and the PaaS executes it
• self- service application deployment
• automated application infrastructure provisioning- ability to develop locally and deploy to a cloud environment.
• curated, updated and operated as a service

 This provides the opportunity for the developers to just focus on the code of the application.

Why Cloud Foundry?


Most of the PaaS solutions today in the market are incomplete and have significant adoption barriers.

• Cant move between clouds- When you choose the PaaS you have to choose the cloud with it. Choosing the cloud is not decoupled from choosing the PaaS.
• Limited to a single provider- There is only one provider of the service, not having the ability to choose a technology that can be provided by many providers
• No on- premise solutions - not being able to develop the application on local machine and deploy it in PaaS later
• Limited to a single framework- developer have to think where he is going to deploy the application and write the code depending on that
• Require special frameworks

Cloud Foundry is introduced as a complete PaaS addressing all these issues. 
Its all about choice in cloud foundry 

• Choice of clouds for deployment - open PaaS
• Choice of industry- standard frameworks
• Choice of application infrastructure services
• Extensible architecture to "digest" future cloud innovation- bullet proof for future cloud innvoations ex: new frameworks
• Available as open source under apache 2 license and available on github
  
  Cloud Foundry has a significant growing ecosystem
• Have tens of thousands of beta users 
• Thousands of applications deployed
• Multiple distributers, deployers and clouds - cloudfoundry.com is available under pivotal and you can go for other distributors like Canonical, Dell, enStratus etc.
• As Cloud Foundry is open source it is looking for more and more additional frameworks. They already have two charter members : AppFog- PHP and ActiveState- Python
• Strong open source community participation - have hundreds of contributions already

Architecture of Cloud Foundry 

Cloud Foundry has 3 sub systems
1) BOSH

• creates and deploys VMs on top of a physical computing infrastructure
• runs cloud foundry on top of this cloud
• the deployement is done according to a manifest document 

2) Cloud Controller

• runs the applications and other processes on the cloud’s VMs, balancing demand and managing app lifecycles.

3) Go router

• routes incoming traffic from the world to the VMs that are running the applications that the traffic demands, usually working with a customer-provided load balancer.

Cloud Foundry has two types of VMs

1) Component VMs- consitute the platform’s infrastructure
2) Application VMs - host apps for the outside world.

Diego System- distributes the hosted app load over all the Application VMs, and keeps it running and balanced through demand surges, outages, or other changes according to an auction algorithm.


Applications on Cloud Foundry

When an application is deployed to Cloud Foundry

• an image is created for the application
• the image is stored internally. 
• that image is then deployed to a Warden container to run in -
  Cloud Foundry's internal Controller uses BOSH to get the underlying infrastructure to spin up virtual machines to run the Warden containers on.
• for multiple instances, multiple images are started on multiple containers. 
• when an application is terminated, all its VMs can be recycled for another application to use.
• if the application instance crashes, its container is killed and a new Warden container is started automatically.
• a container only ever runs one application ensuring isolation, security and resilience.
•  a load-balancing router sits at the front of Cloud Foundry to route incoming requests to the correct application - essentially to one of the containers where the application is running
• application manifest file tells what to do with the application
  

To meet the demand, multiple application VMs run duplicate instances of the same application. For this the applications must be portable. Cloud Foundry distributes application source code to VMs with everything needed to compile and run the applications locally. This includes
              1) the OS stack that the application runs on
              2) a buildpack containing all languages, libraries, services etc. that the app uses.
Before sending an app to a VM, the Cloud Controller stages it for delivery by combining stack, buildpack, and source code into a droplet that the VM can unpack, compile, and run. (For simple, standalone apps with no dynamic pointers, the droplet can contain a pre-compiled executable instead of source code, language, and libraries.)

Services in Cloud Foundry

Applications deployed to Cloud Foundry use services to access external resources. In a PaaS environment, all external dependencies such as databases, messaging systems, files systems and so on are Services. When an application is pushed to Cloud Foundry, the services it should use also can be specified. Depending on the application language, auto-configuration of services is possible - for example a Java application requiring a MySQL database picks up the MySQL service on Cloud Foundry if it is the only one defined in the current space.
Services have to be deployed to the platform first and then are available to any application using it.

References

https://www.youtube.com/watch?v=KNI2c6yS2Bo&noredirect=1
https://docs.cloudfoundry.org/concepts/overview.html  
https://en.wikipedia.org/wiki/Cloud_Foundry 
https://docs.pivotal.io/pivotalcf/concepts/overview.html