My tuppence/two cents:

I have met folks who used non-BOSH Cloud Foundry solutions, and were
surprised when they hired people with "Cloud Foundry" on their resumes who
then had to start from scratch when debugging operational issues.

"I thought you operated Cloud Foundry in your last place?"
"I did, but none of the tools work on *this* one."

That's a marketing and reputation issue, right there. I'm all for more
innovative (and resource-efficient) ways of deploying Cloud Foundry, and if
BOSH isn't part of the deal then some thought needs to go into how these
differences are communicated to users and customers such that they aren't
left with any nasty surprises, because that's clearly bad for the ecosystem
as a whole.

Regards,
Daniel Jones - CTO
+44 (0)79 8000 9153
@DanielJonesEB <https://twitter.com/DanielJonesEB>
*EngineerBetter* Ltd <http://www.engineerbetter.com> - UK Cloud Foundry
Specialists

On Thu, Oct 27, 2016 at 7:57 PM, Chip Childers <cchilders(a)cloudfoundry.org>
wrote:

RE: Question #2 below -

One of the things that we've been thinking about regarding operator
experiences with Cloud Foundry, and why standardizing on BOSH may be very
attractive, is figuring out how people that get skills in CF operations are
able to move between different environments (service providers / product
companies / enterprise users) and have relatively transferable skills
across installations.

This is something I'd like to test with feedback from the community. Does
it seem valuable to have consistency for operators? Would there actually be
consistency?

On Thu, Oct 27, 2016 at 10:06 AM Chip Childers <cchilders(a)cloudfoundry.org>
wrote:

Bundling up Dr. Nic's questions for a single reply... Great questions! I
did a bunch of the pre-work on behalf of the PMC Council on this topic, so
I have a bunch of the context loaded.

*Question #1:* To confirm - if a CF platform patches any CF components
outside of the biweekly or so release cycle that the components might have,
then they lose their certification status? I know some on-prem vendors
maintain private forks of cf-release and release patches of older versions
for their customers; is this allowed or not?

*Short Answer:* Yes

*Longer Answer:* "Offerings" should always be based on a specific
cf-release + recommended sub-components that aren't directly included in
the cf-release itself (really this will transition to cf-deployment once
that starts getting versioned "releases"). Bug fixes / vulnerability fixes
are allowed to be back-ported, based on the "Exceptions" listed. This
assumes that the fixes are in the upstream projects. Also notice the
section about "current versions". That's an important concept. In 2017, the
trademark license agreement that is used as the contractual vehicle for
certification will be a perpetual license to use the 2017 "certification
mark". The point here is that the upstream projects don't do LTS (long term
support), but vendors are allowed to. They just have to reference the
appropriate certification year for LTS versions.

*Question #2:* Why is "using BOSH" a requirement? As awesome as it is for
many things, it isn't perfect. If companies innovate/experiment with
alternate deployment systems why do they lose certification status?

*Short Answer:* Consistent operational experience and deployment platform
for services

*Long Answer: *I agree that BOSH can be better, as can all software ;-).
However, the certification process for offerings isn't about
experimentation in the ecosystem. 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.

*Question #3:* "For managed offerings, BOSH does not need to be exposed
to customers" - what is the origin & reason this is explicitly stated? Does
it infer that there is any scenario at all where BOSH must be exposed to
end users/customers?

*Short Answer:* It doesn't infer that for users.

*Long Answer:* That language was put in there to be specific that
offerings that are online PaaS services shouldn't be required to (and none
do) expose the BOSH layer to users of the Elastic Runtime layer (or
customers generally).

Hope that helps!

-chip


On Thu, Oct 27, 2016 at 5:29 AM Dr Nic Williams <drnicwilliams(a)gmail.com>
wrote:

Also, why is "using BOSH" a requirement? As awesome as it is for many
things, it isn't perfect. If companies innovate/experiment with alternate
deployment systems why do they lose certification status?






On Thu, Oct 27, 2016 at 6:11 PM +1000, "Dieu Cao" <dcao(a)pivotal.io> wrote:

Hello all,

The 2017 PaaS Certification Requirements is available here [1] and we
would appreciate questions/comments on the doc or in this thread.

I've also attached a PDF version for those of you that have difficulty
accessing google docs.

2 major changes from the 2016 certification requirements include requiring
Diego/Garden and also requiring the use of BOSH.

-Dieu Cao
Runtime PMC Lead

[1] https://docs.google.com/document/d/1S9o4u65uG_
YrVQAdg7nxw7BrXAiL64hFSWBNVKZCMNI/edit

--
Chip Childers
VP Technology, Cloud Foundry Foundation
1.267.250.0815 <(267)%20250-0815>

--
Chip Childers
VP Technology, Cloud Foundry Foundation
1.267.250.0815