|
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.
|
|
|
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
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.
|
|
|
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
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
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.
|
|
|
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
toggle quoted message
Show quoted text
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!
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.
|
|
|
+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 EnglandFrom:
"Krannich,
Bernd" <bernd.krannich@...>To:
"cf-dev@..."
<cf-dev@...>Date:
16/11/2020
08:15Subject:
[EXTERNAL]
Re: [cf-dev] Thoughts on cf-for-k8s Use CasesSent
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.
|
|
|
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
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.
|
|
|
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
toggle quoted message
Show quoted text
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
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.
|
|
|
