Pivotal Cloud Foundry and Microsoft Azure Reference Architectures For Cloud Native Applications

Pivotal Cloud Foundry
& Microsoft Azure:

Reference Architectures for
Cloud Native Applications
A Pivotal and Microsoft White Paper
PIVOTAL CLOUD FOUNDRY & MICROSOFT AZURE WHITE PAPER 2
Table of Contents
Introduction....................................................................................... 3 Reference Architecture:
Applications & Microservices
What’s Included............................................................................. 4 Running on Pivotal Cloud Foundry............................19
Pivotal Cloud Foundry: Platform & Services .............................. 4 Reference Architecture Components...........................................19
Infrastructure Services Virtual Network............................................ 5 Considerations for High Availability

Elastic RunTime Virtual Network........................................................ 5 Across Multiple Sites......................................................................... 20
Application Services Virtual Network................................................ 6 Peer Replication with Service Registry....................................... 20
Other Topics.......................................................................................... 7
Reference Architecture:
How the Platform Supports Compliance & Security................ 7
Sample Customer App......................................................... 22
Spring Cloud Services & Steeltoe................................................... 9
Sample App Components............................................................... 22
Overview................................................................................................ 9
PCF Platform Services...................................................................... 22
Config Server for Pivotal Cloud Foundry.......................................... 9
Service Registry for Pivotal Cloud Foundry...................................... 9 Take the Next Step...................................................................23
Circuit Breaker Dashboard for Pivotal Cloud Foundry................. 10
Appendix: What is Cloud Native
Microservices for .NET with Steeltoe.............................................. 10
and Why Does It Matter? ...................................................24
Reference Architecture: Appendix A – Welcome to Your Cloud Native Journey........24
Logical Infrastructure..............................................................12 So, How Does One Eat The World With Software?.......................24
Logical Infrastructure: Microsoft Azure in the The Goal: Shorter Cycles To Increase Quality
Public Cloud............................................................................................12 and Grow The Business....................................................................24
Availability Sets in Microsoft Azure..................................................13 Appendix B – What Keeps You Up at Night?........................... 25
IaaS Architecture.................................................................................14 Appendix C – How Do Pivotal Customers Go About
Network Topology...............................................................................16 Becoming Cloud Native? It Starts with a Platform................. 26
Further Guidance: Microsoft Azure..................................................16 About Pivotal.........................................................................................27
Hybrid Considerations........................................................................16 About Microsoft....................................................................................27
Data Replication...................................................................................16
Routing Site Selection........................................................................17
Active-Active or Active-Passive?.......................................................17
Deployment Orchestration.................................................................18
© Copyright 2017 Pivotal Software, Inc. All rights Reserved. (c) 2017 Microsoft Corporation pivotal.io | microsoft.com
Introduction
Many companies want to become a cloud-native enterprise. Pivotal Cloud Foundry (PCF) is the most
popular tool to help make this happen. (The Appendix includes more on this topic.)
Pivotal’s engineers and architects have worked with hundreds of the largest companies in recent
years. Our team has refined "best practices" for how to best deploy PCF, and how to best develop
modern apps. This insight helps customers reduce risk, and deliver high-quality software faster.
Many of these enterprises wish to run Pivotal Cloud Foundry on Microsoft® Azure™. Azure is a popular
choice for several reasons:
• Global Reach. Deploy PCF in any Azure region, to ensure proximity to customers and users. Azure
has over 30 regions across the Americas, Europe, and Asia Pacific, including sovereign clouds in
mainland China and Germany, and for the US government.
• Differentiated Services. The Microsoft Azure Service Broker for PCF exposes application services
natively through PCF.
• Deep Partnership. Pivotal and Microsoft have joint engineering teams working together, to ensure
ongoing enhancements.
• Integrated Support. Pivotal and Microsoft have integrated support teams, workflows, and ticketing
systems to offer seamless support.
• Proven in Production. PCF on Azure is deployed in production with many enterprise accounts.
Customers have asked for advice on how to best deploy PCF atop Azure. To this end, this white
paper encapsulates our learnings as reference architectures. These designs help enterprises deliver
software continuously, in a secure and scalable way. We'll review four architectures and address
common questions.
• What’s included in Pivotal Cloud Foundry? How does it help my organization develop software
faster and run more securely? How can I extend the platform with the data services I need? And
how does the Spring framework fit into all this? Refer to What’s Included
• How should I deploy PCF on Microsoft Azure? What about hybrid deployments that run in my data
center? How can I get multi-site availability for my apps? Refer to Reference Architecture: Logical
Infrastructure
• How do you run microservices and event-driven architectures on Pivotal Cloud Foundry? Refer to
Reference Architecture: Applications & Microservices Running on Pivotal Cloud Foundry
• What does an actual sample app look like on Pivotal Cloud Foundry and Spring Cloud Services?
Refer to Reference Architecture: Sample Customer App
What’s Included
PIVOTAL CLOUD FOUNDRY: PLATFORM & SERVICES

Pivotal Cloud Foundry (PCF) is a cloud-native platform for deploying and operating applications. PCF
can run on-premises, and atop public cloud providers like Microsoft Azure. This gives enterprises a
hybrid and multi-cloud platform.
PCF is a uniform way for you to launch, and quickly iterate, on applications in any popular language.
The platform manages many implementation details for you. With PCF, you no longer have to think
about how to deploy, scale, and expose an app. You can instead focus on adding business value
with custom code. PCF enables developers to speed up application development and reduce time to
market.
Figure 1
The diagram in Figure 1 highlights important PCF components. This architecture organizes elements
according to their network affinity.
Load Balancer
App Services Elastic Runtime
Virtual Network Virtual Network
Spring Cloud Platform API TCP Router HTTP Router Gorouter

Services
Azure SQL Diego

Database PCF Metrics
Config Windows
Data Linux Cell(s)
Azure Redis
Provisioning & Cell(s)
De-Provisioning
Cache of Services Log Search Brain
Interactions
Secured via
Azure Event HTTP/s
Hubs Log Azure Blob
Messaging Errand Aggregation storage
Azure Service
Bus
Secure Network Connection via NAT Gateway
Third Party
Services
BOSH PCF Ops
LDAP
Director Manager
Internal
Services
Infrastructure Services Virtual Network
Figure 1 – An overview of selected Pivotal Cloud Foundry components.
• Infrastructure Services Virtual Network, used by Pivotal Cloud Foundry Ops Manager to control
the underlying infrastructure
• Elastic Runtime Virtual Network, used by PCF’s Elastic Runtime, container orchestrator, and other
related services
• App Services Virtual Network, used by PCF managed services like MySQL, RabbitMQ and Spring
Cloud® Services for Pivotal Cloud Foundry
Let’s review each item in Figure 1.
Infrastructure Services Virtual Network

