Date   

Re: [VOTE] CoreDNS project proposal (inception)

Camille Fournier
 

I'm +1, with the strong encouragement for this project to find more active committers. It really looks like a one-person show right now. Comparing to our other inception project, which has 7 people who seem to have more than 25 commits, this project has only 1 person who dominates the commit history. But I think we can do inception with the current status.

C

On Thu, Feb 16, 2017 at 2:15 PM, Benjamin Hindman via cncf-toc <cncf-toc@...> wrote:
+1

On Thu, Feb 16, 2017 at 11:03 AM, Brian Grant via cncf-toc <cncf-toc@...> wrote:
+1

On Fri, Feb 3, 2017 at 10:38 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
+1



On Fri, Feb 3, 2017 at 1:16 PM, Ram, J via cncf-toc
<cncf-toc@...> wrote:
> +1
>
> ________________________________
> From: cncf-toc-bounces@... <cncf-toc-bounces@...o> on
> behalf of Jonathan Boulle via cncf-toc <cncf-toc@...>
> Sent: Friday, February 3, 2017 7:57:33 AM
> To: Chris Aniszczyk
> Cc: CNCF TOC
> Subject: Re: [cncf-toc] [VOTE] CoreDNS project proposal (inception)
>
> +1
>
> On 2 February 2017 at 22:52, Chris Aniszczyk via cncf-toc
> <cncf-toc@...> wrote:
>>
>> At yesterday's TOC meeting, the TOC decided to formally invite CoreDNS
>> again but this time as an inception level CNCF project. Please vote on the
>> project proposal located here:
>>
>> https://github.com/cncf/toc/pull/9
>>
>> Remember that the TOC has binding votes only, but we do appreciate
>> non-binding votes from the community as a sign of support.
>>
>> Thanks!
>>
>> --
>> Chris Aniszczyk (@cra) | +1-512-961-6719
>>
>> _______________________________________________
>> cncf-toc mailing list
>> cncf-toc@...
>> https://lists.cncf.io/mailman/listinfo/cncf-toc
>>
>
>
> _______________________________________________
> cncf-toc mailing list
> cncf-toc@...
> https://lists.cncf.io/mailman/listinfo/cncf-toc
>
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


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




--
Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos

Follow us on Twitter: @mesosphere

Watch the Video .See how Verizon is tackling
IoT with DC/OS
 

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



Re: CNCF TOC Open Agenda - call for topics

alexis richardson
 

+1 good topic.



On Mon, Feb 27, 2017 at 2:40 PM, Jonathan Boulle
<jonathan.boulle@...> wrote:
I'd like to talk again about the CNCF providing documentation resources for
projects.

On 27 February 2017 at 15:05, Alexis Richardson via cncf-toc
<cncf-toc@...> wrote:

all,

post the Tahoe f2f we agreed to run with a more "open agenda" for TOC
calls.

PLEASE feel free to post topics to this thread over next 24 hours, and
I'll work with Chris A to devise an Agenda for the 1st March call this
week.

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


Re: CNCF TOC Open Agenda - call for topics

Jonathan Boulle <jonathan.boulle@...>
 

I'd like to talk again about the CNCF providing documentation resources for projects.

On 27 February 2017 at 15:05, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
all,

post the Tahoe f2f we agreed to run with a more "open agenda" for TOC calls.

PLEASE feel free to post topics to this thread over next 24 hours, and
I'll work with Chris A to devise an Agenda for the 1st March call this
week.

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


CNCF TOC Open Agenda - call for topics

alexis richardson
 

all,

post the Tahoe f2f we agreed to run with a more "open agenda" for TOC calls.

PLEASE feel free to post topics to this thread over next 24 hours, and
I'll work with Chris A to devise an Agenda for the 1st March call this
week.

a


CNCF speaking opportunities

Dan Kohn <dan@...>
 

CNCF will be sponsoring and helping to program content for the events below. We would encourage you to have engineers from your companies propose talks on Kubernetes and other cloud native related topics. We have travel funding available for women and other under-represented minority presenters.

OpenStack
Boston, MA - May 8 - 11
Kubernetes Day (May 9)
CFP - closes on March 20

Open Source Summit Japan 
Tokyo, Japan - May 31 - June 2
CFP - closes on March 4
Co-located Automotive Linux Summit 
June 1
CFP - closes March 4
Fluentd Mini-Summit 
June 1
CFP - closes on March 15

LinuxCon ContainerCon CloudOpen 
Beijing, China - June 19 - June 20
CFP - closes on March 18

Open Source Summit North America
Los Angeles, CA - September 11 - 13
CFP - closes on May 6

Open Source Summit Europe
Prague, Czech Republic - October 23 - 25
CFP - closes on July 8

Questions? Please contact me and Katie Schultz <kschultz@...>.
--
Dan Kohn <mailto:dan@linuxfoundation.org>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000


Re: Storage Patterns for container native - community content

Yaron Haviv
 

Alex,

 

I agree with Clinton’s point that we want to focus on what makes Cloud-Native different, not sure covering all the legacy Storage protocols serves that purpose

There are too many users today that try to fit VM concepts into Cloud-Native and take us out of focus

The key point is allowing continuous development and ops, elasticity, distribution, ..

Looking at the 12 factors, notions of Stateless & immutable tasks, Service bindings (to data), Atomicity are enabling that

 

It’s a different craft than today’s storage approached as I highlighted in my blog post, e.g. you don’t snapshot/backup a POD, you build it from a Git tag

You use message queues to enable elastic scaling and fault-tolerance, you store data using atomic operations (to Obj/NoSQL) vs trust file-systems to flush data out and risk inconsistent states. For the guys who would argue they want to snapshot stateful services like Mongo/Cassandra/Object, a short reminder is those are un-coordinated scaled-out instances, and in many cases versioning and re-builds are built into it

 

Yaron

 

From: Alex Chircop [mailto:alex.chircop@...]
Sent: Friday, February 24, 2017 4:14 PM
To: Kitson, Clinton <Clinton.Kitson@...>; Yaron Haviv <yaronh@...>; cncf-toc@...
Subject: RE: [cncf-toc] Storage Patterns for container native - community content

 

Clinton / Yaron,

 

Thank you for the feedback.   We will get some of that added to the doc, although we were thinking of covering some of those topics in more depth in future articles.   We’ll update the draft and recirculate.

 

Thanks,

Alex

 

 

 

From: Kitson, Clinton [mailto:Clinton.Kitson@...]
Sent: Thursday, February 23, 2017 4:11 AM
To: Yaron Haviv <yaronh@...>; Alex Chircop <alex.chircop@...>; cncf-toc@...
Subject: RE: [cncf-toc] Storage Patterns for container native - community content

 

Alex,

 

Sorry for the late review. My concern currently is that the document spends 80% of the time talking about what is known about some storage platforms today and the last portion discussing what looks to be technical details of a specific storage platform implementation. Cloud native with storage is definitely different, and just applying existing hardware thinking to this new area doesn't feel quite right.

 

Here are some of the questions that I think should be answered which leads towards a "what is cloud native storage topic".

 

What makes storage in cloud native computing different?

What cloud native applications require persistent storage of any form?

What kinds of storage services are used with cloud native applications?

What role does integration and interoperability play to build cloud native storage?

What opportunities do cloud native orchestrators present for operating persistent storage platforms?

What is cloud native storage?

 

 

Clint Kitson

Technical Director

{code} by Dell EMC

--- 

mobile: "+1 424 645 4116"

team: codeDellEMC.com

twitter: "@clintonskitson"

github: github.com/clintonskitson


From: cncf-toc-bounces@... [cncf-toc-bounces@...] on behalf of Yaron Haviv via cncf-toc [cncf-toc@...]
Sent: Wednesday, February 22, 2017 11:23 AM
To: Alex Chircop; cncf-toc@...
Subject: Re: [cncf-toc] Storage Patterns for container native - community content

I wrote a post a while ago on impact of Cloud-Native on Storage, can reuse its content, you may want to take the abstraction to the next level just like we did on compute (from VMs to services/apps).

 

https://sdsblog.com/2015/09/16/cloud-native-will-shake-up-enterprise-storage/

 

Yaron

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alex Chircop via cncf-toc
Sent: Wednesday, February 22, 2017 6:31 PM
To: cncf-toc@...
Subject: Re: [cncf-toc] Storage Patterns for container native - community content

 

Hi,

 

We have prepared the content for the first topic in the list (albeit a little later than we hoped for).   This is the first doc we have produced and is meant to serve as an overview of storage concepts to provide some background before going into the more detailed content articles we are planning next.   We have tried to keep it fairly broad and have touched on some of the technologies found in many enterprises as well as in CN environments like virtual and distributed options.

 

I’d like to know your thoughts and get feedback and comments (I’m sure there will be loads) so that we can make it a better doc for the community.   Also, as per the previous request – we would be very happy to work with anybody else who might have some time to contribute!

 

Doc is here: https://docs.google.com/document/d/1ntdU4q4ZmfX-EyClxKAK6yaikQleg6maSeijDXi_u0c/edit?usp=sharing

 

Kind Regards,

Alex

 

 

Alex Chircop

Founder and CTO

T: +44 7968 948832

E: alex.chircop@...

W: http://storageOS.com

L: uk.linkedin.com/in/alexchircop/

Skype: chira001

 

 

This email and any attachments are confidential to the intended recipient and may also be privileged or copyrighted material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient please delete it from your system and notify the sender.
StorageOS Ltd is a company registered in England and Wales with company number 9614942. Registered office address: 2 Minton Place, Victoria Road, Bicester, Oxfordshire, OX26 6QB.

 

 

 

 

 

From: Alex Chircop
Sent: Wednesday, February 1, 2017 3:50 PM
To: cncf-toc@...
Subject: Storage Patterns for container native - community content

 

Hi,

 

Following the discussion at the last TOC call, I’m attaching a doc to cover the topics that we are volunteering to generate for the community.   As background, we are proposing to focus this series on storage related patterns, starting with an overview and moving onto more complex use cases and examples.   We are planning to generate roughly an article a week on average for around ~3 months.

                                                  

