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 >> >> >> |
|