• LDAP. Lightweight Directory Access Protocol is a protocol used for single sign-on methods. It
connects an identity management tool (such as Azure Active Directory) and 3rd party systems.
Pivotal Cloud Foundry supports LDAP and SSO via its UAA service.
• PCF Ops Manager. Operations Manager (“Ops Manager”) is a web application used to deploy
and manage PCF. Ops Manager communicates with the BOSH Director to deploy Elastic Runtime
components and other services.
• BOSH Director. BOSH Director performs a highly automated PCF deployment based on user-
provided configuration details.
• NAT Gateway. A network address translation (NAT) gateway enables services in a private subnet
to connect to other PCF components. The NAT Gateway also prevents components outside the
Infrastructure Services VLAN from initiating a connection with these services. Read more about
configuring firewalls for PCF.
Elastic RunTime Virtual Network

• Load Balancer. Production PCF environments use a highly-available load balancer. The load
balancer routes traffic to PCF Router IPs, supports SSL termination with wildcard DNS location,
and adds appropriate x-forwarded-for and x-forwarded-proto HTTP headers to incoming
requests. WebSockets can be supported as needed. In Azure, we recommend using the Azure
Application Gateway as a scalable load balancer to an individual PCF foundation. Multi-region
deployments should add Azure Traffic Manager to provide DNS routing to the closest available
foundation.
• TCP Router. The TCP Router works with applications that serve requests on non-HTTP TCP
protocols. TCP Routing terminates the TLS as close to your apps as possible. In this scenario,
packets are not decrypted before reaching the application level. This configuration helps
compliance with certain regulations.
• HTTP Router. The HTTP Router manages HTTP traffic into and out of the PCF deployment.
• Gorouter. The Gorouter routes traffic coming into PCF to the appropriate component. For example,
the Gorouter is used when an operator addresses the Platform API. It is also used when application
user accesses an app running on a Diego Cell.
• Platform API. The Platform API (or Cloud Controller) provides REST API endpoints for clients to
access the system. It maintains a database with tables for orgs, spaces, services, user roles, and
more.
• PCF Metrics. PCF Metrics stores logs, metrics data, and event data from applications running on
PCF. The module renders this data visually. This treatment helps operators and developers better
understand the application health and performance.
• Log Search. Operators can use PCF Log Search to analyze logs from different system components.
Some customers prefer Azure's native capabilities in this area. Options include the Microsoft
Operations Management Suite (OMS) and Monitor services. Microsoft has adapted Cloud Foundry's
Firehose and nozzle features, shown below. Users can analyze logs and metrics using this starter
OMS visualization widget.
Figure 2
Figure 2 – Cloud Foundry metrics and logging, shown in the Microsoft OMS.
• Diego. Diego is the container orchestrator for Pivotal Cloud Foundry.
ϐϐ Brain. The Diego Brain distributes one-off tasks and long-running processes (LRPs) to Diego
Cells. These processes are dynamically managed, increasing fault-tolerance and long-term
consistency.
ϐϐ Linux Cell. Each Linux-based application VM has a Linux Cell that executes local application
start and stop actions. The Cell manages the containers within a VM, and reports app status and
other data to the Log Aggregator.
ϐϐ Windows Cell. Windows Cells perform the same functions as Linux Cells, but for tasks and
processes that require Windows and .NET components.
ϐϐ Config Data. This database maintains a real-time representation of the state of the Diego cluster.
Data stored includes metadata about all desired LRPs, running LRP instances, and in-flight tasks.
This also includes a consistent key-value data store to Diego.
• Messaging. Messaging in PCF is done via NATS, a lightweight publish-subscribe and distributed
queueing messaging system.
• Errand. These instances are dedicated to running one-off errands (for example, adding and
removing Tiles).
• Log Aggregator. The Log Aggregator (or “Loggregator”) aggregates and streams logs and metrics.
It collects and processes data from all user apps and Elastic Runtime components.
• Azure Blob Storage. PCF uses Blob Storage to host buildpacks, droplets, packages and resources.
This can be an object storage service or internal file system. Azure Blob storage is recommended
for PCF deployments on Azure. This is supported by default in the recommended BOSH manifest
files.
Application Services Virtual Network

Customers use Pivotal Cloud Foundry's core components to deploy and operate their apps.
Developers and operators tend to extend their modern apps with other services.
These add-ons connect via an Application Services Virtual Network. Here are a few popular services
that Azure customers often integrate into their apps.
• Spring Cloud Services. Spring Cloud Services for Pivotal Cloud Foundry (PCF) packages server-side
components of Spring Cloud projects, including Spring Cloud Netflix and Spring Cloud Config, and
makes them available as services in the PCF Marketplace.
• Azure SQL Database. Azure SQL Database is a managed cloud database for app developers. The
service makes building and maintaining applications easier and more productive. SQL Database
includes built-in intelligence that learns app patterns and adapts to maximize performance,
reliability, and data protection.
• Azure Redis Cache. Azure Redis Cache is based on the popular open-source Redis cache. It gives
you access to a secure, dedicated Redis cache, managed by Microsoft and accessible from any
application within Azure. It is available in three tiers: basic, standard, or premium.
• Azure Event Hubs. Azure Event Hubs is a hyper-scale telemetry ingestion service that collects,
transforms, and stores millions of events. As a distributed streaming platform, it offers low latency
and configurable time retention enabling you to ingress massive amounts of telemetry into the
cloud and read the data from multiple applications using publish-subscribe semantics.
• Azure Service Bus. Azure Service Bus offers a highly-reliable cloud messaging service between
applications and services, even when one or more is offline. Available in every Azure region, this
fully-managed service eliminates the burdens of server management and licensing. Asynchronous
operations enable flexible, brokered messaging between client and server, along with structured
first-in-first-out (FIFO) messaging and publish/subscribe capabilities—perfect for tasks such as order
processing.
• Third-Party Services. Many different software packages can be integrated with Pivotal Cloud
Foundry. Application performance management (APM), API Gateways, and NoSQL databases are
some of the most popular categories.
• Internal Services. Customers may connect their own internal services using the service broker
interface.
Other Topics
• Apps Manager. Apps Manager, a web-based tool, manages roles and permissions in Pivotal Cloud
Foundry.
• Buildpacks. Buildpacks provide framework and runtime support for your applications. Buildpacks
examine user-provided artifacts to determine dependencies. It also manages the configuration
needed to communicate with bound services. When you push an application, PCF detects the
needed buildpack. It then installs the buildpack bits where the application will be staged.
• Service Brokers. Applications depend on services from databases or third-party SaaS providers. A
service broker arranges for this connection. The service broker provides the service instance, then
the app may communicate with that instance.
HOW THE PLATFORM SUPPORTS COMPLIANCE & SECURITY

