Introduction to Cloud Foundry

What features are exciting in new applications? There are new frameworks and languages. So you have frameworks like Spring, Node.js, Ruby on Rails, Python, Scala and many more. Developers have many frameworks to build more reach applications and get them faster to market. Then there are new devices and domains. No longer applications are developed to a single PC or a server. Now a days, applications are built to run on multiple devices and multiple domains. Then there are new data types and requirements. Today, data is growing exclusively. We have more flexible ways of handling data via NoSQL solutions like Hadoop, MongoDB etc. Then we need to be able to program to those data solutions, maintain them and access data in real time. All together form new infrastructures. Thus this whole thing can run in any where either in your own environment, your data center, on physical hardware, on cloud, on top of a PaaS or an IaaS. All these enhancements are to fulfill two necessities. One is to increase developer productivity and the other is to reduce the time to market.

Not surprisingly, if you have lot of choices, that offers a lot of complexity to developers. Typical apps look like below. They are more complex. Building is really hard with multiple app servers, load balancers, databases and messaging systems. This is pretty complex. As a developer, you will not prefer an architecture like this.  

What do we mean by the term 'complex'? There are multiple nodes and multiple roles within a node. Then you need some way to connect them where you will come up with different deployment challenges. Following questions will pop up in your mind. 

• How do I build a VM?
• How do I manage the network?
• How do I make the application accessible over the Internet?
• What happens when I scale the applications?
• Do I need to reconfigure my load balancers?
• What happens when I do updates or roll backs?
• What happens when I change environment between development, QA, production, staging?
• How do I keep the applications running for 24 x 7 x 365?
• How do I get to know what is running at which place?

Developers want to have one command line and very few api calls to basically cut off all of that complexities that you have in that earlier picture. In other words, they want fiction free application deployment and management. In fact, code you develop should not get affected by where it is deployed, how its operating system scaled and which components belong to it. On the other hand, all these scaling processes, load balancing and configuring tasks should not be a part of developer's business logic. Developers want different services to be easily consumed.

Developers want maximum productivity and operations want to manage all of that elastically and efficiently. And that's where the PaaS comes into topic.

The current way we do middle ware is not optimized to cloud environment. So we need a new platform. And this new platform needs to be an integrated software stack. What Cloud Foundry tries is to move the enterprise or developer away from that previously shown complex architecture. Then from the developers' perspective, they can deploy the applications to run in cloud in seconds. 

We want a mechanism where we can simply point to the cloud, push the application to the cloud, create an endpoint to any data services on need and then to suddenly find the application taken off by everyone in the company to use. 

Characteristics of a PaaS

A PaaS solution should have an integrated stack. It should have an application execution engine. Developers write the code and push it into the PaaS environment and the PaaS executes code for them. This needs to be a self service. Once you deploy an application using a few api calls, rest will happen under the PaaS. This needs to be automated in terms of infrastructure provisioning. We need the ability to develop application locally and then deploy it in a cloud environment. Applications need to run in any public cloud environment or in your own laptop in the exact same way. 

The way I see this is like a contract between development and operation. Developers focus on code. Operations focus on optimizing the way they mange the application. No matter where it is run, it should work. This is a key principle for cloud foundry. It should run your private cloud, on your choice of public cloud or on any laptop.

Incomplete PaaS

Number of things introduces significant inhibitors to main stream or enterprise. A  PaaS solution is incomplete if you,
                            - Can't move between clouds
                            - Limited to a single provider
                            - No on-premise solutions
                            - Limited to a single framework
                            - Require special frameworks

The Industry-Standard Cloud Platform

Cloud platforms let anyone deploy network applications or services and make them available to the world in a few minutes. When an application becomes more popular, the cloud easily scales it to handle more traffic, replacing with a few keystrokes the build-out and migration efforts that earlier took months.
Not all cloud platforms offer same set of facilities. Some have limited language and framework support, lack key application services or restrict deployment to a single cloud. Cloud Foundry has become the industry standard today. It’s an open source platform that you can run your applications on your own computing infrastructure, or deploy on an IaaS like AWS, vSphere, or OpenStack.

