Thanks Chip, setting deadlines helps to focus ;-)

tl;dr

* From our (SAP HANA Cloud Platform’s) perspective, today BOSH is the only sustainable solution to deploying and managing CF (read: new CF versions can be adopted in no-time without additional effort) – as seen in this thread, other CF vendors have a different view here.
* We are big fans of the capabilities BOSH offers to operators of the platform and deploying with BOSH helped us to resolve some situations which otherwise would have ended quite unpleasantly; this is also why SAP is invested in bringing BOSH forward, especially in the OpenStack CPI area.
* However:
· Our platform consists of “not only CF” (our SAP HANA databases, big data components and others) and a holistic management of all platform pieces is something we strive for to allow for efficient operations of our own and our customer’s deployments. Here, we don’t see BOSH being adopted outside the CF ecosystem.
· Also, we see BOSH well-suited for “traditional” IaaS environments but less suited for a deployment of CF to containerization platforms which we see as a coming trend.

==> We see the risk that including BOSH in the certification will indeed prevent future innovation in deploying CF from happening. Especially when it comes to solutions that extend the current scope of deployment options (e.g. deploying CF on container platforms) and as those options are maturing, we require flexibility from the community to extend the list of “certifiable” lifecycle management tools for CF.

Additional thoughts (my personal views, not necessarily the ones of my employer)
I attended last week’s OpenStack Summit Barcelona and memories are quite fresh still. Seeing the topics discussed there and comparing them with the discussions in our community I see quite a few parallels but also differences emerging (bear with me).

Important topics discussed during OpenStack Summit were:

1. Interoperability (how to make sure that a solution that can be deployed to an OpenStack of vendor “A” can also be deployed to an OpenStack of vendor “B”) and Multi-cloud (how to distribute workloads across multiple OpenStack deployments but also across OpenStack and other public IaaS offerings like AWS and Azure)
2. Containerization (the elephant in the room was how OpenStack responds to containerization platforms with Kubernetes being the clear thought leader and others like Docker Swarm and Mesos/DCOS being rarely mentioned)

1. Interoperability and Multi-Cloud
On the interop topic, there was a showcase with 16 OpenStack vendors deploying a clustered WordPress including database on their distributions. What sounds like a great idea initially for me left some question marks because the vendors didn’t really all run the same script (for example invoking certain CLI commands) but instead used a wrapper library called Shade [1] to abstract away the differences between OpenStack distros in terms of login, capabilities, etc. Essentially a big case statement per vendor… not exactly how I would define interop.

As a side note, it became apparent for me that OpenStack’s “big tent” approach [2] led to a huge number of projects under the OpenStack umbrella with – what I perceive as – the core projects being a bit left alone when it comes to very basic capabilities they are still lacking because many core projects are run by a surprisingly small number of contributors only. I think we are doing much better in the CF ecosystem.

On Multi-Cloud, you might say: “This is exactly what we have with BOSH” and you are right as far as provisioning of CF on “traditional” IaaS environments are concerned. This is definitely a strength of our ecosystem. In contrast, if I see the vendor-specific ways of how OpenStack is deployed and managed the picture is quite confusing for me in the OpenStack environment and maybe some of the “let’s include BOSH in the certification” comes from fearing a similar situation.

On the other hand, if we are talking about CF application developers, I’m not sure our multi-cloud/interop story is really great in terms of “you can deploy one CF app on distros of multiple vendors”. Isn’t the later where our focus needs to go first?

2. Containerization
Especially a talk by Rob Hirschfeld (former OpenStack board member and co-chair of the OpenStack DevCore initiative, now involved in Kubernetes as well) called “Will it Blend? The Joint OpenStack Kubernetes Environment” [3] (IMHO one of the best talks at the Summit and also worthwhile for CF people to watch) did shed some light on this topic. Rob focused on deploying OpenStack on top of Kubernetes in his talk. He’s advocating to enable Kubernetes as an underlay for OpenStack but using it in a way that fits to what Kubernetes is designed for. Also, he’s pretty realistic on how mature Kubernetes is today. But, he’s also realistic on the fact that “it’s going to happen anyway” and depicts first steps into how OpenStack and Kubernetes “will blend” and the benefits of such a combination. The reasoning he provides is at the core of why my view at the moment is that certain core concepts of BOSH wouldn’t “blend” very well with Kubernetes (things like 12-factor-configuration for containers, health management and scheduling done by Kubernetes). Also, Rob makes an argument by saying that the changes required in OpenStack to better fit a deployment on top of Kubernetes are beneficial for OpenStack itself, even outside of a Kubernetes world.

Sorry for taking a de-tour via the OpenStack ecosystem. My point is: Much of the above could be said by replacing OpenStack with Cloud Foundry and it would still hold true from my perspective.

To sum things up:
· 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
· Along those lines, containerization platforms as an underlay is a trend we don’t have a good answer for in the CF ecosystem IMHO; on the other hand, I don’t feel this topic is mature yet so I “wouldn’t bet the house on it” (yet).
· On the other part of the mail thread around certification: I like the efforts of making cf-deployments leaner (and manage the dependencies based on BOSH release versions) than what cf-release is today. I hope building much more on features like BOSH links on the other hand still allows for people to take whatever is defined in cf-deployments and turn that into something that for example HPE has done with fissile [4]. Along the lines of what Amit wrote, I think it is then in the responsibility of the vendors embracing such alternatives to make sure these alternatives are also brought in early into the release integration process (which also includes staffing).
· Lastly, I believe it’s about collaboration between ecosystems and adopting things that work in one to benefit the others and I’m not sure that pinning things on BOSH would help in that direction. As Jonathan Bryce, executive director of the OpenStack foundation put it in his OpenStack Summit keynote: https://youtu.be/t8IiULAPKwo?t=977 (till 18:30)

Regards,
Bernd

[1] https://github.com/openstack-infra/shade/blob/master/shade/openstackcloud.py
[2] http://governance.openstack.org/reference/projects/
[3] https://www.youtube.com/watch?v=QeA8qgaXz-I - slides at http://www.slideshare.net/rhirschfeld/joint-openstack-kubernetes-environment-openstack-summit
[4] https://github.com/hpcloud/fissile

Bernd Krannich
SAP HANA Cloud Platform
SAP SE
Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

E bernd.krannich(a)sap.com<mailto:bernd.krannich(a)sap.com>

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum<http://www.sap.com/company/legal/impressum.epx/>

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.


From: Chip Childers <cchilders(a)cloudfoundry.org>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Monday 31 October 2016 at 15:35
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: [IMPORTANT] 2017 PaaS Certification Requirements

Thanks all for the great feedback so far. I don't want to halt discussion, but it would be useful for everyone to get their opinions noted by EOD tomorrow (Tuesday).