A common security mindset: “going slower reduces risk.” Pivotal and its customers believe that the
opposite is true. The faster systems change, the harder they are to penetrate. That’s the core idea
of cloud-native security, and the “secure by default” features in PCF. These features help companies
meet common compliance and security requirements.
• Authentication. The User Account and Authentication (UAA) is the identity management service for
PCF. It is an OAuth2 provider, issuing tokens for client applications to use when they act on behalf
of PCF users. UAA works with the login server to authenticate users with their PCF credentials. It
performs single sign-on (SSO) duties using those credentials (or others). UAA has endpoints for
managing user accounts, and other functions like registering OAuth2 clients. On Azure, customers
tend to use their enterprise Azure Active Directory (AAD). PCF offers easy integration with AAD for
platform access. In fact, it's the same as on-premise Active Directory or LDAP integration. You need
to provide the necessary XML metadata file, and it's done!
• BOSH. BOSH deploys Pivotal Cloud Foundry and related services. It unifies the management of
cloud software across its lifecycle. BOSH can provision and deploy software over hundreds of VMs.
It also performs monitoring, failure recovery, and software updates with zero-to-minimal downtime.
BOSH supports many “immutable infrastructure” concepts. It enables two important elements of
cloud-native security:
ϐϐ Repair. Repair vulnerable software as soon as updates are available.

ϐϐ Repave. Repave servers and applications from a known good state, and do this often. Malware
thrives on vulnerable software and static, unchanging systems. Change the state of your
environment frequently, and end malware-friendly conditions. Use BOSH to deploy your
environment several times a day - all with no downtime and minimal manual effort.
• CVEs, Patches, & Updates for a Broad Range of Elements. Pivotal regularly patches PCF
components, the underlying operating system, middleware, and third-party dependencies. When
our security team identifies a "high" or "critical" CVE, they respond with a fix within 48 hours. These
updates can applied using Ops Manager and other tooling, often without downtime. Refer to https://
pivotal.io/security for additional information.
• Encryption of Data at Rest. The native encryption features of Azure storage in the deployment
achieve this requirement.
• Encryption of Data in Transit (IPsec Add-on). The IPsec Add-on for PCF encrypts IP data in transit
in a PCF deployment. This module provides internal system protection if a malicious actor breaches
your firewall.
• Role-Based Access Controls. PCF supports enterprise access controls with Orgs, Spaces, Roles,
and Permissions. This feature works in concert to ensure developers and operators have the
right level of access. The Apps Manager is a web-based tool to help administer these roles and
permissions.
ϐϐ Org. An org is a development account used by an individual or a team. Collaborators access an

org with user accounts. Collaborators share the org's resource quota plan, applications, services
availability, and custom domains.
ϐϐ User Accounts. A user account represents an individual in a PCF installation. A user may have
different roles in different spaces within an org.
ϐϐ Spaces. Every application and service is part of a space. Each org contains at least one space.
A space provides a shared location for application development, deployment, and maintenance.
Each space role applies only to a particular space.
ϐϐ Roles and Permissions. A user can have one or more roles. These roles defines the user’s
permissions in the org and within specific spaces in that org.
• SSL/TLS. SSL/TLS certificates can secure HTTP traffic into your Elastic Runtime deployment. To
secure non-HTTP traffic, terminate TLS at your load balancer or at the application with TCP Routing.
SPRING CLOUD SERVICES & STEELTOE

Overview
Spring Cloud Services (SCS) for PCF includes components of Spring Cloud projects
(like Spring Cloud Netflix and Spring Cloud Config). SCS are available as services in the
PCF Marketplace. With SCS, you do not have to manage or maintain these components,
Pivotal does that for you.
Use SCS to create a Config Server, Service Registry, or Circuit Breaker Dashboard service instance
on-demand. From there, you can bind to it and consume it. This again frees you to focus on the value
added by your own microservices.
Config Server for Pivotal Cloud Foundry

Config Server for PCF is an externalized application configuration service. This delivers a
central place to manage an application’s external properties across all environments.
Config Server will manage the configuration for an app as it advances through the deployment
pipeline (dev, test, prod). Developers can be sure that an app has everything it needs to run during this
process. Config Server supports labeled versions of environment-specific configurations. Users can
manage configuration content with many tools, including Git. We also plan future support for Vault (as
well as Git and Vault in composite fashion).
2. Source config
Git Repository
Config Server
greeing: ohai
1. Push
config
1. Pull
config
App A App B App C

greeing: ohai greeing: ohai greeing: ohai
Figure 3 – Config Server for Pivotal Cloud Foundry.
Service Registry for Pivotal Cloud Foundry

Service Registry for PCF provides an implementation of the Service Discovery pattern,
based on Netflix Eureka. This is one of the key tenets of a microservice-based
architecture.
Manual configuration of each client or service is difficult. It often proves brittle in production. Instead,
use Service Registry to dynamically discover and call registered services.
Service
Registry
1. register
2. discover
Producer Consumer
3. connect
Figure 4 – Service Registry for Pivotal Cloud Foundry.
First, a client registers with the Service Registry. The client also provides metadata about itself, like its
host and port. Once registered, the Registry expects a regular heartbeat message from each service
instance. If the heartbeat message is not received consistently, the Service Registry removes the
instance from its registry.
Circuit Breaker Dashboard for Pivotal Cloud Foundry

The Hystrix library (part of Spring Cloud Netflix) provides an implementation of the Circuit Breaker
pattern. The Circuit Breaker Dashboard for PCF visualizes the metrics of the circuit
breakers inside an app. Cloud-native architectures are often composed of many layers of
distributed services. End-user requests may comprise multiple calls to these services. If a
lower-level service fails, that failure can cascade up to the end user and spread to other
dependent services. Heavy traffic to a failing service can also make it difficult to repair.
Figure 5
Hystrix circuit breakers can prevent failures from cascading. They can also provide fallback behavior
until a failing service is restored to normal.
Closed Open
on call / pass through trip breaker
on call / fail
call succeeds / reset count
on timeout / attempt reset
call fails / count failure
threshold reached / trip breaker
trip attempt
breaker reset
reset Half-Open
on call / pass through
call succeeds / reset
call fails / trip breaker
Figure 5 – Circuit Breaker for Pivotal Cloud Foundry.
When applied to a service, a circuit breaker watches for failing calls to the service. If failures reach a
certain threshold, it “opens” the circuit. The circuit breaker automatically redirects calls to the specified
fallback mechanism. This gives the failing service time to recover. The Circuit Breaker Dashboard
provides operational visibility into the behavior of all of the circuit breakers present in a fleet of cloud-
native services.
Microservices for .NET with Steeltoe