I’m keen to understand if this is in line with what you think would be useful to the community and would be interested in any feedback and comments.   We would obviously be more than happy to work with anyone else who might be interested in contributing and/or any opportunity for joint work on any of the topics.

 

Doc is here: https://docs.google.com/document/d/14vVawyRcRRPm_mGZfl-tpQDCq2Q9aWxeHgdpZLAWnzU

 

Kind Regards,

Alex

 

 

Alex Chircop

Founder and CTO

T: +44 7968 948832

E: alex.chircop@...

W: http://storageOS.com

L: uk.linkedin.com/in/alexchircop/

Skype: chira001

 

 

This email and any attachments are confidential to the intended recipient and may also be privileged or copyrighted material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient please delete it from your system and notify the sender.StorageOS Ltd is a company registered in England and Wales with company number 9614942. Registered office address: 2 Minton Place, Victoria Road, Bicester, Oxfordshire, OX26 6QB.

 


Re: Storage Patterns for container native - community content

Alex Chircop
 

Clinton / Yaron,

 

Thank you for the feedback.   We will get some of that added to the doc, although we were thinking of covering some of those topics in more depth in future articles.   We’ll update the draft and recirculate.

 

Thanks,

Alex

 

 

 

From: Kitson, Clinton [mailto:Clinton.Kitson@...]
Sent: Thursday, February 23, 2017 4:11 AM
To: Yaron Haviv <yaronh@...>; Alex Chircop <alex.chircop@...>; cncf-toc@...
Subject: RE: [cncf-toc] Storage Patterns for container native - community content

 

Alex,

 

Sorry for the late review. My concern currently is that the document spends 80% of the time talking about what is known about some storage platforms today and the last portion discussing what looks to be technical details of a specific storage platform implementation. Cloud native with storage is definitely different, and just applying existing hardware thinking to this new area doesn't feel quite right.

 

Here are some of the questions that I think should be answered which leads towards a "what is cloud native storage topic".

 

What makes storage in cloud native computing different?

What cloud native applications require persistent storage of any form?

What kinds of storage services are used with cloud native applications?

What role does integration and interoperability play to build cloud native storage?

What opportunities do cloud native orchestrators present for operating persistent storage platforms?

What is cloud native storage?

 

 

Clint Kitson

Technical Director

{code} by Dell EMC

--- 

mobile: "+1 424 645 4116"

team: codeDellEMC.com

twitter: "@clintonskitson"

github: github.com/clintonskitson


From: cncf-toc-bounces@... [cncf-toc-bounces@...] on behalf of Yaron Haviv via cncf-toc [cncf-toc@...]
Sent: Wednesday, February 22, 2017 11:23 AM
To: Alex Chircop; cncf-toc@...
Subject: Re: [cncf-toc] Storage Patterns for container native - community content

I wrote a post a while ago on impact of Cloud-Native on Storage, can reuse its content, you may want to take the abstraction to the next level just like we did on compute (from VMs to services/apps).

 

https://sdsblog.com/2015/09/16/cloud-native-will-shake-up-enterprise-storage/

 

Yaron

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alex Chircop via cncf-toc
Sent: Wednesday, February 22, 2017 6:31 PM
To: cncf-toc@...
Subject: Re: [cncf-toc] Storage Patterns for container native - community content

 

Hi,

 

We have prepared the content for the first topic in the list (albeit a little later than we hoped for).   This is the first doc we have produced and is meant to serve as an overview of storage concepts to provide some background before going into the more detailed content articles we are planning next.   We have tried to keep it fairly broad and have touched on some of the technologies found in many enterprises as well as in CN environments like virtual and distributed options.

 

I’d like to know your thoughts and get feedback and comments (I’m sure there will be loads) so that we can make it a better doc for the community.   Also, as per the previous request – we would be very happy to work with anybody else who might have some time to contribute!

 

Doc is here: https://docs.google.com/document/d/1ntdU4q4ZmfX-EyClxKAK6yaikQleg6maSeijDXi_u0c/edit?usp=sharing

 

Kind Regards,

Alex

 

 

Alex Chircop

Founder and CTO

T: +44 7968 948832

E: alex.chircop@...

W: http://storageOS.com

L: uk.linkedin.com/in/alexchircop/

Skype: chira001

 

 

This email and any attachments are confidential to the intended recipient and may also be privileged or copyrighted material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient please delete it from your system and notify the sender.
StorageOS Ltd is a company registered in England and Wales with company number 9614942. Registered office address: 2 Minton Place, Victoria Road, Bicester, Oxfordshire, OX26 6QB.

 

 

 

 

 

From: Alex Chircop
Sent: Wednesday, February 1, 2017 3:50 PM
To: cncf-toc@...
Subject: Storage Patterns for container native - community content

 

Hi,

 

Following the discussion at the last TOC call, I’m attaching a doc to cover the topics that we are volunteering to generate for the community.   As background, we are proposing to focus this series on storage related patterns, starting with an overview and moving onto more complex use cases and examples.   We are planning to generate roughly an article a week on average for around ~3 months.

                                                  

I’m keen to understand if this is in line with what you think would be useful to the community and would be interested in any feedback and comments.   We would obviously be more than happy to work with anyone else who might be interested in contributing and/or any opportunity for joint work on any of the topics.

 

Doc is here: https://docs.google.com/document/d/14vVawyRcRRPm_mGZfl-tpQDCq2Q9aWxeHgdpZLAWnzU

 

Kind Regards,

Alex

 

 

Alex Chircop

Founder and CTO

T: +44 7968 948832

E: alex.chircop@...

W: http://storageOS.com

L: uk.linkedin.com/in/alexchircop/

Skype: chira001

 

 

This email and any attachments are confidential to the intended recipient and may also be privileged or copyrighted material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient please delete it from your system and notify the sender.StorageOS Ltd is a company registered in England and Wales with company number 9614942. Registered office address: 2 Minton Place, Victoria Road, Bicester, Oxfordshire, OX26 6QB.

 


Re: ANN: Formation of Working Groups

Camille Fournier
 

If you are interested in hearing about the progress of the CI working group, I am planning on using the CI mailing list for public discussion. Please join that mailing list, cncf-ci-public@lists.cncf.io, as per Dan's email on the topic on Feb 1.

Thanks,
Camille

On Mon, Feb 20, 2017 at 3:27 PM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
All,

An agenda item for the TOC f2f was the possible formation of "working
groups".  These have come up a number of times in the last 9+ months
since the TOC formed.  The idea is to spawn CNCF TOC discussions off
into their own groups, with a stated topic and chairperson.

I am pleased to report that the TOC have reached consensus on this,
following discussions in Tahoe.

CNCF now has:

* Storage WG chaired by Ben Hindman
* CI WG chaired by Camille Fournier
* Cluster WG chaired by Bryan Cantrill

For now, WGs are chaired by TOC voting members.  This is not a
perpetual requirement.  Let's keep it that way until we know more.

As with CNCF OSS projects, WGs will be as self-governed as possible.
Some norms may emerge in time and even become rules.

As of today:
* Feel free to contact the named people to join discussions.
* Feel free to initiate discussions on the CNCF TOC list, pending
creation of lists / docs / whatever the WGs need.
* Feel free to request updates

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


Re: Storage Patterns for container native - community content

Kitson, Clinton <Clinton.Kitson@...>
 

Alex,

Sorry for the late review. My concern currently is that the document spends 80% of the time talking about what is known about some storage platforms today and the last portion discussing what looks to be technical details of a specific storage platform implementation. Cloud native with storage is definitely different, and just applying existing hardware thinking to this new area doesn't feel quite right.

Here are some of the questions that I think should be answered which leads towards a "what is cloud native storage topic".

What makes storage in cloud native computing different?
What cloud native applications require persistent storage of any form?
What kinds of storage services are used with cloud native applications?
What role does integration and interoperability play to build cloud native storage?
What opportunities do cloud native orchestrators present for operating persistent storage platforms?
What is cloud native storage?


Clint Kitson
Technical Director
{code} by Dell EMC
--- 
email: Clinton.Kitson@...
mobile: "+1 424 645 4116"
team: codeDellEMC.com
twitter: "@clintonskitson"
github: github.com/clintonskitson


From: cncf-toc-bounces@... [cncf-toc-bounces@...] on behalf of Yaron Haviv via cncf-toc [cncf-toc@...]
Sent: Wednesday, February 22, 2017 11:23 AM
To: Alex Chircop; cncf-toc@...
Subject: Re: [cncf-toc] Storage Patterns for container native - community content

I wrote a post a while ago on impact of Cloud-Native on Storage, can reuse its content, you may want to take the abstraction to the next level just like we did on compute (from VMs to services/apps).

 

https://sdsblog.com/2015/09/16/cloud-native-will-shake-up-enterprise-storage/

 

Yaron

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alex Chircop via cncf-toc
Sent: Wednesday, February 22, 2017 6:31 PM
To: cncf-toc@...
Subject: Re: [cncf-toc] Storage Patterns for container native - community content

 

Hi,

 

We have prepared the content for the first topic in the list (albeit a little later than we hoped for).   This is the first doc we have produced and is meant to serve as an overview of storage concepts to provide some background before going into the more detailed content articles we are planning next.   We have tried to keep it fairly broad and have touched on some of the technologies found in many enterprises as well as in CN environments like virtual and distributed options.

 

I’d like to know your thoughts and get feedback and comments (I’m sure there will be loads) so that we can make it a better doc for the community.   Also, as per the previous request – we would be very happy to work with anybody else who might have some time to contribute!

 

Doc is here: https://docs.google.com/document/d/1ntdU4q4ZmfX-EyClxKAK6yaikQleg6maSeijDXi_u0c/edit?usp=sharing

 

Kind Regards,

Alex

 

 

Alex Chircop

Founder and CTO

T: +44 7968 948832

