Date   

Re: audience for "reference architecture" content

Mark Balch <mark@...>
 

No worries…let me try to confirm my understanding.  You’re saying there is a control plane for cloud native infrastructure (includes the fabric you reference below) and a control plane for deploying apps on that infra?  And that the infrastructure must support multi-cloud federation.

 

I was thinking of these as being one overall control plane, though there could be some pieces unused in specific scenarios.  Example:

·        Deploy app consisting of N containers, with associated segmentation and storage policy in a specific container cluster

·        Deploy the same app across hybrid container cluster subject to security/placement/cost policy (to name a few), assuming the app is designed in such a way as to be deployable across federated clusters

 

In the first scenario, policies related to cluster federation would be ignored.  Certain control plane functions related to cluster federation may not be required in the second scenario.

 

Thoughts?

 

Thanks,

Mark

 

 

From: NASSAUR, DOUGLAS C [mailto:dn283x@...]
Sent: Friday, July 22, 2016 12:08 PM
To: mark@...
Cc: Alexis Richardson <alexis@...>; Alan Conley <aconley@...>; cncf-toc@...; Chris Aniszczyk <caniszczyk@...>
Subject: Re: [cncf-toc] audience for "reference architecture" content

 

Thanks Mark, got what you meant so apologies for not being clear. My primary point is that their are two separate and distinct paths which each exhibit the model-view-control reference pattern - one specific to the cloud native app fabric itself and the other for the 1-n app logic workloads under its management. Imo one can be left flexible while the other must be clearly defined in a manner which supports multi cloud federation above the infrastructure substrate. 

Regards, Doug


On Jul 22, 2016, at 1:59 PM, Mark Balch <mark@...> wrote:

By data plane, I meant the application data flow itself: code, runtime, OS, app data storage, app data connectivity (i.e., networking).  Models and policy are important aspects that can blur lines between data/control plane, but typically I see them more associated with the control plane because they usually direct how deployments occur in the data plane and how the data plane behaves (e.g., your segmentation scenario).  There may be situations where model/policy is more closely aligned to the data plane – I’m not seeking a rigid definition.

 

With respect to how networks are/not segmented between management and data, this is something I would expect the control plane policy model to allow for customer preference and not force either way. 

 

I agree with setting up a problem statement to define the ref arch context.  However, to the extent that a problem statement becomes a dictionary definition of what we’re trying to solve, it can become a protracted charter-defining type of process.  We might do both in parallel to not gate progress on the ref arch.  Disconnects can be resolve as the discussion unfolds.

 

Mark

 

 

From: NASSAUR, DOUGLAS C [mailto:dn283x@...]
Sent: Friday, July 22, 2016 10:44 AM
To: 'mark@...' <mark@...>; Alexis Richardson <alexis@...>; Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: RE: [cncf-toc] audience for "reference architecture" content

 

Would you consider “model” and control planes? It would be inclusive of “data” but also accommodates a larger context. Also, can we endeavor to capture the nano-segmentation aspects of container networking when differentiating the two planes?

 

Here’s the gap I’m hoping we address – Old days (few years ago) we had completely separate networks for both, current time we vlan/segment etc. Forward looking folks believe that by mapping vnic to vlan we can maintain the separation when we know that won’t work across WAN/routed, multi-cloud and IoT oriented networks.

 

Perhaps we can set up the problem statement via the ref architecture so the masses can see and digest it and then show how nano segmentation/CNI/CNM addresses it?

 

From: Mark Balch [mailto:mark@...]
Sent: Friday, July 22, 2016 1:36 PM
To: Alexis Richardson <alexis@...>; NASSAUR, DOUGLAS C <dn283x@...>; Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: RE: [cncf-toc] audience for "reference architecture" content

 

Using the airport analogy, airplanes and airports are an orthogonal to air traffic control, baggage routing, etc.  Back to our world, it's the difference between data and control planes. 

 

I'd like to suggest that our reference model make clear the management/control plane in addition to the data plane as depicted in the landscape doc.  Craig's original diagram blended the two together, which is useful because there is much work to be done in both areas.  Column 'C' has some thoughts in this area, though unfinished.

 

CNCF can at least define the boundaries and functions users should be aware of in how the application/infrastructure stack is deployed, configured, and managed.  Further, we can facilitate interoperability in the control plane.

 

If there are no violent disagreements, I'll put up a strawman.

 

Mark

 

 

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alexis Richardson via cncf-toc
Sent: Friday, July 22, 2016 10:31 AM
To: NASSAUR, DOUGLAS C <dn283x@...>; Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: Re: [cncf-toc] audience for "reference architecture" content

 

i actually like how you think about this Doug.  it is a great flag on the hill.  but can it work?  complete freedom for components combined with app dev productivity. 

 

On Fri, 22 Jul 2016, 18:28 NASSAUR, DOUGLAS C, <dn283x@...> wrote:

Any thoughts folks?

-----Original Message-----
From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of NASSAUR, DOUGLAS C via cncf-toc
Sent: Friday, July 22, 2016 12:22 PM
To: 'Alexis Richardson' <alexis@...>; Alan Conley <aconley@...>
Cc: 'cncf-toc@...' <cncf-toc@...>
Subject: Re: [cncf-toc] audience for "reference architecture" content

The approach I've been taking on this has been from a slightly different perspective. Most definitions have started with the infrastructure and I'm starting from the application and working backwards.

Using a combination of the power company utility model and the airport "separation of concerns" model of Air traffic control and ground control, I've been defining the roles of a) An independent application or specialty platform, b) a cloud native application fabric and c) an infrastructure substrate.

The premise is that applications decompose into segments, each of which distill into a finite set of application workload patterns. These patterns align to composition, distribution and execution models which provide the characteristics and behaviors each specific pattern requires. Simply put, the jobs decompose as follows:

1)  The application developer composes and describes the application
2) The app fabric recognizes the pattern, determines the best deployment pattern, transforms the workload and shops it for resources across a syndicate of infrastructure substrate providers (and technologies).
3) The infrastructure substrate executes the workload reliably at a local provider level

The fundamental shift notes that a cloud native app fabric scales business and technical functions implemented via software. As such, it can recognize demand using higher order indicators specific to functionality as opposed to traditional CPU, memory etc. As such, we align resource needs and utilization to meaningful business transactions and "right-size" supply with demand at the functional level.

If we take the technology, vendor and project names out of the picture and focus on capabilities we can describe this ecosystem in terms of enablers. Once we define these enablers and their roles in each of the three layers above we see pretty clearly that concepts like policy, orchestration etc. actually occur in several places and can draw the following parallels...

1) A baggage handler in New York has no need to know what a baggage handler in Atlanta is doing. Each does need to coordinate with their respective (and local) air traffic controller.
2) Air traffic control in Atlanta does need to be aware of what the ATC in New York is doing.
3) The blender Alexis uses to make us coctails does not care if the power it uses came from Georgia Power, Alabama Power or Florida power, nor does it care if it was generated using Coal, Hydro, Nuclear etc. power...
4) Georgia power does not sit in design meetings with the Xbox engineering team.
5) The system to generate power, handle luggage, load meals on planes etc. is free to innovate and be adopted independently from the ability to fly people around reliably.

My hopes for the CNCF reference model is that we show this reference model inclusive of the OCF and DAB and independent of the technologies, projects and products which can be used to enable the behaviors. I also hope that ongoing we maintain the list of these players and where they play when they implement according to the reference architecture.

Thoughts? Have I completely lost my mind?



-----Original Message-----
From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alexis Richardson via cncf-toc
Sent: Friday, July 22, 2016 11:50 AM
To: Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: Re: [cncf-toc] audience for "reference architecture" content

Alan,

Thank-you.

"anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional
component that would fit within that architecture.  Pretty much every
company I've spoken with is currently rolling their own from a select
set of open source projects and developing their own glue to fill gaps
and stitch the pieces together"

Does this mean:
- large enterprises
- vendors
- other..?

a



On Fri, Jul 22, 2016 at 4:44 PM, Alan Conley <aconley@...> wrote:
> I think this goes back to what is the charter of the CNCF.
>
>
> Taking a few short cuts in this narrative and avoiding some of the politics.
> Containers became mainstream when docker "standardized" their use.  The
> industry saw this rapid adoption and suggested a forum should "govern" these
> standards which resulted in the OCP->OCI.  From the OCI charter,
> "...industry participants may easily contribute to building a
> vendor-neutral, portable and open specification and runtime...".  So we have
> both a spec and working code.
>
>
> What was missing, was the equivalent for container management (orchestrator,
> control plane, monitoring) solutions.  I believe this was the genesis of the
> CNCF, originated by Craig and why k8s was the initial project.  The original
> reference architecture provided a simple view of these functional
> components.  BTW, most would see the similarities between this and OpenStack
> for VMs.  I personally have no interest in seeing the CNCF focused on one
> implementation.
>
>
> Assuming I'm not completely off the path, the target audience for the ref
> arch is anyone assembling a container management solution (orchestrator,
> control plane etc.) and anyone attempting to build a functional component
> that would fit within that architecture.  Pretty much every company I've
> spoken with is currently rolling their own from a select set of open source
> projects and developing their own glue to fill gaps and stitch the pieces
> together.  (My company is doing that for our own SaaS solutions.)  There are
> a few of us interested in extending what we see as one of the needed
> functional components.  However, we are unclear on how others see that
> interfacing with other components and in some cases see overlapping
> capabilities.  We can certainly just put it out there and see if there is
> adoption, but then that begs the question as to what value does the CNCF
> actually provide other than marketing.
>
>
> I'll stop before this becomes  too much of a ramble, for comments.
>
>
> Alan
>
>
>
>
>
> ________________________________
> From: Alexis Richardson <alexis@...>
> Sent: Thursday, July 21, 2016 4:54 AM
> To: cncf-toc@...
> Subject: audience for "reference architecture" content
>
> Hi all,
>
> Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken
> and I put out.  One piece of feedback, from Doug Davis by email, and then eg
> from Alan Conley on the call, was that much more detail could help.
>
> I believe this is a "target audience" issue.  We may need different material
> for different audiences even if those audiences are all "technical".  For
> example - I argued that for developer end users, less detail is good.
>
> It would be very helpful to hear from the people advocating for more detail,
> regarding their target audience.
>
> alexis
>
>
>
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


test email for forwarding

Avery Schneider <aschneider@...>
 

A quick test of the cncf-toc mailing list to confirm email forwards.

Thanks!


Re: audience for "reference architecture" content

NASSAUR, DOUGLAS C <dn283x@...>
 

Thanks Mark, got what you meant so apologies for not being clear. My primary point is that their are two separate and distinct paths which each exhibit the model-view-control reference pattern - one specific to the cloud native app fabric itself and the other for the 1-n app logic workloads under its management. Imo one can be left flexible while the other must be clearly defined in a manner which supports multi cloud federation above the infrastructure substrate. 

Regards, Doug

On Jul 22, 2016, at 1:59 PM, Mark Balch <mark@...> wrote:

By data plane, I meant the application data flow itself: code, runtime, OS, app data storage, app data connectivity (i.e., networking).  Models and policy are important aspects that can blur lines between data/control plane, but typically I see them more associated with the control plane because they usually direct how deployments occur in the data plane and how the data plane behaves (e.g., your segmentation scenario).  There may be situations where model/policy is more closely aligned to the data plane – I’m not seeking a rigid definition.

 