Spring Cloud Services bring common microservices patterns to Java
developers. Steeltoe does the same for .NET developers. Steeltoe helps
.NET client apps integrate with Spring Cloud Services. Steeltoe also includes connector libraries for
Cloud Foundry. This handles the parsing of environment variables (VCAP_SERVICES) for you. As a
result, extending apps with backing services like Azure SQL DB is that much easier.
Steeltoe includes three modules:
Service Discovery
How do you make the interactions between your microservices reliable and failure tolerant? For
starters, you need a service registry—basically a phone book for your microservices—so service
consumers know exactly where to find healthy service instances. Steeltoe includes a .NET client for
Netflix Eureka so your microservices can register themselves and discover other registered services.
Config Server
“Strict separation of config from code” has become a cloud mandate, but that begs the question,
where do you put it? And once you’ve externalized your config from your app, how do you track who
changed what, when? Steeltoe leverages Spring Cloud Config Server so you can store your app’s
config in a centralized, version-controlled git repo and then load it at runtime.
Cloud Connectors
Steeltoe automatically wires up common backing services, because no microservice is an island. And
because it was built by Pivotal, Steeltoe integrates elegantly with Cloud Foundry.
Reference Architecture: Logical

Infrastructure
This Reference Architecture simulate a base deployment of Pivotal’s products.
LOGICAL INFRASTRUCTURE: MICROSOFT AZURE IN THE

PUBLIC CLOUD
The architecture in Figure 6 describes a secure, PCF Foundation hosted in Microsoft Azure.
The diagram shows core networking, created via an Azure virtual network. It has the following subnets:
• Infrastructure
• ERT (Elastic Runtime)
• Service tiles
• Dynamic or On Demand Service tiles
Public IP Public IP Public IP
ALB ALB ALB ALB Each ERT Job

API & ssh-proxy top-router (Mysql) has its own
Apps (optional) (optional) availability set
Ops Jump Availability Availability Availability Availability Availability

Mgr BOSH Box Set Set Set Set Set(s)
Go Diego TCP My Other

Router Brains ERT
Rtr SQL Jobs
“Infrastructure” /22
“ERT” /22
vnet
“Services-#” /22 “Dynamic Services” /22
Dynamic
Service Service Service Services
Tile Tile Tile (future)
Availability Availability Availability Availability
Set Set Set Set
Pivotal Customer0
PCF on Azure Ref Arch
v 1.0
Dec 6, 2016 BOSH Ops Mgr ERT ERT ERT
(Must be LRS)
Azure Resource Group 01 Storage Accounts
Figure 6 – A logical reference architecture for Pivotal Cloud Foundry atop Microsoft Azure, featuring a single resource group.
Availability Sets in Microsoft Azure

Some cloud providers provide VM availability guarantees through the use of explicit availability zones.
In Azure, you can achieve equivalent availability guarantees through the use of availability sets, but
the concepts are different. Availability sets automatically spread VMs from the same logical application
tier across the Azure infrastructure to eliminate single points of failure, which are referred to as fault
domains.
To illustrate this, consider the layout of three standard PCF components, the GoRouter, the Diego Brain,
and MySQL. In a standard PCF foundation, each of these components is deployed in 3 VMs to ensure
high availability. With availability zones, the three VMs would be distributed as shown below:
Figure 7 – Configuration with availability zones
In this approach, the single point of failure is the availability zone, and each component (GoRouter,
Diego Brain, MySQL) is prepared to deal with the loss of a single AZ.
In Azure, the same set of VMs are laid as shown below:
Figure 8 – Configuration with availability sets.
Here, single points of failure are managed within individual availability sets in the form of fault domains.
Note that you cannot compare fault domains across availability sets - thus, a failure in FD0 of the
GoRouter availability set does not necessarily mean that the VMs in FD0 of the MySQL availability set
will fail. However, since the various components of the PCF foundation are designed to be individually
fault tolerant, this is not a concern. It is also worth pointing out that all major cloud providers offer
extremely high levels of VM availability, so even individual failures are uncommon. Azure currently
offers an SLA of 99.95% availability for VMs within an availability set and in practice operates at a
much higher rate.
IaaS Architecture
Here are the core Azure architectural constructs required to deploy PCF. Pivotal recommends that
customers automate their deployment with the Azure Resource Marketplace template. This reduces
the likelihood of human error and makes your deployments more consistent.
Figure 6 shows a single PCF deployment in a single Azure Resource Group. Availability Sets within
Azure expose infrastructure services to PCF. Use Availability Sets to deliver implicit HA for all virtual
machines within a region.
The ‘base’ reference approach creates a single Resource Group. The Resource Group is then
populated with the required Azure constructs, such as virtual networks, network interfaces, network
security groups, public IP addresses, load balancers, and and storage accounts. From there, Pivotal
Operations Manager deploys PCF.
• One service principal account bound to an Azure Active Directory (AAD) application. This
enables BOSH to interact with the API. Pivotal.io includes useful documentation on this step.
• One or two Resource Groups per PCF installation. PCF deployments on Azure need at least
one resource group. Two resource groups are an option when more control over access to Azure
networking objects is desired. Here, the 'Network' Resource Group manages Azure virtual networks.
The second 'PCF' Resource Group is for objects deployed with BOSH.
• Many Availability Sets, created by BOSH for each deployment job type. Availability sets allocate
BOSH jobs across 1 or more fault or upgrade domains. This allows jobs to complete, even if Azure
failures occur. Each BOSH job in a PCF release gets their own availability set. This creates many
instances, so that jobs can proceed in case of a single Azure Fault Domain failure. See here for
more information on Azure Availability Sets.
• One virtual network (vnet) with a large range of address space that is sub-divided. Let's look at a
common division.
ϐϐ Example: 10.xxx.yyy.0/20
–– One network for Infrastructure 10.xxx.yyy.0/26
–– One network for Elastic Runtime 10.xxx.yyy.0/22
–– One for Services-# 10.xxx.yyy.0/22
–– One for Dynamic Service-# 10.xxx.yyy.0/22
ϐϐ Note that a subnet is a logical component, bound to a single virtual network. It must exist in the
the same Resource Group. In Multi Resource Group deployments, 'Network' and 'PCF resource
groups should share the same region. This allows BOSH jobs in one resource group to attach
networks to another.
• One Network Security Group (NSG). NSG manages firewall rules that apply to network interfaces.
Ops Manager for Azure currently limits PCF deployments to 1 security group.
• Four Azure Load Balancers (ALBs). Load balancers are used as follows:
ϐϐ One for Public app access, enabling an API (or Control Path) and Apps (or Data Path)
ϐϐ One for Internal use, for example MySQL
ϐϐ One for an Optional TCP Routers, if selected

