On Friday, my brothers and sisters at Dell EMC made the first release of a Pivotal Ready Architecture available.
Put simply, the Pivotal Ready Architecture (PRA) brings together:
- a multi-cloud/hybrid-cloud and cloud agnostic application framework, container, and function platform (Pivotal Cloud Foundry) that dev teams love and couples it with…
- a modern, efficient, software-defined HCI developer-ready infrastructure platform (VxRail), which is a turnkey instantiation of the VMware stack in engineered system form that infra and ops teams love.
There is NO easier way to accelerate building better apps, in better ways, on infrastructure that fades into the background.
Why? Because the Pivotal Ready Architecture takes the best enterprise app/container platform – and couples it with the industry’s best software compute, storage and network abstractions (VMware), the industry’s best x86 building block platform (Dell EMC PowerEdge) all – tightly integrates the stack with lightweight but effective life-cycle management capability.
We know that while many customers demand openness at every level, and many choose to build their own stack – with each passing day, they want an easy button – the ongoing transition from construction to consumption that I’ve talked about here and here.
The PRA effort is to deliver an opinionated on-premises instantiation that is simple, and easy to deploy and lifecycle. Like PKS (which is a joint VMware/Pivotal effort) the PRA is a combined Dell Technologies effort.
This friday marks the the first release of something we will persistently continue to work to refine – making the best on-premises platform for developers simple enough to love, automated enough to consume versus construct.
Here’s a little love haiku to the Pivotal Ready Architecture and the teams that work so hard on it.
Modern infra that just works
Where can you go if you want more info?
- The people to contact if you want more info on the Pivotal Ready Architecture are the VxRail experts at Dell EMC (Modern Datacenter Specialists), the Cloud Native specialists at VMware.
- There are weekly enablement webcasts going on (last week’s sizing/configuration call was great with the one and only Mo Khalid). I’ll make sure these are open to anyone.
- If you’re a Dell EMC employee – the landing page on Inside Dell is here. You can find all sorts of documentation there.
- If you are stuck and just need a hand – email AskPRA@dell.com
There is a LOT more to the Pivotal Ready Architecture – so read on past the break for more detail, patterns for common deployments (single/multi-AZ, multi-foundation, HA models), as well as where the team is going to go next!
An additional way to think of PRA as a BOSH reference architecture.
BOSH is the critical layer that underpins Pivotal Cloud Foundry – including the Pivotal Application Service (PAS), the Pivotal Container Service (PKS) – and in the future Pivotal Functions Service) as well.
BOSH along with the the embedded OS, and deep NSX-T and vSphere integration is an essential part of what we’re doing to make infrastructure that developers will love, and make IT heroes once again to people building cloud-native applications.
The BOSH layer also abstracts the interfaces to all of the underlying IaaS layers – and creates an open, multi-cloud model.
That said, it’s important to note – the best on premises deployment model is vSphere – period. The vSphere CPI is the most mature, and the most widely deployed by a large (!) margin. We saw a little pop-up of OpenStack use, but this declined in the enterprise pretty quickly as people realized the sustaining complexity was harder than they expected.
An example of how “the infra layer does matter” is the NSX-T integration across everything Pivotal. This is also a huge deal, a topic that even healthy skeptics are realizing, and customer are telling us every day is critical, particularly for container use cases. With app framework use cases, the infra layer is less visible – but container workloads and use cases often have more infra dependency (streaming use cases, data layers that specify specific logical network topologies, etc).
Put that the CPI and NSX-T topics together – and you can see why VMware is the right on premises choice. Then the next step is to make the Pivotal Cloud Foundry + VMware integration simple, complete and turnkey. THAT is the PRA purpose.
The team on PRA have completely implemented the best practices that are essential in where BOSH mates to the infrastructure layer (via the Cloud Provider Interface) in several key areas – simplifying so you don’t need to think about them:
- Network made SIMPLE. Key steps for implementation of the four isolated networks supporting the concepts outlined in the Pivotal RA for vSphere but with key customizations specified for VxRail, including guidance on the network adapter configuration, hardware ordering and ToR requirements. VxRail can work with almost any network switch vendor – but we’ve made ordering with standard configurations with Dell EMC’s leading open network ToR and management switches simple. The PRA sizing tools will automatically guide you on components needed to make the solution work. Everything is validated as working with NSX-T as needed. Beyond the physical layer, PRA prescribes the correct set of networking dependencies between the isolated networks, including port level communications requirements. In addition, PRA includes a tool called the Site Survey tool that will validate connectivity to the port level for various SoR dependencies (DNS, time, S3 endpoints, etc) – something we’ve learnt is a key step before standing up PCF.
- Common PCF deployment patterns made SIMPLE. The PRA enables customers to deploy single or multiple-AZ deployments of VxRail that we have tested and validated. The Multi-AZ PRA guidelines prescribe precise requirements for the VxRail networking within the rack, as well as the east-west requirements for network traffic between the racks. This can be adapted to modern datacenter networking designs with Spine/Leaf architectures or to more traditional core oriented designs. Customers can implement the AZ’s to match their HA requirements – separate datacenter zones (Rack-level HA or cluster-level HA), collocated, or a mix. And of course – we plan for multi foundation deployment models.
- Object storage made SIMPLE. The PRA includes prescriptive guidance for object storage – DellEMC’s elastic cloud storage, or Virtustream Storage Cloud. While you can absolutely use any S3 object store with PCF (including the native Pivotal blob store on vSAN embedded in VxRail), it’s important to recognize the importance of object storage in developer-centric use cases, and developer-ready infrastructure. S3 is a core dependency for a full-fledged multi-AZ implementation of PAS, and a very useful dependency for the Harbor Docker Registry with PKS – employing ECS also opens up options for geo-replication of buckets for application data as well.
Now, app-centric dev readers, and perhaps some of my new Pivotal brothers and sisters may be asking “does the infrastructure matter?” Answer = hell yes.
I’ve talked about NSX-T and BOSH, but it’s worth one more double click on this.
When you deploy PCF on a public cloud, someone is taking care of all sorts of stuff for you that you don’t know about. Everything under the CPI layer is “magic” or at least “behind the curtain”.
But anyone with experience being “behind the curtain” knows that “magic” is just great technology and ops and automation being implemented by people perfectly – all working correctly.
Sure BOSH nicely abstracts infra – but if the infrastructure layer doesn’t mean certain minimums, or is too rigid to expand easily, or is fragile, or is hard to update – well you end up with a very “non cloud like” experience for the PCF workloads that are deployed on premises.
The “everything will be in the public cloud” pendulum has started to swing to a more pragmatic position, and we’ve all started to figure out that some workloads belong on the private, on-premises part of the multi/hybrid-cloud world we live in. So – how can on-premises infra approach the simplicity/agility of the public cloud model? Ergo how do we make the stack below the CPI better operate with the same “magic” as the public cloud models?
Nothing slows down “developer innovation/agility” and takes out all of the fun of “building software that people love” like infrastructure that sucks, or is rigid, or difficult to scale/update. I have seen this at customer after customer.
Still struggling with the question of “why the infra layer” matters? Ok, let’s use an analogy. Think of it this way – Pivots are used to the idea that things like BOSH, an embedded standardized lightweight OS, NSX-T, Ops Manager, PivNet, Concourse and other things make the PCF a platform you consume vs. construct… All so that people can “focus above the value line”.
VxRail and the tightly integrated VMware stack makes the infrastructure layer something you consume instead of constructing, so that you can “focus above the value line” at the developer-ready infrastructure layer of the stack.
Customers don’t manage the parts of the hardware components with VxRail, but instead use the HCI features of VxRail Manager to push updates into the IaaS. VxRail is completely aligned with the VMware stack, and makes it as simple as an “on button”. Like PCF, scaling the infrastructure up with VxRail is easy due to vSphere, vSAN, and VxRail manager (very unlike traditional hardware that is the common underpinning stack on PCF deployments).
Pivotal Ready Architecture can start SMALL and SIMPLE. You cannot build simplicity on top of complexity. You can deploy on almost all the VxRail node types (only not G series – as they don’t have enough physical NICs by default):
The minimal PRA deployment is downright SMALL. 4 VxRail appliances, ToRs, management switches is all that’s needed for a single AZ, node HA, and using the native blob store on top of vSAN. This can happily support 150+ PAS Application instances and many PKS Kubernetes pods.
But – it can be BIG too. PRA can scale to large configs with 1000’s of PAS application instances and PKS K8s pods. Scaling is out is simple – more VxRail nodes, and using VxRail manager to add nodes (takes minutes). Not quite as simple as a “cf-scale” – but as close as you can be when you’re talking about physical/logical infrastructure.
It’s flexible as well – PRA supports deployment patterns that include multi-site, multi-AZ, multiple PCF foundations, and additional services like Pivotal Cloud Cache:
Sizing is simple.
Start with the Pivotal Cloud Foundry sizer here.
As you put in your expected AI count, along with additional services (Redis, MySQL, RabbitMQ, etc) you may use, the sizer will output the physical and virtual dependencies for CPU/RAM/Storage.
The inputs go into the VxRail sizer, which has PCF workload options (you can get that at the VxRail enablement center here). In the VxRail 4.5 sizer, you’ll see PCF as a workload type. Ensure that the cluster configuration will be able to exceed the base requirements.
Then – make sure you evaluate for other workloads, multiple foundations on the same stack, as well as multi-AZ and HA (failure condition handling for things like rack-failures).
All of these are covered in the Pivotal Ready Architecture sizing and deployment guides.
Above and beyond what’s in the PRA – there’s a rich ecosystem of tools, and 3rd party capabilities. A short list of examples:
- Monitoring and Logging tools for optics of the entire Architecture with vROPS + Log Insight + Blue Medora.
- Tool and Services from Pivotal like HealthWatch, Bosh Backup and Restore, IPSec and more from Pivotal Marketplace can be leveraged to manage the platform.
- Platform Automation using Concourse provided by Pivotal Cloud Foundry where updates and upgrades of PCF can be automated via pipelines.
- … and I know that there are really cool PKS 3rd party integrations coming from the broad data ecosystem (imagine MongoDB, Cassandra all as simple PKS container packages) and APM (lots of cool stuff from New Relic, Dynatrace, App Dyanmics and more).
Now – this is the first PRA release. What’s next?
- Next major update will further quantify and simplify PKS and NSX-T use. This first release focused on the PCF 2.0 release, and the PKS 1.0 release was in Feb. Now I want to be crystal CLEAR. PKS 1.0 and NSX-T work on VxRail RIGHT NOW. It’s just that the sizing, deployment guides and documentation are focused on the Pivotal Application Service for this first release. Expect more on this front shortly “built in” to the Pivotal Ready Architecture. If you need PKS and NSX-T right now, you can move forward with confidence validated to work), but should engage your VMware, Pivotal, and Dell EMC friends to ensure you get their input for sizing and configuration.
- You’ll note that we don’t target VMware Cloud Foundation for the Pivotal Ready Architecture in this PRA release – only VxRail. This isn’t an accident. You can absolutely deploy PCF on VMware Cloud Foundation and VxRack SDDC, but there are some gotchas. Currently covering multi-AZ use cases can drive to more infra than would normally be needed, and only NSX-V is supported on ESXi hosts in a VCF/VxRack SDDC deployment. As teams, we are working on it. For now – keep things simple, VxRail is the PRA base platform.
- Customer input will rule the day – but I expect a lot of “help me with these _____ ecosystem partners” (and in particular the data/APM ecosystem are where I expect the most intersection).
- Today, the automated CI pipeline for platform updates for PCF with concourse is great, but requires a services engagement to help stand up. I dream that one day we’ll get to the point where a PRA deployment will be totally hands off – and we’ll automate the CI pipeline to the point where it’s as simple as the “get your VxRail in days” experience.
I think that making things that customers LOVE is exciting, and fun – it’s not easy, but it’s worth it. It also means challenging customers’ instincts to build things that are less valuable.
Pivotal Cloud Foundry helps customers build software that devs love.
VxRail powered by VMware helps customers have infrastructure that is invisible and keeps PCF happy, and the infra/ops team will love.
Love * Love = (Love)^2.
Congrats to the team that has been working so hard on this. Dear readers, I would love your input – comments always welcome!