The most interesting thing about technology conferences is that they give the opportunity to hear from real-world technology users. Such was the case at the recent Cloud Foundry Summit in Basel, Switzerland, during which a whole host of large enterprises took the stage to talk about how Cloud Foundry is an integral part of driving their digital strategies.

One case study, in particular, was fascinating for a number of reasons. Fidelity uses Cloud Foundry for a bunch of different applications including retail websites and trading systems. Cloud Foundry powers applications across both the UK and Asia for Fidelity. As such, it’s a great win for the Cloud Foundry project. For me what was even more interesting, however, was to hear from one of Fidelity’s PaaS engineers, Rachael Wonnacott. The fact that Wonnacott is only a recent graduate, and only has a couple of years operating Cloud Foundry belies the expertise she has built up. It is also, without wanting this to sound like a marketing message for Wonnacott herself, an example of how a smart, young, innovative and open-minded technologist can fundamentally change the way an organization thinks and works.

In her talk, Wonnacott detailed how Fidelity was a customer of a particular commercial distribution of Cloud Foundry but has recently completed a migration from that vendor’s platform to the open source version of Cloud Foundry. The case study was interesting both from the perspective of the process Fidelity used, but also the fact that it raises some questions about the commercial Cloud Foundry distributions and their long-term opportunity.

Keeping the car going while changing the wheels

As mentioned earlier, Fidelity already had applications running on Cloud Foundry. As such, the move to the open source version could potentially have had deleterious impacts. The way around that conundrum? Fidelity ran two Cloud Foundry’s in parallel and migrated applications as they were stable and reliable on the open source version. And with a requirement to offers a six-9s SLA, stable and reliable is serious business.

But other than the obvious requirement for stability and reliability, a key driver for Fidelity’s cloud strategy has been to do transformation within the context of cost-effectiveness. It’s a refreshing message, all too often we hear of traditional digital transformation projects which entail massively expensive and time-consuming technology projects to achieve – while Fidelity has obviously spent significantly on its technology solutions, it has done so through a lens of value for money.

This is, it would seem, much of the driver for the move from the commercial product to open source. Someone within Fidelity obviously had a well thought out plan for their Cloud Foundry initiative: firstly to rely on the fully-featured commercial distribution, and gain comfort from having “one throat to choke.” But to progress from this model once staff were comfortable, once internal processes were reliable, and once there was sufficient internal capability to do things independently.

Essentially it’s a case of seeing a commercial vendor not merely as a provider of a service, but as a rich source of IP that the organization can gain by osmosis. Fidelity was obviously very intentional about not building dependency upon their commercial partner, but rather sucking as much knowledge from that commercial partner to enables successful separation.

Is Fidelity an outlier?

Let’s face it, for every organization that builds teams to manage an open-source platform itself, there are dozens who rely on the comfort-factor that having an external commercial vendor offers. Was Fidelity somehow an outlier? Were they of such a scale that they could hire a team as big and competent as that which the commercial vendors have? On the former question, absolutely yes. While I didn’t talk with other members of the Fidelity team at the summit, the fact that their one of their young employees was talking about the subject, and not a wizened old technologist speaks hugely to a culture of meritocracy and openness. I got the feeling that Fidelity lives and breathes the sort of nimbleness, agility and DevOps culture that others aspire to.

But on the second question, that of economics and team size seemingly not. Fidelity made the move to open source with zero increased headcount. Sure, they leveraged some external consulting resource to help with the shift – but with no net gain in human resource, and a massive (seven figures, although not detailed the size of that seven-figure sum) cost saving moving from a commercial product, this is a serious case study of how open source can really drive value.

The dissenting view

Luckily, Fidelity’s was the first user presentation I went to and I followed up this attendance by seeing what Air France/KLM and Rabobank, both Pivotal Cloud Foundry (PCF) customers, had to say about their experience. In the case of AFKLM, they are still at very early stages of their Cloud Foundry journey and don’t have any internal competency themselves. AF-KLM’s speakers at the event, Fabien Lebrere, and Nathan Wattimena, talked much of how the decision to use Pivotal was equally about the technical capability that Pivotal bought to the party as well as it was about culture-change. AFKLM obviously had some big legacy processes and cultural aspects it needed to change, and they rightly determined that they couldn’t do that themselves.

I do worry a little about relying on a technology vendor to facilitate culture change within an organization – the two things, while connected, are different and, let’s face it, technology vendors don’t have a natural inclination to help customers quickly move to a position of dependence. I’m not saying that vendors such as Pivotal intentionally build dependency into their interactions with customers, but if your metric of success is ongoing revenue, there’s not huge motivation to build independence.

AF-KLM’s change project was far broader than simply a PaaS. It truly is an innovation and transformation project that is seen as a global initiative and includes aspects such as CI/CD, infrastructure choices as well as the overarching agility factors needed to drive innovation.

With all of this said, I asked the AFKLM presenters what their perspective was on the Pivotal versus open source Cloud Foundry subject. While their response was that there was no appetite to “do” Cloud Foundry themselves at the start, they perceived a point in time when they would have the comfort and capability to make the switch. Essentially the message was that going with Pivotal was about risk-reduction and, over time, that could change.

Rabobank banking on partner-driven enablement

I also attended a session in which Rabobank talked about their own technology transformation process. Rabobank has a long history of enabling their customer through digital touchpoints but recently realized that innovation was hampered by their then approach of J2EE and WebSphere. The company decided to make the move to a new platform, built on top of Cloud Foundry. This platform will support their move from waterfall to agile to DevOps, as well as core technology requirements such as new languages and microservices architecture.

Like in the case of AFKLM, Vincent Oostindie from Rabobank explained that they used Pivotal Cloud Foundry to give themselves the confidence as well as the security of a “single throat to choke.” As Oostindie said to me in response to a question around PCF versus opens source:

We wouldn’t have ever just picked up the open source components and put it together ourselves. We relied on Pivotal in these early stages.

However, here is where it gets interesting when I asked him to crystal ball gaze to think whether, in a  couple of years Rabobank will still feel a need to pay for the comfort-factors that Pivotal brings them, he as unsure. It seems that all the customers are thinking about an engagement that sees them build up capability before making a switch to home-baked (i.e. cheaper) options.


Don’t get me wrong, the vast majority of end-users who I spoke to at the summit are customers of Pivotal (which, itself, raises some questions about if any of the commercial distributions outside of PCF are of any relevance). Pivotal is certainly doing a good job of helping these organizations build transformation on top of PCF.

But helping them today doesn’t equate to building long-term value, at least when it comes to contrasting PCF with the open source version of the platform. If the vendors I spoke to are anything to go by, there is a very real chance that Pivotal will enjoy a few years of good revenue from these customers, only to see them move to the open source version over time.

It will be fascinating to see how the commercial distribution vendors respond to this risk and what they do to build and provide ongoing value to their customers.lou

Ben Kepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.