E: alex.chircop@...

W: http://storageOS.com

L: uk.linkedin.com/in/alexchircop/

Skype: chira001

 

 

This email and any attachments are confidential to the intended recipient and may also be privileged or copyrighted material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient please delete it from your system and notify the sender.
StorageOS Ltd is a company registered in England and Wales with company number 9614942. Registered office address: 2 Minton Place, Victoria Road, Bicester, Oxfordshire, OX26 6QB.

 

 

 

 

 

From: Alex Chircop
Sent: Wednesday, February 1, 2017 3:50 PM
To: cncf-toc@...
Subject: Storage Patterns for container native - community content

 

Hi,

 

Following the discussion at the last TOC call, I’m attaching a doc to cover the topics that we are volunteering to generate for the community.   As background, we are proposing to focus this series on storage related patterns, starting with an overview and moving onto more complex use cases and examples.   We are planning to generate roughly an article a week on average for around ~3 months.

                                                  

I’m keen to understand if this is in line with what you think would be useful to the community and would be interested in any feedback and comments.   We would obviously be more than happy to work with anyone else who might be interested in contributing and/or any opportunity for joint work on any of the topics.

 

Doc is here: https://docs.google.com/document/d/14vVawyRcRRPm_mGZfl-tpQDCq2Q9aWxeHgdpZLAWnzU

 

Kind Regards,

Alex

 

 

Alex Chircop

Founder and CTO

T: +44 7968 948832

E: alex.chircop@...

W: http://storageOS.com

L: uk.linkedin.com/in/alexchircop/

Skype: chira001

 

 

This email and any attachments are confidential to the intended recipient and may also be privileged or copyrighted material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient please delete it from your system and notify the sender.StorageOS Ltd is a company registered in England and Wales with company number 9614942. Registered office address: 2 Minton Place, Victoria Road, Bicester, Oxfordshire, OX26 6QB.

 


Re: Storage Patterns for container native - community content

Yaron Haviv
 

I wrote a post a while ago on impact of Cloud-Native on Storage, can reuse its content, you may want to take the abstraction to the next level just like we did on compute (from VMs to services/apps).

 

https://sdsblog.com/2015/09/16/cloud-native-will-shake-up-enterprise-storage/

 

Yaron

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alex Chircop via cncf-toc
Sent: Wednesday, February 22, 2017 6:31 PM
To: cncf-toc@...
Subject: Re: [cncf-toc] Storage Patterns for container native - community content

 

Hi,

 

We have prepared the content for the first topic in the list (albeit a little later than we hoped for).   This is the first doc we have produced and is meant to serve as an overview of storage concepts to provide some background before going into the more detailed content articles we are planning next.   We have tried to keep it fairly broad and have touched on some of the technologies found in many enterprises as well as in CN environments like virtual and distributed options.

 

I’d like to know your thoughts and get feedback and comments (I’m sure there will be loads) so that we can make it a better doc for the community.   Also, as per the previous request – we would be very happy to work with anybody else who might have some time to contribute!

 

Doc is here: https://docs.google.com/document/d/1ntdU4q4ZmfX-EyClxKAK6yaikQleg6maSeijDXi_u0c/edit?usp=sharing

 

Kind Regards,

Alex

 

 

Alex Chircop

Founder and CTO

T: +44 7968 948832

E: alex.chircop@...

W: http://storageOS.com

L: uk.linkedin.com/in/alexchircop/

Skype: chira001

 

 

This email and any attachments are confidential to the intended recipient and may also be privileged or copyrighted material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient please delete it from your system and notify the sender.
StorageOS Ltd is a company registered in England and Wales with company number 9614942. Registered office address: 2 Minton Place, Victoria Road, Bicester, Oxfordshire, OX26 6QB.

 

 

 

 

 

From: Alex Chircop
Sent: Wednesday, February 1, 2017 3:50 PM
To: cncf-toc@...
Subject: Storage Patterns for container native - community content

 

Hi,

 

Following the discussion at the last TOC call, I’m attaching a doc to cover the topics that we are volunteering to generate for the community.   As background, we are proposing to focus this series on storage related patterns, starting with an overview and moving onto more complex use cases and examples.   We are planning to generate roughly an article a week on average for around ~3 months.

                                                  

I’m keen to understand if this is in line with what you think would be useful to the community and would be interested in any feedback and comments.   We would obviously be more than happy to work with anyone else who might be interested in contributing and/or any opportunity for joint work on any of the topics.

 

Doc is here: https://docs.google.com/document/d/14vVawyRcRRPm_mGZfl-tpQDCq2Q9aWxeHgdpZLAWnzU

 

Kind Regards,

Alex

 

 

Alex Chircop

Founder and CTO

T: +44 7968 948832

E: alex.chircop@...

W: http://storageOS.com

L: uk.linkedin.com/in/alexchircop/

Skype: chira001

 

 

This email and any attachments are confidential to the intended recipient and may also be privileged or copyrighted material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient please delete it from your system and notify the sender.StorageOS Ltd is a company registered in England and Wales with company number 9614942. Registered office address: 2 Minton Place, Victoria Road, Bicester, Oxfordshire, OX26 6QB.

 


Re: Storage Patterns for container native - community content

Alex Chircop
 

Hi,

 

We have prepared the content for the first topic in the list (albeit a little later than we hoped for).   This is the first doc we have produced and is meant to serve as an overview of storage concepts to provide some background before going into the more detailed content articles we are planning next.   We have tried to keep it fairly broad and have touched on some of the technologies found in many enterprises as well as in CN environments like virtual and distributed options.

 

I’d like to know your thoughts and get feedback and comments (I’m sure there will be loads) so that we can make it a better doc for the community.   Also, as per the previous request – we would be very happy to work with anybody else who might have some time to contribute!

 

Doc is here: https://docs.google.com/document/d/1ntdU4q4ZmfX-EyClxKAK6yaikQleg6maSeijDXi_u0c/edit?usp=sharing

 

Kind Regards,

Alex

 

 

Alex Chircop

Founder and CTO

T: +44 7968 948832

E: alex.chircop@...

W: http://storageOS.com

L: uk.linkedin.com/in/alexchircop/

Skype: chira001

 

 

This email and any attachments are confidential to the intended recipient and may also be privileged or copyrighted material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient please delete it from your system and notify the sender.
StorageOS Ltd is a company registered in England and Wales with company number 9614942. Registered office address: 2 Minton Place, Victoria Road, Bicester, Oxfordshire, OX26 6QB.

 

 

 

 

 

From: Alex Chircop
Sent: Wednesday, February 1, 2017 3:50 PM
To: cncf-toc@...
Subject: Storage Patterns for container native - community content

 

Hi,

 

Following the discussion at the last TOC call, I’m attaching a doc to cover the topics that we are volunteering to generate for the community.   As background, we are proposing to focus this series on storage related patterns, starting with an overview and moving onto more complex use cases and examples.   We are planning to generate roughly an article a week on average for around ~3 months.

                                                  

I’m keen to understand if this is in line with what you think would be useful to the community and would be interested in any feedback and comments.   We would obviously be more than happy to work with anyone else who might be interested in contributing and/or any opportunity for joint work on any of the topics.

 

Doc is here: https://docs.google.com/document/d/14vVawyRcRRPm_mGZfl-tpQDCq2Q9aWxeHgdpZLAWnzU

 

Kind Regards,

Alex

 

 

Alex Chircop

Founder and CTO

T: +44 7968 948832

E: alex.chircop@...

W: http://storageOS.com

L: uk.linkedin.com/in/alexchircop/

Skype: chira001

 

 

This email and any attachments are confidential to the intended recipient and may also be privileged or copyrighted material.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient please delete it from your system and notify the sender.StorageOS Ltd is a company registered in England and Wales with company number 9614942. Registered office address: 2 Minton Place, Victoria Road, Bicester, Oxfordshire, OX26 6QB.

 


ANN: Formation of Working Groups

alexis richardson
 

All,

An agenda item for the TOC f2f was the possible formation of "working
groups". These have come up a number of times in the last 9+ months
since the TOC formed. The idea is to spawn CNCF TOC discussions off
into their own groups, with a stated topic and chairperson.

I am pleased to report that the TOC have reached consensus on this,
following discussions in Tahoe.

CNCF now has:

* Storage WG chaired by Ben Hindman
* CI WG chaired by Camille Fournier
* Cluster WG chaired by Bryan Cantrill

For now, WGs are chaired by TOC voting members. This is not a
perpetual requirement. Let's keep it that way until we know more.

As with CNCF OSS projects, WGs will be as self-governed as possible.
Some norms may emerge in time and even become rules.

As of today:
* Feel free to contact the named people to join discussions.
* Feel free to initiate discussions on the CNCF TOC list, pending
creation of lists / docs / whatever the WGs need.
* Feel free to request updates

alexis


Re: Interesting tech marketing from Amazon

Yaron Haviv
 

Andy, thanks, sure we should follow w “How” after the “Why”

 

Another reason for that order is to set the architecture context, e.g. many still view containers as lightweight VMs, can see requests for volume backup/snapshots, “vmotion” .. those violate the cloud-native notion of “disposable” containers/micro-services (which enable reliability, changing versions on the fly, scaling-out, .. i.e. continuous dev & ops).

 

I assume once CNCF defines the why/goal we should come with a reference architecture of how to enable these next gen apps, e.g. see a great post from Brian Gracely on Cloud-Native apps & data architecture:

http://wikibon.com/new-applications-require-a-modern-look-at-data-management/

 

Note how he captured both Biz/CIO level (why) messages with the tech details (how)

 

Yaron

 

 

From: Andrew Randall [mailto:andy@...]
Sent: Saturday, February 18, 2017 3:50 AM
To: Brian Grant <briangrant@...>; Kitson, Clinton <Clinton.Kitson@...>; Tony Hsu <gosharplite@...>; Yaron Haviv <yaronh@...>; cncf-toc@...
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon

 

