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
toggle quoted message
Show quoted text
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
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)
mobile: "+1 424 645 4116"
twitter: "@clintonskitson"
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
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.
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
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:
- 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.
And you could add "built on open source foundation" as a fourth, or leave it implicit given the foundation nature of LF/CNCF.
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
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
_______________________________________________
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
|
|
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
toggle quoted message
Show quoted text
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
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)
mobile: "+1 424 645 4116"
twitter: "@clintonskitson"
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
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.
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
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:
- 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.
And you could add "built on open source foundation" as a fourth, or leave it implicit given the foundation nature of LF/CNCF.
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
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
_______________________________________________
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
|
|
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
toggle quoted message
Show quoted text
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)
mobile: "+1 424 645 4116"
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
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.
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
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:
- 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.
And you could add "built on open source foundation" as a fourth, or leave it implicit given the foundation nature of LF/CNCF.
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
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
_______________________________________________
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
|
|
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
toggle quoted message
Show quoted text
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
+1
That's very concrete, and provides a framework for explaining what and why.
|
|
+1
That's very concrete, and provides a framework for explaining what and why.
|
|

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.
Regards, Tony Hsu
toggle quoted message
Show quoted text
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
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:
- 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.
And you could add "built on open source foundation" as a fourth, or leave it implicit given the foundation nature of LF/CNCF.
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
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
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
|
|
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
toggle quoted message
Show quoted text
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:
- 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.
And you could add "built on open source foundation" as a fourth, or leave it implicit given the foundation nature of LF/CNCF.
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
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
|
|
|
|
+1 I will follow up early next week.
toggle quoted message
Show quoted text
On Thu, Feb 16, 2017 at 11:31 AM Alexis Richardson via cncf-toc < cncf-toc@...> wrote: Joe, I think the marketing committee folks could happily use or repurpose ~CIO facing materials.
On Thu, Feb 16, 2017 at 11:28 AM Joe Beda < joe@...> wrote: This series was essentially a reworking of that. I tried to update it as I wrote it out.
This stuff was aimed at the ~CIO level so I tried to keep things approachable but real. Happy to go in to more depth if the discussion would be useful.
On Thu, Feb 16, 2017 at 11:27 AM Alexis Richardson <alexis@...> wrote:
Many thanks Joe! I thought that was a great series. Do you still have your cloud native white paper from last year, or do you consider that to be dated now?
On Thu, Feb 16, 2017 at 11:21 AM Joe Beda < joe@...> wrote: On Thu, Feb 16, 2017 at 10:25 AM Alexis Richardson via cncf-toc < cncf-toc@...> wrote: Just to wrap up this thread:
1) Thanks to everyone for the sparky contributions. This is clearly an area that matters to people.
2) During the GB & TOC meetings yesterday, it was decided to take steps to unify and write out the CNCF thinking on positioning. The CTA here is: please connect with Mark Coleman, marketing committee chair. On Tue, Feb 14, 2017 at 11:35 AM Scott McCarty via cncf-toc < cncf-toc@...> wrote:
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
_______________________________________________
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
|
|
Joe, I think the marketing committee folks could happily use or repurpose ~CIO facing materials.
toggle quoted message
Show quoted text
On Thu, Feb 16, 2017 at 11:28 AM Joe Beda < joe@...> wrote: This series was essentially a reworking of that. I tried to update it as I wrote it out.
This stuff was aimed at the ~CIO level so I tried to keep things approachable but real. Happy to go in to more depth if the discussion would be useful.
On Thu, Feb 16, 2017 at 11:27 AM Alexis Richardson <alexis@...> wrote:
Many thanks Joe! I thought that was a great series. Do you still have your cloud native white paper from last year, or do you consider that to be dated now?
On Thu, Feb 16, 2017 at 11:21 AM Joe Beda < joe@...> wrote: On Thu, Feb 16, 2017 at 10:25 AM Alexis Richardson via cncf-toc < cncf-toc@...> wrote: Just to wrap up this thread:
1) Thanks to everyone for the sparky contributions. This is clearly an area that matters to people.
2) During the GB & TOC meetings yesterday, it was decided to take steps to unify and write out the CNCF thinking on positioning. The CTA here is: please connect with Mark Coleman, marketing committee chair. On Tue, Feb 14, 2017 at 11:35 AM Scott McCarty via cncf-toc < cncf-toc@...> wrote:
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
_______________________________________________
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
|
|
This series was essentially a reworking of that. I tried to update it as I wrote it out.
This stuff was aimed at the ~CIO level so I tried to keep things approachable but real. Happy to go in to more depth if the discussion would be useful.
Joe
toggle quoted message
Show quoted text
On Thu, Feb 16, 2017 at 11:27 AM Alexis Richardson <alexis@...> wrote:
Many thanks Joe! I thought that was a great series. Do you still have your cloud native white paper from last year, or do you consider that to be dated now?
On Thu, Feb 16, 2017 at 11:21 AM Joe Beda < joe@...> wrote: On Thu, Feb 16, 2017 at 10:25 AM Alexis Richardson via cncf-toc < cncf-toc@...> wrote: Just to wrap up this thread:
1) Thanks to everyone for the sparky contributions. This is clearly an area that matters to people.
2) During the GB & TOC meetings yesterday, it was decided to take steps to unify and write out the CNCF thinking on positioning. The CTA here is: please connect with Mark Coleman, marketing committee chair. On Tue, Feb 14, 2017 at 11:35 AM Scott McCarty via cncf-toc < cncf-toc@...> wrote:
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
_______________________________________________
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
|
|
Many thanks Joe! I thought that was a great series. Do you still have your cloud native white paper from last year, or do you consider that to be dated now?
toggle quoted message
Show quoted text
On Thu, Feb 16, 2017 at 11:21 AM Joe Beda < joe@...> wrote: On Thu, Feb 16, 2017 at 10:25 AM Alexis Richardson via cncf-toc < cncf-toc@...> wrote: Just to wrap up this thread:
1) Thanks to everyone for the sparky contributions. This is clearly an area that matters to people.
2) During the GB & TOC meetings yesterday, it was decided to take steps to unify and write out the CNCF thinking on positioning. The CTA here is: please connect with Mark Coleman, marketing committee chair. On Tue, Feb 14, 2017 at 11:35 AM Scott McCarty via cncf-toc < cncf-toc@...> wrote:
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
_______________________________________________
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
|
|
toggle quoted message
Show quoted text
On Thu, Feb 16, 2017 at 10:25 AM Alexis Richardson via cncf-toc < cncf-toc@...> wrote: Just to wrap up this thread:
1) Thanks to everyone for the sparky contributions. This is clearly an area that matters to people.
2) During the GB & TOC meetings yesterday, it was decided to take steps to unify and write out the CNCF thinking on positioning. The CTA here is: please connect with Mark Coleman, marketing committee chair. On Tue, Feb 14, 2017 at 11:35 AM Scott McCarty via cncf-toc < cncf-toc@...> wrote:
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
_______________________________________________
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
|
|
Just to wrap up this thread:
1) Thanks to everyone for the sparky contributions. This is clearly an area that matters to people.
2) During the GB & TOC meetings yesterday, it was decided to take steps to unify and write out the CNCF thinking on positioning. The CTA here is: please connect with Mark Coleman, marketing committee chair.
alexis
toggle quoted message
Show quoted text
On Tue, Feb 14, 2017 at 11:35 AM Scott McCarty via cncf-toc < cncf-toc@...> wrote:
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
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
|
|
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.comWhen should you split your application into multiple containers? http://red.ht/22xKw9i
|
|
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.
toggle quoted message
Show quoted text
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 :-)
|
|
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 :-)
|
|
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.
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
toggle quoted message
Show quoted text
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.
--
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
--
Andrew Randall CEO Tigera, Inc. 510-520-0999
|
|
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.
toggle quoted message
Show quoted text
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.
|
|
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.
toggle quoted message
Show quoted text
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.
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
|
|