ϐϐ One for an Optional SSH Proxy
• Five Standard Storage Accounts to match deployment needs. Storage accounts are used to store
the VM disks. Multiple storage accounts are suggested for two reasons. First, IOPS is capped at
around 20,000 per account. Second, this avoids a single point of failure in the storage tier. Please
note that customers pay for the consumption of storage, not the number of Storage Accounts.
The five accounts should be allocated as follows.
ϐϐ One for Ops Manager

ϐϐ One for BOSH
ϐϐ Three for Elastic Runtime and other tile deployments
We recommend Premium storage for Elastic Runtime and tile deployments.
Support for Azure’s Managed Disks feature is planned for Pivotal Cloud Foundry.
• One jump box on the infrastructure network to provide CLI tools. A jump box inside your PCF
deployment is a handy utility. That’s why a jump box is part of the PCF Azure Resource Manager
template. This template includes the jump box with the recommended CLIs, so this is done for you.
Manual deployments will need to create this jump box, then install recommended CLIs manually.
The CLIs are listed in the Pivotal Customer0 repo.
• One to five public IPs, assigned as follows. Note that public IPs are not needed if deploying with a
VPN or Express Route Solution.
ϐϐ One VIP for Azure Load Balancer for CF domains (sys. and apps.)
ϐϐ One to SSH into jump box
ϐϐ One optional for VIP for Azure Load Balancer to TCP Routers
ϐϐ One optional HTTPS Ops Manager
ϐϐ One optional SSH Proxy to Diego Brains
Network Topology
Figure 9 shows the Azure network elements configured in practice.
Pivotal Customer0 ingress egress 1to1_nat

PCF on Azure Network Topology (NAT)
Traffic Path Legend
v 1.0
Dec 6, 2016
Rule Name: Ports: Source>Dest Action:

internal-anything * VirtualNetwork->ANY Allow Public IP Public IP Public IP Public IP Public IP
ssh TCP:22 Internet:ANY Allow
bosh-agent TCP:6868 Internet:ANY Allow
bosh-director TCP:25555 Internet:ANY Allow
dns ANY:53 Internet:ANY Allow
http ANY:80 Internet:ANY Allow ALB ALB ALB ALB
https ANY:443 Internet:ANY Allow API & ssh-proxy top-router (Mysql)
loggregator ANY:443 Internet:ANY Allow Apps (optional) (optional)
mysql TCP:3306 Internet:ANY Allow
mysql-healthchk TCP:1936 Internet:ANY Allow
diego-ssh TCP:2222 Internet:ANY Allow
top TCP:11000-12000 Internet:ANY Allow
Network Security Group (Applies to All Network Interfaces)
Ops Jump
Mgr BOSH Box Go Diego TCP SQL
Router(s) Cell(s) Router(s) Proxy
Brains
Availability Availability Availability Availability Availability

Set Set Set Set Set
Azure
SNAT
“Infrastructure” /22 “ERT” /22
External
Dest
Svc Svc Svc Route
Job(s) Job(s) Job(s)
Express
Route
&/or
VPN
“Services-#” /22 “Dynamic Services” /22
Resource Group 01 / Virtual Network
Figure 9 – A common network topology for Pivotal Cloud Foundry atop Microsoft Azure.
Further Guidance: Microsoft Azure

Additional guidance for this reference architecture is in the Pivotal Customer0 Github repo. The repo
also offers configurations for multi-resource group environments.
HYBRID CONSIDERATIONS
The most popular hybrid configuration with enterprises? Using the public cloud as an extension of an
on-premises datacenter. Microsoft support this scenario with Azure Express Route.
Here, apps run on-prem, and in multi-tenant, elastic infrastructure. Administrators configure firewall
rules in the public cloud. This restricts access, such that only certain IP ranges (those of a corporate
network) can access the app.
Here are four areas to keep in mind for this scenario.
Data Replication
Data should be the foremost consideration in designing hybrid architectures. After all, most
regulations and compliance standards apply to the treatment of data!
Traditional scenarios feature a primary site and a secondary site. The system sends database logs
from the primary data center to the secondary location in regular intervals.
But, most Pivotal customers desire something different and more powerful: bi-directional data
replication. Here, the system replicates data in near real-time, between sites. Both sites serve traffic
and process requests. This approach boosts reliability and resiliency of the application.
Pivotal Cloud Foundry customers achieve this with Pivotal Cloud Cache (PCC), a high-performance,
highly available caching layer. As changes occur, PCC creates events in a replication queue, then
sends them to the other site. Events can be replicated in user-specified intervals (“every 5 seconds”),
or after a defined count (“every 1000 events”). PCC compresses and encrypts the events before
sending. Upon receipt at the other site, it decompresses and decrypts the data.
Either cluster can perform read/write operations. PCC also handles de-duplication and conflict
resolution. This is an important feature to ensure 100% data redundancy across locations.
SITE 1 SITE 2
Microservices Microservices
Data
Replication
Pivotal Data Store Pivotal Pivotal Data Store Pivotal

Cloud Cache Cloud Cache Cloud Cache Cloud Cache
Figure 10 – Data replication across two sites, featuring Pivotal Cloud Foundry and Pivotal Cloud Cache.
Routing Site Selection

If you’re running an app in the public cloud and in your datacenter, how do you want to route the
traffic? Pivotal Cloud Foundry customers have chosen one of two options.
• “Go through my data center every time.” In this scenario, traffic flows through your existing global
traffic manager. Administrators create routing policies based on custom rules. These policies steer
requests to the most suitable site, either on-premises or the public cloud. Then, admins build firewall
rules that only allow traffic from your data center to the public cloud. These rules block all other
traffic into the company's public cloud instances. This hybrid setup requires a high-speed, dedicated
connection between your data center(s) and the public cloud site. It is important to note that data is
typically served from the on-premises site. Other application elements enjoy greater elasticity.
• “Balance traffic across public cloud nodes and my datacenter.” For this option, use DNS routing or
a global load balancing service from a 3rd party. Pivotal Cloud Foundry easily supports this scenario.
Deploy two PCF foundations, then configure each to work with the desired policies.
Active-Active or Active-Passive?
These terms mean different things to different audiences. For this white paper, let’s define
active-active as real-time HA. Active-passive is a configuration where some lag in consistency or