Cloud Foundry is an open source cloud computing PaaS. It was originally developed by VMware and now owned by Pivotal Software, a joint venture by EMC, VMware and General Electric. It was designed and developed by a small team from Google led by Derek Collison and was originally called project B29. Cloud Foundry was primarily written in Ruby and Go. The platform’s openness and extensibility prevent its users from being locked into a single framework, set of application services, or cloud. Cloud Foundry is ideal for anyone interested in removing the cost and complexity of configuring infrastructure for their applications. Developers can deploy their applications to Cloud Foundry using their existing tools and with zero modification to their code.

“...we believe that the best cloud PaaS platform solution should be available on top of any cloud and not just locked into a specific one”
                                                                                                                                                -Mike Soby in JAX magazine
                                                                                                                                                Special edition

I will relate you a real story. A certain team created a new mobile app in weeks. But it took the IT team nine months to deploy it within their internal infrastructure which made two of the competitors to beat the market. This is not an unusual incident. Operations teams meet the massive complexity to configure, maintain and scale your applications in production. Network access rights, physical servers, OSes, VMs, App servers and web servers and many other systems come into play with applications. Even if the technical process is simple, human driven manual process adds tremendous latency that is potential for error. That's why traditional application deployment took months of downtime. Cloud Foundry accelerates this application deployment. It fully automates not only initial infrastructure, but also ongoing life cycle events.

Developers can build innovative applications in weeks but then spend lot of time in configuring the infrastructure in middle ware stack. Cloud Foundry running in your public cloud can remove the friction in how you build, deploy and operate applications.

With Cloud Foundry, developers can focus on the application code. With a single command, they can deploy an application into the cloud within seconds. It auto detects languages, selects run times and bind services like databases to remove all that hard work for the development process. There's no need of configuring the environment. Thus huge efficiency is gained from infrastructure automation, scaling and management. Operators are now releaved from these manual tasks. These benefits come from operational capabilities built in Cloud Foundry. These features reduce the complexity cost and time of scale. Log aggregation lets you analyze application performance monitoring to solve problems of performance issues so that you can auto scale. Cloud Foundry maximizes developer productivity in the mean time reducing operations complexity. As a result, you can deploy new applications and new features to existing applications in less time than ever before. It gives you the speed to compete with internet startups. You can focus on app innovation not on infrastructure management and scaling. In the long term, you can build your application and move it to any cloud. That is what called multi cloud portability. Cloud Foundry is a future proof eco system. That means you can always have the next new technology for your platform. 

Ultimately, Cloud Foundry makes both application build and run in extremely scalable, fast and extensible way giving you the speeds you need to iterate in weeks for your company to be more innovative, competitive and profitable.

Cloud Foundry is not only built to support popular frameworks today. It is also easy to add new frameworks. So you as a consumer of Cloud Foundry are kind of bullet proof yourselves for future cloud innovations that will come in weeks, months, years of ahead.

Cloud Foundry is completely open source under the apache 2 license and its code is available on Git Hub. We can trust that it really works.

Choice of frameworks, application services, clouds

So what do you have in Cloud Foundry? You have your own choice of frameworks. Currently, this supports a large space of frameworks such as Spring, nodeJS, Ruby on Rails, Python, Java and many more that you can choose for your development of choice. It also supports the ability to plug in custom run times.

You also have application service interfaces that basically allows you to plug in new services and support those services on top of Cloud Foundry. Most applications are not useful unless they have some data source or service or even some additional API that you want to plug on side. Currently Cloud Foundry supports Vfabric, Postgres database, Mysql database, RabbitMQ for messaging, Redis for key value store, mongoDB for unstructured document data and big data solutions.  What this looks like to you as an application developer is the ability to look up on your connection from environment you run in. 

Last but not the least the way how you deploy it. The multi cloud concept is important because when we choose our PaaS, we don't have to choose our cloud. Micro clouds can be run in our laptops for development. Then public clouds like Vmware can be run on public cloud environment. 