With respect to how networks are/not segmented between management and data, this is something I would expect the control plane policy model to allow for customer preference and not force either way. 

 

I agree with setting up a problem statement to define the ref arch context.  However, to the extent that a problem statement becomes a dictionary definition of what we’re trying to solve, it can become a protracted charter-defining type of process.  We might do both in parallel to not gate progress on the ref arch.  Disconnects can be resolve as the discussion unfolds.

 

Mark

 

 

From: NASSAUR, DOUGLAS C [mailto:dn283x@...]
Sent: Friday, July 22, 2016 10:44 AM
To: 'mark@...' <mark@...>; Alexis Richardson <alexis@...>; Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: RE: [cncf-toc] audience for "reference architecture" content

 

Would you consider “model” and control planes? It would be inclusive of “data” but also accommodates a larger context. Also, can we endeavor to capture the nano-segmentation aspects of container networking when differentiating the two planes?

 

Here’s the gap I’m hoping we address – Old days (few years ago) we had completely separate networks for both, current time we vlan/segment etc. Forward looking folks believe that by mapping vnic to vlan we can maintain the separation when we know that won’t work across WAN/routed, multi-cloud and IoT oriented networks.

 

Perhaps we can set up the problem statement via the ref architecture so the masses can see and digest it and then show how nano segmentation/CNI/CNM addresses it?

 

From: Mark Balch [mailto:mark@...]
Sent: Friday, July 22, 2016 1:36 PM
To: Alexis Richardson <alexis@...>; NASSAUR, DOUGLAS C <dn283x@...>; Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: RE: [cncf-toc] audience for "reference architecture" content

 

Using the airport analogy, airplanes and airports are an orthogonal to air traffic control, baggage routing, etc.  Back to our world, it's the difference between data and control planes. 

 

I'd like to suggest that our reference model make clear the management/control plane in addition to the data plane as depicted in the landscape doc.  Craig's original diagram blended the two together, which is useful because there is much work to be done in both areas.  Column 'C' has some thoughts in this area, though unfinished.

 

CNCF can at least define the boundaries and functions users should be aware of in how the application/infrastructure stack is deployed, configured, and managed.  Further, we can facilitate interoperability in the control plane.

 

If there are no violent disagreements, I'll put up a strawman.

 

Mark

 

 

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alexis Richardson via cncf-toc
Sent: Friday, July 22, 2016 10:31 AM
To: NASSAUR, DOUGLAS C <dn283x@...>; Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: Re: [cncf-toc] audience for "reference architecture" content

 

i actually like how you think about this Doug.  it is a great flag on the hill.  but can it work?  complete freedom for components combined with app dev productivity. 

 

On Fri, 22 Jul 2016, 18:28 NASSAUR, DOUGLAS C, <dn283x@...> wrote:

Any thoughts folks?

-----Original Message-----
From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of NASSAUR, DOUGLAS C via cncf-toc
Sent: Friday, July 22, 2016 12:22 PM
To: 'Alexis Richardson' <alexis@...>; Alan Conley <aconley@...>
Cc: 'cncf-toc@...' <cncf-toc@...>
Subject: Re: [cncf-toc] audience for "reference architecture" content

The approach I've been taking on this has been from a slightly different perspective. Most definitions have started with the infrastructure and I'm starting from the application and working backwards.

Using a combination of the power company utility model and the airport "separation of concerns" model of Air traffic control and ground control, I've been defining the roles of a) An independent application or specialty platform, b) a cloud native application fabric and c) an infrastructure substrate.

The premise is that applications decompose into segments, each of which distill into a finite set of application workload patterns. These patterns align to composition, distribution and execution models which provide the characteristics and behaviors each specific pattern requires. Simply put, the jobs decompose as follows:

1)  The application developer composes and describes the application
2) The app fabric recognizes the pattern, determines the best deployment pattern, transforms the workload and shops it for resources across a syndicate of infrastructure substrate providers (and technologies).
3) The infrastructure substrate executes the workload reliably at a local provider level

The fundamental shift notes that a cloud native app fabric scales business and technical functions implemented via software. As such, it can recognize demand using higher order indicators specific to functionality as opposed to traditional CPU, memory etc. As such, we align resource needs and utilization to meaningful business transactions and "right-size" supply with demand at the functional level.

If we take the technology, vendor and project names out of the picture and focus on capabilities we can describe this ecosystem in terms of enablers. Once we define these enablers and their roles in each of the three layers above we see pretty clearly that concepts like policy, orchestration etc. actually occur in several places and can draw the following parallels...

1) A baggage handler in New York has no need to know what a baggage handler in Atlanta is doing. Each does need to coordinate with their respective (and local) air traffic controller.
2) Air traffic control in Atlanta does need to be aware of what the ATC in New York is doing.
3) The blender Alexis uses to make us coctails does not care if the power it uses came from Georgia Power, Alabama Power or Florida power, nor does it care if it was generated using Coal, Hydro, Nuclear etc. power...
4) Georgia power does not sit in design meetings with the Xbox engineering team.
5) The system to generate power, handle luggage, load meals on planes etc. is free to innovate and be adopted independently from the ability to fly people around reliably.

My hopes for the CNCF reference model is that we show this reference model inclusive of the OCF and DAB and independent of the technologies, projects and products which can be used to enable the behaviors. I also hope that ongoing we maintain the list of these players and where they play when they implement according to the reference architecture.

Thoughts? Have I completely lost my mind?



-----Original Message-----
From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alexis Richardson via cncf-toc
Sent: Friday, July 22, 2016 11:50 AM
To: Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: Re: [cncf-toc] audience for "reference architecture" content

Alan,

Thank-you.

"anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional
component that would fit within that architecture.  Pretty much every
company I've spoken with is currently rolling their own from a select
set of open source projects and developing their own glue to fill gaps
and stitch the pieces together"

Does this mean:
- large enterprises
- vendors
- other..?

a



On Fri, Jul 22, 2016 at 4:44 PM, Alan Conley <aconley@...> wrote:
> I think this goes back to what is the charter of the CNCF.
>
>
> Taking a few short cuts in this narrative and avoiding some of the politics.
> Containers became mainstream when docker "standardized" their use.  The
> industry saw this rapid adoption and suggested a forum should "govern" these
> standards which resulted in the OCP->OCI.  From the OCI charter,
> "...industry participants may easily contribute to building a
> vendor-neutral, portable and open specification and runtime...".  So we have
> both a spec and working code.
>
>
> What was missing, was the equivalent for container management (orchestrator,
> control plane, monitoring) solutions.  I believe this was the genesis of the
> CNCF, originated by Craig and why k8s was the initial project.  The original
> reference architecture provided a simple view of these functional
> components.  BTW, most would see the similarities between this and OpenStack
> for VMs.  I personally have no interest in seeing the CNCF focused on one
> implementation.
>
>
> Assuming I'm not completely off the path, the target audience for the ref
> arch is anyone assembling a container management solution (orchestrator,
> control plane etc.) and anyone attempting to build a functional component
> that would fit within that architecture.  Pretty much every company I've
> spoken with is currently rolling their own from a select set of open source
> projects and developing their own glue to fill gaps and stitch the pieces
> together.  (My company is doing that for our own SaaS solutions.)  There are
> a few of us interested in extending what we see as one of the needed
> functional components.  However, we are unclear on how others see that
> interfacing with other components and in some cases see overlapping
> capabilities.  We can certainly just put it out there and see if there is
> adoption, but then that begs the question as to what value does the CNCF
> actually provide other than marketing.
>
>
> I'll stop before this becomes  too much of a ramble, for comments.
>
>
> Alan
>
>
>
>
>
> ________________________________
> From: Alexis Richardson <alexis@...>
> Sent: Thursday, July 21, 2016 4:54 AM
> To: cncf-toc@...
> Subject: audience for "reference architecture" content
>
> Hi all,
>
> Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken
> and I put out.  One piece of feedback, from Doug Davis by email, and then eg
> from Alan Conley on the call, was that much more detail could help.
>
> I believe this is a "target audience" issue.  We may need different material
> for different audiences even if those audiences are all "technical".  For
> example - I argued that for developer end users, less detail is good.
>
> It would be very helpful to hear from the people advocating for more detail,
> regarding their target audience.
>
> alexis
>
>
>
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: audience for "reference architecture" content

Mark Balch <mark@...>
 

By data plane, I meant the application data flow itself: code, runtime, OS, app data storage, app data connectivity (i.e., networking).  Models and policy are important aspects that can blur lines between data/control plane, but typically I see them more associated with the control plane because they usually direct how deployments occur in the data plane and how the data plane behaves (e.g., your segmentation scenario).  There may be situations where model/policy is more closely aligned to the data plane – I’m not seeking a rigid definition.

 

With respect to how networks are/not segmented between management and data, this is something I would expect the control plane policy model to allow for customer preference and not force either way. 

 

I agree with setting up a problem statement to define the ref arch context.  However, to the extent that a problem statement becomes a dictionary definition of what we’re trying to solve, it can become a protracted charter-defining type of process.  We might do both in parallel to not gate progress on the ref arch.  Disconnects can be resolve as the discussion unfolds.

 

Mark

 

 

From: NASSAUR, DOUGLAS C [mailto:dn283x@...]
Sent: Friday, July 22, 2016 10:44 AM
To: 'mark@...' <mark@...>; Alexis Richardson <alexis@...>; Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: RE: [cncf-toc] audience for "reference architecture" content

 

Would you consider “model” and control planes? It would be inclusive of “data” but also accommodates a larger context. Also, can we endeavor to capture the nano-segmentation aspects of container networking when differentiating the two planes?

 

Here’s the gap I’m hoping we address – Old days (few years ago) we had completely separate networks for both, current time we vlan/segment etc. Forward looking folks believe that by mapping vnic to vlan we can maintain the separation when we know that won’t work across WAN/routed, multi-cloud and IoT oriented networks.

 

Perhaps we can set up the problem statement via the ref architecture so the masses can see and digest it and then show how nano segmentation/CNI/CNM addresses it?

 

From: Mark Balch [mailto:mark@...]
Sent: Friday, July 22, 2016 1:36 PM
To: Alexis Richardson <alexis@...>; NASSAUR, DOUGLAS C <dn283x@...>; Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: RE: [cncf-toc] audience for "reference architecture" content

 

Using the airport analogy, airplanes and airports are an orthogonal to air traffic control, baggage routing, etc.  Back to our world, it's the difference between data and control planes. 

 

I'd like to suggest that our reference model make clear the management/control plane in addition to the data plane as depicted in the landscape doc.  Craig's original diagram blended the two together, which is useful because there is much work to be done in both areas.  Column 'C' has some thoughts in this area, though unfinished.

 

CNCF can at least define the boundaries and functions users should be aware of in how the application/infrastructure stack is deployed, configured, and managed.  Further, we can facilitate interoperability in the control plane.

 

If there are no violent disagreements, I'll put up a strawman.

 

Mark

 

 

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alexis Richardson via cncf-toc
Sent: Friday, July 22, 2016 10:31 AM
To: NASSAUR, DOUGLAS C <dn283x@...>; Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: Re: [cncf-toc] audience for "reference architecture" content

 

i actually like how you think about this Doug.  it is a great flag on the hill.  but can it work?  complete freedom for components combined with app dev productivity. 

 

On Fri, 22 Jul 2016, 18:28 NASSAUR, DOUGLAS C, <dn283x@...> wrote:

Any thoughts folks?

-----Original Message-----
From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of NASSAUR, DOUGLAS C via cncf-toc
Sent: Friday, July 22, 2016 12:22 PM
To: 'Alexis Richardson' <alexis@...>; Alan Conley <aconley@...>
Cc: 'cncf-toc@...' <cncf-toc@...>
Subject: Re: [cncf-toc] audience for "reference architecture" content

The approach I've been taking on this has been from a slightly different perspective. Most definitions have started with the infrastructure and I'm starting from the application and working backwards.

Using a combination of the power company utility model and the airport "separation of concerns" model of Air traffic control and ground control, I've been defining the roles of a) An independent application or specialty platform, b) a cloud native application fabric and c) an infrastructure substrate.

The premise is that applications decompose into segments, each of which distill into a finite set of application workload patterns. These patterns align to composition, distribution and execution models which provide the characteristics and behaviors each specific pattern requires. Simply put, the jobs decompose as follows:

1)  The application developer composes and describes the application
2) The app fabric recognizes the pattern, determines the best deployment pattern, transforms the workload and shops it for resources across a syndicate of infrastructure substrate providers (and technologies).
3) The infrastructure substrate executes the workload reliably at a local provider level

The fundamental shift notes that a cloud native app fabric scales business and technical functions implemented via software. As such, it can recognize demand using higher order indicators specific to functionality as opposed to traditional CPU, memory etc. As such, we align resource needs and utilization to meaningful business transactions and "right-size" supply with demand at the functional level.

If we take the technology, vendor and project names out of the picture and focus on capabilities we can describe this ecosystem in terms of enablers. Once we define these enablers and their roles in each of the three layers above we see pretty clearly that concepts like policy, orchestration etc. actually occur in several places and can draw the following parallels...

1) A baggage handler in New York has no need to know what a baggage handler in Atlanta is doing. Each does need to coordinate with their respective (and local) air traffic controller.
2) Air traffic control in Atlanta does need to be aware of what the ATC in New York is doing.
3) The blender Alexis uses to make us coctails does not care if the power it uses came from Georgia Power, Alabama Power or Florida power, nor does it care if it was generated using Coal, Hydro, Nuclear etc. power...
4) Georgia power does not sit in design meetings with the Xbox engineering team.
5) The system to generate power, handle luggage, load meals on planes etc. is free to innovate and be adopted independently from the ability to fly people around reliably.

My hopes for the CNCF reference model is that we show this reference model inclusive of the OCF and DAB and independent of the technologies, projects and products which can be used to enable the behaviors. I also hope that ongoing we maintain the list of these players and where they play when they implement according to the reference architecture.

Thoughts? Have I completely lost my mind?



-----Original Message-----
From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alexis Richardson via cncf-toc
Sent: Friday, July 22, 2016 11:50 AM
To: Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: Re: [cncf-toc] audience for "reference architecture" content

Alan,

Thank-you.

"anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional
component that would fit within that architecture.  Pretty much every
company I've spoken with is currently rolling their own from a select
set of open source projects and developing their own glue to fill gaps
and stitch the pieces together"

Does this mean:
- large enterprises
- vendors
- other..?

a



On Fri, Jul 22, 2016 at 4:44 PM, Alan Conley <aconley@...> wrote:
> I think this goes back to what is the charter of the CNCF.
>
>
> Taking a few short cuts in this narrative and avoiding some of the politics.
> Containers became mainstream when docker "standardized" their use.  The
> industry saw this rapid adoption and suggested a forum should "govern" these
> standards which resulted in the OCP->OCI.  From the OCI charter,
> "...industry participants may easily contribute to building a
> vendor-neutral, portable and open specification and runtime...".  So we have
> both a spec and working code.
>
>
> What was missing, was the equivalent for container management (orchestrator,
> control plane, monitoring) solutions.  I believe this was the genesis of the
> CNCF, originated by Craig and why k8s was the initial project.  The original
> reference architecture provided a simple view of these functional
> components.  BTW, most would see the similarities between this and OpenStack
> for VMs.  I personally have no interest in seeing the CNCF focused on one
> implementation.
>
>
> Assuming I'm not completely off the path, the target audience for the ref
> arch is anyone assembling a container management solution (orchestrator,
> control plane etc.) and anyone attempting to build a functional component
> that would fit within that architecture.  Pretty much every company I've
> spoken with is currently rolling their own from a select set of open source
> projects and developing their own glue to fill gaps and stitch the pieces
> together.  (My company is doing that for our own SaaS solutions.)  There are
> a few of us interested in extending what we see as one of the needed
> functional components.  However, we are unclear on how others see that
> interfacing with other components and in some cases see overlapping
> capabilities.  We can certainly just put it out there and see if there is
> adoption, but then that begs the question as to what value does the CNCF
> actually provide other than marketing.
>
>
> I'll stop before this becomes  too much of a ramble, for comments.
>
>
> Alan
>
>
>
>
>
> ________________________________
> From: Alexis Richardson <alexis@...>
> Sent: Thursday, July 21, 2016 4:54 AM
> To: cncf-toc@...
> Subject: audience for "reference architecture" content
>
> Hi all,
>
> Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken
> and I put out.  One piece of feedback, from Doug Davis by email, and then eg
> from Alan Conley on the call, was that much more detail could help.
>
> I believe this is a "target audience" issue.  We may need different material
> for different audiences even if those audiences are all "technical".  For
> example - I argued that for developer end users, less detail is good.
>
> It would be very helpful to hear from the people advocating for more detail,
> regarding their target audience.
>
> alexis
>
>
>
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: audience for "reference architecture" content

NASSAUR, DOUGLAS C <dn283x@...>
 

Would you consider “model” and control planes? It would be inclusive of “data” but also accommodates a larger context. Also, can we endeavor to capture the nano-segmentation aspects of container networking when differentiating the two planes?

 

Here’s the gap I’m hoping we address – Old days (few years ago) we had completely separate networks for both, current time we vlan/segment etc. Forward looking folks believe that by mapping vnic to vlan we can maintain the separation when we know that won’t work across WAN/routed, multi-cloud and IoT oriented networks.

 

Perhaps we can set up the problem statement via the ref architecture so the masses can see and digest it and then show how nano segmentation/CNI/CNM addresses it?

 

From: Mark Balch [mailto:mark@...]
Sent: Friday, July 22, 2016 1:36 PM
To: Alexis Richardson <alexis@...>; NASSAUR, DOUGLAS C <dn283x@...>; Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: RE: [cncf-toc] audience for "reference architecture" content

 

Using the airport analogy, airplanes and airports are an orthogonal to air traffic control, baggage routing, etc.  Back to our world, it's the difference between data and control planes. 

 

I'd like to suggest that our reference model make clear the management/control plane in addition to the data plane as depicted in the landscape doc.  Craig's original diagram blended the two together, which is useful because there is much work to be done in both areas.  Column 'C' has some thoughts in this area, though unfinished.

 

CNCF can at least define the boundaries and functions users should be aware of in how the application/infrastructure stack is deployed, configured, and managed.  Further, we can facilitate interoperability in the control plane.

 

If there are no violent disagreements, I'll put up a strawman.

 

Mark

 

 

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alexis Richardson via cncf-toc
Sent: Friday, July 22, 2016 10:31 AM
To: NASSAUR, DOUGLAS C <dn283x@...>; Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: Re: [cncf-toc] audience for "reference architecture" content

 

i actually like how you think about this Doug.  it is a great flag on the hill.  but can it work?  complete freedom for components combined with app dev productivity. 

 

On Fri, 22 Jul 2016, 18:28 NASSAUR, DOUGLAS C, <dn283x@...> wrote:

Any thoughts folks?

-----Original Message-----
From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of NASSAUR, DOUGLAS C via cncf-toc
Sent: Friday, July 22, 2016 12:22 PM
To: 'Alexis Richardson' <alexis@...>; Alan Conley <aconley@...>
Cc: 'cncf-toc@...' <cncf-toc@...>
Subject: Re: [cncf-toc] audience for "reference architecture" content

The approach I've been taking on this has been from a slightly different perspective. Most definitions have started with the infrastructure and I'm starting from the application and working backwards.

Using a combination of the power company utility model and the airport "separation of concerns" model of Air traffic control and ground control, I've been defining the roles of a) An independent application or specialty platform, b) a cloud native application fabric and c) an infrastructure substrate.

The premise is that applications decompose into segments, each of which distill into a finite set of application workload patterns. These patterns align to composition, distribution and execution models which provide the characteristics and behaviors each specific pattern requires. Simply put, the jobs decompose as follows:

1)  The application developer composes and describes the application
2) The app fabric recognizes the pattern, determines the best deployment pattern, transforms the workload and shops it for resources across a syndicate of infrastructure substrate providers (and technologies).
3) The infrastructure substrate executes the workload reliably at a local provider level

The fundamental shift notes that a cloud native app fabric scales business and technical functions implemented via software. As such, it can recognize demand using higher order indicators specific to functionality as opposed to traditional CPU, memory etc. As such, we align resource needs and utilization to meaningful business transactions and "right-size" supply with demand at the functional level.

If we take the technology, vendor and project names out of the picture and focus on capabilities we can describe this ecosystem in terms of enablers. Once we define these enablers and their roles in each of the three layers above we see pretty clearly that concepts like policy, orchestration etc. actually occur in several places and can draw the following parallels...

1) A baggage handler in New York has no need to know what a baggage handler in Atlanta is doing. Each does need to coordinate with their respective (and local) air traffic controller.
2) Air traffic control in Atlanta does need to be aware of what the ATC in New York is doing.
3) The blender Alexis uses to make us coctails does not care if the power it uses came from Georgia Power, Alabama Power or Florida power, nor does it care if it was generated using Coal, Hydro, Nuclear etc. power...
4) Georgia power does not sit in design meetings with the Xbox engineering team.
5) The system to generate power, handle luggage, load meals on planes etc. is free to innovate and be adopted independently from the ability to fly people around reliably.

My hopes for the CNCF reference model is that we show this reference model inclusive of the OCF and DAB and independent of the technologies, projects and products which can be used to enable the behaviors. I also hope that ongoing we maintain the list of these players and where they play when they implement according to the reference architecture.

Thoughts? Have I completely lost my mind?



-----Original Message-----
From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alexis Richardson via cncf-toc
Sent: Friday, July 22, 2016 11:50 AM
To: Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: Re: [cncf-toc] audience for "reference architecture" content

Alan,

Thank-you.

"anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional
component that would fit within that architecture.  Pretty much every
company I've spoken with is currently rolling their own from a select
set of open source projects and developing their own glue to fill gaps
and stitch the pieces together"

Does this mean:
- large enterprises
- vendors
- other..?

a



