Re: [IMPORTANT] 2017 PaaS Certification Requirements

Iovanov, Vlad Mircea

Regarding a consistent operator experience, I believe it will differ with or
without BOSH being a requirement for certification.
Some vendors will choose to add layers on top of BOSH, to improve UX, much like
what Pivotal is doing with the Pivotal Operations Manager.
So, in a sense, we can look at the common bits of CF as a kernel, from which
you get distros. If I'm Red Hat certified, it doesn't mean I can transfer all
my knowledge to Ubuntu.

From an architectural perspective, I think it's a mistake to further couple BOSH
with Cloud Foundry. During our CF containerization work, we've found that has
already lead to bad coding practices. I am referring to ERB templates and tight
coupling to monit.
But BOSH does have great primitives. It prescribes how code needs to be
organized, built and configured. That makes the codebase great for
experimentation with other deployment mechanisms and strategies.
For that reason, I think using the BOSH release as a form to package the
certified code of Cloud Foundry is a good idea. But using BOSH to deploy Cloud
Foundry would cut off the drive to experiment. Which means that no one will pay
attention to the problems that come from tightly coupling the two systems.
Furthermore, BOSH is a deployment mechanism for the VM world. Given the current
investment of the industry towards containers, why are we trying to further tie
Cloud Foundry to a VM-based infrastructure?

On 10/28/16, 11:04 AM, "Topnik, Troy" <troy.topnik(a)> wrote:

It's important that this community understands that the *inclusion* of BOSH in the 2017 certification would *exclude* the Stackato and ContainerCF distributions which were certified in 2016, possibly others. This draft moves the goalposts significantly.

Quoting Chip:

> It's about consistency across the distributions. Requiring BOSH as the
> deployment method gives us two key things: (1) much more consistency for
> operators of the platform and (2) a consistent target (really a least common
> denominator) for ISV's packaging software for backing services. The value of
> consistency year over year doesn't diminish the value of experimentation
> outside of the certified distributions.

What about a consistent target for Cloud Foundry certified distributions? I completely disagree that this does not diminish experimentation. Companies will not invest in experiments that can never be commercially leveraged, and cannot make financial commitments without "consistency year over year" in the certification process itself.

To provide a little of my perspective: HPE's Stackato team embarked on a huge effort to re-engineer our product to meet the 2016 Cloud Foundry certification standard. This involved deprecating a lot of code and starting basically from scratch to develop Stakato 4.

We made this investment and took these risks with the understanding that the benefits of certification (customer confidence, compatibility, developers better positioned to contribute upstream, less churn maintaining forked code) would outweigh the hardships. If the BOSH requirement makes it into the 2017 certification we're actually worse off than we were a year ago, with less confidence that the requirements won't shift under our feet again.

I'm not actually objecting to BOSH itself here, just the notion that adding it to Cloud Foundry certification requirements is necessary. BOSH was built to be a comprehensive release engineering tool for *any* project. Let it be it's own thing.


Troy Topnik
Sr. Product Manager | Helion Stackato

Join { to automatically receive all group messages.