Date   

Reminder: CNCF TOC Weekly Meeting (February 15, 2017)

Brett Preston <bpreston@...>
 

CNCF TOC Community,

Reminder that the TOC will be meeting on Wednesday, February 15, from 3:40pm - 5:10pm PT sharp.

Dial-in: https://www.uberconference.com/cloudnative or +1-415-579-0198 No PIN

For those in Lake Tahoe for the Open Source Leadership Summit, you are welcome to join the meeting in person: Meeting Room: Castle Peak A

Thank you,


Brett

--
Brett Preston
The Linux Foundation
+1 (971) 303-9030
bpreston@...

Google Talk: bpreston@...
Skype: bprestoncf


Re: Interesting tech marketing from Amazon

Scott McCarty
 

On 02/14/2017 01:41 PM, Mark Coleman via cncf-toc wrote:
Andy, I like dynamically scalable. That's much better.
Dynamic, or horizontal....

I'd also like to add that what we're proposing here is that people can get any /or all/ of those 3 by going cloud native. I think that's an important distinction.

On Tue, Feb 14, 2017 at 10:40 AM Dustin Kirkland <kirkland@... <mailto:kirkland@...>> wrote:

On Tue, Feb 14, 2017 at 12:37 PM, Andrew Randall via cncf-toc
<cncf-toc@... <mailto: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.

Agreed. I can only remember about 3 of the 12-factors :-)

--
+31 652134960
CEO www.implicit-explicit.com <http://www.implicit-explicit.com>
Co-Founder www.softwarecircus.io <http://softwarecircus.io/>
Marketing Chair www.cncf.io <https://www.cncf.io/>


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

Scott McCarty, RHCA

Technical Product Marketing: Containers

Email: smccarty@...

Phone: 312-660-3535

Cell: 330-807-1043

Web: http://crunchtools.com

When should you split your application into multiple containers? http://red.ht/22xKw9i


Re: Interesting tech marketing from Amazon

Mark Coleman <mark@...>
 

Andy, I like dynamically scalable. That's much better.

I'd also like to add that what we're proposing here is that people can get any or all of those 3 by going cloud native. I think that's an important distinction.


On Tue, Feb 14, 2017 at 10:40 AM Dustin Kirkland <kirkland@...> wrote:
On Tue, Feb 14, 2017 at 12:37 PM, 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.

Agreed.  I can only remember about 3 of the 12-factors :-)
--
+31 652134960
Marketing Chair www.cncf.io


Re: Interesting tech marketing from Amazon

Dustin Kirkland <kirkland@...>
 

On Tue, Feb 14, 2017 at 12:37 PM, 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.
Agreed. I can only remember about 3 of the 12-factors :-)


Re: Interesting tech marketing from Amazon

Andrew Randall
 

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.

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.
510-520-0999


Re: Interesting tech marketing from Amazon

Mark Coleman <mark@...>
 

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


--
+31 652134960
Marketing Chair www.cncf.io


Re: Interesting tech marketing from Amazon

Camille Fournier
 

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



Re: Interesting tech marketing from Amazon

alexis richardson
 



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


Re: Interesting tech marketing from Amazon

Anthony Skipper <anthony@...>
 

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




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.


--
--
+31 652134960
Marketing Chair www.cncf.io

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



Re: Interesting tech marketing from Amazon

alexis richardson
 

Mark,

Those are good too :-)  Please see my reply to Dustin.  Can we come up with "5 values"?  (or is it 3? it can't be more than 5).  What are the key freedoms and capabilities that impact cloud native app developers at a primal/emotional level?  "I'm here because I love ..."

a


On Tue, Feb 14, 2017 at 10:15 AM Mark Coleman <mark@...> 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.


--
--


Re: Interesting tech marketing from Amazon

alexis richardson
 

I like those Dustin.

Can we come up with "5 values"?

Let's say that Sally is a developer, and thinking about attending a Cloud Native conference or meetup in 2017.  What are the shared values of the people whom she expects to meet there?  What is it about her "tribe" that makes it different from other communities?


On Tue, Feb 14, 2017 at 10:13 AM Dustin Kirkland <kirkland@...> wrote:
On Tue, Feb 14, 2017 at 12:09 PM, Alexis Richardson via cncf-toc
<cncf-toc@...> wrote:
> yes
>
> we need to develop a cloud native brand that has values which developers
> want
>
> - free & open
> - automated pipelines
> - faster to make changes
> - ..?

+1 to those.  Here are a few others:

 - interoperability with others
 - choice/plugability at every level
 - velocity, but stability


Re: Interesting tech marketing from Amazon

Mark Coleman <mark@...>
 

*but obviously = *because obviously


On Tue, Feb 14, 2017 at 10:15 AM Mark Coleman <mark@...> 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.


--
--
--
+31 652134960
Marketing Chair www.cncf.io


Re: Interesting tech marketing from Amazon

Mark Coleman <mark@...>
 

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.


--
--
+31 652134960
Marketing Chair www.cncf.io


Re: Interesting tech marketing from Amazon

Dustin Kirkland <kirkland@...>
 

On Tue, Feb 14, 2017 at 12:09 PM, Alexis Richardson via cncf-toc
<cncf-toc@...> wrote:
yes

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

- free & open
- automated pipelines
- faster to make changes
- ..?
+1 to those. Here are a few others:

- interoperability with others
- choice/plugability at every level
- velocity, but stability


Re: Interesting tech marketing from Amazon

alexis richardson
 

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.


--


Re: Interesting tech marketing from Amazon

Mark Coleman <mark@...>
 

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.


--
+31 652134960
Marketing Chair www.cncf.io


Re: RFC: CNCF TOC Meeting at OSLC Tahoe 2017

alexis richardson
 

Bump on this.


On Wed, Jan 18, 2017 at 4:10 PM Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
The TOC requested that we work together on planning an agenda for the TOC F2F in Tahoe:


Feel free to modify and suggest topics for the agenda.

--
Chris Aniszczyk (@cra) | +1-512-961-6719
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: [cncf-gb] Mudslide closes I-80 near Truckee in both directions - SFGate

Bercovici, Val <Valentin.Bercovici@...>
 

Yes, for those not local – it has been a record-breaking winter season of snow & rain in Tahoe / Squaw.  Avalanches and mudlines have therefore been regular occurrences.  On the bright side – It looks like the weather is clearing for Monday’s arrival as well as Tuesday & Wednesday.  Thursday is another story ;)

 