On Fri, Jul 22, 2016 at 4:44 PM, Alan Conley <aconley@...> wrote:
> I think this goes back to what is the charter of the CNCF.
>
>
> Taking a few short cuts in this narrative and avoiding some of the politics.
> Containers became mainstream when docker "standardized" their use.  The
> industry saw this rapid adoption and suggested a forum should "govern" these
> standards which resulted in the OCP->OCI.  From the OCI charter,
> "...industry participants may easily contribute to building a
> vendor-neutral, portable and open specification and runtime...".  So we have
> both a spec and working code.
>
>
> What was missing, was the equivalent for container management (orchestrator,
> control plane, monitoring) solutions.  I believe this was the genesis of the
> CNCF, originated by Craig and why k8s was the initial project.  The original
> reference architecture provided a simple view of these functional
> components.  BTW, most would see the similarities between this and OpenStack
> for VMs.  I personally have no interest in seeing the CNCF focused on one
> implementation.
>
>
> Assuming I'm not completely off the path, the target audience for the ref
> arch is anyone assembling a container management solution (orchestrator,
> control plane etc.) and anyone attempting to build a functional component
> that would fit within that architecture.  Pretty much every company I've
> spoken with is currently rolling their own from a select set of open source
> projects and developing their own glue to fill gaps and stitch the pieces
> together.  (My company is doing that for our own SaaS solutions.)  There are
> a few of us interested in extending what we see as one of the needed
> functional components.  However, we are unclear on how others see that
> interfacing with other components and in some cases see overlapping
> capabilities.  We can certainly just put it out there and see if there is
> adoption, but then that begs the question as to what value does the CNCF
> actually provide other than marketing.
>
>
> I'll stop before this becomes  too much of a ramble, for comments.
>
>
> Alan
>
>
>
>
>
> ________________________________
> From: Alexis Richardson <alexis@...>
> Sent: Thursday, July 21, 2016 4:54 AM
> To: cncf-toc@...
> Subject: audience for "reference architecture" content
>
> Hi all,
>
> Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken
> and I put out.  One piece of feedback, from Doug Davis by email, and then eg
> from Alan Conley on the call, was that much more detail could help.
>
> I believe this is a "target audience" issue.  We may need different material
> for different audiences even if those audiences are all "technical".  For
> example - I argued that for developer end users, less detail is good.
>
> It would be very helpful to hear from the people advocating for more detail,
> regarding their target audience.
>
> alexis
>
>
>
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: audience for "reference architecture" content

NASSAUR, DOUGLAS C <dn283x@...>
 

Thanks sir, I’m working with several POC participants to illustrate this stack with the intent of offering it up to our team here as a working example. It also shows the Eli Whitney aspects illustrating the cloud native benefit of integration/interoperability without lock in.

 

The multi-cloud aspect is really a nice leap since it offers two distinct pathways with a clear, single question differentiator which determines which path to take. Does my application have functional services which would benefit from elastic scaling independent of my larger platform resource allocation? If so, I go to the right (Cloud Native) and if not, (that segment of my app) can have its needs met via virtual hosting.

 

Of course, it should still be containerized, dynamically scheduled etc. since we don’t want planes flying around our airspace without our ATC knowing about them J

 

From: Alexis Richardson [mailto:alexis@...]
Sent: Friday, July 22, 2016 1:31 PM
To: NASSAUR, DOUGLAS C <dn283x@...>; Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: Re: [cncf-toc] audience for "reference architecture" content

 

i actually like how you think about this Doug.  it is a great flag on the hill.  but can it work?  complete freedom for components combined with app dev productivity. 

 

On Fri, 22 Jul 2016, 18:28 NASSAUR, DOUGLAS C, <dn283x@...> wrote:

Any thoughts folks?

-----Original Message-----
From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of NASSAUR, DOUGLAS C via cncf-toc
Sent: Friday, July 22, 2016 12:22 PM
To: 'Alexis Richardson' <alexis@...>; Alan Conley <aconley@...>
Cc: 'cncf-toc@...' <cncf-toc@...>
Subject: Re: [cncf-toc] audience for "reference architecture" content

The approach I've been taking on this has been from a slightly different perspective. Most definitions have started with the infrastructure and I'm starting from the application and working backwards.

Using a combination of the power company utility model and the airport "separation of concerns" model of Air traffic control and ground control, I've been defining the roles of a) An independent application or specialty platform, b) a cloud native application fabric and c) an infrastructure substrate.

The premise is that applications decompose into segments, each of which distill into a finite set of application workload patterns. These patterns align to composition, distribution and execution models which provide the characteristics and behaviors each specific pattern requires. Simply put, the jobs decompose as follows:

1)  The application developer composes and describes the application
2) The app fabric recognizes the pattern, determines the best deployment pattern, transforms the workload and shops it for resources across a syndicate of infrastructure substrate providers (and technologies).
3) The infrastructure substrate executes the workload reliably at a local provider level

The fundamental shift notes that a cloud native app fabric scales business and technical functions implemented via software. As such, it can recognize demand using higher order indicators specific to functionality as opposed to traditional CPU, memory etc. As such, we align resource needs and utilization to meaningful business transactions and "right-size" supply with demand at the functional level.

If we take the technology, vendor and project names out of the picture and focus on capabilities we can describe this ecosystem in terms of enablers. Once we define these enablers and their roles in each of the three layers above we see pretty clearly that concepts like policy, orchestration etc. actually occur in several places and can draw the following parallels...

1) A baggage handler in New York has no need to know what a baggage handler in Atlanta is doing. Each does need to coordinate with their respective (and local) air traffic controller.
2) Air traffic control in Atlanta does need to be aware of what the ATC in New York is doing.
3) The blender Alexis uses to make us coctails does not care if the power it uses came from Georgia Power, Alabama Power or Florida power, nor does it care if it was generated using Coal, Hydro, Nuclear etc. power...
4) Georgia power does not sit in design meetings with the Xbox engineering team.
5) The system to generate power, handle luggage, load meals on planes etc. is free to innovate and be adopted independently from the ability to fly people around reliably.

My hopes for the CNCF reference model is that we show this reference model inclusive of the OCF and DAB and independent of the technologies, projects and products which can be used to enable the behaviors. I also hope that ongoing we maintain the list of these players and where they play when they implement according to the reference architecture.

Thoughts? Have I completely lost my mind?



-----Original Message-----
From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alexis Richardson via cncf-toc
Sent: Friday, July 22, 2016 11:50 AM
To: Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: Re: [cncf-toc] audience for "reference architecture" content

Alan,

Thank-you.

"anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional
component that would fit within that architecture.  Pretty much every
company I've spoken with is currently rolling their own from a select
set of open source projects and developing their own glue to fill gaps
and stitch the pieces together"

Does this mean:
- large enterprises
- vendors
- other..?

a



On Fri, Jul 22, 2016 at 4:44 PM, Alan Conley <aconley@...> wrote:
> I think this goes back to what is the charter of the CNCF.
>
>
> Taking a few short cuts in this narrative and avoiding some of the politics.
> Containers became mainstream when docker "standardized" their use.  The
> industry saw this rapid adoption and suggested a forum should "govern" these
> standards which resulted in the OCP->OCI.  From the OCI charter,
> "...industry participants may easily contribute to building a
> vendor-neutral, portable and open specification and runtime...".  So we have
> both a spec and working code.
>
>
> What was missing, was the equivalent for container management (orchestrator,
> control plane, monitoring) solutions.  I believe this was the genesis of the
> CNCF, originated by Craig and why k8s was the initial project.  The original
> reference architecture provided a simple view of these functional
> components.  BTW, most would see the similarities between this and OpenStack
> for VMs.  I personally have no interest in seeing the CNCF focused on one
> implementation.
>
>
> Assuming I'm not completely off the path, the target audience for the ref
> arch is anyone assembling a container management solution (orchestrator,
> control plane etc.) and anyone attempting to build a functional component
> that would fit within that architecture.  Pretty much every company I've
> spoken with is currently rolling their own from a select set of open source
> projects and developing their own glue to fill gaps and stitch the pieces
> together.  (My company is doing that for our own SaaS solutions.)  There are
> a few of us interested in extending what we see as one of the needed
> functional components.  However, we are unclear on how others see that
> interfacing with other components and in some cases see overlapping
> capabilities.  We can certainly just put it out there and see if there is
> adoption, but then that begs the question as to what value does the CNCF
> actually provide other than marketing.
>
>
> I'll stop before this becomes  too much of a ramble, for comments.
>
>
> Alan
>
>
>
>
>
> ________________________________
> From: Alexis Richardson <alexis@...>
> Sent: Thursday, July 21, 2016 4:54 AM
> To: cncf-toc@...
> Subject: audience for "reference architecture" content
>
> Hi all,
>
> Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken
> and I put out.  One piece of feedback, from Doug Davis by email, and then eg
> from Alan Conley on the call, was that much more detail could help.
>
> I believe this is a "target audience" issue.  We may need different material
> for different audiences even if those audiences are all "technical".  For
> example - I argued that for developer end users, less detail is good.
>
> It would be very helpful to hear from the people advocating for more detail,
> regarding their target audience.
>
> alexis
>
>
>
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: audience for "reference architecture" content

Mark Balch <mark@...>
 

Using the airport analogy, airplanes and airports are an orthogonal to air traffic control, baggage routing, etc.  Back to our world, it's the difference between data and control planes. 

 

I'd like to suggest that our reference model make clear the management/control plane in addition to the data plane as depicted in the landscape doc.  Craig's original diagram blended the two together, which is useful because there is much work to be done in both areas.  Column 'C' has some thoughts in this area, though unfinished.

 

CNCF can at least define the boundaries and functions users should be aware of in how the application/infrastructure stack is deployed, configured, and managed.  Further, we can facilitate interoperability in the control plane.

 

If there are no violent disagreements, I'll put up a strawman.

 

Mark

 

 

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alexis Richardson via cncf-toc
Sent: Friday, July 22, 2016 10:31 AM
To: NASSAUR, DOUGLAS C <dn283x@...>; Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: Re: [cncf-toc] audience for "reference architecture" content

 

i actually like how you think about this Doug.  it is a great flag on the hill.  but can it work?  complete freedom for components combined with app dev productivity. 

 

On Fri, 22 Jul 2016, 18:28 NASSAUR, DOUGLAS C, <dn283x@...> wrote:

Any thoughts folks?

-----Original Message-----
From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of NASSAUR, DOUGLAS C via cncf-toc
Sent: Friday, July 22, 2016 12:22 PM
To: 'Alexis Richardson' <alexis@...>; Alan Conley <aconley@...>
Cc: 'cncf-toc@...' <cncf-toc@...>
Subject: Re: [cncf-toc] audience for "reference architecture" content

The approach I've been taking on this has been from a slightly different perspective. Most definitions have started with the infrastructure and I'm starting from the application and working backwards.

Using a combination of the power company utility model and the airport "separation of concerns" model of Air traffic control and ground control, I've been defining the roles of a) An independent application or specialty platform, b) a cloud native application fabric and c) an infrastructure substrate.

The premise is that applications decompose into segments, each of which distill into a finite set of application workload patterns. These patterns align to composition, distribution and execution models which provide the characteristics and behaviors each specific pattern requires. Simply put, the jobs decompose as follows:

1)  The application developer composes and describes the application
2) The app fabric recognizes the pattern, determines the best deployment pattern, transforms the workload and shops it for resources across a syndicate of infrastructure substrate providers (and technologies).
3) The infrastructure substrate executes the workload reliably at a local provider level

The fundamental shift notes that a cloud native app fabric scales business and technical functions implemented via software. As such, it can recognize demand using higher order indicators specific to functionality as opposed to traditional CPU, memory etc. As such, we align resource needs and utilization to meaningful business transactions and "right-size" supply with demand at the functional level.

If we take the technology, vendor and project names out of the picture and focus on capabilities we can describe this ecosystem in terms of enablers. Once we define these enablers and their roles in each of the three layers above we see pretty clearly that concepts like policy, orchestration etc. actually occur in several places and can draw the following parallels...

