Re: [IMPORTANT] 2017 PaaS Certification Requirements
|
Iovanov, Vlad Mircea
Regarding a consistent operator experience, I believe it will differ with or
toggle quoted message
Show quoted text
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)hpe.com> 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. TT -- Troy Topnik Sr. Product Manager | Helion Stackato troy.topnik(a)hpe.com |
|
|