availability is tolerable.
One of the main obstacles to achieving active-active is latency between data centers. Distributed
transactions cause latency, and should be avoided whenever possible. Access data locally; resolve
requests in a single DC. Data partitioning can also mitigate latency. But, this comes with its own set of
issues (consistency, who to trust for conflict resolution, and so on).
Refer to Considerations for High Availability Across Multiple Sites for more on HA patterns at the app
level.
Active-passive configurations are relatively easy. The passive site gets an update every X seconds or Y
events, as described in the Data Replication section). If the active site goes down, you simply re-route
traffic to the passive location.
Another option for replication: SQL DB Geo-replication. This option replicates database transactions
within a region and across Azure regions.
Customers may connect their private data centers to Azure data centers with Azure Express Route.
Support for Azure Stack is planned.
Deployment Orchestration
Continuous deployment is one three crucial tenants for the digital era. Verify your CI/CD tooling and
processes as you deploy asynchronous apps across different targets. Systems such as Concourse
and Spinnaker are particularly well-suited for this use case. Visual Studio integrations also provide
deployment automation to PCF instances.
There is one consideration to highlight: keep track of database schema changes. Replication errors
and event mismatching will occur if schema versions are not aligned. Advance database versions
together, and be able to roll them back together easily.
Reference Architecture: Applications

& Microservices Running on Pivotal
Cloud Foundry
The architecture in Figure 11 features common cloud-native attributes.
• A modern approach to real-time data processing

• A highly distributed, scale-out pattern
• The Command Query Responsibility Segregation (CQRS) approach. This divides the system in
two distinct parts. CQRS separates the components used for writing (executing commands) from
those for querying. As such, the Command Service and Query Service are independently scalable
services. They are decoupled, and can be operated separately.
• An event store for processing a high-volume of transactions
Discovery Edge Gateway with OAuth2

Azure API Management
Service
Registry HTTP POST/PUT HTTP GET
SSO
Command Query
Service Service
Registraton
Query DB
Manage Create
Configuration Read
Views
Config Event SQL
Server Publish Processor Database
Events
Subscribe to Events
Event Store with

Azure Event Hub
Figure 11 – An event-driven, cloud-native application running Spring Cloud Services and Pivotal Cloud Foundry.
REFERENCE ARCHITECTURE COMPONENTS

• Edge Gateway, implemented with Azure API Management. This service facilitates communication
between the API publisher and the services that consume the APIs. Other capabilities include
dynamic routing, monitoring, resiliency, security, and more. In this architecture, it executes specified
dynamic routing rules, and accommodates diverse inbound clients. A deeper integration is available
by using a route service to bind an app to an API management proxy.
• Service Registry, implemented as Spring Cloud Services Service Registry, tracks the services.
The Command Service and the Query Service both register with this module; the Edge Gateway
uses the Service Registry to discover service locations and where requests should be routed.
• SSO (Single Sign-On) for PCF. The Single Sign-On service is an all-in-one solution for securing
access to the application and its services. It improves security and productivity since users do not
have to log in to individual components.
• Command Service, written with Spring Cloud Data Flow, orders the system do something or
change its state. This represents part of the business logic of the application.
• Query Service, a Spring Boot app, searches the relational database and returns relevant results.
In contrast to the Command Service, this does not change the state of the system. This service is
likely to experience variable load, and can be scaled accordingly.
• Config Server, implemented as Spring Cloud Services Config Server, stores all environmental
variables. No configuration is stored in any of the services. The Config Server stores this
information and provides it on-demand. This is a cloud-native best practice, in keeping with “12
factor app” principles.
• Event Processor, written in Spring Cloud Data Flow, works with the Command Service. This is the
other part of the application’s business logic.
• SQL Database serves as the “system of truth.” It returns results requested by the Query Service.
• Event Store, based on Azure Event Hubs, is the high-volume event processing system. This
pattern is often referred to as “Event Sourcing”. It is a superior option for this scenario, since event
streams in the past may need to be “replayed.” In contrast, systems like RabbitMQ immediately
delete messages upon successful receipt. Azure Event Hubs natively supports C# .NET clients and
Java clients.
CONSIDERATIONS FOR HIGH AVAILABILITY

ACROSS MULTIPLE SITES
The Hybrid Considerations reviews some elements of high availability. Messaging middleware and the
use of event-driven architecture address HA the application level.
Distributed architectures thrive on asynchronous, message-driven communication between

application services. This stands in contrast to traditional, synchronous systems that need massive
bandwidth for traffic between clusters.
The event store in Figure 11 can be configured to send events to multiple sites. Now, let’s examine how
to discover and consume services in different locations.
PEER REPLICATION WITH SERVICE REGISTRY

Consider a recent real-world use case from a financial services organization shown in Figure 12. This
bank has a large number of services deployed across orgs and spaces (part of the permissions model
reviewed in the security section). These services need to be discovered and used across the bank.
Administrators want these services consumed by apps regardless of their PCF organization and space.
With Service Registry peer replication, applications can be managed within the authorization model of
a space, and services can be made accessible in a controlled way across organizations.
A West PCF East PCF A

A A
C Service
Peer Replication
Service D
Registry Registry
D C
B B
Figure 12 – Multi-site peer replication for service registration.
Service Registry peer replication works across PCF installations. It also works across organizations
within a single PCF installation. The diagram above shows a simple Service Registry peer replication
configuration across two sites. If we look at the West PCF data center, the local Service Registry
registers the A and C services in light blue. They are also made available for lookup in the East
PCF data center. The same is true of services in East PCF. The Services Registry there registers the
services in light green locally, then makes them available for lookup in West PCF.
Once peer replication is enabled, development and operations teams enjoy:

• Increased availability for their microservices in the face of partial failures
• Load balancing across network boundaries
• Successful discovery of services across distinct PCF installations or organizations
More details on this scenario, including code samples, are available on the Pivotal blog.
Reference Architecture: Sample Customer App
Now, let's consider a Sample Application written by a PCF customer (Figure 13). We can see how the
platform enables the developers to focus on their custom code. PCF and Spring Cloud Services take
care of ongoing management and operation.
PCF Platform Services
REST REST AMQP REST
Input HTTPS XML JSON

Validation Enrichment Orchestration EDP
Source JMS EVENT
CRUD HUBS
REST REST REST REST REST REST
JSON
State State Search External Derivation Data
REST
Audit
Figure 13 – An production financial services application architecture from a Pivotal customer.
SAMPLE APP COMPONENTS

The customer app features these custom services:
• Validation & State • Search • Audit

• Enrichment Orchestration • External • Data
• State • Derivation • (EDP) Event Data Processing
PCF PLATFORM SERVICES