1) A baggage handler in New York has no need to know what a baggage handler in Atlanta is doing. Each does need to coordinate with their respective (and local) air traffic controller.
2) Air traffic control in Atlanta does need to be aware of what the ATC in New York is doing.
3) The blender Alexis uses to make us coctails does not care if the power it uses came from Georgia Power, Alabama Power or Florida power, nor does it care if it was generated using Coal, Hydro, Nuclear etc. power...
4) Georgia power does not sit in design meetings with the Xbox engineering team.
5) The system to generate power, handle luggage, load meals on planes etc. is free to innovate and be adopted independently from the ability to fly people around reliably.

My hopes for the CNCF reference model is that we show this reference model inclusive of the OCF and DAB and independent of the technologies, projects and products which can be used to enable the behaviors. I also hope that ongoing we maintain the list of these players and where they play when they implement according to the reference architecture.

Thoughts? Have I completely lost my mind?



-----Original Message-----
From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alexis Richardson via cncf-toc
Sent: Friday, July 22, 2016 11:50 AM
To: Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: Re: [cncf-toc] audience for "reference architecture" content

Alan,

Thank-you.

"anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional
component that would fit within that architecture.  Pretty much every
company I've spoken with is currently rolling their own from a select
set of open source projects and developing their own glue to fill gaps
and stitch the pieces together"

Does this mean:
- large enterprises
- vendors
- other..?

a



On Fri, Jul 22, 2016 at 4:44 PM, Alan Conley <aconley@...> wrote:
> I think this goes back to what is the charter of the CNCF.
>
>
> Taking a few short cuts in this narrative and avoiding some of the politics.
> Containers became mainstream when docker "standardized" their use.  The
> industry saw this rapid adoption and suggested a forum should "govern" these
> standards which resulted in the OCP->OCI.  From the OCI charter,
> "...industry participants may easily contribute to building a
> vendor-neutral, portable and open specification and runtime...".  So we have
> both a spec and working code.
>
>
> What was missing, was the equivalent for container management (orchestrator,
> control plane, monitoring) solutions.  I believe this was the genesis of the
> CNCF, originated by Craig and why k8s was the initial project.  The original
> reference architecture provided a simple view of these functional
> components.  BTW, most would see the similarities between this and OpenStack
> for VMs.  I personally have no interest in seeing the CNCF focused on one
> implementation.
>
>
> Assuming I'm not completely off the path, the target audience for the ref
> arch is anyone assembling a container management solution (orchestrator,
> control plane etc.) and anyone attempting to build a functional component
> that would fit within that architecture.  Pretty much every company I've
> spoken with is currently rolling their own from a select set of open source
> projects and developing their own glue to fill gaps and stitch the pieces
> together.  (My company is doing that for our own SaaS solutions.)  There are
> a few of us interested in extending what we see as one of the needed
> functional components.  However, we are unclear on how others see that
> interfacing with other components and in some cases see overlapping
> capabilities.  We can certainly just put it out there and see if there is
> adoption, but then that begs the question as to what value does the CNCF
> actually provide other than marketing.
>
>
> I'll stop before this becomes  too much of a ramble, for comments.
>
>
> Alan
>
>
>
>
>
> ________________________________
> From: Alexis Richardson <alexis@...>
> Sent: Thursday, July 21, 2016 4:54 AM
> To: cncf-toc@...
> Subject: audience for "reference architecture" content
>
> Hi all,
>
> Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken
> and I put out.  One piece of feedback, from Doug Davis by email, and then eg
> from Alan Conley on the call, was that much more detail could help.
>
> I believe this is a "target audience" issue.  We may need different material
> for different audiences even if those audiences are all "technical".  For
> example - I argued that for developer end users, less detail is good.
>
> It would be very helpful to hear from the people advocating for more detail,
> regarding their target audience.
>
> alexis
>
>
>
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: audience for "reference architecture" content

alexis richardson
 

i actually like how you think about this Doug.  it is a great flag on the hill.  but can it work?  complete freedom for components combined with app dev productivity. 


On Fri, 22 Jul 2016, 18:28 NASSAUR, DOUGLAS C, <dn283x@...> wrote:
Any thoughts folks?

-----Original Message-----
From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of NASSAUR, DOUGLAS C via cncf-toc
Sent: Friday, July 22, 2016 12:22 PM
To: 'Alexis Richardson' <alexis@...>; Alan Conley <aconley@...>
Cc: 'cncf-toc@...' <cncf-toc@...>
Subject: Re: [cncf-toc] audience for "reference architecture" content

The approach I've been taking on this has been from a slightly different perspective. Most definitions have started with the infrastructure and I'm starting from the application and working backwards.

Using a combination of the power company utility model and the airport "separation of concerns" model of Air traffic control and ground control, I've been defining the roles of a) An independent application or specialty platform, b) a cloud native application fabric and c) an infrastructure substrate.

The premise is that applications decompose into segments, each of which distill into a finite set of application workload patterns. These patterns align to composition, distribution and execution models which provide the characteristics and behaviors each specific pattern requires. Simply put, the jobs decompose as follows:

1)  The application developer composes and describes the application
2) The app fabric recognizes the pattern, determines the best deployment pattern, transforms the workload and shops it for resources across a syndicate of infrastructure substrate providers (and technologies).
3) The infrastructure substrate executes the workload reliably at a local provider level

The fundamental shift notes that a cloud native app fabric scales business and technical functions implemented via software. As such, it can recognize demand using higher order indicators specific to functionality as opposed to traditional CPU, memory etc. As such, we align resource needs and utilization to meaningful business transactions and "right-size" supply with demand at the functional level.

If we take the technology, vendor and project names out of the picture and focus on capabilities we can describe this ecosystem in terms of enablers. Once we define these enablers and their roles in each of the three layers above we see pretty clearly that concepts like policy, orchestration etc. actually occur in several places and can draw the following parallels...

1) A baggage handler in New York has no need to know what a baggage handler in Atlanta is doing. Each does need to coordinate with their respective (and local) air traffic controller.
2) Air traffic control in Atlanta does need to be aware of what the ATC in New York is doing.
3) The blender Alexis uses to make us coctails does not care if the power it uses came from Georgia Power, Alabama Power or Florida power, nor does it care if it was generated using Coal, Hydro, Nuclear etc. power...
4) Georgia power does not sit in design meetings with the Xbox engineering team.
5) The system to generate power, handle luggage, load meals on planes etc. is free to innovate and be adopted independently from the ability to fly people around reliably.

My hopes for the CNCF reference model is that we show this reference model inclusive of the OCF and DAB and independent of the technologies, projects and products which can be used to enable the behaviors. I also hope that ongoing we maintain the list of these players and where they play when they implement according to the reference architecture.

Thoughts? Have I completely lost my mind?



-----Original Message-----
From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Alexis Richardson via cncf-toc
Sent: Friday, July 22, 2016 11:50 AM
To: Alan Conley <aconley@...>
Cc: cncf-toc@...
Subject: Re: [cncf-toc] audience for "reference architecture" content

Alan,

Thank-you.

"anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional
component that would fit within that architecture.  Pretty much every
company I've spoken with is currently rolling their own from a select
set of open source projects and developing their own glue to fill gaps
and stitch the pieces together"

Does this mean:
- large enterprises
- vendors
- other..?

a



On Fri, Jul 22, 2016 at 4:44 PM, Alan Conley <aconley@...> wrote:
> I think this goes back to what is the charter of the CNCF.
>
>
> Taking a few short cuts in this narrative and avoiding some of the politics.
> Containers became mainstream when docker "standardized" their use.  The
> industry saw this rapid adoption and suggested a forum should "govern" these
> standards which resulted in the OCP->OCI.  From the OCI charter,
> "...industry participants may easily contribute to building a
> vendor-neutral, portable and open specification and runtime...".  So we have
> both a spec and working code.
>
>
> What was missing, was the equivalent for container management (orchestrator,
> control plane, monitoring) solutions.  I believe this was the genesis of the
> CNCF, originated by Craig and why k8s was the initial project.  The original
> reference architecture provided a simple view of these functional
> components.  BTW, most would see the similarities between this and OpenStack
> for VMs.  I personally have no interest in seeing the CNCF focused on one
> implementation.
>
>
> Assuming I'm not completely off the path, the target audience for the ref
> arch is anyone assembling a container management solution (orchestrator,
> control plane etc.) and anyone attempting to build a functional component
> that would fit within that architecture.  Pretty much every company I've
> spoken with is currently rolling their own from a select set of open source
> projects and developing their own glue to fill gaps and stitch the pieces
> together.  (My company is doing that for our own SaaS solutions.)  There are
> a few of us interested in extending what we see as one of the needed
> functional components.  However, we are unclear on how others see that
> interfacing with other components and in some cases see overlapping
> capabilities.  We can certainly just put it out there and see if there is
> adoption, but then that begs the question as to what value does the CNCF
> actually provide other than marketing.
>
>
> I'll stop before this becomes  too much of a ramble, for comments.
>
>
> Alan
>
>
>
>
>
> ________________________________
> From: Alexis Richardson <alexis@...>
> Sent: Thursday, July 21, 2016 4:54 AM
> To: cncf-toc@...
> Subject: audience for "reference architecture" content
>
> Hi all,
>
> Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken
> and I put out.  One piece of feedback, from Doug Davis by email, and then eg
> from Alan Conley on the call, was that much more detail could help.
>
> I believe this is a "target audience" issue.  We may need different material
> for different audiences even if those audiences are all "technical".  For
> example - I argued that for developer end users, less detail is good.
>
> It would be very helpful to hear from the people advocating for more detail,
> regarding their target audience.
>
> alexis
>
>
>
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Re: audience for "reference architecture" content

NASSAUR, DOUGLAS C <dn283x@...>
 

Any thoughts folks?

-----Original Message-----
From: cncf-toc-bounces@lists.cncf.io [mailto:cncf-toc-bounces@lists.cncf.io] On Behalf Of NASSAUR, DOUGLAS C via cncf-toc
Sent: Friday, July 22, 2016 12:22 PM
To: 'Alexis Richardson' <alexis@weave.works>; Alan Conley <aconley@infoblox.com>
Cc: 'cncf-toc@lists.cncf.io' <cncf-toc@lists.cncf.io>
Subject: Re: [cncf-toc] audience for "reference architecture" content

The approach I've been taking on this has been from a slightly different perspective. Most definitions have started with the infrastructure and I'm starting from the application and working backwards.

Using a combination of the power company utility model and the airport "separation of concerns" model of Air traffic control and ground control, I've been defining the roles of a) An independent application or specialty platform, b) a cloud native application fabric and c) an infrastructure substrate.

The premise is that applications decompose into segments, each of which distill into a finite set of application workload patterns. These patterns align to composition, distribution and execution models which provide the characteristics and behaviors each specific pattern requires. Simply put, the jobs decompose as follows:

1) The application developer composes and describes the application
2) The app fabric recognizes the pattern, determines the best deployment pattern, transforms the workload and shops it for resources across a syndicate of infrastructure substrate providers (and technologies).
3) The infrastructure substrate executes the workload reliably at a local provider level

The fundamental shift notes that a cloud native app fabric scales business and technical functions implemented via software. As such, it can recognize demand using higher order indicators specific to functionality as opposed to traditional CPU, memory etc. As such, we align resource needs and utilization to meaningful business transactions and "right-size" supply with demand at the functional level.

