1. cf-dev@lists.cloudfoundry.org
  2. Messages
   Date   
CAB call! Wednesday December 16 @8am (Pacific)

Troy Topnik
 

Once again James Hunt from Stark & Wayne has something cool to show us at the Community Advisory Board call.

Join us this Wednesday for a demonstration of deploying CF-for-K8s using Helm, as well as all the usual project updates and some open discussion.

TT
----------
Chat room: go to slack.cloudfoundry.org and then join the #cab channel


Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/757994996

Or iPhone one-tap :
    US: +16468769923,,757994996# or +16699006833,,757994996#
Or Telephone:
    Dial(for higher quality, dial a number based on your current location):
        US: +1 646 876 9923 or +1 669 900 6833 or +1 408 638 0968
    Meeting ID: 757 994 996
    International numbers available: https://zoom.us/zoomconference?m=BbM_MZowkH08pdKycQk10at13V5cLneM

Agenda doc: https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI
 

--
Troy Topnik
 
 
Re: Cloud Service Broker in the Extensions PMC

Guillaume Berche
 

+1

The Open Service Broker api (OSB) is a very powerful standard. The cloud service broker now enables authors to leverage the large ecosystem of terraform providers in order to easily surface associated underlying services to OSB clients (cloudfoundry and kubernetes). This further strengthens the existing rich OSB ecosystem (see related recent PR at [1] as an attempt to make this ecosystem more easily discoverable by the community).

Orange had already a great experience with the cloud service broker for internal use cases. We're very happy that the CSB project joined the CFF and are eager to further contribute to the project in various ways (documentation, product ideas, as well as new features and bug fixes). Thanks to Google and Vmware for this great community contribution!

On Mon, Dec 7, 2020 at 5:50 PM Eric Malm <emalm@...> wrote:
Congratulations to Omer and the rest of the CSB project team!

Best,
Eric

From: cf-dev@... <cf-dev@...> on behalf of Troy Topnik via lists.cloudfoundry.org <troy.topnik=suse.com@...>
Sent: Friday, December 4, 2020 4:06 PM
To: cf-dev@... <cf-dev@...>
Subject: [Suspected Spam] [cf-dev] Cloud Service Broker in the Extensions PMC
 

Let's warmly welcome the Cloud Service Broker project into the Cloud Foundry Extensions PMC!

https://github.com/pivotal/cloud-service-broker

Cloud Service Broker is an OSBAPI broker that uses Brokerpaks to expose services via Terraform. The project is led by Omer Bensaadon from VMware. We didn't get any feedback during the (admittedly short) proposal phase for this, so if any Extensions PMC project leads have any objections, please contact me directly on Slack or via email.

TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
 
Re: Feature Narrative: Fine-granular & custom platform roles for Cloud Foundry

Guillaume Berche
 

Thanks Stephan for this proposal. I'm concerned that adding new roles will further increase complexity and degrade UX. This will likely increase the current feeling of combinatorial explosion when reading the role reference table [1]. I've contributed detailed comments in the documents to proceed as a community with analysing related use-cases and try to converge to a better proposal from the UX perspective.

Hope this helps,

Guillaume.


On Wed, Dec 2, 2020 at 5:26 PM Klevenz, Stephan <stephan.klevenz@...> wrote:

Hi CF,

 

Here is a feature narrative and it is called "Fine-granular & custom platform roles for Cloud Foundry".

 

https://docs.google.com/document/d/1isfsSWvF8xDU0G69k4MqB3o5c2vB0P3Vbi79W0yvqFQ/edit?usp=sharing

 

This proposal is the result of direct feedback we have received from many CF users. It addresses the problem that every space developer can delete a service. And there may be important data attached to this service. Oops.

Comments, feedback, suggestions, and questions very welcome and appreciated!

 

Regards,

Stephan

 

 
Re: Thoughts on cf-for-k8s Use Cases

Eric Malm
 

Hi, Bernd,

Thanks very much for the detailed write-up about future directions for cf-for-k8s, and for your elaboration on relevant operator segments, which matches our perspective on the community landscape. The specific needs and objectives you've expressed also align to feedback and questions we have received so far about how cf-for-k8s can achieve the same security and scale outcomes that CF has on BOSH, as well as how it could improve its operational flexibility, reliability, and interoperability with existing K8s clusters and their workloads. Sounds like a great roadmap for ongoing collaboration as we keep bringing CF outcomes to K8s!

Best,
Eric

From: cf-dev@... <cf-dev@...> on behalf of Daniel Jones via lists.cloudfoundry.org <daniel.jones=engineerbetter.com@...>
Sent: Monday, November 16, 2020 7:04 AM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: Re: [cf-dev] Thoughts on cf-for-k8s Use Cases
 
Thanks for the clarifications! I think in my narrow perspective I forgot that y'all probably have a lot of other things to manage, so you really do get economies of scale from internal Kubernetes knowledge.

Regards,
Daniel 'Deejay' Jones - CEO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists


On Mon, 16 Nov 2020 at 07:58, Simon D Moser <smoser@...> wrote:
+1 to what Bernd wrote - this exactly echoes my thinking as well on the points made

Mit freundlichen Grüßen / Kind regards

Simon Moser

Senior Technical Staff Member / IBM Master Inventor
Bluemix Application Platform Lead Architect
Dept. C727, IBM Research & Development Boeblingen

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser@...
-------------------------------------------------------------------------------------------------------------------------------------------
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

*******