Meanwhile, PCF manages the underlying infrastructure and runtime dependencies. The platform also
handles these essential elements:
• Config Server. Config Server manages the Sample App’s external configuration properties.
• Service Registry. Service Registry performs Service Discovery for the Sample App’s microservices.
It dynamically discovers and calls registered services for the Sample App.
• Circuit Breaker Dashboard. The Sample App includes multiple layers of distributed services. The
Hystrix library (part of Spring Cloud Netflix) provides an implementation of the Circuit Breaker
pattern. It can provide fallback behavior until a failing service is restored to normal operation. The
Circuit Breaker Dashboard for PCF visualizes the metrics of the circuit breakers inside an app.
• App Autoscaler. The App Autoscaler automatically adjusts capacity for this Sample App. It does so
according to custom triggers and thresholds. The service adds and subtracts instances based on
CPU Usage, HTTP Latency, and HTTP Throughput.
Take the Next Step

We trust these materials have shown you how to best deploy Pivotal Cloud Foundry on Microsoft
Azure, and adopt Spring Cloud Services. Now, take the next step!
Try out PCF on Azure from the Azure Marketplace. This creates a full PCF deployment, including the
Azure Service Broker. Add Pivotal Spring Cloud Services and try out the powerful combination of
Pivotal, Spring, and Azure.
Need more help? We offer architectural guidance and consulting for companies like yours.
At Pivotal, we help organizations assess and execute application replatforming—even operating the
resulting applications on-platform for customers. Businesses of all sizes (from large enterprises to
startups) across industries trust our software, services, and experience to lead them on their journey to
the cloud—before, during, and after deployment.
• Work with Pivotal to identify target applications for replatforming that match the level effort and
benefit tradeoff needed for the business.
• Take advantage of the Pivotal Labs approach, which uses Agile methodologies to gain results
iteratively in 10-week sprints versus months of portfolio analysis before delivering value.
• Quickly find the minimum viable number of the twelve factors that must be addressed before
applications can run in the cloud.
• Team with Pivotal to identify seams in the monolithic approach that can be extracted, migrating
incrementally and keeping value flowing to the business as apps that need the full benefit of cloud-
native design are replatformed.
• Deploy and manage your applications with Pivotal Cloud Foundry—our cloud-native platform that
accelerates time to value.
Contact us today to get started!
PIVOTAL CLOUD FOUNDRY & MICROSOFT AZURE EBOOK 24
Appendix: What is Cloud Native and

Why Does It Matter?
APPENDIX A – WELCOME TO YOUR CLOUD NATIVE JOURNEY

Appendix A is an excerpt from a Pivotal blog post by Michael Coté.
So, How Does One Eat The World With Software?

Most of our customers are looking to becoming a cloud native enterprise. This has given us the
chance to observe how numerous enterprises are transforming and how they use custom written
software to run their business.
Each of them is responding to the need to become a software defined business—the pressure
from “Silicon Valley” to use agility, cloud, data, and devices to disrupt how business is done. Those
pressures are well covered elsewhere, and I wanted to start collecting the highlights of how these
companies have been changing and what they’re doing. This concept is often called the “journey,”
which is a euphemism for “it takes a lot of hard work and time—you won’t just succeed overnight.”
Similarly, building your own home or raising children is a “journey.” There are no easy answers, things
“go wrong” often, but setting up a process that continually learns and improves is what ends up
addressing the problems, resulting in custom built houses and functioning adults.
So, this article begins to explain what customers of Pivotal Cloud Foundry have been doing to make
sure their kids stay out of jail. First, we’ll briefly discuss the goal—the reason companies are looking
to become cloud native enterprises. Second, we’ll look at the three types of organizations we often
encounter and how they’re crafting their cloud native strategies. In future articles within the series,
we’ll look at technical and architectural concerns that arise, how those concerns are addressed,
and many other aspects of the cloud native journey. My hope is that you can use this overview to
understand why the “journey” matters, what it looks like and how to start planning for the journey to
becoming a cloud native enterprise.
The Goal: Shorter Cycles To Increase Quality And Grow The Business
Our customers want to use Pivotal Cloud Foundry to improve how IT is used within their organization.
To run and improve their business and their customer experience, they must become really good at
writing and managing their own software. To do this, they are looking to improve the quality of the
software life-cycle—from thinking of a new idea to developing it to running it in production. As Andy
Zitney of Allstate puts it, their goal is to think of a new software idea on Monday and have it running in
production by Friday.
I like to reduce the goal down to speeding up the software delivery cycle, as shown in a diagram I use
a lot:
Continuous Delivery Pipeline
Infrastructure Production
Version Test/Verify Package Concerns
Specify Code Control Build Platform
repository (monitoring,
(laaS, PaaS, VMs)
scaling, ect.)
Feedback Loop
Your goal is to make moving code through that pipeline, safely and reliably, as quick as possible. A
good goal is every week, but, if you can master small batches and put in all the process and
technology rigging needed, you should shoot for daily deployments.
This is the goal to keep in mind as the short and medium term goal for your organization—reducing the
full cycle time it takes to get new features into production. The long term goal is to improve not only
the quality of your software delivery process, but the quality of your business.
APPENDIX B – WHAT KEEPS YOU UP AT NIGHT?

Cloud-native patterns and practices can help you release high-quality software faster. This in turn,
helps your business get a leg up in the market. How can these new methods apply to your business?
What opportunities, challenges, and threats can better software help you address?
Four key areas stand out, based on our observations.
INDUSTRY TREND CLOUD NATIVE ADVANTAGE
Rising consumer expectations. Consumers now With a cloud native application, the priority is an
expect always-on access to your products and API-first design. Developers can deliver features to
services. They want to apps with real-time data users across across many devices. Great APIs also
delivered across many different devices. They want deliver a zippy user experience.
self-service. This can be a challenge, especially for
companies that still run legacy tech up and down the
stack.
Increased competition from startups. Software Three things help you become a software-defined
is eating the world! Startups are gaining market business. First, a microservices architecture. This
share on the strengths of their software. They can encourages rapid iteration, and small changes to
rapidly improve it based on customer feedback. discrete components of a system. Next, continuous
These startups have many advantages compared to delivery gives developers a frictionless path to
incumbents. A better culture, leaner processes, and a production. This leads to frequent deployments
lack of technical debt to name a few. We’ve seen this of small changes that add up to big benefits over
disruption pattern play out in many industries the last time. Finally, a DevOps culture eschews traditional
5 years, and it’s likely affecting your business right developer and operator roles and objectives. Instead,
now. the goal is to deliver value to the customer.
INDUSTRY TREND CLOUD NATIVE ADVANTAGE
Regulatory requirements & compliance. IT systems, Cloud-native approaches prize automation and a
processes, and applications need to keep pace with “security-first” approach to feature design. These two
a tidal wave of industry regulations and compliance points are crucial to compliance. Highly automated
standards. That demands significant time, attention, systems log every activity. It’s easy to see what
and budget. changed, when, and who triggered the update.
Further, automated systems can be rapidly patched
and updated with new bits often. And automated
systems generally need much less day-to-day human
involvement, boosting security.
“Security first” means that engineers design security
into features from the start. They are not bolted on
later.
Security. The threat landscape is constantly evolving Conventional wisdom within enterprise security
and changing. Your organization must contend with circles advises “go slow to reduce risk. In the
malware, advanced persistent threats (APTs), and the cloud-native world, it’s “go fast to reduce risk.” Why?
specter of leaked credentials. Systems that change often are far less vulnerable to
malware and other threats. Static environments are
where bad actors thrive, and wreak havoc on your
enterprise.
Use automation to rapidly apply the latest patches to
systems. Embrace immutable infrastructure concepts
and re-deploy your stack to a “last known good state”
often. And rotate credentials often, so that any leaked
creds quickly expire and become worthless.
You can capitalize on new market opportunities faster with a cloud-native practices. Compliance can
be more easily achieved with highly automated application delivery and operations. And you can
improve your security posture with concepts like immutable infrastructure.
APPENDIX C – HOW DO PIVOTAL CUSTOMERS GO ABOUT