If we take the technology, vendor and project names out of the picture and focus on capabilities we can describe this ecosystem in terms of enablers. Once we define these enablers and their roles in each of the three layers above we see pretty clearly that concepts like policy, orchestration etc. actually occur in several places and can draw the following parallels...

1) A baggage handler in New York has no need to know what a baggage handler in Atlanta is doing. Each does need to coordinate with their respective (and local) air traffic controller.
2) Air traffic control in Atlanta does need to be aware of what the ATC in New York is doing.
3) The blender Alexis uses to make us coctails does not care if the power it uses came from Georgia Power, Alabama Power or Florida power, nor does it care if it was generated using Coal, Hydro, Nuclear etc. power...
4) Georgia power does not sit in design meetings with the Xbox engineering team.
5) The system to generate power, handle luggage, load meals on planes etc. is free to innovate and be adopted independently from the ability to fly people around reliably.

My hopes for the CNCF reference model is that we show this reference model inclusive of the OCF and DAB and independent of the technologies, projects and products which can be used to enable the behaviors. I also hope that ongoing we maintain the list of these players and where they play when they implement according to the reference architecture.

Thoughts? Have I completely lost my mind?



-----Original Message-----
From: cncf-toc-bounces@lists.cncf.io [mailto:cncf-toc-bounces@lists.cncf.io] On Behalf Of Alexis Richardson via cncf-toc
Sent: Friday, July 22, 2016 11:50 AM
To: Alan Conley <aconley@infoblox.com>
Cc: cncf-toc@lists.cncf.io
Subject: Re: [cncf-toc] audience for "reference architecture" content

Alan,

Thank-you.

"anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional
component that would fit within that architecture. Pretty much every
company I've spoken with is currently rolling their own from a select
set of open source projects and developing their own glue to fill gaps
and stitch the pieces together"

Does this mean:
- large enterprises
- vendors
- other..?

a



On Fri, Jul 22, 2016 at 4:44 PM, Alan Conley <aconley@infoblox.com> wrote:
I think this goes back to what is the charter of the CNCF.


Taking a few short cuts in this narrative and avoiding some of the politics.
Containers became mainstream when docker "standardized" their use. The
industry saw this rapid adoption and suggested a forum should "govern" these
standards which resulted in the OCP->OCI. From the OCI charter,
"...industry participants may easily contribute to building a
vendor-neutral, portable and open specification and runtime...". So we have
both a spec and working code.


What was missing, was the equivalent for container management (orchestrator,
control plane, monitoring) solutions. I believe this was the genesis of the
CNCF, originated by Craig and why k8s was the initial project. The original
reference architecture provided a simple view of these functional
components. BTW, most would see the similarities between this and OpenStack
for VMs. I personally have no interest in seeing the CNCF focused on one
implementation.


Assuming I'm not completely off the path, the target audience for the ref
arch is anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional component
that would fit within that architecture. Pretty much every company I've
spoken with is currently rolling their own from a select set of open source
projects and developing their own glue to fill gaps and stitch the pieces
together. (My company is doing that for our own SaaS solutions.) There are
a few of us interested in extending what we see as one of the needed
functional components. However, we are unclear on how others see that
interfacing with other components and in some cases see overlapping
capabilities. We can certainly just put it out there and see if there is
adoption, but then that begs the question as to what value does the CNCF
actually provide other than marketing.


I'll stop before this becomes too much of a ramble, for comments.


Alan





________________________________
From: Alexis Richardson <alexis@weave.works>
Sent: Thursday, July 21, 2016 4:54 AM
To: cncf-toc@lists.cncf.io
Subject: audience for "reference architecture" content

Hi all,

Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken
and I put out. One piece of feedback, from Doug Davis by email, and then eg
from Alan Conley on the call, was that much more detail could help.

I believe this is a "target audience" issue. We may need different material
for different audiences even if those audiences are all "technical". For
example - I argued that for developer end users, less detail is good.

It would be very helpful to hear from the people advocating for more detail,
regarding their target audience.

alexis


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


Re: audience for "reference architecture" content

NASSAUR, DOUGLAS C <dn283x@...>
 

The approach I've been taking on this has been from a slightly different perspective. Most definitions have started with the infrastructure and I'm starting from the application and working backwards.

Using a combination of the power company utility model and the airport "separation of concerns" model of Air traffic control and ground control, I've been defining the roles of a) An independent application or specialty platform, b) a cloud native application fabric and c) an infrastructure substrate.

The premise is that applications decompose into segments, each of which distill into a finite set of application workload patterns. These patterns align to composition, distribution and execution models which provide the characteristics and behaviors each specific pattern requires. Simply put, the jobs decompose as follows:

1) The application developer composes and describes the application
2) The app fabric recognizes the pattern, determines the best deployment pattern, transforms the workload and shops it for resources across a syndicate of infrastructure substrate providers (and technologies).
3) The infrastructure substrate executes the workload reliably at a local provider level

The fundamental shift notes that a cloud native app fabric scales business and technical functions implemented via software. As such, it can recognize demand using higher order indicators specific to functionality as opposed to traditional CPU, memory etc. As such, we align resource needs and utilization to meaningful business transactions and "right-size" supply with demand at the functional level.

If we take the technology, vendor and project names out of the picture and focus on capabilities we can describe this ecosystem in terms of enablers. Once we define these enablers and their roles in each of the three layers above we see pretty clearly that concepts like policy, orchestration etc. actually occur in several places and can draw the following parallels...

1) A baggage handler in New York has no need to know what a baggage handler in Atlanta is doing. Each does need to coordinate with their respective (and local) air traffic controller.
2) Air traffic control in Atlanta does need to be aware of what the ATC in New York is doing.
3) The blender Alexis uses to make us coctails does not care if the power it uses came from Georgia Power, Alabama Power or Florida power, nor does it care if it was generated using Coal, Hydro, Nuclear etc. power...
4) Georgia power does not sit in design meetings with the Xbox engineering team.
5) The system to generate power, handle luggage, load meals on planes etc. is free to innovate and be adopted independently from the ability to fly people around reliably.

My hopes for the CNCF reference model is that we show this reference model inclusive of the OCF and DAB and independent of the technologies, projects and products which can be used to enable the behaviors. I also hope that ongoing we maintain the list of these players and where they play when they implement according to the reference architecture.

Thoughts? Have I completely lost my mind?

-----Original Message-----
From: cncf-toc-bounces@lists.cncf.io [mailto:cncf-toc-bounces@lists.cncf.io] On Behalf Of Alexis Richardson via cncf-toc
Sent: Friday, July 22, 2016 11:50 AM
To: Alan Conley <aconley@infoblox.com>
Cc: cncf-toc@lists.cncf.io
Subject: Re: [cncf-toc] audience for "reference architecture" content

Alan,

Thank-you.

"anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional
component that would fit within that architecture. Pretty much every
company I've spoken with is currently rolling their own from a select
set of open source projects and developing their own glue to fill gaps
and stitch the pieces together"

Does this mean:
- large enterprises
- vendors
- other..?

a



On Fri, Jul 22, 2016 at 4:44 PM, Alan Conley <aconley@infoblox.com> wrote:
I think this goes back to what is the charter of the CNCF.


Taking a few short cuts in this narrative and avoiding some of the politics.
Containers became mainstream when docker "standardized" their use. The
industry saw this rapid adoption and suggested a forum should "govern" these
standards which resulted in the OCP->OCI. From the OCI charter,
"...industry participants may easily contribute to building a
vendor-neutral, portable and open specification and runtime...". So we have
both a spec and working code.


What was missing, was the equivalent for container management (orchestrator,
control plane, monitoring) solutions. I believe this was the genesis of the
CNCF, originated by Craig and why k8s was the initial project. The original
reference architecture provided a simple view of these functional
components. BTW, most would see the similarities between this and OpenStack
for VMs. I personally have no interest in seeing the CNCF focused on one
implementation.


Assuming I'm not completely off the path, the target audience for the ref
arch is anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional component
that would fit within that architecture. Pretty much every company I've
spoken with is currently rolling their own from a select set of open source
projects and developing their own glue to fill gaps and stitch the pieces
together. (My company is doing that for our own SaaS solutions.) There are
a few of us interested in extending what we see as one of the needed
functional components. However, we are unclear on how others see that
interfacing with other components and in some cases see overlapping
capabilities. We can certainly just put it out there and see if there is
adoption, but then that begs the question as to what value does the CNCF
actually provide other than marketing.


I'll stop before this becomes too much of a ramble, for comments.


Alan





________________________________
From: Alexis Richardson <alexis@weave.works>
Sent: Thursday, July 21, 2016 4:54 AM
To: cncf-toc@lists.cncf.io
Subject: audience for "reference architecture" content

Hi all,

Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken
and I put out. One piece of feedback, from Doug Davis by email, and then eg
from Alan Conley on the call, was that much more detail could help.

I believe this is a "target audience" issue. We may need different material
for different audiences even if those audiences are all "technical". For
example - I argued that for developer end users, less detail is good.

It would be very helpful to hear from the people advocating for more detail,
regarding their target audience.

alexis


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


Re: audience for "reference architecture" content

alexis richardson
 



On Fri, 22 Jul 2016, 17:12 Alan Conley, <aconley@...> wrote:

Of course they start with one of the major monolithic solutions in this space, k8s, mesos, docker dc.  However, they are working with different networking, monitoring, service r&d solutions.   Is there no desire to allow companies to replace a component in one of these major solutions?

yes I do think that network and a couple of other things are, ideally, pluggable in each platform.






From: Alexis Richardson <alexis@...>
Sent: Friday, July 22, 2016 9:05 AM

To: Alan Conley
Cc: cncf-toc@...
Subject: Re: audience for "reference architecture" content
On Fri, Jul 22, 2016 at 5:01 PM, Alan Conley <aconley@...> wrote:
> I'm referring mostly to large enterprises.

I find that startling.

Are you sure they are not just creating integration points around the
'edge' of Kubernetes or Docker Data Center or ...