ITIL has led people to think in siloes ("go fix change management").
Project Management has led people to think in finite units of work instead of streams of product.
Both are fundamental dysfunctions of the framework model, not failures of execution.
⁃ Rob England



From:        "Krannich, Bernd" <bernd.krannich@...>
To:        "cf-dev@..." <cf-dev@...>
Date:        16/11/2020 08:15
Subject:        [EXTERNAL] Re: [cf-dev] Thoughts on cf-for-k8s Use Cases
Sent by:        cf-dev@...



Hi Daniel, Thank you very much for your additional questions....                                                                                                                                                                                      
This Message Is From an External Sender
This message came from outside your organization.

Hi Daniel,

 

Thank you very much for your additional questions. Let me try and answer some of them from my perspective (this is me talking, not necessarily the “official voice” of my employer):

 

> It sounds like there are a lot of overheads for SAP in adopting cf-for-k8s. More operational complexity managing many clusters, and then the effort of migrating from cf-for-VMs to the new world. Is this all worth it?

 

We actually approach the topic from a different angle: We have much more to manage than „just“ CF – but many other services – and so the question for us is which common layers we establish as basis for our offering. One decision SAP has taken (and I hear that VMware, IBM, and Suse aren’t maybe that much different) is to use Kubernetes as one such layer. And taking that decision at our scale means a huge task in managing many clusters anyways. Our answer for this is Gardener (shameless advertisement for an SAP-initiated Open Source project: https://gardener.cloud/), but YMMV.

 

> Are end-users clamouring to be able to deploy things to Kubernetes alongside their CF apps?

> […]

> I wonder if all the migration efforts required to adopt cf-for-k8s are worthwhile to existing users.

 

I believe I referred to this topic during our CF Summit panel discussion: I think there’s more than one group of end-users to consider:

  • People using CF today that are happy with it: I think they are in the “let me continue to `cf push` my apps” camp and I believe they require feature parity to the BOSH-managed world to continue doing what they do. I also think they don’t care about Kubernetes as an underlay similar to how they didn’t care about BOSH managing CF’s lifecycle before.
  • People that tried using CF but couldn’t build their scenarios. Some of these people have what I would call a “mixed workload”: Things that could run on CF and things that can’t. For them, the question is if they want a “hybrid” model where they `cf push` their stateless apps to one system and `kubectl apply` the other parts of their workload to a different system or if they – once they have taken on the more difficult part of learning Kubernetes anyways – also move over their stateless workloads to Kubernetes directly. For this group of people, I feel, a value prop of “just having the CF API next to kubectl” as an access point to their cluster is a good thing. That’s also part of the reason why I’m suggesting to remove as much of the CF control plane from the “workload cluster” in my document. It’s their cluster and probably they want to do non-CF stuff with it as well.
  • People that approach the topic coming from a Kubernetes background: Here, we keep seeing projects over projects essentially re-inventing PaaS (some of them with an added Git-Ops flavor on top). Things that are non-Kubernetes or things that can be deployed on Kubernetes but “feel” non-K8s-native will not get them engaged. Which is why a Cloud Foundry on Kubernetes will need to feel K8s-native to be successful with this – probably very big – group.
 

> The notion of specifying different target runtime environments per isolation segment is intriguing. If this were possible, would it be simpler to stick with cf-for-VMs, and have a Kubernetes cluster for each tenant that runs apps and user workloads?

 

Not for us, because it would still leave us with both BOSH-based deployments as well as having to manage a huge fleet of K8s-clusters, so all of the work with none of the benefits.

 

Regards,

Bernd

 

From: cf-dev@... <cf-dev@...>
Date: Friday, 13. November 2020 at 10:26
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: Re: [cf-dev] Thoughts on cf-for-k8s Use Cases

Hey all!

 

Thanks for sharing your thoughts, Bernd.

 

It sounds like there are a lot of overheads for SAP in adopting cf-for-k8s. More operational complexity managing many clusters, and then the effort of migrating from cf-for-VMs to the new world. Is this all worth it? Are end-users clamouring to be able to deploy things to Kubernetes alongside their CF apps?

 

The notion of specifying different target runtime environments per isolation segment is intriguing. If this were possible, would it be simpler to stick with cf-for-VMs, and have a Kubernetes cluster for each tenant that runs apps and user workloads? This would be exactly the same as running Eirini on cf-for-VMs (which VMware published as an offering), except there'd be the option for one-Kubernetes-per-tenant.

 

As an aside, I do sincerely hope that the large CF vendors are intending to heavily market CF as the easy mode for Kubernetes. I wonder if all the migration efforts required to adopt cf-for-k8s are worthwhile to existingusers.

 

Regards,

Daniel 'Deejay' Jones - CEO

+44 (0)79 8000 9153

@DanielJonesEB

EngineerBetterLtd- More than cloud platform specialists

 

 

On Thu, 12 Nov 2020 at 17:34, Wayne E. Seguin <wayneeseguin@...> wrote:

Bernd,

 

Fantastic! I'm looking forward to reading it over, thank you for putting your thoughts down!

Thanks,

 

  ~Wayne

 

Wayne E. Seguin

CTO, Stark & Wayne LLC

wayneeseguin@...

 

 

 

On Thu, Nov 12, 2020 at 11:37 AM Krannich, Bernd <bernd.krannich@...> wrote:

Hello all,

 

With cf-for-k8s turning 1.0, I started putting my thoughts around “what’s next after what’s next for cf-for-k8s?” in writing.

 

I wanted to share the resulting document with the community to get feedback, additional perspectives and maybe even to inspire thinking around the topics I collected:

https://docs.google.com/document/d/1Hk19MkUOGQmP_dkoCwkogRQqlBwGE0Bpgr2U96JhW3I/edit?usp=sharing

 

Thanks,

Bernd

 

Bernd Krannich

SAP Cloud Platform

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

E bernd.krannich@...

 

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum

 

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.
Re: Feature Narrative: Fine-granular & custom platform roles for Cloud Foundry

Duncan Mcintyre <mcintyredu@...>
 

I’m all for anything which gives finer grained control. At present customers like RBS wrap the cf api with their own tooling in order to limit who can do what – which is obviously not optimal.

 

Shame we never implemented the ability to define custom roles in the database rather than have them hard-coded.

 

D

 

Duncan McIntyre
Advisory Solutions Engineer

mcintyredu@...
Mobile: +44 7917 580 118

VMware

VMware

 

 

From: cf-dev@... <cf-dev@...>
Date: Wednesday, December 2, 2020 at 5:29 PM
To: cf-dev@... <cf-dev@...>
Subject: Re: [cf-dev] Feature Narrative: Fine-granular & custom platform roles for Cloud Foundry

This is really a promising step. cloud.gov uses "service accounts", https://cloud.gov/docs/services/cloud-gov-service-account/, which are implemented with: https://github.com/cloudfoundry-community/uaa-credentials-broker.  Usually these are used in CI/CD systems for deployments.

The service accounts are way too over-powered using the Developer role, so this is a great step to scoping deployer accounts to, well, deployments in a CD system. However, I think the Operator account is too restrictive for any real human operator, and too expansive for a CI deployer account.

I'd like to see Operator renamed to Deployer and have some further rights removed, like viewing other spaces or or other users and roles, perhaps.

 

Or if there's a real need for the Operator role, then maybe add yet another role for Deployers (but that seems to be getting into IAM-level scope creep).

 

--Peter

 

On Wed, Dec 2, 2020 at 11:27 AM Klevenz, Stephan <stephan.klevenz@...> wrote:

Hi CF,

 

Here is a feature narrative and it is called "Fine-granular & custom platform roles for Cloud Foundry".

 

https://docs.google.com/document/d/1isfsSWvF8xDU0G69k4MqB3o5c2vB0P3Vbi79W0yvqFQ/edit?usp=sharing

 

This proposal is the result of direct feedback we have received from many CF users. It addresses the problem that every space developer can delete a service. And there may be important data attached to this service. Oops.

Comments, feedback, suggestions, and questions very welcome and appreciated!

 

Regards,

Stephan

 

 



--

- 

Peter Burkholder |  cloud.gov compliance & security

please use cloud-gov-compliance@... for cloud.gov matters

 
Routing Release 0.210.0 now available

Josh Russett
 

Hey y’all,

 

Routing Release 0.210.0 is now available.

 

Release Highlights

  • Operators can limit CAs that the gorouter trusts when validating client certs to a specified list (fixes #181 )
  • Bumps to golang 1.15.6

 

 

🌟🌲 Warm regards ❄️⛄️

CF for VMs Networking
CF Contributor Survey - last call!

Chris Clark
 

Hi all, 

If you haven't already, here's a quick reminder to please fill out this very brief survey for the CFF.  Thank you!

https://www.surveymonkey.com/r/ZGS7BNW 
Re: Cloud Service Broker in the Extensions PMC

Eric Malm
 

Congratulations to Omer and the rest of the CSB project team!

Best,
Eric

From: cf-dev@... <cf-dev@...> on behalf of Troy Topnik via lists.cloudfoundry.org <troy.topnik=suse.com@...>
Sent: Friday, December 4, 2020 4:06 PM
To: cf-dev@... <cf-dev@...>
Subject: [Suspected Spam] [cf-dev] Cloud Service Broker in the Extensions PMC
 

Let's warmly welcome the Cloud Service Broker project into the Cloud Foundry Extensions PMC!

https://github.com/pivotal/cloud-service-broker

Cloud Service Broker is an OSBAPI broker that uses Brokerpaks to expose services via Terraform. The project is led by Omer Bensaadon from VMware. We didn't get any feedback during the (admittedly short) proposal phase for this, so if any Extensions PMC project leads have any objections, please contact me directly on Slack or via email.

TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
troy.topnik@...
 
Cloud Service Broker in the Extensions PMC

Troy Topnik
 

Let's warmly welcome the Cloud Service Broker project into the Cloud Foundry Extensions PMC!

https://github.com/pivotal/cloud-service-broker

Cloud Service Broker is an OSBAPI broker that uses Brokerpaks to expose services via Terraform. The project is led by Omer Bensaadon from VMware. We didn't get any feedback during the (admittedly short) proposal phase for this, so if any Extensions PMC project leads have any objections, please contact me directly on Slack or via email.

TT

--
Troy Topnik
Senior Product Manager, 
SUSE Cloud Application Platform 
troy.topnik@...
 
CF Bi-Weekly Roundup 12/2

Chris Clark
 

Hi, all. As the year comes to an end, there are a few exciting things coming up I’d like to highlight: 

From the Last Few Weeks:

Dates To Remember (All times US Pacific):

Check the community calendar for updates and meeting details!

Ecosystem and General News:

Community Updates:

  • Have a question for the staff at Cloud Foundry Foundation? Want to stay current with updates for the Foundation? Join the #cff-forum channel on the community Slack.
  • Looking for a job? Check out the jobs board and the #jobs channel in our community slack; folks are sharing the job openings in our community.  

(And if you are hiring, please do share the info in that channel.)


--
Chris Clark
Technical Operations Manager
Cloud Foundry Foundation
Re: Feature Narrative: Fine-granular & custom platform roles for Cloud Foundry

Peter Burkholder
 

This is really a promising step. cloud.gov uses "service accounts", https://cloud.gov/docs/services/cloud-gov-service-account/, which are implemented with: https://github.com/cloudfoundry-community/uaa-credentials-broker.  Usually these are used in CI/CD systems for deployments.

The service accounts are way too over-powered using the Developer role, so this is a great step to scoping deployer accounts to, well, deployments in a CD system. However, I think the Operator account is too restrictive for any real human operator, and too expansive for a CI deployer account.

I'd like to see Operator renamed to Deployer and have some further rights removed, like viewing other spaces or or other users and roles, perhaps.

Or if there's a real need for the Operator role, then maybe add yet another role for Deployers (but that seems to be getting into IAM-level scope creep).

--Peter


On Wed, Dec 2, 2020 at 11:27 AM Klevenz, Stephan <stephan.klevenz@...> wrote:

Hi CF,

 

Here is a feature narrative and it is called "Fine-granular & custom platform roles for Cloud Foundry".

 

https://docs.google.com/document/d/1isfsSWvF8xDU0G69k4MqB3o5c2vB0P3Vbi79W0yvqFQ/edit?usp=sharing

 

This proposal is the result of direct feedback we have received from many CF users. It addresses the problem that every space developer can delete a service. And there may be important data attached to this service. Oops.

Comments, feedback, suggestions, and questions very welcome and appreciated!

 

Regards,

Stephan

 

 



--
- 
Peter Burkholder |  cloud.gov compliance & security
please use cloud-gov-compliance@... for cloud.gov matters
Feature Narrative: Fine-granular & custom platform roles for Cloud Foundry

Klevenz, Stephan <stephan.klevenz@...>
 

Hi CF,

 

Here is a feature narrative and it is called "Fine-granular & custom platform roles for Cloud Foundry".

 

https://docs.google.com/document/d/1isfsSWvF8xDU0G69k4MqB3o5c2vB0P3Vbi79W0yvqFQ/edit?usp=sharing

 

This proposal is the result of direct feedback we have received from many CF users. It addresses the problem that every space developer can delete a service. And there may be important data attached to this service. Oops.

Comments, feedback, suggestions, and questions very welcome and appreciated!

 

Regards,

Stephan

 

 
CF Contributor Survey

Chris Clark
 

Dear Cloud Foundry community, 

If you could, please fill out this very short survey for the Cloud Foundry Foundation! This is an opportunity for you to speak your mind about the direction of Cloud Foundry, the job the CFF has been doing this year, and anything else that might be on your mind.

This is for everyone, not just CF committers, and it should just take 2-3 minutes.  
Oh, and a hearty congratulations on getting through 11 months of 2020. 

https://www.surveymonkey.com/r/ZGS7BNW 

--
Chris Clark
Technical Operations Manager
Cloud Foundry Foundation
Re-usable Concourse Tasks

Daniel Jones
 

Hi folks,

Slightly off-topic, but I know a lot of you use Concourse.

We've made a an open source repo of small, reusable, side-effect-free Concourse tasks: https://github.com/EngineerBetter/concourse-tasks

These are tested using a YAML-based spec and associated test runner called Ironbird. It has a few rough edges, but it allows folks to test simple tasks without needing to know Ginkgo, or break out a 'proper' programming language.

I got annoyed when I realised that EngineerBetter must have collectively written a 'tar the files' task about a bazillion times, often without tests because "it's just a tar task, how hard can it be?" When you're deploying critical infrastructure, that's not good enough, and I'm sure everyone on this mailing list knows how frustrating it is when a simple task fails at the end of a four-hour infrastructure pipeline.

Anyway, I thought you might find the above useful. Contributions are very welcome, and perhaps if we all contribute to the same repo, we can achieve economies of scale, make our pipelines a bit more robust, and avoid duplicated effort.

Regards,
Daniel 'Deejay' Jones - CEO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists
Re: CF Bi-Weekly Roundup

Chris Clark
 

Hi folks,

Reminder: there are a ton of great talks from CF Summit live now on YouTube.  

From the Last Few Weeks:

 

Notable Releases:

  • CF-deployment v15.0.0, with breaking changes

    • re-generation of NATS certificates

  • Stratos v4.3.0 - more here

    • Numerous improvements to features and UI

  • BOSH-bootloader, aka "bbl", v8.4.2


Dates To Remember (All times US Pacific):

  • CAB call - 8:00 AM on November 18

  • CF Extensions PMC meeting - 11:00 AM on November 23

  • CF for Kubernetes SIG meeting - 8:30 AM on November 24

  • Bi-Weekly CF App Runtime PMC meeting - 10:30 AM on November 24

  • Office Hours: Logging and Metrics - 11:00 AM on November 24

Check the community calendar for updates and meeting details!


Ecosystem and General News:


Community Updates:

  • Have a question for the staff at Cloud Foundry Foundation? Want to stay current with updates for the Foundation? Join the #cff-forum channel on the community Slack.

  • Looking for a job? Check out the jobs board and the #jobs channel in our community slack; folks are sharing the job openings in our community.  

(And if you are hiring, please do share the info in that channel.)
CFF Technical Governance Working Group - Call for participation

Chip Childers <cchilders@...>
 

Hello CF community!

Earlier in the year, the CFF's board of directors asked a small group of past and current technical community contributors to do an assessment of how our open source community was operating and to make recommendations for improvements to the governance process. That group has been meeting for a couple of months, and saw an opportunity to build a healthier and more dynamic open governance environment for the projects by rethinking the PMC Council / PMC / Project structure, and approaching governance closer to the Kubernetes, Istio and KNative community models.

The time has come to take the small group's initial ideas and open up the discussion to anyone in the community that cares to participate. You can find the work here: https://github.com/cloudfoundry/community

There are two ways that anyone can get involved in this effort:
  • The work is centered in GitHub, so feel free to review everything, comment on PRs and issues, propose your own PRs, open issues, etc... as the work continues to progress.
  • We welcome anyone with an interest in helping to evolve the CF community's project level decision making to join a weekly call on Friday's at 4PM GMT (11 AM US Eastern, 8 AM US Pacific). I have put the meeting on the CFF community calendar, and you can join us for the first call on Friday, December 4th!
We're looking forward to hearing from all of you or seeing you during the calls.

Thanks!

Chip Childers
Executive Director
Cloud Foundry Foundation

Re: Thoughts on cf-for-k8s Use Cases

Daniel Jones
 

Thanks for the clarifications! I think in my narrow perspective I forgot that y'all probably have a lot of other things to manage, so you really do get economies of scale from internal Kubernetes knowledge.

Regards,
Daniel 'Deejay' Jones - CEO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists


On Mon, 16 Nov 2020 at 07:58, Simon D Moser <smoser@...> wrote:
+1 to what Bernd wrote - this exactly echoes my thinking as well on the points made

Mit freundlichen Grüßen / Kind regards

Simon Moser

Senior Technical Staff Member / IBM Master Inventor
Bluemix Application Platform Lead Architect
Dept. C727, IBM Research & Development Boeblingen

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser@...
-------------------------------------------------------------------------------------------------------------------------------------------
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

*******

ITIL has led people to think in siloes ("go fix change management").
Project Management has led people to think in finite units of work instead of streams of product.
Both are fundamental dysfunctions of the framework model, not failures of execution.
⁃ Rob England



From:        "Krannich, Bernd" <bernd.krannich@...>
To:        "cf-dev@..." <cf-dev@...>
Date:        16/11/2020 08:15
Subject:        [EXTERNAL] Re: [cf-dev] Thoughts on cf-for-k8s Use Cases
Sent by:        cf-dev@...



Hi Daniel, Thank you very much for your additional questions....                                                                                                                                                                                      
This Message Is From an External Sender
This message came from outside your organization.

Hi Daniel,

 

Thank you very much for your additional questions. Let me try and answer some of them from my perspective (this is me talking, not necessarily the “official voice” of my employer):

 

> It sounds like there are a lot of overheads for SAP in adopting cf-for-k8s. More operational complexity managing many clusters, and then the effort of migrating from cf-for-VMs to the new world. Is this all worth it?

 

We actually approach the topic from a different angle: We have much more to manage than „just“ CF – but many other services – and so the question for us is which common layers we establish as basis for our offering. One decision SAP has taken (and I hear that VMware, IBM, and Suse aren’t maybe that much different) is to use Kubernetes as one such layer. And taking that decision at our scale means a huge task in managing many clusters anyways. Our answer for this is Gardener (shameless advertisement for an SAP-initiated Open Source project: https://gardener.cloud/), but YMMV.

 

> Are end-users clamouring to be able to deploy things to Kubernetes alongside their CF apps?

> […]

> I wonder if all the migration efforts required to adopt cf-for-k8s are worthwhile to existing users.

 

I believe I referred to this topic during our CF Summit panel discussion: I think there’s more than one group of end-users to consider:

  • People using CF today that are happy with it: I think they are in the “let me continue to `cf push` my apps” camp and I believe they require feature parity to the BOSH-managed world to continue doing what they do. I also think they don’t care about Kubernetes as an underlay similar to how they didn’t care about BOSH managing CF’s lifecycle before.
  • People that tried using CF but couldn’t build their scenarios. Some of these people have what I would call a “mixed workload”: Things that could run on CF and things that can’t. For them, the question is if they want a “hybrid” model where they `cf push` their stateless apps to one system and `kubectl apply` the other parts of their workload to a different system or if they – once they have taken on the more difficult part of learning Kubernetes anyways – also move over their stateless workloads to Kubernetes directly. For this group of people, I feel, a value prop of “just having the CF API next to kubectl” as an access point to their cluster is a good thing. That’s also part of the reason why I’m suggesting to remove as much of the CF control plane from the “workload cluster” in my document. It’s their cluster and probably they want to do non-CF stuff with it as well.
  • People that approach the topic coming from a Kubernetes background: Here, we keep seeing projects over projects essentially re-inventing PaaS (some of them with an added Git-Ops flavor on top). Things that are non-Kubernetes or things that can be deployed on Kubernetes but “feel” non-K8s-native will not get them engaged. Which is why a Cloud Foundry on Kubernetes will need to feel K8s-native to be successful with this – probably very big – group.
 

> The notion of specifying different target runtime environments per isolation segment is intriguing. If this were possible, would it be simpler to stick with cf-for-VMs, and have a Kubernetes cluster for each tenant that runs apps and user workloads?

 

Not for us, because it would still leave us with both BOSH-based deployments as well as having to manage a huge fleet of K8s-clusters, so all of the work with none of the benefits.

 

Regards,

Bernd

 

From: cf-dev@... <cf-dev@...>
Date: Friday, 13. November 2020 at 10:26
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: Re: [cf-dev] Thoughts on cf-for-k8s Use Cases

Hey all!

 

Thanks for sharing your thoughts, Bernd.

 

It sounds like there are a lot of overheads for SAP in adopting cf-for-k8s. More operational complexity managing many clusters, and then the effort of migrating from cf-for-VMs to the new world. Is this all worth it? Are end-users clamouring to be able to deploy things to Kubernetes alongside their CF apps?

 

The notion of specifying different target runtime environments per isolation segment is intriguing. If this were possible, would it be simpler to stick with cf-for-VMs, and have a Kubernetes cluster for each tenant that runs apps and user workloads? This would be exactly the same as running Eirini on cf-for-VMs (which VMware published as an offering), except there'd be the option for one-Kubernetes-per-tenant.

 

As an aside, I do sincerely hope that the large CF vendors are intending to heavily market CF as the easy mode for Kubernetes. I wonder if all the migration efforts required to adopt cf-for-k8s are worthwhile to existingusers.

 

Regards,

Daniel 'Deejay' Jones - CEO

+44 (0)79 8000 9153

@DanielJonesEB

EngineerBetterLtd- More than cloud platform specialists

 

 

On Thu, 12 Nov 2020 at 17:34, Wayne E. Seguin <wayneeseguin@...> wrote:

Bernd,

 

Fantastic! I'm looking forward to reading it over, thank you for putting your thoughts down!

Thanks,

 

  ~Wayne

 

Wayne E. Seguin

CTO, Stark & Wayne LLC

wayneeseguin@...

 

 

 

On Thu, Nov 12, 2020 at 11:37 AM Krannich, Bernd <bernd.krannich@...> wrote:

Hello all,

 

With cf-for-k8s turning 1.0, I started putting my thoughts around “what’s next after what’s next for cf-for-k8s?” in writing.

 

I wanted to share the resulting document with the community to get feedback, additional perspectives and maybe even to inspire thinking around the topics I collected:

https://docs.google.com/document/d/1Hk19MkUOGQmP_dkoCwkogRQqlBwGE0Bpgr2U96JhW3I/edit?usp=sharing

 

Thanks,

Bernd

 

Bernd Krannich

SAP Cloud Platform

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

E bernd.krannich@...

 

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum

 

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.
Re: Thoughts on cf-for-k8s Use Cases

Simon D Moser
 

+1 to what Bernd wrote - this exactly echoes my thinking as well on the points made

Mit freundlichen Grüßen / Kind regards

Simon Moser

Senior Technical Staff Member / IBM Master Inventor
Bluemix Application Platform Lead Architect
Dept. C727, IBM Research & Development Boeblingen

-------------------------------------------------------------------------------------------------------------------------------------------
IBM Deutschland Research & Development GmbH
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-4304
Fax: +49-7031-16-4890
E-Mail: smoser@...
-------------------------------------------------------------------------------------------------------------------------------------------
Vorsitzender des Aufsichtsrats: Gregor Pillen
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

*******

ITIL has led people to think in siloes ("go fix change management").
Project Management has led people to think in finite units of work instead of streams of product.
Both are fundamental dysfunctions of the framework model, not failures of execution.
⁃ Rob England



From:        "Krannich, Bernd" <bernd.krannich@...>
To:        "cf-dev@..." <cf-dev@...>
Date:        16/11/2020 08:15
Subject:        [EXTERNAL] Re: [cf-dev] Thoughts on cf-for-k8s Use Cases
Sent by:        cf-dev@...



Hi Daniel, Thank you very much for your additional questions....                                                                                                                                                                                      
This Message Is From an External Sender
This message came from outside your organization.

Hi Daniel,

 

Thank you very much for your additional questions. Let me try and answer some of them from my perspective (this is me talking, not necessarily the “official voice” of my employer):

 

> It sounds like there are a lot of overheads for SAP in adopting cf-for-k8s. More operational complexity managing many clusters, and then the effort of migrating from cf-for-VMs to the new world. Is this all worth it?

 

We actually approach the topic from a different angle: We have much more to manage than „just“ CF – but many other services – and so the question for us is which common layers we establish as basis for our offering. One decision SAP has taken (and I hear that VMware, IBM, and Suse aren’t maybe that much different) is to use Kubernetes as one such layer. And taking that decision at our scale means a huge task in managing many clusters anyways. Our answer for this is Gardener (shameless advertisement for an SAP-initiated Open Source project: https://gardener.cloud/), but YMMV.

 

> Are end-users clamouring to be able to deploy things to Kubernetes alongside their CF apps?

> […]

> I wonder if all the migration efforts required to adopt cf-for-k8s are worthwhile to existing users.

 

I believe I referred to this topic during our CF Summit panel discussion: I think there’s more than one group of end-users to consider:

  • People using CF today that are happy with it: I think they are in the “let me continue to `cf push` my apps” camp and I believe they require feature parity to the BOSH-managed world to continue doing what they do. I also think they don’t care about Kubernetes as an underlay similar to how they didn’t care about BOSH managing CF’s lifecycle before.
  • People that tried using CF but couldn’t build their scenarios. Some of these people have what I would call a “mixed workload”: Things that could run on CF and things that can’t. For them, the question is if they want a “hybrid” model where they `cf push` their stateless apps to one system and `kubectl apply` the other parts of their workload to a different system or if they – once they have taken on the more difficult part of learning Kubernetes anyways – also move over their stateless workloads to Kubernetes directly. For this group of people, I feel, a value prop of “just having the CF API next to kubectl” as an access point to their cluster is a good thing. That’s also part of the reason why I’m suggesting to remove as much of the CF control plane from the “workload cluster” in my document. It’s their cluster and probably they want to do non-CF stuff with it as well.
  • People that approach the topic coming from a Kubernetes background: Here, we keep seeing projects over projects essentially re-inventing PaaS (some of them with an added Git-Ops flavor on top). Things that are non-Kubernetes or things that can be deployed on Kubernetes but “feel” non-K8s-native will not get them engaged. Which is why a Cloud Foundry on Kubernetes will need to feel K8s-native to be successful with this – probably very big – group.
 

> The notion of specifying different target runtime environments per isolation segment is intriguing. If this were possible, would it be simpler to stick with cf-for-VMs, and have a Kubernetes cluster for each tenant that runs apps and user workloads?

 

Not for us, because it would still leave us with both BOSH-based deployments as well as having to manage a huge fleet of K8s-clusters, so all of the work with none of the benefits.

 

Regards,

Bernd

 

From: cf-dev@... <cf-dev@...>
Date: Friday, 13. November 2020 at 10:26
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: Re: [cf-dev] Thoughts on cf-for-k8s Use Cases

Hey all!

 

Thanks for sharing your thoughts, Bernd.

 

It sounds like there are a lot of overheads for SAP in adopting cf-for-k8s. More operational complexity managing many clusters, and then the effort of migrating from cf-for-VMs to the new world. Is this all worth it? Are end-users clamouring to be able to deploy things to Kubernetes alongside their CF apps?

 

The notion of specifying different target runtime environments per isolation segment is intriguing. If this were possible, would it be simpler to stick with cf-for-VMs, and have a Kubernetes cluster for each tenant that runs apps and user workloads? This would be exactly the same as running Eirini on cf-for-VMs (which VMware published as an offering), except there'd be the option for one-Kubernetes-per-tenant.

 

As an aside, I do sincerely hope that the large CF vendors are intending to heavily market CF as the easy mode for Kubernetes. I wonder if all the migration efforts required to adopt cf-for-k8s are worthwhile to existingusers.

 

Regards,

Daniel 'Deejay' Jones - CEO

+44 (0)79 8000 9153

@DanielJonesEB

EngineerBetterLtd- More than cloud platform specialists

 

 

On Thu, 12 Nov 2020 at 17:34, Wayne E. Seguin <wayneeseguin@...> wrote:

Bernd,

 

Fantastic! I'm looking forward to reading it over, thank you for putting your thoughts down!

Thanks,

 

  ~Wayne

 

Wayne E. Seguin

CTO, Stark & Wayne LLC

wayneeseguin@...

 

 

 

On Thu, Nov 12, 2020 at 11:37 AM Krannich, Bernd <bernd.krannich@...> wrote:

Hello all,

 

With cf-for-k8s turning 1.0, I started putting my thoughts around “what’s next after what’s next for cf-for-k8s?” in writing.

 

I wanted to share the resulting document with the community to get feedback, additional perspectives and maybe even to inspire thinking around the topics I collected:

https://docs.google.com/document/d/1Hk19MkUOGQmP_dkoCwkogRQqlBwGE0Bpgr2U96JhW3I/edit?usp=sharing

 

Thanks,

Bernd

 

Bernd Krannich

SAP Cloud Platform

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

E bernd.krannich@...

 

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum

 

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.
Re: Thoughts on cf-for-k8s Use Cases

Krannich, Bernd
 

Hi Daniel,

 

Thank you very much for your additional questions. Let me try and answer some of them from my perspective (this is me talking, not necessarily the “official voice” of my employer):

 

> It sounds like there are a lot of overheads for SAP in adopting cf-for-k8s. More operational complexity managing many clusters, and then the effort of migrating from cf-for-VMs to the new world. Is this all worth it?

 

We actually approach the topic from a different angle: We have much more to manage than „just“ CF – but many other services – and so the question for us is which common layers we establish as basis for our offering. One decision SAP has taken (and I hear that VMware, IBM, and Suse aren’t maybe that much different) is to use Kubernetes as one such layer. And taking that decision at our scale means a huge task in managing many clusters anyways. Our answer for this is Gardener (shameless advertisement for an SAP-initiated Open Source project: https://gardener.cloud/), but YMMV.

 

> Are end-users clamouring to be able to deploy things to Kubernetes alongside their CF apps?

> […]

> I wonder if all the migration efforts required to adopt cf-for-k8s are worthwhile to existing users.

 

I believe I referred to this topic during our CF Summit panel discussion: I think there’s more than one group of end-users to consider:

  • People using CF today that are happy with it: I think they are in the “let me continue to `cf push` my apps” camp and I believe they require feature parity to the BOSH-managed world to continue doing what they do. I also think they don’t care about Kubernetes as an underlay similar to how they didn’t care about BOSH managing CF’s lifecycle before.
  • People that tried using CF but couldn’t build their scenarios. Some of these people have what I would call a “mixed workload”: Things that could run on CF and things that can’t. For them, the question is if they want a “hybrid” model where they `cf push` their stateless apps to one system and `kubectl apply` the other parts of their workload to a different system or if they – once they have taken on the more difficult part of learning Kubernetes anyways – also move over their stateless workloads to Kubernetes directly. For this group of people, I feel, a value prop of “just having the CF API next to kubectl” as an access point to their cluster is a good thing. That’s also part of the reason why I’m suggesting to remove as much of the CF control plane from the “workload cluster” in my document. It’s their cluster and probably they want to do non-CF stuff with it as well.
  • People that approach the topic coming from a Kubernetes background: Here, we keep seeing projects over projects essentially re-inventing PaaS (some of them with an added Git-Ops flavor on top). Things that are non-Kubernetes or things that can be deployed on Kubernetes but “feel” non-K8s-native will not get them engaged. Which is why a Cloud Foundry on Kubernetes will need to feel K8s-native to be successful with this – probably very big – group.

 

> The notion of specifying different target runtime environments per isolation segment is intriguing. If this were possible, would it be simpler to stick with cf-for-VMs, and have a Kubernetes cluster for each tenant that runs apps and user workloads?

 

Not for us, because it would still leave us with both BOSH-based deployments as well as having to manage a huge fleet of K8s-clusters, so all of the work with none of the benefits.

 

Regards,

Bernd

 

From: cf-dev@... <cf-dev@...>
Date: Friday, 13. November 2020 at 10:26
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev@...>
Subject: Re: [cf-dev] Thoughts on cf-for-k8s Use Cases

Hey all!

 

Thanks for sharing your thoughts, Bernd.

 

It sounds like there are a lot of overheads for SAP in adopting cf-for-k8s. More operational complexity managing many clusters, and then the effort of migrating from cf-for-VMs to the new world. Is this all worth it? Are end-users clamouring to be able to deploy things to Kubernetes alongside their CF apps?

 

The notion of specifying different target runtime environments per isolation segment is intriguing. If this were possible, would it be simpler to stick with cf-for-VMs, and have a Kubernetes cluster for each tenant that runs apps and user workloads? This would be exactly the same as running Eirini on cf-for-VMs (which VMware published as an offering), except there'd be the option for one-Kubernetes-per-tenant.

 

As an aside, I do sincerely hope that the large CF vendors are intending to heavily market CF as the easy mode for Kubernetes. I wonder if all the migration efforts required to adopt cf-for-k8s are worthwhile to existing users.

 

Regards,

Daniel 'Deejay' Jones - CEO

+44 (0)79 8000 9153

EngineerBetter Ltd - More than cloud platform specialists

 

 

On Thu, 12 Nov 2020 at 17:34, Wayne E. Seguin <wayneeseguin@...> wrote:

Bernd,

 

Fantastic! I'm looking forward to reading it over, thank you for putting your thoughts down!


Thanks,

 

  ~Wayne

 

Wayne E. Seguin

CTO, Stark & Wayne LLC

 

 

 

On Thu, Nov 12, 2020 at 11:37 AM Krannich, Bernd <bernd.krannich@...> wrote:

Hello all,

 

With cf-for-k8s turning 1.0, I started putting my thoughts around “what’s next after what’s next for cf-for-k8s?” in writing.

 

I wanted to share the resulting document with the community to get feedback, additional perspectives and maybe even to inspire thinking around the topics I collected:

https://docs.google.com/document/d/1Hk19MkUOGQmP_dkoCwkogRQqlBwGE0Bpgr2U96JhW3I/edit?usp=sharing

 

Thanks,

Bernd

 

Bernd Krannich

SAP Cloud Platform

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

E bernd.krannich@...

 

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum

 

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.
Re: Thoughts on cf-for-k8s Use Cases

Daniel Jones
 

Hey all!

Thanks for sharing your thoughts, Bernd.

It sounds like there are a lot of overheads for SAP in adopting cf-for-k8s. More operational complexity managing many clusters, and then the effort of migrating from cf-for-VMs to the new world. Is this all worth it? Are end-users clamouring to be able to deploy things to Kubernetes alongside their CF apps?

The notion of specifying different target runtime environments per isolation segment is intriguing. If this were possible, would it be simpler to stick with cf-for-VMs, and have a Kubernetes cluster for each tenant that runs apps and user workloads? This would be exactly the same as running Eirini on cf-for-VMs (which VMware published as an offering), except there'd be the option for one-Kubernetes-per-tenant.

As an aside, I do sincerely hope that the large CF vendors are intending to heavily market CF as the easy mode for Kubernetes. I wonder if all the migration efforts required to adopt cf-for-k8s are worthwhile to existing users.

Regards,
Daniel 'Deejay' Jones - CEO
+44 (0)79 8000 9153
EngineerBetter Ltd - More than cloud platform specialists


On Thu, 12 Nov 2020 at 17:34, Wayne E. Seguin <wayneeseguin@...> wrote:
Bernd,

Fantastic! I'm looking forward to reading it over, thank you for putting your thoughts down!

Thanks,

  ~Wayne

Wayne E. Seguin
CTO, Stark & Wayne LLC



On Thu, Nov 12, 2020 at 11:37 AM Krannich, Bernd <bernd.krannich@...> wrote:

Hello all,

 

With cf-for-k8s turning 1.0, I started putting my thoughts around “what’s next after what’s next for cf-for-k8s?” in writing.

 

I wanted to share the resulting document with the community to get feedback, additional perspectives and maybe even to inspire thinking around the topics I collected:

https://docs.google.com/document/d/1Hk19MkUOGQmP_dkoCwkogRQqlBwGE0Bpgr2U96JhW3I/edit?usp=sharing

 

Thanks,

Bernd

 

Bernd Krannich

SAP Cloud Platform

SAP SE

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

 

E bernd.krannich@...

 

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum

 

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.
201 - 220 of 9431