Re: [IMPORTANT] 2017 PaaS Certification Requirements
One moretoggle quoted messageShow quoted text
From Hewlett Packard Enterprise point of view, we do not believe it is in the best interest of the Cloud Foundry project or the Cloud Foundry community to have a single, mandatory deployment solution.
· That the project needs a development standard, we fully agree with, that is what BOSH is today.
· Today, Cloud Foundry certification already dictates the use of the shared Cloud Foundry kernel (see https://www.cloudfoundry.org/use/cloud-foundry-certified/certification-requirements/), adding a mandatory deployment model on top of this, makes it that all Cloud Foundry distributions will have to be the same. Not only does this create a nonviable business model; customers demand choice, specialization and customization to fit their needs and environments. These forces are at the opposite ends of each other, where the customer will always win, meaning that there is no value in certification when approached as such.
· On the technical front BOSH is not the Swiss army knife we are made to believe. Its complexity makes it loved by consultants and services organizations for obvious reasons. But BOSH is not what the customer is buying, the customer wants to run Cloud Foundry, build 12-factor apps, using the Heroku workflow. The objective should be to install a Cloud Foundry cluster in hours or less, with the least amount of friction, using the infrastructure of choosing, which can be a VM instance or a container running on bare-metal. The fact that Pivotal created PCF Dev https://docs.pivotal.io/pcf-dev/ is another indicator that one deployment solution does not solve all needs.
· BOSH has a broader application then just deploying Cloud Foundry, tying the two together is a disservice to the BOSH project.
With Stackato v4.0 we demonstrated one can create a fully containerized Cloud Foundry deployment hosted on Kubernetes, deriving it from the BOSH manifests. (See https://github.com/hpcloud/fissile)
The important in the above statement, is that the value is in the manifest, not in the BOSH director or agent. Which gets us to the need of contract based certification, using API contracts and manifests, not implementation.
Gert Drapers (gert.drapers(a)hpe.com<mailto:gert.drapers(a)hpe.com>)
VP Engineering – Helion Cloud Native Application Platform
701 Pike St. Suite 9000
Seattle, WA 98101
On Nov 1, 2016, at 10:46 AM, Chip Childers <cchilders(a)cloudfoundry.org<mailto:cchilders(a)cloudfoundry.org>> wrote:
On Mon, Oct 31, 2016 at 3:39 PM Dan Young <dan.young(a)engineerbetter.com<mailto:dan.young(a)engineerbetter.com>> wrote:
Thanks Bernd, you make some very good points, including this one:
• Interoperability of CF deployments on an API level is an important property, at the level of what’s exposed to a developer using CF; I’m not sure that interoperability on the “platform operations” level has the same priority at this point in time with many of the underlying infrastructure pieces moving quite rapidly
In Chip's first response to Dr Nic he said, 'the certification process for offerings isn't about experimentation in the ecosystem. It's about consistency across the distributions.'. This struck me as interesting because I always thought there was a strong, implicit connection between certification and the ecosystem. CF certification is a powerful concept that benefits both user and vendors. If you turn up the dial on certification requirements you improve consistency, but the inevitable trade off is a reduced space for competition and ecosystem growth.
Your point here about timing is, I think, particularly astute. The Foundation finds itself faced with a similar decision to that of a central bank trying to decide when to raise interest rates. The CF user experience is sacrosanct, but the timing of whether to introduce mandatory BOSH for deployment is crucial given the existence of non BOSH-based vendors, the size of the CF ecosystem, overall industry context and pace of change at the infrastructure layer.
Timing is always the challenge with anything like this. ;-)
If feels that this conversation has died down here on the list now. Hearing multiple perspectives has been really useful. To all those that shared thoughts, thank you! We need to continue to have more discussions like this on-list... even when it might feel uncomfortable at first.
In my personal opinion, based on the input from this discussion, 2017 doesn't appear to be the right timing for the overall ecosystem to require BOSH. I'll present that opinion (along with all of the comments in this thread) to the PMC Council when we move the requirements through to a formal vote there.
CTO, Cloud Foundry Foundation