Whether you’re driving in from Reno airport or the Bay Area, it’s worth checking Google Maps for I-80 road closures as well as a site like this with live webcams:

·         http://www.magnifeye.com/webcams.php

 

Have a great trip in and see you there!

 

Valentin Bercovici | CTO | SolidFire

+1 408 718 5208 | @valb00

 

 

From: <cncf-gb-bounces@...> on behalf of Alexis Richardson via cncf-gb <cncf-gb@...>
Reply-To: Alexis Richardson <alexis@...>
Date: Saturday, February 11, 2017 at 1:57 AM
To: Alexis Richardson via cncf-toc <cncf-toc@...>, "cncf-gb@..." <cncf-gb@...>
Subject: [cncf-gb] Mudslide closes I-80 near Truckee in both directions - SFGate

 


Mudslide closes I-80 near Truckee in both directions - SFGate

alexis richardson
 


[cncf-kubernetescertwg] K8s Certification Update - February 10, 2017 (plain text)

Dan Kohn <dan@...>
 

I'm forwarding the Kubernetes certification update because I know there's a wide interest in the status. If you'd like to keep up-to-date going forward, please subscribe to the Kubernetes Certification Working Group list (https://lists.cncf.io/mailman/listinfo/cncf-kubernetescertwg). 
-- 
Dan Kohn <mailto:dan@...>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000

---------- Forwarded message ----------
From: Liz Kline <lkline@...>
Date: Fri, Feb 10, 2017 at 12:56 PM
Subject: [cncf-kubernetescertwg] K8s Certification Update - February 10, 2017 (plain text)
To: cncf-kubernetescertwg@...


Hello Kubernetes Certification Working Group!

In November, the Cloud Native Computing Foundation (CNCF) launched (https://www.linuxfoundation.org/announcements/cloud-native-computing-foundation-launches-certification-training-and-managed-service) a new training, certification and Kubernetes Managed Service Provider (KMSP) program (http://blog.kubernetes.io/2016/10/kubernetes-service-technology-partners-program.html). Since that announcement, a team of K8s experts have been busy defining an online, proctored certification program to be run by The Linux Foundation for CNCF. Below is an update on the certification progress so far.

We are still looking for volunteers to help with beta testing the exams. If you have interest and expertise please consider subscribing to the Kubernetes Certification Working Group list (https://lists.cncf.io/mailman/listinfo/cncf-kubernetescertwg). We’ll be reaching out to volunteers as the process progresses.

Overview
* The exam will be performance-based (i.e. live system) which candidates have to operate
* Job Task Analysis (JTA) Committee of K8s community experts met in Dec 2016 and defined the overall scope, topics for the exams as well as drafted the exam items
* Team is currently working on setting up an environment that can be automatically deployed for each candidate
* In parallel, work has started to to develop the automated scripts to setup and grade the exam items
* Currently forecasting to field test in May and publicly launch in June

Scope Definition for the Certified Kubernetes Administrator (CKA) exam
A certified K8s administrator can work proficiently to design, install, configure, and manage a Kubernetes production-grade cluster.  They will have an understanding of key concepts such as Kubernetes networking, storage, security, maintenance, logging and monitoring, application lifecycle, troubleshooting, API object primitives and the ability to establish basic use-cases for end users.  

JTA Development
13 K8s experts from 9 different companies participated in a facilitated 2-day DACUM (Developing a Curriculum) workshop in early December and defined: 
* 10 subject Domains and their % weight on the exam:
5%   Scheduling
5%   Logging / Monitoring
8%   Application Lifecycle Management
11% Cluster Maintenance
12% Security
7%   Storage
10%  Troubleshooting
19%  Core Concepts
11%  Networking
12%  Installation & Configuration
* 55 Topics, aka subdomains 
* The exam environment and technical specs
* An estimated exam length of 4 hours

Exam Item Development
14 K8s experts from 13 different companies participated in a second, intensive 2-day item writing workshop facilitated by a performance-based assessment expert in mid-December and:
* drafted 44 exam items based on the Domains and Topics defined during the JTA; items are logged in a private GitHub repo
* chose 34 of the best Items targeted for the exam by weighted Domain
* applied a difficulty rating of Easy, Moderate, Hard for each item
* agreed upon a K8s Exam environment proposal

Timeline for the Next Steps
* Exam item refinement is ongoing
* 10 week process to complete items set up, exam environment, and develop the grading scripts. (thru mid April). 
* 8 weeks post-setup to conduct the alpha/beta testing, determine passing score,and set up exam portal (mid April to early June)
* Exam launch targeted for the 2nd week of June

We’ve also made available (in partnership with The Linux Foundation) a self-paced online training course that aims to prepare users for the K8s exam. You can find details and sign up for it here: (https://training.linuxfoundation.org/linux-courses/system-administration-training/kubernetes-fundamentals).

Regards,
Liz Kline

Liz Kline
Certification Manager
The Linux Foundation
Skype:  liz.kline.co
m:  (512) 694-4605 (Central Time)
e:  lkline@...

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

6561 - 6580 of 7167