Since Cloud Foundry is open source, we can grab its code, run and host it. There are also vendors like pivotal that provides commercial offerings. Pivotal public cloud runs on top of Amazon. You can either take open source space Cloud Foundry and run it in your stack or you can purchase a free package product such as Pivotal Cloud Foundry. 

Micro cloud is the ability to spin up all of the components and run them in a single VM on your local machine. So if you want to contribute to Cloud Foundry, you can try it out in a single VM. If you have that local experience, it is exactly the same as it happens in public cloud. 

A growing ecosystem

The users who are accustomed to Cloud Foundry has doubled every two months. Already tens of thousands of users are using it. Thousands of applications are deployed in it. There are multiple distributors and deployers. Community leads are also very important. Since Cloud Foundry is open source, it is looking for more and more partners to provide additional frameworks and solutions in Cloud Foundry. We call this “Community Leads Program”. AppFog which provides PHP and ActiveState which provides python are examples. If you want to join this program, go to cloudfoundry.org and you will get the link to join the program. So this project has a strong open source community participation. There are hundreds of contributors from open source community. 

Source code of Cloud Foundry is available on github. This allows any developer to access, evaluate and modify code. It can be integrated with other frameworks as well. We can add application services and deploy to other infrastructure clouds. 

Why we should deploy apps to Cloud Foundry? 

We can use Cloud Foundry to deploy, run and scale applications to meet our agile needs. It allows choice of frameworks and runtimes. It is not limited to a particular set of code. The competition is growing and Cloud Foundry is very active. Since it is completely open source, there are lots of innovations too. It is portable, scalable and flexible. As a developer we have the advantage that it is easy to deploy many instances. For that we don't have to do much. Once it is set up, we don't have to worry about how the VMs and containers are set up. That part is done for you as a service from cloud foundry PaaS. How ever I want to clarify a bit. If you are just deploying a single application, CF is not the right choice for you. Cloud Foundry is for massive applications which require scaling. In fact we can use Cloud Foundry as a service. 

Multi tenancy support

Cloud Foundry supports multi tenancy too. It is an architecture in which a single instance of a software application serves multiple customers. Each customer is a tenant. Tenants are given ability to customize some parts of application such as UI or business rules, but they cannot customize application code. Each tenant's data is isolated and remains invisible to other tenants. Cloud Foundry is by default a highly distributed multi tenant platform that is usually deployed at a scale. For the novice Cloud Foundry developer, a full scale PaaS deployment is not possible and it is not an affordable choice. To address this issue, Cloud Foundry team released BoshLite which provides developers a method to deploy it locally in their machine.

Why is an open cloud platform important?

Having something future proof, customizable or spacing , extensible or adapt to changes is important. We don't know what programming language will be introduced in the future. We don't know what's going to come from language perspective, hardware perspective or infrastructure perspective. It's really important that we are not locked in. Don't be locked in. Because we don't know about future, we want a way of working and a platform that enables us to go with. 

Moving to architecture ...

Clouds balance their processing loads over multiple machines, optimizing for efficiency and resilience against point failure. A Cloud Foundry installation accomplishes this at three levels: 

- The BOSH system creates and deploys virtual machines (VMs) on top of a physical computing infrastructure, and deploys and runs Cloud Foundry on top of this cloud. To configure the deployment, it follows a manifest document. 

- The CF Cloud Controller runs the applications and other processes on the cloud’s VMs, balancing demand and managing app life cycles. 

- The 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 designates two types of VMs: 

                             -  Component VMs that consitute the platform’s infrastructure
                             -  Application VMs that host apps for the outside world

Within Cloud Foundry, the 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. Diego accomplishes this through an auction algorithm. 

To meet demand, multiple Application VMs run duplicate instances of the same application. This means the apps must be portable. Cloud Foundry distributes application source code to VMs with everything needed to compile and run the apps locally.
This includes,
                    1) OS stack that the application runs on
                    2) 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.

To organize user access to the cloud and to control resource use, a cloud operator defines orgs and spaces within an installation and assigns Roles to all users: admin, developer, manager, auditor, etc. The User Authentication and Authorization(UAA) server supports access control as anOAuth2 service, and can store user information internally or connect to external user stores through LDAP or SAML. 

Cloud Foundry uses the git system on github to version-control source code, buildpacks, documentation, and other resources. Developers on the platform also use github for their own applications, custom configurations, etc. To store large binary files, such as droplets, Cloud Foundry maintains an internal Blob Store. To store and share temporary information, such as internal component states, CF uses the distributed value-store systems Consul and etcd. 

Cloud Foundry components communicate with each other by posting messages internally via http and https protocol and by sending NATS messages to each other directly. 

As the cloud operates, the Cloud Controller VM, router VM, and all VMs running applications continuously generate logs and metrics. The Loggregator system corrals this information into structured, usable form. 

Typical applications depend on free or metered services such as databases or third-party APIs. To incorporate these into an application, a developer writes a Service Broker, an API that publishes to the Cloud Controller the ability to list service offerings, provision the service, and enable applications to make calls out to it.

Cloud Foundry components include a self-service application execution engine, an automation engine for application deployment and lifecycle management, and a scriptable command line interface (CLI), as well as integration with development tools to ease deployment processes. Cloud Foundry has an open architecture that includes a buildpack mechanism for adding frameworks, an application services interface, and a cloud provider interface. 

Router

The router routes incoming traffic to the appropriate component, usually the Cloud Controller or a running application on a DEA node.

OAuth2 Server (UAA) and Login Server

The OAuth2 server (the UAA) and Login Server work together to provide identity management.

Cloud Controller

The Cloud Controller is responsible for managing the life cycle of applications. When a developer pushes an application to Cloud Foundry, he is targeting the Cloud Controller. The Cloud Controller then stores the raw application bits, creates a record to track the application metadata, and directs a DEA node to stage and run the application. The Cloud Controller also maintains records of orgs, spaces, services, service instances, user roles, and more.

Health Manager

This has four core responsibilities:

1. Monitor applications to determine their state (e.g. running, stopped, crashed, etc.), version, and number of instances. It updates the actual state of an application based on heartbeats and droplet.exited messages issued by the DEA running the application. 
2. Determine applications’ expected state, version, and number of instances. It obtains the desired state of an application from a dump of the Cloud Controller database. 
3. Reconcile the actual state of applications with their expected state. For instance, if fewer than expected instances are running, it will instruct the Cloud Controller to start the appropriate number of instances. 
4. Direct Cloud Controller to take action to correct any discrepancies in the state of applications. 

Health manager is essential to ensuring that apps running on Cloud Foundry remain available. It restarts applications whenever the DEA running an app shuts down for any reason, when Warden kills the app because it violated a quota, or when the application process exits with a non-zero exit code.

Application Execution (DEA)

The Droplet Execution Agent manages application instances, tracks started instances, and broadcasts state messages. Application instances live inside Warden containers. Containerization ensures that application instances run in isolation, get their fair share of resources, and are protected from noisy neighbors.

Blob Store

The blob store holds: 1. Application code 2. Buildpacks 3. Droplets

Service Brokers

Applications typically depend on services such as databases or third-party SaaS providers. When a developer provisions and binds a service to an application, the service broker for that service is responsible for providing the service instance.

Message Bus (NATS)

Cloud Foundry uses NATS, a lightweight publish-subscribe and distributed queueing messaging system, for internal communication between components.

Metrics Collector and App Log Aggregator: Logging and Statistics

The metrics collector gather metrics from the components. Operators can use this information to monitor an instance of Cloud Foundry. The application log aggregator streams application logs to developers.

Zero Downtime Deployment and Scaling in Cloud Foundry

• Application instances - Deploy at least two instances of every application. 
• Components - Distribute across two or more availability zones (Azs).
• Space - Ensure that you allocate and maintain enough free space on DEAs
• Resource pools - According to the requirements of your deployment.
• Scaling platform capacity - Scale platform capacity vertically by adding memory and disk, or horizontally by adding more VMs running instances of Cloud Foundry components.

In the next blog post, I will be describing you on how to deploy an application locally in the machine using Cloud Foundry.