|
Afra, Ziad <ziad.afra@...>
Hi All, seen this? what is everyone’s view?
Thanks
Ziad
==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================
|
|
|
The lowest friction adoption path for CNCF technologies in the CF community is via add-ons, accessed via the CF service broker mechanism. Kubo is a step in that direction because existing CF users may wish to deploy Kubernetes using the same infra automation as they use for CF, ie. BOSH. This move is therefore a win win. We'll see if it gets much traction in the next few months - I hope it does. On Fri, Mar 17, 2017 at 3:05 PM, Afra, Ziad via cncf-toc <cncf-toc@lists.cncf.io> wrote: Hi All, seen this? what is everyone’s view?
Thanks
Ziad
==============================================================================
Please access the attached hyperlink for an important electronic
communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================
_______________________________________________
cncf-toc mailing list
cncf-toc@lists.cncf.io
https://lists.cncf.io/mailman/listinfo/cncf-toc
|
|
|
Afra, Ziad <ziad.afra@...>
Low friction, low switching cost....interesting topics. How we manage the large "brownfield" estate is a big challenge.
What I am interested in seeing is how PCF+Kube+Docker evolves and how RH OpenShift positions itself as enterprise products to manage containers.
toggle quoted messageShow quoted text
-----Original Message----- From: Alexis Richardson [mailto:alexis@weave.works] Sent: Friday, March 17, 2017 11:15 AM To: Afra, Ziad (MLES) Cc: cncf-toc@lists.cncf.io Subject: Re: [cncf-toc] https://pivotal.io/kuboThe lowest friction adoption path for CNCF technologies in the CF community is via add-ons, accessed via the CF service broker mechanism. Kubo is a step in that direction because existing CF users may wish to deploy Kubernetes using the same infra automation as they use for CF, ie. BOSH. This move is therefore a win win. We'll see if it gets much traction in the next few months - I hope it does. On Fri, Mar 17, 2017 at 3:05 PM, Afra, Ziad via cncf-toc <cncf-toc@lists.cncf.io> wrote: Hi All, seen this? what is everyone’s view?
Thanks
Ziad
==============================================================================
Please access the attached hyperlink for an important electronic
communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==============================================================================
_______________________________________________
cncf-toc mailing list
cncf-toc@lists.cncf.io
https://lists.cncf.io/mailman/listinfo/cncf-toc
=============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================
|
|
|
which one of those is brownfield? ;-)
On Fri, Mar 17, 2017 at 3:20 PM Afra, Ziad < ziad.afra@...> wrote: Low friction, low switching cost....interesting topics. How we manage the large "brownfield" estate is a big challenge.
What I am interested in seeing is how PCF+Kube+Docker evolves and how RH OpenShift positions itself as enterprise products to manage containers.
-----Original Message-----
From: Alexis Richardson [mailto:alexis@...]
Sent: Friday, March 17, 2017 11:15 AM
To: Afra, Ziad (MLES)
Cc: cncf-toc@...
Subject: Re: [cncf-toc] https://pivotal.io/kubo
The lowest friction adoption path for CNCF technologies in the CF
community is via add-ons, accessed via the CF service broker
mechanism. Kubo is a step in that direction because existing CF users
may wish to deploy Kubernetes using the same infra automation as they
use for CF, ie. BOSH. This move is therefore a win win. We'll see if
it gets much traction in the next few months - I hope it does.
On Fri, Mar 17, 2017 at 3:05 PM, Afra, Ziad via cncf-toc
<cncf-toc@...> wrote:
> Hi All, seen this? what is everyone’s view?
>
>
>
> Thanks
>
> Ziad
>
>
>
>
> ==============================================================================
> Please access the attached hyperlink for an important electronic
> communications disclaimer:
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ==============================================================================
>
>
> _______________________________________________
> cncf-toc mailing list
> cncf-toc@...
> https://lists.cncf.io/mailman/listinfo/cncf-toc
>
===============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================
|
|
|
Regarding Kubo, it’s not immediately obvious to me how useful it is in the long term (although I must stress that I’m definitely not a Cloud Foundry expert).
Reading the Kubo docs it seems that it is, in essence, two pieces:
1. A TCP routing system (load balancer) to get client traffic to Kubernetes-hosted services.
2. A VM monitoring and management system (BOSH) to keep the VM’s (that Kubernetes is running on top of) deployed, healthy and scaled correctly.
In practice #1 is typically provided by a combination of the IaaS load balancers (e.g. AWS ELB, GCE LB, OpenStack LBaaS and associated plugins, etc), and Kubernetes integration with those.
#2 is usually provided by a combination of native IaaS VM auto-scaling (e.g. AWS Auto-scaling Groups, GCE Managed Instance Groups, OpenStack Autoscaling etc), and again, Kubernetes integration
with those.
Hence my above question around Kubo’s long-term usefulness.
What I did find interesting however is that Pivotal and CloudFoundry are explicitly and publicly supporting Kubernetes, so hopefully that means that porting CloudFoundry apps and tools
to Kubernetes will become easier and more mainstream over time (through, for example, Cloud Foundry to Kubernetes API adaptors).
Q
Quinton Hoole
Technical Vice President
America Research Center
2330 Central Expressway, Santa Clara, CA 95050
Tel: 408-330-4721 Cell: 408-320-8917 Office # E2-9
Email:
quinton.hoole@...
ID#Q00403160
From:
<cncf-toc-bounces@...> on behalf of "Afra, Ziad via cncf-toc" <cncf-toc@...>
Reply-To: "Afra, Ziad" <ziad.afra@...>
Date: Friday, March 17, 2017 at 08:20
To: Alexis Richardson <alexis@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] https://pivotal.io/kubo
toggle quoted messageShow quoted text
Low friction, low switching cost....interesting topics. How we manage the large "brownfield" estate is a big challenge.
What I am interested in seeing is how PCF+Kube+Docker evolves and how RH OpenShift positions itself as enterprise products to manage containers.
-----Original Message-----
Sent: Friday, March 17, 2017 11:15 AM
The lowest friction adoption path for CNCF technologies in the CF
community is via add-ons, accessed via the CF service broker
mechanism. Kubo is a step in that direction because existing CF users
may wish to deploy Kubernetes using the same infra automation as they
use for CF, ie. BOSH. This move is therefore a win win. We'll see if
it gets much traction in the next few months - I hope it does.
On Fri, Mar 17, 2017 at 3:05 PM, Afra, Ziad via cncf-toc
Hi All, seen this? what is everyone’s view?
==============================================================================
Please access the attached hyperlink for an important electronic
communications disclaimer:
==============================================================================
_______________________________________________
===============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
===============================================================================
_______________________________________________
|
|
|
Ziad, since you mentioned Docmer here is my take on your question. The type of convergence we're seeing is Kube+containerd and cloudfoundry+containerd. With the donation of containerd to CNCF underway, Docker is positioned as a direct competitor to Openshift in the enterprise container management space.
For anyone interested in comparing infrastructure management tools for Kubernetes provisioning and upgrading, I recommend checking out Infrakit. I'm hearing lots of Kubernetes operators mention it as something they're playing with.
If anyone is interested in discussing the same use case for Infrakit+Kubernetes, let me know we would be happy to do more in that area.
On Friday, March 17, 2017, Afra, Ziad via cncf-toc < cncf-toc@...> wrote: Low friction, low switching cost....interesting topics. How we manage the large "brownfield" estate is a big challenge.
What I am interested in seeing is how PCF+Kube+Docker evolves and how RH OpenShift positions itself as enterprise products to manage containers.
-----Original Message-----
From: Alexis Richardson [mailto:alexis@...]
Sent: Friday, March 17, 2017 11:15 AM
To: Afra, Ziad (MLES)
Cc: cncf-toc@...
Subject: Re: [cncf-toc] https://pivotal.io/kubo
The lowest friction adoption path for CNCF technologies in the CF
community is via add-ons, accessed via the CF service broker
mechanism. Kubo is a step in that direction because existing CF users
may wish to deploy Kubernetes using the same infra automation as they
use for CF, ie. BOSH. This move is therefore a win win. We'll see if
it gets much traction in the next few months - I hope it does.
On Fri, Mar 17, 2017 at 3:05 PM, Afra, Ziad via cncf-toc
<cncf-toc@...> wrote:
> Hi All, seen this? what is everyone’s view?
>
>
>
> Thanks
>
> Ziad
>
>
>
>
> ==============================================================================
> Please access the attached hyperlink for an important electronic
> communications disclaimer:
> http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
> ==============================================================================
>
>
> _______________________________________________
> cncf-toc mailing list
> cncf-toc@...
> https://lists.cncf.io/mailman/listinfo/cncf-toc
>
===============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
|
|
|
Anthony Skipper <anthony@...>
>>What I did find
interesting however is that Pivotal and CloudFoundry are explicitly and
publicly supporting Kubernetes, so hopefully that means that porting
CloudFoundry apps and tools
to Kubernetes will become easier and more mainstream over time
The only viable PaaS models going forward will be PaaS on top of CaaS. With CaaS you can implement nearly any type of system, with PaaS that isn't neccessarily true. The example of this is things like low latency trading systems, which you can't really implement on any existing PaaS solution, but can be made to work on a CaaS system. So the writing is on the wall that anyone doing PaaS probably needs to replatform it ontop of CaaS.
On Fri, Mar 17, 2017 at 11:39 AM, Quinton Hoole via cncf-toc <cncf-toc@...> wrote:
Regarding Kubo, it’s not immediately obvious to me how useful it is in the long term (although I must stress that I’m definitely not a Cloud Foundry expert).
Reading the Kubo docs it seems that it is, in essence, two pieces:
1. A TCP routing system (load balancer) to get client traffic to Kubernetes-hosted services.
2. A VM monitoring and management system (BOSH) to keep the VM’s (that Kubernetes is running on top of) deployed, healthy and scaled correctly.
In practice #1 is typically provided by a combination of the IaaS load balancers (e.g. AWS ELB, GCE LB, OpenStack LBaaS and associated plugins, etc), and Kubernetes integration with those.
#2 is usually provided by a combination of native IaaS VM auto-scaling (e.g. AWS Auto-scaling Groups, GCE Managed Instance Groups, OpenStack Autoscaling etc), and again, Kubernetes integration
with those.
Hence my above question around Kubo’s long-term usefulness.
What I did find interesting however is that Pivotal and CloudFoundry are explicitly and publicly supporting Kubernetes, so hopefully that means that porting CloudFoundry apps and tools
to Kubernetes will become easier and more mainstream over time (through, for example, Cloud Foundry to Kubernetes API adaptors).
Q
Quinton Hoole
Technical Vice President
America Research Center
2330 Central Expressway, Santa Clara, CA 95050
Tel: 408-330-4721 Cell: 408-320-8917 Office # E2-9
Email:
quinton.hoole@...
ID#Q00403160
Low friction, low switching cost....interesting topics. How we manage the large "brownfield" estate is a big challenge.
What I am interested in seeing is how PCF+Kube+Docker evolves and how RH OpenShift positions itself as enterprise products to manage containers.
-----Original Message-----
Sent: Friday, March 17, 2017 11:15 AM
The lowest friction adoption path for CNCF technologies in the CF
community is via add-ons, accessed via the CF service broker
mechanism. Kubo is a step in that direction because existing CF users
may wish to deploy Kubernetes using the same infra automation as they
use for CF, ie. BOSH. This move is therefore a win win. We'll see if
it gets much traction in the next few months - I hope it does.
On Fri, Mar 17, 2017 at 3:05 PM, Afra, Ziad via cncf-toc
Hi All, seen this? what is everyone’s view?
==============================================================================
Please access the attached hyperlink for an important electronic
communications disclaimer:
==============================================================================
_______________________________________________
===============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer:
===============================================================================
_______________________________________________
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
|
|
|
|
|
|