BECOMING CLOUD NATIVE? IT STARTS WITH A PLATFORM.
Many companies adopt self-service platforms to help teams deliver software continuously. Why?
A platform provides a consistent, predictable, and secure way to deploy and run apps. Platforms
deliver crucial features to developers in a unified self-service model.
In other words, platforms hide the messy details of a very complex set of IT capabilities. At its best, a
platform is the boring and reliable presentation of all the features your teams need. Capabilities are
accessible in a way that is fast and simple for its consumers.
Platforms provide these capabilities as fully-automated “dial-tone” that just works. Every application
team can easily consume platform services on their own.
You can imagine the economies of scale with platforms. The more apps you run on a platform, the
more efficient it becomes for the organization, and the more value it provides.
When an organization goes “all in” on the right cloud-native platform, everyone wins. Developers,
operators, and finance teams all realize massive gains.
ABOUT PIVOTAL
Pivotal’s cloud native platform drives software innovation for many of the world’s most admired brands.
With millions of developers in communities around the world, Pivotal technology touches billions of
users every day. After shaping the software development culture of Silicon Valley's most valuable
companies for over a decade, today Pivotal leads a global technology movement transforming how
the world builds software. www.pivotal.io
ABOUT MICROSOFT
Founded in 1975, Microsoft (Nasdaq: “MSFT”) is the worldwide leader in software, services and
solutions that help people and businesses realize their full potential. Microsoft offers the Azure cloud
computing platform, a growing collection of integrated services—analytics, computing, database,
mobile, networking, storage, and web—for moving faster, achieving more, and saving money.
azure.microsoft.com
Pivotal, Pivotal Cloud Foundry, Pivotal Cloud Cache, and Cloud Foundry are trademarks and/or registered trademarks of Pivotal
Software, Inc. in the United States and/or other Countries. All other trademarks used herein are the property of their respective owners.

Pivotal Cloud Foundry and Microsoft Azure Reference Architectures For Cloud Native Applications

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pivotal Cloud Foundry and Microsoft Azure Reference Architectures For Cloud Native Applications

Uploaded by

Copyright:

Available Formats

Pivotal Cloud Foundry

& Microsoft Azure:

Infrastructure Services Virtual Network............................................ 5 Considerations for High Availability

Application Services Virtual Network................................................ 6 Peer Replication with Service Registry....................................... 20

Routing Site Selection........................................................................17

PIVOTAL CLOUD FOUNDRY: PLATFORM & SERVICES

Spring Cloud Platform API TCP Router HTTP Router Gorouter

Azure SQL Diego

Figure 1 – An overview of selected Pivotal Cloud Foundry components.

Let’s review each item in Figure 1.

Infrastructure Services Virtual Network

Elastic RunTime Virtual Network

• Diego. Diego is the container orchestrator for Pivotal Cloud Foundry.

Application Services Virtual Network

HOW THE PLATFORM SUPPORTS COMPLIANCE & SECURITY

ϐϐ Repair. Repair vulnerable software as soon as updates are available.

ϐϐ Org. An org is a development account used by an individual or a team. Collaborators access an

SPRING CLOUD SERVICES & STEELTOE

Config Server for Pivotal Cloud Foundry

App A App B App C

Figure 3 – Config Server for Pivotal Cloud Foundry.

Service Registry for Pivotal Cloud Foundry

Figure 4 – Service Registry for Pivotal Cloud Foundry.

Circuit Breaker Dashboard for Pivotal Cloud Foundry

Figure 5 – Circuit Breaker for Pivotal Cloud Foundry.

Microservices for .NET with Steeltoe

Steeltoe includes three modules:

Reference Architecture: Logical

LOGICAL INFRASTRUCTURE: MICROSOFT AZURE IN THE

Public IP Public IP Public IP

ALB ALB ALB ALB Each ERT Job

Ops Jump Availability Availability Availability Availability Availability

Go Diego TCP My Other

Azure Resource Group 01 Storage Accounts

Availability Sets in Microsoft Azure

Figure 7 – Configuration with availability zones

In Azure, the same set of VMs are laid as shown below:

Figure 8 – Configuration with availability sets.

ϐϐ One for an Optional TCP Routers, if selected

ϐϐ One for Ops Manager

Pivotal Customer0 ingress egress 1to1_nat

Rule Name: Ports: Source>Dest Action:

Network Security Group (Applies to All Network Interfaces)

Availability Availability Availability Availability Availability

“Services-#” /22 “Dynamic Services” /22

Resource Group 01 / Virtual Network

Further Guidance: Microsoft Azure

Here are four areas to keep in mind for this scenario.

Pivotal Data Store Pivotal Pivotal Data Store Pivotal

Routing Site Selection

active-active as real-time HA. Active-passive is a configuration where some lag in consistency or

Support for Azure Stack is planned.

Reference Architecture: Applications

• A modern approach to real-time data processing

Discovery Edge Gateway with OAuth2

Event Store with

REFERENCE ARCHITECTURE COMPONENTS

CONSIDERATIONS FOR HIGH AVAILABILITY

Distributed architectures thrive on asynchronous, message-driven communication between

PEER REPLICATION WITH SERVICE REGISTRY

A West PCF East PCF A

Figure 12 – Multi-site peer replication for service registration.

Once peer replication is enabled, development and operations teams enjoy: