Pivotal Cloud Foundry (PCF) is the leading PaaS solution for enterprise customers today, providing a fast way to convert their ideas from conception to production. This is achieved by providing a platform to run their code in any cloud and any language taking care of all the infrastructure “stuff” for them.

From building the container image, compiling it with the required runtime , deploying it in a highly available mode and connecting it to the required services, PCF allows dev shops to concentrate on developing their code.

While the platform is providing developers with the most simplified experience conceivable, under the hood there are many moving parts that make that happen and plumbing all these parts can be complex. That’s where customers are really enjoying the power of VMware’s SDDC, and the glue between the PaaS and SDDC layers is NSX, it is the enabler that makes it all work.

In this blog post I detail some of the main uses cases customers have already deployed NSX for PCF on top of vSphere and how PCF and NSX are much better together in the real world.

The use cases customers are deploying with NSX for PCF are varied and ill divide them into 3 main categories:

  1. Security and Isolation
  2. Day 1 operations
  3. Day 2 operations

Security and Isolation

When customers are deploying PCF on traditional infrastructure and want to secure and isolate either a PCF Foundation from another Foundation (PCF deployments are called Foundations) or some deployed applications from the rest of the application running on the platform, usually they will have to use a physical Firewalls to do so. That creates operational and performance challenges.

From an operational perspective, the physical firewalls are managed separately from PCF and by different teams, every new application that requires a level of compliance and isolation, needs to be set up in multiple physical firewalls. That can slow down deployment of apps immensely and contradicts the whole purpose of buying in to a PaaS such a PCF that its main driver is speed and agility. We have customers that use physical firewalls today and are either already migrated or looking to migrate to NSX to remove the shackles from their development operations.

NSX provides an ability to manage policies dynamically based on BOSH managed NSX groups, BOSH is part of PCF responsible for deploying VMs, monitoring their health, configurating and managing their day 2 operations, and it automatically populates those NSX security groups that it creates with membership of the PCF components. These groups are then can be used in the Distributed FW (DFW) rules and policies. See here the NSX security groups created and managed by BOSH:

Screenshot of teh BOSH managed NSX Security Groups

 

 

These DFW policies provide isolation and control between applications segments and between PCF internal components in highly secure environments.

From a performance point of view when packets are sent to be inspected at the physical FW the network flow is slowed down and sent up the stream, which in many case can be multiple hops away and back. This is sub optimal to say the least as It elongates the time of communication and can add harmful latency. The more an application scales and the more it is network sensitive the more this becomes a problem. Here’s a simplified representation of such topology where the physical FW is a shared resource and the implications on internal platform communication:

Internal Communication flow with a Physical FW

 

With NSX we can use the DFW to inspect the packet at the vNIC level of the source and destination VMs where the application instances (containers) run. If the NSX load balancer is also being leveraged it removes a lot of the hopping north bound and provides a much better performance and much more flexible design. We can now create PCF Isolation segments and place applications there to isolate them easily from the rest of the pack which is also helpful for compliance purposes as well while creating policies to control access between different components of PCF and provided services that are inspected at the source.

The following image is a representation of where the enforcement is done at the source and not up in a physical FW:

DFW protecting a PCF Foundation

 

Another use case that can be  much simplified with NSX and provides performance benefits is the ability to isolate foundation from foundation on the same hardware using logical edge gateways, for example having a test foundation separated from prod and controlled with ACL to each one. By doing so our customers gain much stronger control on access to each foundation and because it is a logical FW not only we can control its placement in the physical topology in relations to the Load balancer, switch and routing layout, or putting it closer to the workloads, combined with vSphere it provides a simple way of utilizing hardware much better.

In the following diagram is the logical representation of a customer implantation where 3 foundations are sharing the same hardware, and isolated by resource pools and logical firewall

Multi-Foundation Multi-Rack

 

 

In addition to all of that goodness I have detailed above, by being able to create virtual network switches and networks in software out of thin air allows us to isolate different components of PCF like services, isolation segments and deployment networks from one another easily and to set the topology based on the applications requirements. For example, at one customer they deploy one foundation for a high performance high security app with one logical configurations that includes a switch for every service and separate LB constructs while for the rest of the applications they have shared networks and shared LB VIPs etc.

There are many more design choices customers choose to deploy side by side due to the logical nature of the SDDC and I’ll detail that in another blog post.

 

Day 1 automation

As I previously mentioned, PCF simplifies the life of the developers while under the hood it can be quite complex, it requires IPs for the dozens or even hundreds of VMs a foundation is compiled of, load balancing configuration and FW rules. With NSX we can simplify all of that by using automation (NSX is software based and programmatically controlled) and by being able to utilize virtual NAT GW to deploy overlapping ip schemes if customer chose to.

Deployment time of a new foundation can be reduced from a matter of weeks to hours with much less room for human error. Here is an example of a deployment model where NSX is laid out automatically and PCF on top in a matter of a few hours using concourse pipeline. Security conscience customers can build their own automation easily for their own consumption. This is a ling to the NSX/PCF automated Pipeline github page https://github.com/cf-platform-eng/nsx-ci-pipeline

Deploying PCF and NSX automatically using the Concourse Pipeline

 

Day 2

As mentioned above day 2 is one of the main reasons why customers choose PCF and NSX separately. With the integration between BOSH and NSX introduced in PCF 1.11, BOSH creates NSX security groups and automatically populates them with PCF internal jobs. These groups are than used for DFW source and destination configuration as explained above but also for the NSX load balancing pools, that means that the security groups are nested in the resource pools. When there is a need to scale a load balanced component like the Go routers who provide access to the applications internally, The added resource would be added to the NSX security group and consequentially to the load balancing pool. Automatic scaling of the NSX load balancer based on scaling of PCF. This is also very helpful when creating new Isolation segments and scaling those as well.

Autoscaling the LB using BOSH managed Security Groups

 

As you can see NSX provides the required design flexibility which enables many use cases for our customers. This shows how valuable the SDDC is for the application transformation to enhance agility, security and operations of PCF using NSX.