Cloud Foundry. Providing the best cloud services can be easy! There are a few companies that offer at very god price all the services or all most of it.
The one we like to discuss here is Cloud Foundry maybe the one of the first Top 5 cloud companies!
Cloud Foundry is an open source cloud computing platform as a service (PaaS) originally developed by VMware and now owned by Pivotal Software – a joint venture by EMC, VMware and General Electric. Cloud Foundry was designed and developed by a small team from Google led by Derek Collison and was originally called project B29.
They offer premium cloud products like:
Router:
The router routes traffic coming into Cloud Foundry to the appropriate component, whether it’s an operator addressing the Cloud Controller or an application user accessing an app running on a Diego Cell. The router is implemented in Go. Implementing a custom router in Go gives the router full control over every connection, which makes it easier to support WebSockets and other types of traffic (for example, via HTTP CONNECT). A single process contains all routing logic, removing unnecessary latency.
Refer to the following instructions for help getting started with the gorouter in a standalone environment.
Authentication
The UAA is the identity management service for Cloud Foundry. Its primary role is as an OAuth2 provider, issuing tokens for client applications to use when they act on behalf of Cloud Foundry users. In collaboration with the login server, it can authenticate users with their Cloud Foundry credentials, and can act as an SSO service using those credentials (or others). It has endpoints for managing user accounts and for registering OAuth2 clients, as well as various other management functions.
Cloud Controller:
The Cloud Controller provides REST API endpoints for clients to access the system. The Cloud Controller maintains a database with tables for orgs, spaces, services, user roles, and more.
The Cloud Controller collects these advertisements in a construct called a pool. When the Cloud Controller needs to find a DEA to run an app, it runs through the following steps, using criteria (minimum thresholds for disk, memory, etc.) specific to the app that the chosen DEA will run:
- It removes the expired DEA advertisements from the pool.
- It filters the remaining advertisements to include only those:
- with adequate disk
- with adequate memory
- running the required stack (linux or windows)
HM900:
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.
Refer to the descriptions below for more information about Cloud Foundry components. Some descriptions include links to more detailed documentation.
Application Execution (DEA):
A Droplet Execution Agent (DEA) performs the following key functions:
- Manage Warden containers: The DEA stages applications and runs applications in Wardencontainers.
- Stage applications: When a new application or a new version of an application is pushed to Cloud Foundry, the Cloud Controller selects a DEA from the pool of available DEAs to stage the application. The DEA uses the appropriate buildpack to stage the application. The result of this process is a droplet.
- Run droplets: A DEA manages the lifecycle of each application instance running in it, starting and stopping droplets upon request of the Cloud Controller. The DEA monitors the state of a started application instance, and periodically broadcasts application state messages over NATS for consumption by the HM9000.
Blob Store:
To create final releases, configure your release repository with a blobstore. BOSH uploads final releases to the blobstore, so that the release can later be retrieved from another computer.
To prevent the release repository from becoming bloated with large binary files (e.g. source tarballs), large files can be placed in the blobs directory, and then uploaded to the blobstore.
Service Brokers:
Architecture & Terminology
Services are integrated with Cloud Foundry by implementing a documented API for which the cloud controller is the client; we call this the Service Broker API. This should not be confused with the cloud controller API, often used to refer to the version of Cloud Foundry itself; when one refers to “Cloud Foundry v2” they are referring to the version of the cloud controller API. The services API is versioned independently of the cloud controller API.
Service Broker is the term we use to refer to a component of the service which implements the service broker API. This component was formerly referred to as a Service Gateway, however as traffic between applications and services does not flow through the broker we found the term gateway caused confusion. Although gateway still appears in old code, we use the term broker in conversation, in new code, and in documentation.
Message Bus:
This information was adapted from the NATS README. NATS is a lightweight publish-subscribe and distributed queueing messaging system written in Ruby.
Logging and Statistics:
Loggregator is the next generation system for aggregating and streaming logs and metrics from all of the user apps and system components in a Cloud Foundry deployment.
Using Loggregator
The main use cases are as follows:
- App developers can tail their application logs or dump the recent logs from the CF CLI, or stream these to a third party log archive and analysis service.
- Operators and administrators can access the Loggregator Firehose, the combined stream of logs from all apps, plus metrics data from CF components.
- Operators can deploy ‘nozzles’ to the Firehose. A nozzle is a component that listens to the Firehose for specified events and metrics and streams this data to external services.