Integrate Cloud Foundry with Azure

Cloud Foundry is a PaaS platform running on top of cloud providers’ IaaS platform. It offers consistent application deployment experience across cloud providers. It can also integrate with various Azure services, with enterprise grade HA, scalability, and cost savings. There are 6 subsystems of Cloud Foundry, that can be flexibly scale online, including: Routing, Authentication, Application life-cycle management, Service management, Messaging and Monitoring. For each of the subsystems, you can configure Cloud Foundry to use correspondent Azure service.

Cloud Foundry on Azure Integration Architecture

1. High Availability and Scalability

Managed Disk

Bosh uses Azure CPI (Cloud Provider Interface) for disk creating and deleting routines. By default, unmanaged disks are used. It requires customer to manually create storage accounts, then configure the accounts in CF manifest files. This is because of the limitation on the number of disks per storage account. Now Managed Disk is available, offers managed secure and reliable disk storage for virtual machines. Customer no longer need to deal with the storage account for scale and HA. Azure arranges disks automatically. Whether it's a new or an existing deployment, the Azure CPI will handle the creation or migration of the managed disk during a CF deployment. It's supported with PCF 1.11. You can also explore the open-source Cloud Foundry Managed Disk guidance for reference.

Availability Zone *

As a cloud-native application platform, Cloud Foundry is designed with four level of High availability. While the first three levels of software failures can be handled by CF system itself, platform fault tolerance is provided by cloud providers. The key CF components should be protected with a cloud provider’s platform HA solution. This includes GoRouters, Diego Brains, CF database and service tiles. By default, Azure Availability Set is used for fault tolerance between clusters in a data center. The good new is, Azure Availability Zone is released now, bringing the fault tolerance to next level, with low latency redundancy across data centers. Azure Availability Zone achieves HA by placing a set of VMs into 2+ data centers, each set of VMs are redundant to other sets. If one Zone is down, the other sets are still live, isolated from the disaster.

Note

Azure Availability Zone is not offered to all regions yet, check the latest announcement for the list of supported regions. For Open Source Cloud Foundry, check Azure Availability Zone for open source Cloud Foundry guidance.

2. Network Routing

By default, Azure basic load balancer is used for incoming CF API/apps requests, forwarding them to the Gorouters. CF components like Diego Brain, MySQL, ERT can also use the load balancer to balance the traffic for HA. Azure also provides a set of fully managed load-balancing solutions. If you're looking for TLS/SSL termination ("SSL offload") or per HTTP/HTTPS request application layer processing, consider Application Gateway. For high availability and scalability load balancing on layer 4, consider standard load balancer.

Azure Application Gateway *

Azure Application Gateway offers various layer 7 load balancing capabilities, including SSL offloading, end to end TLS, Web Application Firewall, cookie-based session affinity and more. You can configure Application Gateway in Open Source Cloud Foundry. For PCF, check the PCF 2.1 release notes for POC test.

Azure Standard Load Balancer *

Azure Load Balancer is a Layer 4 load balancer. It's used to distribute the traffic among instances of services in a load-balanced set. The standard version provides advanced features on top of the basic version. For example 1. The backend pool max limit is raised from 100 to 1000 VMs. 2. The endpoints now support multiple availability sets instead of single availability set. 3. Additional features like HA ports, richer monitoring data, and so on. If you're moving to Azure Availability Zone, standard load balancer is required. For a new deployment, we recommend you to start with Azure Standard Load Balancer.

3. Authentication

Cloud Foundry User Account and Authentication is the central identity management service for CF and its various components. Azure Active Directory is Microsoft’s multi-tenant, cloud-based directory and identity management service. By default, UAA is used for Cloud Foundry authentication. As an advanced option, UAA also supports Azure AD as an external user store. Azure AD users can access Cloud Foundry using their LDAP identity, without a Cloud Foundry account. Follow these steps to configure the Azure AD for UAA in PCF.

4. Data storage for Cloud Foundry Runtime System

Cloud Foundry offers great extensibility to use Azure blobstore or Azure MySQL/PostgreSQL services for application runtime system storage.

Azure Blobstore for Cloud Foundry Cloud Controller blobstore

The Cloud Controller blobstore is a critical data store for buildpacks, droplets, packages, and resource pools. By default, NFS server is used for Cloud Controller blobstore. To avoid single point of failure, use Azure Blob Storage as external store. Check out the Cloud Foundry documentation for background, and options in Pivotal Cloud Foundry.

MySQL/PostgreSQL as Cloud Foundry Elastic Run Time Database *

CF Elastic Runtime requires two major system databases:

CCDB

The Cloud Controller database. Cloud Controller provides REST API endpoints for clients to access the system. CCDB stores tables for orgs, spaces, services, user roles, and more for Cloud controller.

UAADB

The database for User Account and Authentication. It stores the user authentication related data, for example encrypted user names and passwords.

By default, a local system database (MySQL) can be used. For HA and to scale, leverage Azure managed MySQL or PostgreSQL services. Here is the instruction of enabling Azure MySQL/PostgreSQL for CCDB, UAADB and other system databases with Open Source Cloud Foundry.

5. Open Service Broker

Azure service broker offers consistent interface to manage application’s access to Azure services. The new Open Service Broker for Azure project provides a single and simple way to deliver services to applications across Cloud Foundry, OpenShift, and Kubernetes. See the Azure Open Service Broker for PCF tile for deployment instructions on PCF.

6. Metrics and Logging

The Azure Log Analytics Nozzle is a Cloud Foundry component, that forwards metrics from the Cloud Foundry loggregator firehose to Azure Monitor logs. With the Nozzle, you can collect, view, and analyze your CF system health and performance metrics across multiple deployments. Click here to learn how to deploy the Azure Log Analytics Nozzle to both Open Source and Pivotal Cloud Foundry environment, and then access the data from the Azure Monitor logs console.

Note

From PCF 2.0, BOSH health metrics for VMs are forwarded to the Loggregator Firehose by default, and are integrated into Azure Monitor logs console.

Note

This article was recently updated to use the term Azure Monitor logs instead of Log Analytics. Log data is still stored in a Log Analytics workspace and is still collected and analyzed by the same Log Analytics service. We are updating the terminology to better reflect the role of logs in Azure Monitor. See Azure Monitor terminology changes for details.

7. Cost Saving

Cost Saving for Dev/Test Environments

B-Series: *

While F and D VM series were commonly recommended for Pivotal Cloud Foundry production environment, the new “burstable” B-series brings new options. The B-series burstable VMs are ideal for workloads that don't need the full performance of the CPU continuously, like web servers, small databases and development and test environments. These workloads typically have burstable performance requirements. It is $0.012/hour (B1) compared to $0.05/hour (F1), see the full list of VM sizes and prices for details.

Managed Standard Disk:

Premium disks were recommended for reliable performance in production. With Managed Disk, standard storage can also deliver similar reliability, with different performance. For workload that isn't performance-sensitive, like dev/Test or non-critical environment, managed standard disks offer an alternative option with lower cost.

Cost saving in General

Significant VM Cost Saving with Azure reservations:

Today all CF VMs are billed using “on-demand” pricing, even though the environments typically stay up indefinitely. Now you can reserve VM capacity on a 1 or 3-year term, and gain discounts of 45-65%. Discounts are applied in the billing system, with no changes to your environment. For details, see How Azure reservations works.

Managed Premium Disk with Smaller Sizes:

Managed disks support smaller disk sizes, for example P4(32 GB) and P6(64 GB) for both premium and standard disks. If you have small workloads, you can save cost when migrating from standard premium disks to managed premium disks.

Use Azure First Party Services:

Taking advantage of Azure’s first party service will lower the long-term administration cost, in addition to HA and reliability mentioned in above sections.

Pivotal has launched a Small Footprint ERT for PCF customers, the components are co-located into just 4 VMs, running up to 2500 application instances. The trial version is now available through Azure Market place.

Next Steps

Azure integration features are first available with Open Source Cloud Foundry, before it's available on Pivotal Cloud Foundry. Features marked with * are still not available through PCF. Cloud Foundry integration with Azure Stack isn't covered in this document either. For PCF support on the features marked with *, or Cloud Foundry integration with Azure Stack, contact your Pivotal and Microsoft account manager for latest status.