>
>
> Alan
>
>
>
> ________________________________
> From: Alexis Richardson <alexis@...>
> Sent: Friday, July 22, 2016 8:50 AM
> To: Alan Conley
> Cc: cncf-toc@...
> Subject: Re: audience for "reference architecture" content
>
> Alan,
>
> Thank-you.
>
> "anyone assembling a container management solution (orchestrator,
> control plane etc.) and anyone attempting to build a functional
> component that would fit within that architecture.  Pretty much every
> company I've spoken with is currently rolling their own from a select
> set of open source projects and developing their own glue to fill gaps
> and stitch the pieces together"
>
> Does this mean:
> - large enterprises
> - vendors
> - other..?
>
> a
>
>
>
> On Fri, Jul 22, 2016 at 4:44 PM, Alan Conley <aconley@...> wrote:
>> I think this goes back to what is the charter of the CNCF.
>>
>>
>> Taking a few short cuts in this narrative and avoiding some of the
>> politics.
>> Containers became mainstream when docker "standardized" their use.  The
>> industry saw this rapid adoption and suggested a forum should "govern"
>> these
>> standards which resulted in the OCP->OCI.  From the OCI charter,
>> "...industry participants may easily contribute to building a
>> vendor-neutral, portable and open specification and runtime...".  So we
>> have
>> both a spec and working code.
>>
>>
>> What was missing, was the equivalent for container management
>> (orchestrator,
>> control plane, monitoring) solutions.  I believe this was the genesis of
>> the
>> CNCF, originated by Craig and why k8s was the initial project.  The
>> original
>> reference architecture provided a simple view of these functional
>> components.  BTW, most would see the similarities between this and
>> OpenStack
>> for VMs.  I personally have no interest in seeing the CNCF focused on one
>> implementation.
>>
>>
>> Assuming I'm not completely off the path, the target audience for the ref
>> arch is anyone assembling a container management solution (orchestrator,
>> control plane etc.) and anyone attempting to build a functional component
>> that would fit within that architecture.  Pretty much every company I've
>> spoken with is currently rolling their own from a select set of open
>> source
>> projects and developing their own glue to fill gaps and stitch the pieces
>> together.  (My company is doing that for our own SaaS solutions.)  There
>> are
>> a few of us interested in extending what we see as one of the needed
>> functional components.  However, we are unclear on how others see that
>> interfacing with other components and in some cases see overlapping
>> capabilities.  We can certainly just put it out there and see if there is
>> adoption, but then that begs the question as to what value does the CNCF
>> actually provide other than marketing.
>>
>>
>> I'll stop before this becomes  too much of a ramble, for comments.
>>
>>
>> Alan
>>
>>
>>
>>
>>
>> ________________________________
>> From: Alexis Richardson <alexis@...>
>> Sent: Thursday, July 21, 2016 4:54 AM
>> To: cncf-toc@...
>> Subject: audience for "reference architecture" content
>>
>> Hi all,
>>
>> Yesterday we had our 2nd discussion about the 'marketecture' stack that
>> Ken
>> and I put out.  One piece of feedback, from Doug Davis by email, and then
>> eg
>> from Alan Conley on the call, was that much more detail could help.
>>
>> I believe this is a "target audience" issue.  We may need different
>> material
>> for different audiences even if those audiences are all "technical".  For
>> example - I argued that for developer end users, less detail is good.
>>
>> It would be very helpful to hear from the people advocating for more
>> detail,
>> regarding their target audience.
>>
>> alexis
>>
>>
>>


Re: audience for "reference architecture" content

Alan Conley <aconley@...>
 

Of course they start with one of the major monolithic solutions in this space, k8s, mesos, docker dc.  However, they are working with different networking, monitoring, service r&d solutions.   Is there no desire to allow companies to replace a component in one of these major solutions?



From: Alexis Richardson <alexis@...>
Sent: Friday, July 22, 2016 9:05 AM
To: Alan Conley
Cc: cncf-toc@...
Subject: Re: audience for "reference architecture" content
 
On Fri, Jul 22, 2016 at 5:01 PM, Alan Conley <aconley@...> wrote:
> I'm referring mostly to large enterprises.

I find that startling.

Are you sure they are not just creating integration points around the
'edge' of Kubernetes or Docker Data Center or ...




>
>
> Alan
>
>
>
> ________________________________
> From: Alexis Richardson <alexis@...>
> Sent: Friday, July 22, 2016 8:50 AM
> To: Alan Conley
> Cc: cncf-toc@...
> Subject: Re: audience for "reference architecture" content
>
> Alan,
>
> Thank-you.
>
> "anyone assembling a container management solution (orchestrator,
> control plane etc.) and anyone attempting to build a functional
> component that would fit within that architecture.  Pretty much every
> company I've spoken with is currently rolling their own from a select
> set of open source projects and developing their own glue to fill gaps
> and stitch the pieces together"
>
> Does this mean:
> - large enterprises
> - vendors
> - other..?
>
> a
>
>
>
> On Fri, Jul 22, 2016 at 4:44 PM, Alan Conley <aconley@...> wrote:
>> I think this goes back to what is the charter of the CNCF.
>>
>>
>> Taking a few short cuts in this narrative and avoiding some of the
>> politics.
>> Containers became mainstream when docker "standardized" their use.  The
>> industry saw this rapid adoption and suggested a forum should "govern"
>> these
>> standards which resulted in the OCP->OCI.  From the OCI charter,
>> "...industry participants may easily contribute to building a
>> vendor-neutral, portable and open specification and runtime...".  So we
>> have
>> both a spec and working code.
>>
>>
>> What was missing, was the equivalent for container management
>> (orchestrator,
>> control plane, monitoring) solutions.  I believe this was the genesis of
>> the
>> CNCF, originated by Craig and why k8s was the initial project.  The
>> original
>> reference architecture provided a simple view of these functional
>> components.  BTW, most would see the similarities between this and
>> OpenStack
>> for VMs.  I personally have no interest in seeing the CNCF focused on one
>> implementation.
>>
>>
>> Assuming I'm not completely off the path, the target audience for the ref
>> arch is anyone assembling a container management solution (orchestrator,
>> control plane etc.) and anyone attempting to build a functional component
>> that would fit within that architecture.  Pretty much every company I've
>> spoken with is currently rolling their own from a select set of open
>> source
>> projects and developing their own glue to fill gaps and stitch the pieces
>> together.  (My company is doing that for our own SaaS solutions.)  There
>> are
>> a few of us interested in extending what we see as one of the needed
>> functional components.  However, we are unclear on how others see that
>> interfacing with other components and in some cases see overlapping
>> capabilities.  We can certainly just put it out there and see if there is
>> adoption, but then that begs the question as to what value does the CNCF
>> actually provide other than marketing.
>>
>>
>> I'll stop before this becomes  too much of a ramble, for comments.
>>
>>
>> Alan
>>
>>
>>
>>
>>
>> ________________________________
>> From: Alexis Richardson <alexis@...>
>> Sent: Thursday, July 21, 2016 4:54 AM
>> To: cncf-toc@...
>> Subject: audience for "reference architecture" content
>>
>> Hi all,
>>
>> Yesterday we had our 2nd discussion about the 'marketecture' stack that
>> Ken
>> and I put out.  One piece of feedback, from Doug Davis by email, and then
>> eg
>> from Alan Conley on the call, was that much more detail could help.
>>
>> I believe this is a "target audience" issue.  We may need different
>> material
>> for different audiences even if those audiences are all "technical".  For
>> example - I argued that for developer end users, less detail is good.
>>
>> It would be very helpful to hear from the people advocating for more
>> detail,
>> regarding their target audience.
>>
>> alexis
>>
>>
>>


Re: audience for "reference architecture" content

alexis richardson
 

On Fri, Jul 22, 2016 at 5:01 PM, Alan Conley <aconley@infoblox.com> wrote:
I'm referring mostly to large enterprises.
I find that startling.

Are you sure they are not just creating integration points around the
'edge' of Kubernetes or Docker Data Center or ...






Alan



________________________________
From: Alexis Richardson <alexis@weave.works>
Sent: Friday, July 22, 2016 8:50 AM
To: Alan Conley
Cc: cncf-toc@lists.cncf.io
Subject: Re: audience for "reference architecture" content

Alan,

Thank-you.

"anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional
component that would fit within that architecture. Pretty much every
company I've spoken with is currently rolling their own from a select
set of open source projects and developing their own glue to fill gaps
and stitch the pieces together"

Does this mean:
- large enterprises
- vendors
- other..?

a



On Fri, Jul 22, 2016 at 4:44 PM, Alan Conley <aconley@infoblox.com> wrote:
I think this goes back to what is the charter of the CNCF.


Taking a few short cuts in this narrative and avoiding some of the
politics.
Containers became mainstream when docker "standardized" their use. The
industry saw this rapid adoption and suggested a forum should "govern"
these
standards which resulted in the OCP->OCI. From the OCI charter,
"...industry participants may easily contribute to building a
vendor-neutral, portable and open specification and runtime...". So we
have
both a spec and working code.


What was missing, was the equivalent for container management
(orchestrator,
control plane, monitoring) solutions. I believe this was the genesis of
the
CNCF, originated by Craig and why k8s was the initial project. The
original
reference architecture provided a simple view of these functional
components. BTW, most would see the similarities between this and
OpenStack
for VMs. I personally have no interest in seeing the CNCF focused on one
implementation.


Assuming I'm not completely off the path, the target audience for the ref
arch is anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional component
that would fit within that architecture. Pretty much every company I've
spoken with is currently rolling their own from a select set of open
source
projects and developing their own glue to fill gaps and stitch the pieces
together. (My company is doing that for our own SaaS solutions.) There
are
a few of us interested in extending what we see as one of the needed
functional components. However, we are unclear on how others see that
interfacing with other components and in some cases see overlapping
capabilities. We can certainly just put it out there and see if there is
adoption, but then that begs the question as to what value does the CNCF
actually provide other than marketing.


I'll stop before this becomes too much of a ramble, for comments.


Alan





________________________________
From: Alexis Richardson <alexis@weave.works>
Sent: Thursday, July 21, 2016 4:54 AM
To: cncf-toc@lists.cncf.io
Subject: audience for "reference architecture" content

Hi all,

Yesterday we had our 2nd discussion about the 'marketecture' stack that
Ken
and I put out. One piece of feedback, from Doug Davis by email, and then
eg
from Alan Conley on the call, was that much more detail could help.

I believe this is a "target audience" issue. We may need different
material
for different audiences even if those audiences are all "technical". For
example - I argued that for developer end users, less detail is good.

It would be very helpful to hear from the people advocating for more
detail,
regarding their target audience.

alexis



Re: audience for "reference architecture" content

Alan Conley <aconley@...>
 

I'm referring mostly to large enterprises


Alan




From: Alexis Richardson <alexis@...>
Sent: Friday, July 22, 2016 8:50 AM
To: Alan Conley
Cc: cncf-toc@...
Subject: Re: audience for "reference architecture" content
 
Alan,

Thank-you.

"anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional
component that would fit within that architecture.  Pretty much every
company I've spoken with is currently rolling their own from a select
set of open source projects and developing their own glue to fill gaps
and stitch the pieces together"

Does this mean:
- large enterprises
- vendors
- other..?

a



On Fri, Jul 22, 2016 at 4:44 PM, Alan Conley <aconley@...> wrote:
> I think this goes back to what is the charter of the CNCF.
>
>
> Taking a few short cuts in this narrative and avoiding some of the politics.
> Containers became mainstream when docker "standardized" their use.  The
> industry saw this rapid adoption and suggested a forum should "govern" these
> standards which resulted in the OCP->OCI.  From the OCI charter,
> "...industry participants may easily contribute to building a
> vendor-neutral, portable and open specification and runtime...".  So we have
> both a spec and working code.
>
>
> What was missing, was the equivalent for container management (orchestrator,
> control plane, monitoring) solutions.  I believe this was the genesis of the
> CNCF, originated by Craig and why k8s was the initial project.  The original
> reference architecture provided a simple view of these functional
> components.  BTW, most would see the similarities between this and OpenStack
> for VMs.  I personally have no interest in seeing the CNCF focused on one
> implementation.
>
>
> Assuming I'm not completely off the path, the target audience for the ref
> arch is anyone assembling a container management solution (orchestrator,
> control plane etc.) and anyone attempting to build a functional component
> that would fit within that architecture.  Pretty much every company I've
> spoken with is currently rolling their own from a select set of open source
> projects and developing their own glue to fill gaps and stitch the pieces
> together.  (My company is doing that for our own SaaS solutions.)  There are
> a few of us interested in extending what we see as one of the needed
> functional components.  However, we are unclear on how others see that
> interfacing with other components and in some cases see overlapping
> capabilities.  We can certainly just put it out there and see if there is
> adoption, but then that begs the question as to what value does the CNCF
> actually provide other than marketing.
>
>
> I'll stop before this becomes  too much of a ramble, for comments.
>
>
> Alan
>
>
>
>
>
> ________________________________
> From: Alexis Richardson <alexis@...>
> Sent: Thursday, July 21, 2016 4:54 AM
> To: cncf-toc@...
> Subject: audience for "reference architecture" content
>
> Hi all,
>
> Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken
> and I put out.  One piece of feedback, from Doug Davis by email, and then eg
> from Alan Conley on the call, was that much more detail could help.
>
> I believe this is a "target audience" issue.  We may need different material
> for different audiences even if those audiences are all "technical".  For
> example - I argued that for developer end users, less detail is good.
>
> It would be very helpful to hear from the people advocating for more detail,
> regarding their target audience.
>
> alexis
>
>
>


