FW: Interesting tech marketing from Amazon

NASSAUR, DOUGLAS C <dn283x@...>

Sorry team, Alexis noticed this did not go to the list. Repost. Thanks


From: Alexis Richardson [mailto:alexis@...]
Sent: Thursday, February 16, 2017 1:22 PM
To: NASSAUR, DOUGLAS C <dn283x@...>; Camille Fournier <skamille@...>
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon




I think you should post your thoughts to the public TOC list.





On Wed, Feb 15, 2017 at 12:22 PM NASSAUR, DOUGLAS C <dn283x@...> wrote:

Hey gang,


Sharing an effort we are working on for the architecture committee to share with all. Focused specifically on defining the app patterns that will be deployed with a cloud native infrastructure. Also, specifically defining the enablers that must reside within the cloud native infrastructure to establish a programmable infrastructure topology. Lastly, proposing interface agreements which must exist among the elements to function together when enabling cloud native behaviors.


The approach is intended to tease out for the team/consideration/discussion the specific details associated with “container-packaged”, “dynamically scheduled” and “micro-services oriented”. The intent is to assume three major role categories of enablers that contribute to establish cloud native behaviors: Host/Infra foundations, distribution foundations and app/platform foundations.


Offering an example of a pattern being analyzed I’d offer the following:

1)      Application decomposes into Gateway service, UI/UX services, App Logic Interface, Data Layer Adapter/Interface, Data Model services

2)      Legacy deployment model (Physical or Virtualized) co-locates grouping of these services across typical web/app/db service stack.

3)      Interaction/discovery among intra-app services and from client/peer apps to app services is traditional DNS, IP Route, Load Balancer, ARP, Mac pathway in an active-active, active-passive failover model.

4)      While elements of the application service model is decomposed and packaged (Containerized) and can be distributed across a container fabric it does not refactor application logic.

5)      Contrast this with application refactoring to establish a micro-service orientation and illustrate the new platform services that must be present within the programmable infrastructure topology to support endpoint registration, Service discovery, centralized eventing/messaging and shared frameworks, runtimes and services.


Spinning this up next week on the architecture committee mailing list and welcome all participation and super-smart brains to collaborate. Huge disconnect in the market right now between containerization and ipso-facto micro-services. Good opportunity for us to provide leadership/clarity imo. Delineation for the masses of the difference between a virtually hosted workload and true micro-service and the investment/return case inclusive of cloud native elements that must be included.


Look forward to your thoughts.







From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Camille Fournier via cncf-toc
Sent: Tuesday, February 14, 2017 1:25 PM
To: Alexis Richardson <alexis@...>
Cc: cncf-toc@...
Subject: Re: [cncf-toc] Interesting tech marketing from Amazon


Microservices are cloud native because they are a natural product of the ease of use for cloud. In a evolutionary way I would call them absolutely cloud native, which doesn't mean one must use them to effectively use the cloud but they do effectively show how cloud changed the way developers thought about building systems.


On Feb 14, 2017 10:22 AM, "Alexis Richardson via cncf-toc" <cncf-toc@...> wrote:


On Tue, Feb 14, 2017 at 10:20 AM Anthony Skipper <anthony@...> wrote:

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


Yes, I don't think microservices is a core value.  It's one of several modern cloud native patterns that is useful for some organisational and technical issues.  But not the only one.







On Tue, Feb 14, 2017 at 1:15 PM, Mark Coleman via cncf-toc <cncf-toc@...> wrote:

I think I summarised it in this piece that I ghost wrote for Luke when he was at ClusterHQ (Friend D A please): https://www.infoq.com/articles/microservices-revolution


We have a cloud native triangle composed of:


1. Speed of change (I refer to this as agility in that doc but in general would like to avoid the term moving forwards)

2. Resilience (We should be able to change software quickly and not have it break due to internal or external factors)

3. Scale: We'd like to do really big stuff


From those core requirements we can rationalize containerization, microservices and continuous delivery.


From those 'practices' we can talk about specific tools.


Where we fall down is when we start from the tools, but obviously a large part of getting things right (especially microservices I would argue) require pink matter.


On Tue, Feb 14, 2017 at 10:09 AM Alexis Richardson <alexis@...> wrote:



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


- free & open 

- automated pipelines

- faster to make changes

- ..?



On Tue, Feb 14, 2017 at 10:07 AM Mark Coleman <mark@...> wrote:

I like the model of bringing in end user stories to support the point being made.


The point here clearly seems to be "it's ok to move all your shit to the cloud snd figure it out there" which is an unsurprising position for AWS to take. This is not an opposing point to our mission(TM) though so I will explore this.


Right now I'm mainly concerned that our definition of cloud native is not everyone else's.


On Thu, Feb 2, 2017 at 1:34 AM Alexis Richardson <alexis@...> wrote:

I thought this was worth sharing as an example of the sort of tech-biz guidance that members of the CNCF community could write.  The piece is by someone from AWS and talks about cloud native vs other cloudy things.





cncf-toc mailing list

cncf-toc mailing list