I agree the emphasis of our outbound messaging should be on the why (and the "what's in it for me?"). And Yaron's suggestion of "because it gets you business agility through continuous dev and ops") sounds good to me as a first stab in that direction. That's good marketing. It will certainly get someone interested if they hear that cloud native will help them make their business more agile.

However we also, I think, must define what "cloud native" actually is. Because once you've got them sold that cloud native has the right kind of attributes, they will want to know what it actually means to implement it. And if the answer is "cloud native is anything that makes your business more agile" or just "continuous dev and ops" (with nothing to explain how that's achieved) then we will be perceived as nothing more than a marketing organization with no technical credibility.

At the risk of being controversial I would posit that has the following implications::
1) we must be somewhat opinionated about what makes something "cloud native" -- otherwise everything is cloud native (that obviously doesn't mean we have to say "you must use some specific technology" to be cloud native)
2) without a litmus test that most legacy apps and infrastructure technologies fail, then it is meaningless
3) similarly, in order to be meaningful, it must be possible for cloud native as we currently define it to be made obsolete in the future. (At which point we can wind down or redefine our mission -- but if our definition of cloud native continues to work whatever the developments in technology in the future, then it's not specific enough.)

I really want CNCF to be perceived as relevant and pointing the way for the industry. If we just churn out platitudes (aka motherhood and apple pie) we will fail.

Andy

 

On Fri, Feb 17, 2017 at 2:43 PM Yaron Haviv via cncf-toc <cncf-toc@...> wrote:

If anyone care to watch Simon’s talk pointed by Tony: "people don't buy WHAT you do, but WHY you do it", Containers, micro-services, .. are the what, my point is we should focus on the Why

 

i.e. Why cloud-native? = e.g. enable biz agility through continuous dev & ops (or any other suggestion)

Note that other points below like resiliency,  speed of change,  dynamic scaling ..  All fall under a bigger message of continuous dev & ops which solves the biggest challenge biz have: faster and sustainable digital transformation at lower budgets 

 

The tech can be containers today, maybe server-less functions or whatever tomorrow, the key is the collaboration and standardization driven by CNCF to reduce friction and complexity in the new stack

 

Yaron

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Kitson, Clinton via cncf-toc
Sent: Friday, February 17, 2017 11:17 PM
To: Brian Grant <briangrant@...>; Tony Hsu <gosharplite@...>


Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon

 

 

I agree with some earlier comments about being too opinionated. A broad definition could be "a computing environment focused on optimizing for applications in cloud operating models". This feels like the most natural and direct way to define cloud native computing while ensuring the relevance to how we are seeing people make use of it today and tomorrow.

 

The definition leads to a lot of what was discussed in this thread.

- Requirements (interoperability/composability, automation/orchestration)

- Patterns (micro-services, scale-out, DevOps, CI)

- Components (cncf landscape)

- Benefits/features (resilience, scale, efficiency, resilience, portability)

 

 

 

 

Clint Kitson

Technical Director

{code} by Dell EMC

--- 

mobile: "+1 424 645 4116"

team: codeDellEMC.com

twitter: "@clintonskitson"


From: cncf-toc-bounces@... [cncf-toc-bounces@...] on behalf of Brian Grant via cncf-toc [cncf-toc@...]
Sent: Friday, February 17, 2017 12:32 PM
To: Tony Hsu
Cc: Alexis Richardson via cncf-toc
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon

 

On Feb 17, 2017 2:00 AM, "Tony Hsu via cncf-toc" <cncf-toc@...> wrote:

As a big fan of Joe Beta and Craig McLuckie, my three ingredients for cloud-native operations are containers, orchestrators and microservice frameworks. These three terms come from Craig's post announcing the start of Heptio. https://goo.gl/aJgiQk

 

+1

 

That's very concrete, and provides a framework for explaining what and why.

 

 

Our limbic brains are responsible for all of our feelings, like trust and loyalty. It's also responsible for all human behavior, all decision-making, and it has no capacity for language. Please don't rely on logic and facts, it just doesn't drive behavior.

 

I got this from Simon Sinek's TED talk 'How great leaders inspire action'. https://goo.gl/EsJRvy

 

Regards,

Tony Hsu

 

On Fri, Feb 17, 2017 at 4:37 PM, Yaron Haviv via cncf-toc <cncf-toc@...> wrote:

I think the key message of Cloud-Native should be about its value:

Continuous Development and Operation (Enabling Business Agility/Transformation)  

 

Decomposition to micro-services, stateless, disposable/distributed components, Atomicity .. are the ways by which we achieve that goal, and those may evolve over time. If we want to engage more business owners lets focus on what’s in it for them and the need for a change vs tech buzzwords.   

 

My 2c, Yaron

CTO, iguazio  

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Brian Grant via cncf-toc
Sent: Friday, February 17, 2017 6:05 AM
To: Andrew Randall <
andy@...>
Cc: Alexis Richardson via cncf-toc <
cncf-toc@...>
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon

 

 

 

On Tue, Feb 14, 2017 at 10:37 AM, Andrew Randall via cncf-toc <cncf-toc@...> wrote:

I think we should aim for 3 core principles. Any more than that and people won't be able to repeat as a mantra.

 

Currently the charter has:

- container packaged

- dynamically managed

- micro-services oriented.

 

I like Mark's comments. However, I worry about "massive scale" as a message. LOTS of people I talked with at CloudNativeCon and other shows recently have been doing fairly small scale deployments, but they're still cloud native. I think the nature of how we scale is important -- it's about the distributed, scale-out architectures that enable massive scale (but don't impose a cost burden for the small development shop that's running on a half dozen VMs in AWS).

 

I think "Dynamically scalable" captures that better.

 

Management includes scaling, so IMO "dynamically managed" implies dynamic scaling, as well as a higher rate of change than people had been accustomed to in the past.

 

In practice, the way this is achieved is through automation.

 

 

The inclusion of container-packaged and micro-services in the charter is an opinionated (and informed) stance about where the puck is headed.

 

 

So:

1. Speed of change

2. Resilience

3. Dynamically scalable

 

And you could add "built on open source foundation" as a fourth, or leave it implicit given the foundation nature of LF/CNCF.

 

Andy

 

 

 

On Tue, Feb 14, 2017 at 10:32 AM Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I agree that we may need to think more about how we communicate about microservices, but do we agree that the underlying purpose of cloud native is:

 

1. Speed of change (I used to refer to this as agility but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff

 

?

 

If we know what problems we're solving it will be easier to talk about specific practices and tools in a coherent manner.

 

On Tue, Feb 14, 2017 at 10:24 AM Camille Fournier <skamille@...> wrote:

Microservices are cloud native because they are a natural product of the ease of use for cloud. In a evolutionary way I would call them absolutely cloud native, which doesn't mean one must use them to effectively use the cloud but they do effectively show how cloud changed the way developers thought about building systems.

 

On Feb 14, 2017 10:22 AM, "Alexis Richardson via cncf-toc" <cncf-toc@...> wrote:

 

On Tue, Feb 14, 2017 at 10:20 AM Anthony Skipper <anthony@...> wrote:

I'd argue that if you had good tools, you wouldn't need microservices.

 

Yes, I don't think microservices is a core value.  It's one of several modern cloud native patterns that is useful for some organisational and technical issues.  But not the only one.

 

 

 

 

 

 

On Tue, Feb 14, 2017 at 1:15 PM, Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I think I summarised it in this piece that I ghost wrote for Luke when he was at ClusterHQ (Friend D A please): https://www.infoq.com/articles/microservices-revolution

 

We have a cloud native triangle composed of:

 

1. Speed of change (I refer to this as agility in that doc but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff

 

From those core requirements we can rationalize containerization, microservices and continuous delivery.

 

From those 'practices' we can talk about specific tools.

 

Where we fall down is when we start from the tools, but obviously a large part of getting things right (especially microservices I would argue) require pink matter.

 

On Tue, Feb 14, 2017 at 10:09 AM Alexis Richardson <alexis@...> wrote:

yes

 

we need to develop a cloud native brand that has values which developers want

 

- free & open 

- automated pipelines

- faster to make changes

- ..?

 

 

On Tue, Feb 14, 2017 at 10:07 AM Mark Coleman <mark@...> wrote:

I like the model of bringing in end user stories to support the point being made.

 

The point here clearly seems to be "it's ok to move all your shit to the cloud snd figure it out there" which is an unsurprising position for AWS to take. This is not an opposing point to our mission(TM) though so I will explore this.

 

Right now I'm mainly concerned that our definition of cloud native is not everyone else's.

 

On Thu, Feb 2, 2017 at 1:34 AM Alexis Richardson <alexis@...> wrote:

I thought this was worth sharing as an example of the sort of tech-biz guidance that members of the CNCF community could write.  The piece is by someone from AWS and talks about cloud native vs other cloudy things.

 

 

--

 

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


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

 

--

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

--

Andrew Randall

CEO

Tigera, Inc.


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

 


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

 


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

 

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

--

Andrew Randall

CEO

Tigera, Inc.

510-520-0999


Re: Interesting tech marketing from Amazon

Andrew Randall
 

I agree the emphasis of our outbound messaging should be on the why (and the "what's in it for me?"). And Yaron's suggestion of "because it gets you business agility through continuous dev and ops") sounds good to me as a first stab in that direction. That's good marketing. It will certainly get someone interested if they hear that cloud native will help them make their business more agile.

However we also, I think, must define what "cloud native" actually is. Because once you've got them sold that cloud native has the right kind of attributes, they will want to know what it actually means to implement it. And if the answer is "cloud native is anything that makes your business more agile" or just "continuous dev and ops" (with nothing to explain how that's achieved) then we will be perceived as nothing more than a marketing organization with no technical credibility.

At the risk of being controversial I would posit that has the following implications::
1) we must be somewhat opinionated about what makes something "cloud native" -- otherwise everything is cloud native (that obviously doesn't mean we have to say "you must use some specific technology" to be cloud native)
2) without a litmus test that most legacy apps and infrastructure technologies fail, then it is meaningless
3) similarly, in order to be meaningful, it must be possible for cloud native as we currently define it to be made obsolete in the future. (At which point we can wind down or redefine our mission -- but if our definition of cloud native continues to work whatever the developments in technology in the future, then it's not specific enough.)

I really want CNCF to be perceived as relevant and pointing the way for the industry. If we just churn out platitudes (aka motherhood and apple pie) we will fail.

Andy


On Fri, Feb 17, 2017 at 2:43 PM Yaron Haviv via cncf-toc <cncf-toc@...> wrote:

If anyone care to watch Simon’s talk pointed by Tony: "people don't buy WHAT you do, but WHY you do it", Containers, micro-services, .. are the what, my point is we should focus on the Why

 

i.e. Why cloud-native? = e.g. enable biz agility through continuous dev & ops (or any other suggestion)

Note that other points below like resiliency,  speed of change,  dynamic scaling ..  All fall under a bigger message of continuous dev & ops which solves the biggest challenge biz have: faster and sustainable digital transformation at lower budgets 

 

The tech can be containers today, maybe server-less functions or whatever tomorrow, the key is the collaboration and standardization driven by CNCF to reduce friction and complexity in the new stack

 

Yaron

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Kitson, Clinton via cncf-toc
Sent: Friday, February 17, 2017 11:17 PM
To: Brian Grant <briangrant@...>; Tony Hsu <gosharplite@...>


Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon

 

 

I agree with some earlier comments about being too opinionated. A broad definition could be "a computing environment focused on optimizing for applications in cloud operating models". This feels like the most natural and direct way to define cloud native computing while ensuring the relevance to how we are seeing people make use of it today and tomorrow.

 

The definition leads to a lot of what was discussed in this thread.

- Requirements (interoperability/composability, automation/orchestration)

- Patterns (micro-services, scale-out, DevOps, CI)

- Components (cncf landscape)

- Benefits/features (resilience, scale, efficiency, resilience, portability)

 

 

 

 

Clint Kitson

Technical Director

{code} by Dell EMC

--- 

mobile: "+1 424 645 4116"

team: codeDellEMC.com

twitter: "@clintonskitson"


From: cncf-toc-bounces@... [cncf-toc-bounces@...] on behalf of Brian Grant via cncf-toc [cncf-toc@...]
Sent: Friday, February 17, 2017 12:32 PM
To: Tony Hsu
Cc: Alexis Richardson via cncf-toc
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon

 

On Feb 17, 2017 2:00 AM, "Tony Hsu via cncf-toc" <cncf-toc@...> wrote:

As a big fan of Joe Beta and Craig McLuckie, my three ingredients for cloud-native operations are containers, orchestrators and microservice frameworks. These three terms come from Craig's post announcing the start of Heptio. https://goo.gl/aJgiQk

 

+1

 

That's very concrete, and provides a framework for explaining what and why.

 

 

Our limbic brains are responsible for all of our feelings, like trust and loyalty. It's also responsible for all human behavior, all decision-making, and it has no capacity for language. Please don't rely on logic and facts, it just doesn't drive behavior.

 

I got this from Simon Sinek's TED talk 'How great leaders inspire action'. https://goo.gl/EsJRvy

 

Regards,

Tony Hsu

 

On Fri, Feb 17, 2017 at 4:37 PM, Yaron Haviv via cncf-toc <cncf-toc@...> wrote:

I think the key message of Cloud-Native should be about its value:

Continuous Development and Operation (Enabling Business Agility/Transformation)  

 

Decomposition to micro-services, stateless, disposable/distributed components, Atomicity .. are the ways by which we achieve that goal, and those may evolve over time. If we want to engage more business owners lets focus on what’s in it for them and the need for a change vs tech buzzwords.   

 

My 2c, Yaron

CTO, iguazio  

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Brian Grant via cncf-toc
Sent: Friday, February 17, 2017 6:05 AM
To: Andrew Randall <
andy@...>
Cc: Alexis Richardson via cncf-toc <
cncf-toc@...>
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon

 

 

 

On Tue, Feb 14, 2017 at 10:37 AM, Andrew Randall via cncf-toc <cncf-toc@...> wrote:

think we should aim for 3 core principles. Any more than that and people won't be able to repeat as a mantra.

 

Currently the charter has:

- container packaged

- dynamically managed

- micro-services oriented.

 

I like Mark's comments. However, I worry about "massive scale" as a message. LOTS of people I talked with at CloudNativeCon and other shows recently have been doing fairly small scale deployments, but they're still cloud native. I think the nature of how we scale is important -- it's about the distributed, scale-out architectures that enable massive scale (but don't impose a cost burden for the small development shop that's running on a half dozen VMs in AWS).

 

I think "Dynamically scalable" captures that better.

 

Management includes scaling, so IMO "dynamically managed" implies dynamic scaling, as well as a higher rate of change than people had been accustomed to in the past.

 

In practice, the way this is achieved is through automation.

 

 

The inclusion of container-packaged and micro-services in the charter is an opinionated (and informed) stance about where the puck is headed.

 

 

So:

1. Speed of change

2. Resilience

3. Dynamically scalable

 

And you could add "built on open source foundation" as a fourth, or leave it implicit given the foundation nature of LF/CNCF.

 

Andy

 

 

 

On Tue, Feb 14, 2017 at 10:32 AM Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I agree that we may need to think more about how we communicate about microservices, but do we agree that the underlying purpose of cloud native is:

 

1. Speed of change (I used to refer to this as agility but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff

 

?

 

If we know what problems we're solving it will be easier to talk about specific practices and tools in a coherent manner.

 

On Tue, Feb 14, 2017 at 10:24 AM Camille Fournier <skamille@...> wrote:

Microservices are cloud native because they are a natural product of the ease of use for cloud. In a evolutionary way I would call them absolutely cloud native, which doesn't mean one must use them to effectively use the cloud but they do effectively show how cloud changed the way developers thought about building systems.

 

On Feb 14, 2017 10:22 AM, "Alexis Richardson via cncf-toc" <cncf-toc@...> wrote:

 

On Tue, Feb 14, 2017 at 10:20 AM Anthony Skipper <anthony@...> wrote:

I'd argue that if you had good tools, you wouldn't need microservices.

 

Yes, I don't think microservices is a core value.  It's one of several modern cloud native patterns that is useful for some organisational and technical issues.  But not the only one.

 

 

 

 

 

 

On Tue, Feb 14, 2017 at 1:15 PM, Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I think I summarised it in this piece that I ghost wrote for Luke when he was at ClusterHQ (Friend D A please): https://www.infoq.com/articles/microservices-revolution

 

We have a cloud native triangle composed of:

 

1. Speed of change (I refer to this as agility in that doc but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff

 

From those core requirements we can rationalize containerization, microservices and continuous delivery.

 

From those 'practices' we can talk about specific tools.

 

Where we fall down is when we start from the tools, but obviously a large part of getting things right (especially microservices I would argue) require pink matter.

 

On Tue, Feb 14, 2017 at 10:09 AM Alexis Richardson <alexis@...> wrote:

yes

 

we need to develop a cloud native brand that has values which developers want

 

- free & open 

- automated pipelines

- faster to make changes

- ..?

 

 

On Tue, Feb 14, 2017 at 10:07 AM Mark Coleman <mark@...> wrote:

I like the model of bringing in end user stories to support the point being made.

 

The point here clearly seems to be "it's ok to move all your shit to the cloud snd figure it out there" which is an unsurprising position for AWS to take. This is not an opposing point to our mission(TM) though so I will explore this.

 

Right now I'm mainly concerned that our definition of cloud native is not everyone else's.

 

On Thu, Feb 2, 2017 at 1:34 AM Alexis Richardson <alexis@...> wrote:

I thought this was worth sharing as an example of the sort of tech-biz guidance that members of the CNCF community could write.  The piece is by someone from AWS and talks about cloud native vs other cloudy things.

 

 

--

 

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


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

 

--

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

--

Andrew Randall

CEO

Tigera, Inc.


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

 


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

 


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

 

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
--
Andrew Randall
CEO
Tigera, Inc.
510-520-0999


Re: Interesting tech marketing from Amazon

Yaron Haviv
 

If anyone care to watch Simon’s talk pointed by Tony: "people don't buy WHAT you do, but WHY you do it", Containers, micro-services, .. are the what, my point is we should focus on the Why

 

i.e. Why cloud-native? = e.g. enable biz agility through continuous dev & ops (or any other suggestion)

Note that other points below like resiliency,  speed of change,  dynamic scaling ..  All fall under a bigger message of continuous dev & ops which solves the biggest challenge biz have: faster and sustainable digital transformation at lower budgets 

 

The tech can be containers today, maybe server-less functions or whatever tomorrow, the key is the collaboration and standardization driven by CNCF to reduce friction and complexity in the new stack

 

Yaron

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Kitson, Clinton via cncf-toc
Sent: Friday, February 17, 2017 11:17 PM
To: Brian Grant <briangrant@...>; Tony Hsu <gosharplite@...>
Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon

 

 

I agree with some earlier comments about being too opinionated. A broad definition could be "a computing environment focused on optimizing for applications in cloud operating models". This feels like the most natural and direct way to define cloud native computing while ensuring the relevance to how we are seeing people make use of it today and tomorrow.

 

The definition leads to a lot of what was discussed in this thread.

- Requirements (interoperability/composability, automation/orchestration)

- Patterns (micro-services, scale-out, DevOps, CI)

- Components (cncf landscape)

- Benefits/features (resilience, scale, efficiency, resilience, portability)

 

 

 

 

Clint Kitson

Technical Director

{code} by Dell EMC

--- 

mobile: "+1 424 645 4116"

team: codeDellEMC.com

twitter: "@clintonskitson"

github: github.com/clintonskitson


From: cncf-toc-bounces@... [cncf-toc-bounces@...] on behalf of Brian Grant via cncf-toc [cncf-toc@...]
Sent: Friday, February 17, 2017 12:32 PM
To: Tony Hsu
Cc: Alexis Richardson via cncf-toc
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon

 

On Feb 17, 2017 2:00 AM, "Tony Hsu via cncf-toc" <cncf-toc@...> wrote:

As a big fan of Joe Beta and Craig McLuckie, my three ingredients for cloud-native operations are containers, orchestrators and microservice frameworks. These three terms come from Craig's post announcing the start of Heptio. https://goo.gl/aJgiQk

 

+1

 

That's very concrete, and provides a framework for explaining what and why.

 

 

Our limbic brains are responsible for all of our feelings, like trust and loyalty. It's also responsible for all human behavior, all decision-making, and it has no capacity for language. Please don't rely on logic and facts, it just doesn't drive behavior.

 

I got this from Simon Sinek's TED talk 'How great leaders inspire action'. https://goo.gl/EsJRvy

 

Regards,

Tony Hsu

 

On Fri, Feb 17, 2017 at 4:37 PM, Yaron Haviv via cncf-toc <cncf-toc@...> wrote:

I think the key message of Cloud-Native should be about its value:

Continuous Development and Operation (Enabling Business Agility/Transformation)  

 

Decomposition to micro-services, stateless, disposable/distributed components, Atomicity .. are the ways by which we achieve that goal, and those may evolve over time. If we want to engage more business owners lets focus on what’s in it for them and the need for a change vs tech buzzwords.   

 

My 2c, Yaron

CTO, iguazio  

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Brian Grant via cncf-toc
Sent: Friday, February 17, 2017 6:05 AM
To: Andrew Randall <
andy@...>
Cc: Alexis Richardson via cncf-toc <
cncf-toc@...>
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon

 

 

 

On Tue, Feb 14, 2017 at 10:37 AM, Andrew Randall via cncf-toc <cncf-toc@...> wrote:

think we should aim for 3 core principles. Any more than that and people won't be able to repeat as a mantra.

 

Currently the charter has:

- container packaged

- dynamically managed

- micro-services oriented.

 

I like Mark's comments. However, I worry about "massive scale" as a message. LOTS of people I talked with at CloudNativeCon and other shows recently have been doing fairly small scale deployments, but they're still cloud native. I think the nature of how we scale is important -- it's about the distributed, scale-out architectures that enable massive scale (but don't impose a cost burden for the small development shop that's running on a half dozen VMs in AWS).

 

I think "Dynamically scalable" captures that better.

 

Management includes scaling, so IMO "dynamically managed" implies dynamic scaling, as well as a higher rate of change than people had been accustomed to in the past.

 

In practice, the way this is achieved is through automation.

 

 

The inclusion of container-packaged and micro-services in the charter is an opinionated (and informed) stance about where the puck is headed.

 

 

So:

1. Speed of change

2. Resilience

3. Dynamically scalable

 

And you could add "built on open source foundation" as a fourth, or leave it implicit given the foundation nature of LF/CNCF.

 

Andy

 

 

 

On Tue, Feb 14, 2017 at 10:32 AM Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I agree that we may need to think more about how we communicate about microservices, but do we agree that the underlying purpose of cloud native is:

 

1. Speed of change (I used to refer to this as agility but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff

 

?

 

If we know what problems we're solving it will be easier to talk about specific practices and tools in a coherent manner.

 

On Tue, Feb 14, 2017 at 10:24 AM Camille Fournier <skamille@...> wrote:

Microservices are cloud native because they are a natural product of the ease of use for cloud. In a evolutionary way I would call them absolutely cloud native, which doesn't mean one must use them to effectively use the cloud but they do effectively show how cloud changed the way developers thought about building systems.

 

On Feb 14, 2017 10:22 AM, "Alexis Richardson via cncf-toc" <cncf-toc@...> wrote:

 

On Tue, Feb 14, 2017 at 10:20 AM Anthony Skipper <anthony@...> wrote:

I'd argue that if you had good tools, you wouldn't need microservices.

 

Yes, I don't think microservices is a core value.  It's one of several modern cloud native patterns that is useful for some organisational and technical issues.  But not the only one.

 

 

 

 

 

 

On Tue, Feb 14, 2017 at 1:15 PM, Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I think I summarised it in this piece that I ghost wrote for Luke when he was at ClusterHQ (Friend D A please): https://www.infoq.com/articles/microservices-revolution

 

We have a cloud native triangle composed of:

 

1. Speed of change (I refer to this as agility in that doc but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff

 

From those core requirements we can rationalize containerization, microservices and continuous delivery.

 

From those 'practices' we can talk about specific tools.

 

Where we fall down is when we start from the tools, but obviously a large part of getting things right (especially microservices I would argue) require pink matter.

 

On Tue, Feb 14, 2017 at 10:09 AM Alexis Richardson <alexis@...> wrote:

yes

 

we need to develop a cloud native brand that has values which developers want

 

- free & open 

- automated pipelines

- faster to make changes

- ..?

 

 

On Tue, Feb 14, 2017 at 10:07 AM Mark Coleman <mark@...> wrote:

I like the model of bringing in end user stories to support the point being made.

 

The point here clearly seems to be "it's ok to move all your shit to the cloud snd figure it out there" which is an unsurprising position for AWS to take. This is not an opposing point to our mission(TM) though so I will explore this.

 

Right now I'm mainly concerned that our definition of cloud native is not everyone else's.

 

On Thu, Feb 2, 2017 at 1:34 AM Alexis Richardson <alexis@...> wrote:

I thought this was worth sharing as an example of the sort of tech-biz guidance that members of the CNCF community could write.  The piece is by someone from AWS and talks about cloud native vs other cloudy things.

 

 

--

 

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


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

 

--

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

--

Andrew Randall

CEO

Tigera, Inc.


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

 


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

 


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

 


Re: Interesting tech marketing from Amazon

Kitson, Clinton <Clinton.Kitson@...>
 


I agree with some earlier comments about being too opinionated. A broad definition could be "a computing environment focused on optimizing for applications in cloud operating models". This feels like the most natural and direct way to define cloud native computing while ensuring the relevance to how we are seeing people make use of it today and tomorrow.

The definition leads to a lot of what was discussed in this thread.
- Requirements (interoperability/composability, automation/orchestration)
- Patterns (micro-services, scale-out, DevOps, CI)
- Components (cncf landscape)
- Benefits/features (resilience, scale, efficiency, resilience, portability)




Clint Kitson
Technical Director
{code} by Dell EMC
--- 
email: Clinton.Kitson@...
mobile: "+1 424 645 4116"
team: codeDellEMC.com
twitter: "@clintonskitson"
github: github.com/clintonskitson


From: cncf-toc-bounces@... [cncf-toc-bounces@...] on behalf of Brian Grant via cncf-toc [cncf-toc@...]
Sent: Friday, February 17, 2017 12:32 PM
To: Tony Hsu
Cc: Alexis Richardson via cncf-toc
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon


On Feb 17, 2017 2:00 AM, "Tony Hsu via cncf-toc" <cncf-toc@...> wrote:
As a big fan of Joe Beta and Craig McLuckie, my three ingredients for cloud-native operations are containers, orchestrators and microservice frameworks. These three terms come from Craig's post announcing the start of Heptio. https://goo.gl/aJgiQk

+1

That's very concrete, and provides a framework for explaining what and why.


Our limbic brains are responsible for all of our feelings, like trust and loyalty. It's also responsible for all human behavior, all decision-making, and it has no capacity for language. Please don't rely on logic and facts, it just doesn't drive behavior.

I got this from Simon Sinek's TED talk 'How great leaders inspire action'. https://goo.gl/EsJRvy

Regards,
Tony Hsu

On Fri, Feb 17, 2017 at 4:37 PM, Yaron Haviv via cncf-toc <cncf-toc@...> wrote:

I think the key message of Cloud-Native should be about its value:

Continuous Development and Operation (Enabling Business Agility/Transformation)  

 

Decomposition to micro-services, stateless, disposable/distributed components, Atomicity .. are the ways by which we achieve that goal, and those may evolve over time. If we want to engage more business owners lets focus on what’s in it for them and the need for a change vs tech buzzwords.   

 

My 2c, Yaron

CTO, iguazio  

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@lists.cncf.io] On Behalf Of Brian Grant via cncf-toc
Sent: Friday, February 17, 2017 6:05 AM
To: Andrew Randall <andy@...>
Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon

 

 

 

On Tue, Feb 14, 2017 at 10:37 AM, Andrew Randall via cncf-toc <cncf-toc@...> wrote:

think we should aim for 3 core principles. Any more than that and people won't be able to repeat as a mantra.

 

Currently the charter has:

- container packaged

- dynamically managed

- micro-services oriented.

 

I like Mark's comments. However, I worry about "massive scale" as a message. LOTS of people I talked with at CloudNativeCon and other shows recently have been doing fairly small scale deployments, but they're still cloud native. I think the nature of how we scale is important -- it's about the distributed, scale-out architectures that enable massive scale (but don't impose a cost burden for the small development shop that's running on a half dozen VMs in AWS).

 

I think "Dynamically scalable" captures that better.

 

Management includes scaling, so IMO "dynamically managed" implies dynamic scaling, as well as a higher rate of change than people had been accustomed to in the past.

 

In practice, the way this is achieved is through automation.

 

 

The inclusion of container-packaged and micro-services in the charter is an opinionated (and informed) stance about where the puck is headed.

 

 

So:

1. Speed of change

2. Resilience

3. Dynamically scalable

 

And you could add "built on open source foundation" as a fourth, or leave it implicit given the foundation nature of LF/CNCF.

 

Andy

 

 

 

On Tue, Feb 14, 2017 at 10:32 AM Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I agree that we may need to think more about how we communicate about microservices, but do we agree that the underlying purpose of cloud native is:

 

1. Speed of change (I used to refer to this as agility but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff

 

?

 

If we know what problems we're solving it will be easier to talk about specific practices and tools in a coherent manner.

 

On Tue, Feb 14, 2017 at 10:24 AM Camille Fournier <skamille@...> wrote:

Microservices are cloud native because they are a natural product of the ease of use for cloud. In a evolutionary way I would call them absolutely cloud native, which doesn't mean one must use them to effectively use the cloud but they do effectively show how cloud changed the way developers thought about building systems.

 

On Feb 14, 2017 10:22 AM, "Alexis Richardson via cncf-toc" <cncf-toc@...> wrote:

 

On Tue, Feb 14, 2017 at 10:20 AM Anthony Skipper <anthony@...> wrote:

I'd argue that if you had good tools, you wouldn't need microservices.

 

Yes, I don't think microservices is a core value.  It's one of several modern cloud native patterns that is useful for some organisational and technical issues.  But not the only one.

 

 

 

 

 

 

On Tue, Feb 14, 2017 at 1:15 PM, Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I think I summarised it in this piece that I ghost wrote for Luke when he was at ClusterHQ (Friend D A please): https://www.infoq.com/articles/microservices-revolution

 

We have a cloud native triangle composed of:

 

1. Speed of change (I refer to this as agility in that doc but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff

 

From those core requirements we can rationalize containerization, microservices and continuous delivery.

 

From those 'practices' we can talk about specific tools.

 

Where we fall down is when we start from the tools, but obviously a large part of getting things right (especially microservices I would argue) require pink matter.

 

On Tue, Feb 14, 2017 at 10:09 AM Alexis Richardson <alexis@...> wrote:

yes

 

we need to develop a cloud native brand that has values which developers want

 

- free & open 

- automated pipelines

- faster to make changes

- ..?

 

 

On Tue, Feb 14, 2017 at 10:07 AM Mark Coleman <mark@...> wrote:

I like the model of bringing in end user stories to support the point being made.

 

The point here clearly seems to be "it's ok to move all your shit to the cloud snd figure it out there" which is an unsurprising position for AWS to take. This is not an opposing point to our mission(TM) though so I will explore this.

 

Right now I'm mainly concerned that our definition of cloud native is not everyone else's.

 

On Thu, Feb 2, 2017 at 1:34 AM Alexis Richardson <alexis@...> wrote:

I thought this was worth sharing as an example of the sort of tech-biz guidance that members of the CNCF community could write.  The piece is by someone from AWS and talks about cloud native vs other cloudy things.

 

 

--

 

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


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

 

--

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

--

Andrew Randall

CEO

Tigera, Inc.


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

 


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



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



Re: Interesting tech marketing from Amazon

Brian Grant
 


On Feb 17, 2017 2:00 AM, "Tony Hsu via cncf-toc" <cncf-toc@...> wrote:
As a big fan of Joe Beta and Craig McLuckie, my three ingredients for cloud-native operations are containers, orchestrators and microservice frameworks. These three terms come from Craig's post announcing the start of Heptio. https://goo.gl/aJgiQk

+1

That's very concrete, and provides a framework for explaining what and why.


Our limbic brains are responsible for all of our feelings, like trust and loyalty. It's also responsible for all human behavior, all decision-making, and it has no capacity for language. Please don't rely on logic and facts, it just doesn't drive behavior.

I got this from Simon Sinek's TED talk 'How great leaders inspire action'. https://goo.gl/EsJRvy

Regards,
Tony Hsu

On Fri, Feb 17, 2017 at 4:37 PM, Yaron Haviv via cncf-toc <cncf-toc@...> wrote:

I think the key message of Cloud-Native should be about its value:

Continuous Development and Operation (Enabling Business Agility/Transformation)  

 

Decomposition to micro-services, stateless, disposable/distributed components, Atomicity .. are the ways by which we achieve that goal, and those may evolve over time. If we want to engage more business owners lets focus on what’s in it for them and the need for a change vs tech buzzwords.   

 

My 2c, Yaron

CTO, iguazio  

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@lists.cncf.io] On Behalf Of Brian Grant via cncf-toc
Sent: Friday, February 17, 2017 6:05 AM
To: Andrew Randall <andy@...>
Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon

 

 

 

On Tue, Feb 14, 2017 at 10:37 AM, Andrew Randall via cncf-toc <cncf-toc@...> wrote:

think we should aim for 3 core principles. Any more than that and people won't be able to repeat as a mantra.

 

Currently the charter has:

- container packaged

- dynamically managed

- micro-services oriented.

 

I like Mark's comments. However, I worry about "massive scale" as a message. LOTS of people I talked with at CloudNativeCon and other shows recently have been doing fairly small scale deployments, but they're still cloud native. I think the nature of how we scale is important -- it's about the distributed, scale-out architectures that enable massive scale (but don't impose a cost burden for the small development shop that's running on a half dozen VMs in AWS).

 

I think "Dynamically scalable" captures that better.

 

Management includes scaling, so IMO "dynamically managed" implies dynamic scaling, as well as a higher rate of change than people had been accustomed to in the past.

 

In practice, the way this is achieved is through automation.

 

 

The inclusion of container-packaged and micro-services in the charter is an opinionated (and informed) stance about where the puck is headed.

 

 

So:

1. Speed of change

2. Resilience

3. Dynamically scalable

 

And you could add "built on open source foundation" as a fourth, or leave it implicit given the foundation nature of LF/CNCF.

 

Andy

 

 

 

On Tue, Feb 14, 2017 at 10:32 AM Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I agree that we may need to think more about how we communicate about microservices, but do we agree that the underlying purpose of cloud native is:

 

1. Speed of change (I used to refer to this as agility but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff

 

?

 

If we know what problems we're solving it will be easier to talk about specific practices and tools in a coherent manner.

 

On Tue, Feb 14, 2017 at 10:24 AM Camille Fournier <skamille@...> wrote:

Microservices are cloud native because they are a natural product of the ease of use for cloud. In a evolutionary way I would call them absolutely cloud native, which doesn't mean one must use them to effectively use the cloud but they do effectively show how cloud changed the way developers thought about building systems.

 

On Feb 14, 2017 10:22 AM, "Alexis Richardson via cncf-toc" <cncf-toc@...> wrote:

 

On Tue, Feb 14, 2017 at 10:20 AM Anthony Skipper <anthony@...> wrote:

I'd argue that if you had good tools, you wouldn't need microservices.

 

Yes, I don't think microservices is a core value.  It's one of several modern cloud native patterns that is useful for some organisational and technical issues.  But not the only one.

 

 

 

 

 

 

On Tue, Feb 14, 2017 at 1:15 PM, Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I think I summarised it in this piece that I ghost wrote for Luke when he was at ClusterHQ (Friend D A please): https://www.infoq.com/articles/microservices-revolution

 

We have a cloud native triangle composed of:

 

1. Speed of change (I refer to this as agility in that doc but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff

 

From those core requirements we can rationalize containerization, microservices and continuous delivery.

 

From those 'practices' we can talk about specific tools.

 

Where we fall down is when we start from the tools, but obviously a large part of getting things right (especially microservices I would argue) require pink matter.

 

On Tue, Feb 14, 2017 at 10:09 AM Alexis Richardson <alexis@...> wrote:

yes

 

we need to develop a cloud native brand that has values which developers want

 

- free & open 

- automated pipelines

- faster to make changes

- ..?

 

 

On Tue, Feb 14, 2017 at 10:07 AM Mark Coleman <mark@...> wrote:

I like the model of bringing in end user stories to support the point being made.

 

The point here clearly seems to be "it's ok to move all your shit to the cloud snd figure it out there" which is an unsurprising position for AWS to take. This is not an opposing point to our mission(TM) though so I will explore this.

 

Right now I'm mainly concerned that our definition of cloud native is not everyone else's.

 

On Thu, Feb 2, 2017 at 1:34 AM Alexis Richardson <alexis@...> wrote:

I thought this was worth sharing as an example of the sort of tech-biz guidance that members of the CNCF community could write.  The piece is by someone from AWS and talks about cloud native vs other cloudy things.

 

 

--

 

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


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

 

--

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

--

Andrew Randall

CEO

Tigera, Inc.


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

 


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



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



Re: important updates re TOC meeting scheduling & agenda in future

Lee Calcote
 

+1 for Thursdays at the same time.

- Lee
 

On Feb 16, 2017, at 5:58 PM, Weaver, Nicholas via cncf-toc <cncf-toc@...> wrote:

Either works for me
 
 
-- 
 
Nicholas Weaver
Director - Software Engineering
Intel, Datacenter Solutions Group
 
From: <cncf-toc-bounces@...> on behalf of Camille Fournier via cncf-toc <cncf-toc@...>
Reply-To: Camille Fournier <skamille@...>
Date: Thursday, February 16, 2017 at 3:05 PM
To: Brian Grant <briangrant@...>
Cc: "cncf-toc@..." <cncf-toc@...>
Subject: Re: [cncf-toc] important updates re TOC meeting scheduling & agenda in future
 
I'm flexible
 
On Feb 16, 2017 2:58 PM, "Brian Grant via cncf-toc" <cncf-toc@...> wrote:
These times/days would work for me, thanks.
 
On Thu, Feb 16, 2017 at 11:49 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
TOC members, 
 
We talked about moving the fortnightly TOC calls to another day.  My own preference would be Thursday, with Tuesday as second choice.  Please can we stick with the 8am PT / 11am ET / 4pm UK / 5pm DE slot.  WDYT?
 
TOC community,
 
We are past the bootstrap phase.  The CNCF now has multiple projects, with more to come in 2017.  Now we need to flesh out details of stuff like CI.  And we need to make sure we are nurturing existing projects well.  
 
To that end - the TOC is keen to (a) have more 'working' meetings covering special topics, and (b) involve you more in pre-meeting agenda setting via public channels.  Please be outspoken and demand participation.
 
alexis
 
 
 
 
 


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

 


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

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


Re: Interesting tech marketing from Amazon

Tony Hsu
 

As a big fan of Joe Beta and Craig McLuckie, my three ingredients for cloud-native operations are containers, orchestrators and microservice frameworks. These three terms come from Craig's post announcing the start of Heptio. https://goo.gl/aJgiQk

Our limbic brains are responsible for all of our feelings, like trust and loyalty. It's also responsible for all human behavior, all decision-making, and it has no capacity for language. Please don't rely on logic and facts, it just doesn't drive behavior.

I got this from Simon Sinek's TED talk 'How great leaders inspire action'. https://goo.gl/EsJRvy

Regards,
Tony Hsu

On Fri, Feb 17, 2017 at 4:37 PM, Yaron Haviv via cncf-toc <cncf-toc@...> wrote:

I think the key message of Cloud-Native should be about its value:

Continuous Development and Operation (Enabling Business Agility/Transformation)  

 

Decomposition to micro-services, stateless, disposable/distributed components, Atomicity .. are the ways by which we achieve that goal, and those may evolve over time. If we want to engage more business owners lets focus on what’s in it for them and the need for a change vs tech buzzwords.   

 

My 2c, Yaron

CTO, iguazio  

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@lists.cncf.io] On Behalf Of Brian Grant via cncf-toc
Sent: Friday, February 17, 2017 6:05 AM
To: Andrew Randall <andy@...>
Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon

 

 

 

On Tue, Feb 14, 2017 at 10:37 AM, Andrew Randall via cncf-toc <cncf-toc@...> wrote:

think we should aim for 3 core principles. Any more than that and people won't be able to repeat as a mantra.

 

Currently the charter has:

- container packaged

- dynamically managed

- micro-services oriented.

 

I like Mark's comments. However, I worry about "massive scale" as a message. LOTS of people I talked with at CloudNativeCon and other shows recently have been doing fairly small scale deployments, but they're still cloud native. I think the nature of how we scale is important -- it's about the distributed, scale-out architectures that enable massive scale (but don't impose a cost burden for the small development shop that's running on a half dozen VMs in AWS).

 

I think "Dynamically scalable" captures that better.

 

Management includes scaling, so IMO "dynamically managed" implies dynamic scaling, as well as a higher rate of change than people had been accustomed to in the past.

 

In practice, the way this is achieved is through automation.

 

 

The inclusion of container-packaged and micro-services in the charter is an opinionated (and informed) stance about where the puck is headed.

 

 

So:

1. Speed of change

2. Resilience

3. Dynamically scalable

 

And you could add "built on open source foundation" as a fourth, or leave it implicit given the foundation nature of LF/CNCF.

 

Andy

 

 

 

On Tue, Feb 14, 2017 at 10:32 AM Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I agree that we may need to think more about how we communicate about microservices, but do we agree that the underlying purpose of cloud native is:

 

1. Speed of change (I used to refer to this as agility but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff

 

?

 

If we know what problems we're solving it will be easier to talk about specific practices and tools in a coherent manner.

 

On Tue, Feb 14, 2017 at 10:24 AM Camille Fournier <skamille@...> wrote:

Microservices are cloud native because they are a natural product of the ease of use for cloud. In a evolutionary way I would call them absolutely cloud native, which doesn't mean one must use them to effectively use the cloud but they do effectively show how cloud changed the way developers thought about building systems.

 

On Feb 14, 2017 10:22 AM, "Alexis Richardson via cncf-toc" <cncf-toc@...> wrote:

 

On Tue, Feb 14, 2017 at 10:20 AM Anthony Skipper <anthony@...> wrote:

I'd argue that if you had good tools, you wouldn't need microservices.

 

Yes, I don't think microservices is a core value.  It's one of several modern cloud native patterns that is useful for some organisational and technical issues.  But not the only one.

 

 

 

 

 

 

On Tue, Feb 14, 2017 at 1:15 PM, Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I think I summarised it in this piece that I ghost wrote for Luke when he was at ClusterHQ (Friend D A please): https://www.infoq.com/articles/microservices-revolution

 

We have a cloud native triangle composed of:

 

1. Speed of change (I refer to this as agility in that doc but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff

 

From those core requirements we can rationalize containerization, microservices and continuous delivery.

 

From those 'practices' we can talk about specific tools.

 

Where we fall down is when we start from the tools, but obviously a large part of getting things right (especially microservices I would argue) require pink matter.

 

On Tue, Feb 14, 2017 at 10:09 AM Alexis Richardson <alexis@...> wrote:

yes

 

we need to develop a cloud native brand that has values which developers want

 

- free & open 

- automated pipelines

- faster to make changes

- ..?

 

 

On Tue, Feb 14, 2017 at 10:07 AM Mark Coleman <mark@...> wrote:

I like the model of bringing in end user stories to support the point being made.

 

The point here clearly seems to be "it's ok to move all your shit to the cloud snd figure it out there" which is an unsurprising position for AWS to take. This is not an opposing point to our mission(TM) though so I will explore this.

 

Right now I'm mainly concerned that our definition of cloud native is not everyone else's.

 

On Thu, Feb 2, 2017 at 1:34 AM Alexis Richardson <alexis@...> wrote:

I thought this was worth sharing as an example of the sort of tech-biz guidance that members of the CNCF community could write.  The piece is by someone from AWS and talks about cloud native vs other cloudy things.

 

 

--

 

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


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

 

--

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

--

Andrew Randall

CEO

Tigera, Inc.


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

 


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



Re: Interesting tech marketing from Amazon

Yaron Haviv
 

I think the key message of Cloud-Native should be about its value:

Continuous Development and Operation (Enabling Business Agility/Transformation)  

 

Decomposition to micro-services, stateless, disposable/distributed components, Atomicity .. are the ways by which we achieve that goal, and those may evolve over time. If we want to engage more business owners lets focus on what’s in it for them and the need for a change vs tech buzzwords.   

 

My 2c, Yaron

CTO, iguazio  

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Brian Grant via cncf-toc
Sent: Friday, February 17, 2017 6:05 AM
To: Andrew Randall <andy@...>
Cc: Alexis Richardson via cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon

 

 

 

On Tue, Feb 14, 2017 at 10:37 AM, Andrew Randall via cncf-toc <cncf-toc@...> wrote:

think we should aim for 3 core principles. Any more than that and people won't be able to repeat as a mantra.

 

Currently the charter has:

- container packaged

- dynamically managed

- micro-services oriented.

 

I like Mark's comments. However, I worry about "massive scale" as a message. LOTS of people I talked with at CloudNativeCon and other shows recently have been doing fairly small scale deployments, but they're still cloud native. I think the nature of how we scale is important -- it's about the distributed, scale-out architectures that enable massive scale (but don't impose a cost burden for the small development shop that's running on a half dozen VMs in AWS).

 

I think "Dynamically scalable" captures that better.

 

Management includes scaling, so IMO "dynamically managed" implies dynamic scaling, as well as a higher rate of change than people had been accustomed to in the past.

 

In practice, the way this is achieved is through automation.

 

 

The inclusion of container-packaged and micro-services in the charter is an opinionated (and informed) stance about where the puck is headed.

 

 

So:

1. Speed of change

2. Resilience

3. Dynamically scalable

 

And you could add "built on open source foundation" as a fourth, or leave it implicit given the foundation nature of LF/CNCF.

 

Andy

 

 

 

On Tue, Feb 14, 2017 at 10:32 AM Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I agree that we may need to think more about how we communicate about microservices, but do we agree that the underlying purpose of cloud native is:

 

1. Speed of change (I used to refer to this as agility but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff

 

?

 

If we know what problems we're solving it will be easier to talk about specific practices and tools in a coherent manner.

 

On Tue, Feb 14, 2017 at 10:24 AM Camille Fournier <skamille@...> wrote:

Microservices are cloud native because they are a natural product of the ease of use for cloud. In a evolutionary way I would call them absolutely cloud native, which doesn't mean one must use them to effectively use the cloud but they do effectively show how cloud changed the way developers thought about building systems.

 

On Feb 14, 2017 10:22 AM, "Alexis Richardson via cncf-toc" <cncf-toc@...> wrote:

 

On Tue, Feb 14, 2017 at 10:20 AM Anthony Skipper <anthony@...> wrote:

I'd argue that if you had good tools, you wouldn't need microservices.

 

Yes, I don't think microservices is a core value.  It's one of several modern cloud native patterns that is useful for some organisational and technical issues.  But not the only one.

 

 

 

 

 

 

On Tue, Feb 14, 2017 at 1:15 PM, Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I think I summarised it in this piece that I ghost wrote for Luke when he was at ClusterHQ (Friend D A please): https://www.infoq.com/articles/microservices-revolution

 

We have a cloud native triangle composed of:

 

1. Speed of change (I refer to this as agility in that doc but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff

 

From those core requirements we can rationalize containerization, microservices and continuous delivery.

 

From those 'practices' we can talk about specific tools.

 

Where we fall down is when we start from the tools, but obviously a large part of getting things right (especially microservices I would argue) require pink matter.

 

On Tue, Feb 14, 2017 at 10:09 AM Alexis Richardson <alexis@...> wrote:

yes

 

we need to develop a cloud native brand that has values which developers want

 

- free & open 

- automated pipelines

- faster to make changes

- ..?

 

 

On Tue, Feb 14, 2017 at 10:07 AM Mark Coleman <mark@...> wrote:

I like the model of bringing in end user stories to support the point being made.

 

The point here clearly seems to be "it's ok to move all your shit to the cloud snd figure it out there" which is an unsurprising position for AWS to take. This is not an opposing point to our mission(TM) though so I will explore this.

 

Right now I'm mainly concerned that our definition of cloud native is not everyone else's.

 

On Thu, Feb 2, 2017 at 1:34 AM Alexis Richardson <alexis@...> wrote:

I thought this was worth sharing as an example of the sort of tech-biz guidance that members of the CNCF community could write.  The piece is by someone from AWS and talks about cloud native vs other cloudy things.

 

 

--

 

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


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

 

--

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

--

Andrew Randall

CEO

Tigera, Inc.


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

 

6521 - 6540 of 7182