Re: audience for "reference architecture" content

alexis richardson
 

Alan,

Thank-you.

"anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional
component that would fit within that architecture. Pretty much every
company I've spoken with is currently rolling their own from a select
set of open source projects and developing their own glue to fill gaps
and stitch the pieces together"

Does this mean:
- large enterprises
- vendors
- other..?

a

On Fri, Jul 22, 2016 at 4:44 PM, Alan Conley <aconley@infoblox.com> wrote:
I think this goes back to what is the charter of the CNCF.


Taking a few short cuts in this narrative and avoiding some of the politics.
Containers became mainstream when docker "standardized" their use. The
industry saw this rapid adoption and suggested a forum should "govern" these
standards which resulted in the OCP->OCI. From the OCI charter,
"...industry participants may easily contribute to building a
vendor-neutral, portable and open specification and runtime...". So we have
both a spec and working code.


What was missing, was the equivalent for container management (orchestrator,
control plane, monitoring) solutions. I believe this was the genesis of the
CNCF, originated by Craig and why k8s was the initial project. The original
reference architecture provided a simple view of these functional
components. BTW, most would see the similarities between this and OpenStack
for VMs. I personally have no interest in seeing the CNCF focused on one
implementation.


Assuming I'm not completely off the path, the target audience for the ref
arch is anyone assembling a container management solution (orchestrator,
control plane etc.) and anyone attempting to build a functional component
that would fit within that architecture. Pretty much every company I've
spoken with is currently rolling their own from a select set of open source
projects and developing their own glue to fill gaps and stitch the pieces
together. (My company is doing that for our own SaaS solutions.) There are
a few of us interested in extending what we see as one of the needed
functional components. However, we are unclear on how others see that
interfacing with other components and in some cases see overlapping
capabilities. We can certainly just put it out there and see if there is
adoption, but then that begs the question as to what value does the CNCF
actually provide other than marketing.


I'll stop before this becomes too much of a ramble, for comments.


Alan





________________________________
From: Alexis Richardson <alexis@weave.works>
Sent: Thursday, July 21, 2016 4:54 AM
To: cncf-toc@lists.cncf.io
Subject: audience for "reference architecture" content

Hi all,

Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken
and I put out. One piece of feedback, from Doug Davis by email, and then eg
from Alan Conley on the call, was that much more detail could help.

I believe this is a "target audience" issue. We may need different material
for different audiences even if those audiences are all "technical". For
example - I argued that for developer end users, less detail is good.

It would be very helpful to hear from the people advocating for more detail,
regarding their target audience.

alexis



Re: audience for "reference architecture" content

Alan Conley <aconley@...>
 

I think this goes back to what is the charter of the CNCF.  


Taking a few short cuts in this narrative and avoiding some of the politics.  Containers became mainstream when docker "standardized" their use.  The industry saw this rapid adoption and suggested a forum should "govern" these standards which resulted in the OCP->OCI.  From the OCI charter, "...industry participants may easily contribute to building a vendor-neutral, portable and open specification and runtime...".  So we have both a spec and working code.


What was missing, was the equivalent for container management (orchestrator, control plane, monitoring) solutions.  I believe this was the genesis of the CNCF, originated by Craig and why k8s was the initial project.  The original reference architecture provided a simple view of these functional components.  BTW, most would see the similarities between this and OpenStack for VMs.  I personally have no interest in seeing the CNCF focused on one implementation.


Assuming I'm not completely off the path, the target audience for the ref arch is anyone assembling a container management solution (orchestrator, control plane etc.) and anyone attempting to build a functional component that would fit within that architecture.  Pretty much every company I've spoken with is currently rolling their own from a select set of open source projects and developing their own glue to fill gaps and stitch the pieces together.  (My company is doing that for our own SaaS solutions.)  There are a few of us interested in extending what we see as one of the needed functional components.  However, we are unclear on how others see that interfacing with other components and in some cases see overlapping capabilities.  We can certainly just put it out there and see if there is adoption, but then that begs the question as to what value does the CNCF actually provide other than marketing.


I'll stop before this becomes  too much of a ramble, for comments.


Alan






From: Alexis Richardson <alexis@...>
Sent: Thursday, July 21, 2016 4:54 AM
To: cncf-toc@...
Subject: audience for "reference architecture" content
 
Hi all,

Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken and I put out.  One piece of feedback, from Doug Davis by email, and then eg from Alan Conley on the call, was that much more detail could help.  

I believe this is a "target audience" issue.  We may need different material for different audiences even if those audiences are all "technical".  For example - I argued that for developer end users, less detail is good.  

It would be very helpful to hear from the people advocating for more detail, regarding their target audience.

alexis




Re: audience for "reference architecture" content

alexis richardson
 

All,

Here is a slightly cleaned up version of the "projects and products" data that I mentioned.  It is also a cloud native market landscape.  Ken and I used this to inform our initial thinking on the simplified reference stack, which is also shown on the second tab.  


The original categories were based on public analysis by Matt Miller at Sequoia, but I have modified the categorisation a little.  I have also shown this data to other folks who analyse the space - press, investors, etc.  It feels reasonably thorough.  

I ask that you be gracious in your comments, first by noting some caveats.

1) Some of the categories are definitely "not quite right".  For example the APM-Logging spectrum is a moving target.  I have tried to split this into functions like "visualization" and "monitoring", without complete success.  It feels unfair in places.  Same thing for "platform".  But, I think it's a starting point.

2) I have not tried to put projects in "order of significance".  Just because something is at the top of a list, it does not make it more important than stuff lower down.  The ordering is more "as I thought of them" - ie. subjective.  It would be good to have a better model here, eg. public vs private vs startup vs community... But even that could be invidious.

3) The data in the sheet does not *quite* line up yet with some of the items in Ken's v0.3 deck.  https://docs.google.com/presentation/d/1uMw2wkK0ubmc3khxqIuxK_rLK_wN89tNCnK7gDmTGR8/edit#slide=id.p8

alexis


PS -- Doug, I hope this helps with your questions below.



On Thu, Jul 21, 2016 at 1:28 PM, Doug Davis <dug@...> wrote:

Alexis,

I think the new picture is fine to show things at a very high level (e.g. IaaS at the bottom, PaaS and SaaS are higher up, etc.) but I think most of my conversations will very quickly get into something more like "where does project X fit into all of this?" - and that's where I think the current picture is more useful. With so many CN-related projects out there, a more detailed picture helps to explain how all of the various puzzle pieces (projects) come together into one cohesive story. It also helps to show where we expect people to mix-n-match things based on their needs and where the plug-points might be.

thanks
-Doug
_______________________________________________________
STSM | IBM Open Source, Cloud Architecture & Technology
(919) 254-6905 | IBM 444-6905 | dug@...
The more I'm around some people, the more I like my dog

Alexis Richardson via cncf-toc ---07/21/2016 07:54:53 AM---Hi all, Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken

From: Alexis Richardson via cncf-toc <cncf-toc@...>
To: "cncf-toc@..." <cncf-toc@...>
Date: 07/21/2016 07:54 AM
Subject: [cncf-toc] audience for "reference architecture" content
Sent by: cncf-toc-bounces@...





Hi all,

Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken and I put out.  One piece of feedback, from Doug Davis by email, and then eg from Alan Conley on the call, was that much more detail could help.  

I believe this is a "target audience" issue.  We may need different material for different audiences even if those audiences are all "technical".  For example - I argued that for developer end users, less detail is good.  

It would be very helpful to hear from the people advocating for more detail, regarding their target audience.

alexis


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




Re: audience for "reference architecture" content

Doug Davis <dug@...>
 

Alexis,

I think the new picture is fine to show things at a very high level (e.g. IaaS at the bottom, PaaS and SaaS are higher up, etc.) but I think most of my conversations will very quickly get into something more like "where does project X fit into all of this?" - and that's where I think the current picture is more useful. With so many CN-related projects out there, a more detailed picture helps to explain how all of the various puzzle pieces (projects) come together into one cohesive story. It also helps to show where we expect people to mix-n-match things based on their needs and where the plug-points might be.

thanks
-Doug
_______________________________________________________
STSM | IBM Open Source, Cloud Architecture & Technology
(919) 254-6905 | IBM 444-6905 | dug@...
The more I'm around some people, the more I like my dog

Alexis Richardson via cncf-toc ---07/21/2016 07:54:53 AM---Hi all, Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken

From: Alexis Richardson via cncf-toc <cncf-toc@...>
To: "cncf-toc@..." <cncf-toc@...>
Date: 07/21/2016 07:54 AM
Subject: [cncf-toc] audience for "reference architecture" content
Sent by: cncf-toc-bounces@...





Hi all,

Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken and I put out.  One piece of feedback, from Doug Davis by email, and then eg from Alan Conley on the call, was that much more detail could help.  

I believe this is a "target audience" issue.  We may need different material for different audiences even if those audiences are all "technical".  For example - I argued that for developer end users, less detail is good.  

It would be very helpful to hear from the people advocating for more detail, regarding their target audience.

alexis


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



audience for "reference architecture" content

alexis richardson
 

Hi all,

Yesterday we had our 2nd discussion about the 'marketecture' stack that Ken and I put out.  One piece of feedback, from Doug Davis by email, and then eg from Alan Conley on the call, was that much more detail could help.  

I believe this is a "target audience" issue.  We may need different material for different audiences even if those audiences are all "technical".  For example - I argued that for developer end users, less detail is good.  

It would be very helpful to hear from the people advocating for more detail, regarding their target audience.

alexis




introducing - anand from minio

alexis richardson
 

Hi all,

There was some interest in talking with people who work on Minio.  I have copied Anand "AB" Periasamy, with whom I spoke on Tuesday.

AB,

On the TOC call yesterday, I introduced the idea of Minio creating a CNCF Proposal.  I want to give you some early feedback on this.  Please note that TOC calls are public and that this CNCF mailing list is public.

The first impression - as I mentioned when we spoke on Tuesday - is that Minio is a 'young' project.  As a TOC we are probably minded towards more mature projects at present.  One question that arose is - who is using Minio in production?  There was a feeling that this is especially a concern with distributed storage technology where maturity is hard won.  

Overall, cloud native storage is quite interesting.  We'd love to know: what new things Minio is doing that make it special, how it is designed, and so on.  Do you have anything you could share on that topic?

alexis

6081 - 6100 of 6383