https://pivotal.io/kubo


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
==============================================================================


alexis richardson
 

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.

-----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/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@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
===============================================================================


alexis richardson
 

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
===============================================================================


Quinton Hoole
 

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

 

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)

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:

==============================================================================

 

 

_______________________________________________

cncf-toc mailing list

 

 

 

 

===============================================================================

Please access the attached hyperlink for an important electronic communications disclaimer:

===============================================================================

_______________________________________________

cncf-toc mailing list

 


Solomon Hykes
 

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.


Here is an example how we use it to scale Docker in swarm mode: https://blog.docker.com/2017/03/infrakit-docker-swarm-mode-fault-tolerant-self-healing-cluster/

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.  

The funny question is what is the acronym for PaaS on CaaS?  (POC?)

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

 

From: <cncf-toc-bounces@....io> 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

 

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)

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:

==============================================================================

 

 

_______________________________________________

cncf-toc mailing list

 

 

 

 

===============================================================================

Please access the attached hyperlink for an important electronic communications disclaimer:

===============================================================================

_______________________________________________

cncf-toc mailing list

 


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



alexis richardson
 



On Fri, Mar 17, 2017 at 3:52 PM, Anthony Skipper <anthony@...> wrote:
>>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.  

The funny question is what is the acronym for PaaS on CaaS?  (POC?)

CF runs on a CaaS called Diego, it's just not very well known or used with non-CF systems.  Kubernetes arguably supports more use cases already eg Openshift PaaS, and then others.

I do think that, over time, the industry will prefer a decreasing number of 'standard layers' for the cloud native stack.  It's not obvious how many can thrive at each layer, but I'd hope for more than one myself.  And all this will take time.  


 

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

 

From: <cncf-toc-bounces@...o> 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

 

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)

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:

==============================================================================

 

 

_______________________________________________

cncf-toc mailing list

 

 

 

 

===============================================================================

Please access the attached hyperlink for an important electronic communications disclaimer:

===============================================================================

_______________________________________________

cncf-toc mailing list

 


_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc