Chris, You can add my doc to the link/wiki, has all the tech background on the first topic we discussed (function portability and common event/context model), see: https://docs.google.com/document/d/1

Ken, I would join for iguazio, we have high-perf “serverless” framework for internal use and will soon open-source it Seems like there is a consensus that serverless function portability and common ev

Ben, This is a good point, we can define few Event categories e.g.: Sync (req/rep model like REST), Async (unordered/unrelated msg), Stream (ordered set of msg), and Workflow (graph). and have common

Solomon, Seems like there is interest to learn about Moby beyond the TOC Saw your TheCUBE interview and Moby does make sense, sort of the Linux and RedHat/Fedora model if I got it right The things tha

Mark/Doug, I added my comments and more content to the doc No room for “standards” yet, but I think it’s better to discuss when things are in an early stage rather than after people made significant i

Cathy, I agree that Workflows and Jobs are a natural extension to “Functions”, just like https://aws.amazon.com/step-functions/ I can share my views in the WG how it can be architected into the same f

Doug, I agree, e.g. couple of 1st level topics to start with: Define what constitutes the “Event” and “Context” structures in the function call + expected response, so Functions can be made portable a

“serverless” Perf is a big issue, start-up time is just part of it, most implementation have huge per F call overhead Can see AWS Lambda avg call (after warm-up) is 500ms: https://medium.com/@ferdingl

I agree with many of the points, had a bunch of 1:1 chats @ KubeCon on the need for more colaboration in that space There will be a bunch of implementations by cloud and OpenSource (I presented ours,

Alex, I agree with Clinton’s point that we want to focus on what makes Cloud-Native different, not sure covering all the legacy Storage protocols serves that purpose There are too many users today tha

I wrote a post a while ago on impact of Cloud-Native on Storage, can reuse its content, you may want to take the abstraction to the next level just like we did on compute (from VMs to services/apps).

Andy, thanks, sure we should follow w “How” after the “Why” Another reason for that order is to set the architecture context, e.g. many still view containers as lightweight VMs, can see requests for v

If anyone care to watch Simon’s talk pointed by Tony: "people don't buy WHAT you do, but WHY you do it", Containers, micro-services, .. are the what, my point is we should focus on the Why i.e. Why cl

I think the key message of Cloud-Native should be about its value: Continuous Development and Operation (Enabling Business Agility/Transformation) Decomposition to micro-services, stateless, disposabl

I think we should consider a working group or SIG for “serverless” some of those solutions look naïve at best there is a lot of overlap between k8s functionality and “serverless” on one hand, on the o

Chris, Probably too late to comment, but looking at the charts seems like we are missing a notion of resources binding / dependency, similar to cloud foundry E. G. A web Micro-Service binds to (or dep

Yaron Haviv, Founder & CTO, iguaz.io In the past two decades my direct reports and I have been involved in multiple standard organization bodies and have made significant contributions to variety of v