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

Join cncf-toc@lists.cncf.io to automatically receive all group messages.