cncf-toc@lists.cncf.io | The Cloud-Nativity of Serverless

_______________________________________________
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

Kehoe, Ben <bkehoe@...> #826 Hello all, Sorry to join the discussion so late. I've added comments to the document, but I also wanted to present some thoughts more directly. I work at iRobot, and we transitioned our fleet of connected consumer robots from a full-solution IoT cloud provider to a custom application built on AWS services. This application uses no unmanaged EC2 instances, and therefore I feel justified in calling it fully (or even natively?) serverless. I think serverless is a spectrum, though, rather than a binary classification. First, on naming and scope: "serverless" is, of course, a less than ideal name, but in some ways I think that ship has already sailed. In the mid-aughts, lots of people thought "cloud" was a misleading, ambiguous term—and they were right. But we're stuck with it, and its ambiguities persist to this day. I suspect "serverless" is going to follow the same route (fun fact: SQLite has been calling itself serverless, in the literal sense, since 2007 [1]). I think the primary danger in the ambiguity of "serverless" is about its scope. A lot of people associate it almost exclusively with FaaS, and in my opinion, FaaS is indeed the core of the serverless paradigm—but I also think that paradigm is much wider than just FaaS. A more apt name, suggested by Patrick Debois, is "servicefull" [2] (but, as I said, I don't expect this to gain traction). The most powerful advantage of AWS Lambda is its integration into the ecosystem of AWS services. While iRobot's customer-facing application has its compute entirely in AWS Lambda, it relies on 21 other AWS services to provide the full solution. For many of the features these services provide, switching to another FaaS provider would require a server-based replacement. In terms of standardization or stewardship, I think it may be more useful to work first on the ecosystem integration points, rather than the FaaS implementation itself. Second, the piece that I think is most relevant to the "cloud native" charter in particular: this is speculative and disputed, but I think there is a paradigm shift around serverless and FaaS in the works. The stage we're at currently is biting around the edges: adding glue using FaaS where events already exist in the system. But over time, I think we'll see a shift to "serverless native" as the default—systems will be designed to be event-driven because that enables serverless/FaaS-based architecture, and that will be the default architecture paradigm because of reduction in ops required. In my experience, the biggest shift the change in architecture requires, besides simply a change in mindset, is a change in infrastructure management. With functions as the unit of deployment, your call graph becomes your infrastructure graph. This introduces more integration points, and more opportunities for coupling (especially because of optimizations to mitigate the higher latencies associated with cold starts and container thaw). It seems to me like the cadence of changes to infrastructure is going to be much higher in a serverless native system than with a traditional architecture, and this is going to affect deployment strategies and tooling. Anyways, that's probably more than two cents but it's mine. Thanks for including us in this discussion! Best, Ben [1] https://web-beta.archive.org/web/20071115173112/https://sqlite.org/serverless.html [2] https://www.slideshare.net/jedi4ever/from-serverless-to-service-full-how-the-role-of-devops-is-evolving toggle quoted message Show quoted text From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Cathy Zhang via cncf-toc Sent: Thursday, April 6, 2017 2:00 PM To: Doug Davis <dug@...>; Yaron Haviv <yaronh@...>; Cathy Zhang <Cathy.H.Zhang@...>; cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I also added more content to the doc. I agree with Yaron and Doug on discussing and collaborating at an early stage to avoid the pain of having to build a converged standard later. Especially for the user facing part, I hope we can bring end users into the discussion and work out some baseline that is easy to be extended in the future. It will speed up cloud native adoption if the users are provided with a consistent “interface”. Cathy From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Doug Davis via cncf-toc Sent: Wednesday, April 05, 2017 6:28 PM To: Yaron Haviv Cc: cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Yario - exactly. Even if its too soon for standards, just having some of the key players in the same (virtual) room discussing high level topics (like terminology and usecases) might lead to the identification of areas where people will want to collaborate - with or w/o the involvement of any formal CNCF process. To me this was one of my hopes/goals for the CNCF - be a catalyst for collaboration. 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 Yaron Haviv ---04/05/2017 07:27:00 PM---Mark/Doug, I added my comments and more content to the doc From: Yaron Haviv <yaronh@...> To: Mark Peek <markpeek@...>, Doug Davis/Raleigh/IBM@IBMUS Cc: "cncf-toc@..." <cncf-toc@...> Date: 04/05/2017 07:27 PM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless 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 investments and wont be open for changes. For example, today Docker, DC/OS, & k8s each use a different Volume driver, people spent quite some time to develop those, and now CNCF works on a converged standard and we need to build a 4^th one. This could have been avoided/minimized if the community collaborated at an earlier stage. Personally, I would like to merge efforts with other serverless/FaaS providers, identify areas we can work on together to use the same components (and save VC $$) or leverage 3^rd party solutions (too old for NIH). Will also help remove end-user confusion which slows the market. I’m optimistic others will share that view. For that to happen we need a forum to identify what we all agree on and where each may have unique requirements/opinions which force us to diverge. Such a forum can also work with end users and the broader eco system to gather requirements which help us to further increase cloud native adoption. To my friend Josh, IMO Serverless/FaaS is not yet another widget/use-case, if done right it’s a real-thing that will drive Cloud-Native adoption, removing friction and complexity always win with the mainstream. Yaron Iguazio, CTO From: Mark Peek [mailto:markpeek@...] Sent: Wednesday, April 5, 2017 10:40 PM To: Doug Davis <dug@...>; Yaron Haviv <yaronh@...> Cc: cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless For continuity on this thread, here are some quick notes from discussion in the TOC meeting today: Seeing more developers embrace serverless Most (if not all) people on the call feel it is “early days” for serverless and there is a lot of learning that needs to occur TOC is not sure whether or not a WG should be formed Debate on standardization – don’t want to constrain implementations too early but interop is always good for end users Perhaps allow a minimal scope to launch the WG and have it report back to the TOC. Need a TOC sponsor Use Doug’s doc (link below) to add information on serverless and what a CNCF WG would do in this space for further review at an upcoming TOC call Feel free to correct/augment if I captured something incorrectly. Mark From: <cncf-toc-bounces@...> on behalf of Doug Davis via cncf-toc <cncf-toc@...> Reply-To: Doug Davis <dug@...> Date: Wednesday, April 5, 2017 at 5:01 AM To: Yaron Haviv <yaronh@...> Cc: "cncf-toc@..." <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I took the liberty of starting a google doc just to have a place for people to add their thoughts on this topic: https://docs.google.com/document/d/1L9n9tkGuGtj7Ap9dVRes9RVscSoXeKsF3k-d2hJcDlg/edit# its meant to just be a single place for people to brainstorm on the various topics I've seen mentioned so far in this thread. I'd like to use it, mainly, to just gather all possible topics, just so we don't let things fall thru the cracks. 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 Yaron Haviv ---04/02/2017 10:44:58 AM---Doug, I agree, e.g. couple of 1st level topics to start with: 1. Define what constitutes the “Eve From: Yaron Haviv <yaronh@...> To: Doug Davis/Raleigh/IBM@IBMUS, "cncf-toc@..." <cncf-toc@...> Cc: Clayton Coleman <ccoleman@...> Date: 04/02/2017 10:44 AM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless Doug, I agree, e.g. couple of 1^st 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 across implementations. Will also allow dev of standalone test harnesses/tools. Define a package format for code + library/binary dependencies, so tools can commit/push functions to any framework BTW I think the “serverless” notion can be easily extended to “Micro-Batch Jobs” and “Continuous Services”, the ease of use of writing and publishing cloud-native functions doesn’t have to end with event-driven use cases. Yaron From: Doug Davis [mailto:dug@...] Sent: Sunday, April 2, 2017 4:31 PM To: Yaron Haviv <yaronh@...> Cc: Clayton Coleman <ccoleman@...>; cncf-toc@... Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless One day we may be able to leverage common infrastructure, but for now I think a more realistic goal might be to focus on the end-user and see if we can push for an interoperability statement around what they are exposed to. IOW, focus on the OCI image format equivalent for serverless that gives users the freedom to move between implementations. 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 Yaron Haviv ---04/02/2017 03:54:07 AM---"serverless" Perf is a big issue, start-up time is just part of it, most implementation have huge pe From: Yaron Haviv <yaronh@...> To: Doug Davis/Raleigh/IBM@IBMUS, Clayton Coleman <ccoleman@...>, "cncf-toc@..." <cncf-toc@...> Date: 04/02/2017 03:54 AM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless “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/@ferdingler/aws-lambda-no-thank-you-9c586990e67d I assume we don’t want “Serverless” to consume many more servers, need to address concurrency, cut redundant layers, etc’ to make it useful beyond sporadic execution and web hooks, Wrote a blog on that. My KubeCon session covered various problems in current “serverless” implementations and how we addressed them w few real examples (slide 8-13): http://www.slideshare.net/yaronhaviv/building-super-fast-cloudnative-data-platforms-yaron-haviv-kubecon-2017-eu And again, the key is collaboration, assuming there will be multiple cloud/open implementations how do we make them interchangeable, allow code portability, and leverage common infrastructure and tooling Yaron From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Doug Davis via cncf-toc Sent: Saturday, April 1, 2017 4:01 PM To: Clayton Coleman <ccoleman@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Glad to see lots of agreement on this thread and +1 to the idea of a WG/SIG. One comment though, Ryan said: > I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. I'd put performance in the core, at least w.r.t. the container start-up time. If the performance of the infrastructure to setup the container to execute the function isn't fast enough then I think the uptake on this will be negatively impacted. 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 Clayton Coleman via cncf-toc ---04/01/2017 09:24:39 AM---On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc < cncf-toc@...> wrote: From: Clayton Coleman via cncf-toc <cncf-toc@...> To: Brian Grant <briangrant@...> Cc: cncf-toc <cncf-toc@...> Date: 04/01/2017 09:24 AM Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Sent by: cncf-toc-bounces@... On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. I think this is one of the areas that the open source community could make the most impact in (relative to cloud platform implementations). Event bus and message bus are prevalent in many, many infrastructures, and FaaS practically requires easy and extensive adaptation of existing data stores to reach its potential. (This belongs under point three below for etl, but is really a larger security/interop challenge) 1. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 2. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 3. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Because as you note later all FaaS infrastructure is complementary with the point of container infrastructure optimization - each layer can benefit from the same optimizations (anticipatory scaling, wake on request, data locality, slack capacity assignment, central shard assignment and hot sharding, etc). FaaS on Kube should be better than FaaS not on Kube (to an operations team) Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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_______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More
Cathy Zhang <Cathy.H.Zhang@...> #825 I also added more content to the doc. I agree with Yaron and Doug on discussing and collaborating at an early stage to avoid the pain of having to build a converged standard later. Especially for the user facing part, I hope we can bring end users into the discussion and work out some baseline that is easy to be extended in the future. It will speed up cloud native adoption if the users are provided with a consistent “interface”. Cathy toggle quoted message Show quoted text From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Doug Davis via cncf-toc Sent: Wednesday, April 05, 2017 6:28 PM To: Yaron Haviv Cc: cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Yario - exactly. Even if its too soon for standards, just having some of the key players in the same (virtual) room discussing high level topics (like terminology and usecases) might lead to the identification of areas where people will want to collaborate - with or w/o the involvement of any formal CNCF process. To me this was one of my hopes/goals for the CNCF - be a catalyst for collaboration. 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 Yaron Haviv ---04/05/2017 07:27:00 PM---Mark/Doug, I added my comments and more content to the doc From: Yaron Haviv <yaronh@...> To: Mark Peek <markpeek@...>, Doug Davis/Raleigh/IBM@IBMUS Cc: "cncf-toc@..." <cncf-toc@...> Date: 04/05/2017 07:27 PM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless 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 investments and wont be open for changes. For example, today Docker, DC/OS, & k8s each use a different Volume driver, people spent quite some time to develop those, and now CNCF works on a converged standard and we need to build a 4^th one. This could have been avoided/minimized if the community collaborated at an earlier stage. Personally, I would like to merge efforts with other serverless/FaaS providers, identify areas we can work on together to use the same components (and save VC $$) or leverage 3^rd party solutions (too old for NIH). Will also help remove end-user confusion which slows the market. I’m optimistic others will share that view. For that to happen we need a forum to identify what we all agree on and where each may have unique requirements/opinions which force us to diverge. Such a forum can also work with end users and the broader eco system to gather requirements which help us to further increase cloud native adoption. To my friend Josh, IMO Serverless/FaaS is not yet another widget/use-case, if done right it’s a real-thing that will drive Cloud-Native adoption, removing friction and complexity always win with the mainstream. Yaron Iguazio, CTO From: Mark Peek [mailto:markpeek@...] Sent: Wednesday, April 5, 2017 10:40 PM To: Doug Davis <dug@...>; Yaron Haviv <yaronh@...> Cc: cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless For continuity on this thread, here are some quick notes from discussion in the TOC meeting today: Seeing more developers embrace serverless Most (if not all) people on the call feel it is “early days” for serverless and there is a lot of learning that needs to occur TOC is not sure whether or not a WG should be formed Debate on standardization – don’t want to constrain implementations too early but interop is always good for end users Perhaps allow a minimal scope to launch the WG and have it report back to the TOC. Need a TOC sponsor Use Doug’s doc (link below) to add information on serverless and what a CNCF WG would do in this space for further review at an upcoming TOC call Feel free to correct/augment if I captured something incorrectly. Mark From: <cncf-toc-bounces@...> on behalf of Doug Davis via cncf-toc <cncf-toc@...> Reply-To: Doug Davis <dug@...> Date: Wednesday, April 5, 2017 at 5:01 AM To: Yaron Haviv <yaronh@...> Cc: "cncf-toc@..." <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I took the liberty of starting a google doc just to have a place for people to add their thoughts on this topic: https://docs.google.com/document/d/1L9n9tkGuGtj7Ap9dVRes9RVscSoXeKsF3k-d2hJcDlg/edit# its meant to just be a single place for people to brainstorm on the various topics I've seen mentioned so far in this thread. I'd like to use it, mainly, to just gather all possible topics, just so we don't let things fall thru the cracks. 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 Yaron Haviv ---04/02/2017 10:44:58 AM---Doug, I agree, e.g. couple of 1st level topics to start with: 1. Define what constitutes the “Eve From: Yaron Haviv <yaronh@...> To: Doug Davis/Raleigh/IBM@IBMUS, "cncf-toc@..." <cncf-toc@...> Cc: Clayton Coleman <ccoleman@...> Date: 04/02/2017 10:44 AM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless Doug, I agree, e.g. couple of 1^st 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 across implementations. Will also allow dev of standalone test harnesses/tools. Define a package format for code + library/binary dependencies, so tools can commit/push functions to any framework BTW I think the “serverless” notion can be easily extended to “Micro-Batch Jobs” and “Continuous Services”, the ease of use of writing and publishing cloud-native functions doesn’t have to end with event-driven use cases. Yaron From: Doug Davis [mailto:dug@...] Sent: Sunday, April 2, 2017 4:31 PM To: Yaron Haviv <yaronh@...> Cc: Clayton Coleman <ccoleman@...>; cncf-toc@... Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless One day we may be able to leverage common infrastructure, but for now I think a more realistic goal might be to focus on the end-user and see if we can push for an interoperability statement around what they are exposed to. IOW, focus on the OCI image format equivalent for serverless that gives users the freedom to move between implementations. 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 Yaron Haviv ---04/02/2017 03:54:07 AM---"serverless" Perf is a big issue, start-up time is just part of it, most implementation have huge pe From: Yaron Haviv <yaronh@...> To: Doug Davis/Raleigh/IBM@IBMUS, Clayton Coleman <ccoleman@...>, "cncf-toc@..." <cncf-toc@...> Date: 04/02/2017 03:54 AM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless “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/@ferdingler/aws-lambda-no-thank-you-9c586990e67d I assume we don’t want “Serverless” to consume many more servers, need to address concurrency, cut redundant layers, etc’ to make it useful beyond sporadic execution and web hooks, Wrote a blog on that. My KubeCon session covered various problems in current “serverless” implementations and how we addressed them w few real examples (slide 8-13): http://www.slideshare.net/yaronhaviv/building-super-fast-cloudnative-data-platforms-yaron-haviv-kubecon-2017-eu And again, the key is collaboration, assuming there will be multiple cloud/open implementations how do we make them interchangeable, allow code portability, and leverage common infrastructure and tooling Yaron From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Doug Davis via cncf-toc Sent: Saturday, April 1, 2017 4:01 PM To: Clayton Coleman <ccoleman@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Glad to see lots of agreement on this thread and +1 to the idea of a WG/SIG. One comment though, Ryan said: > I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. I'd put performance in the core, at least w.r.t. the container start-up time. If the performance of the infrastructure to setup the container to execute the function isn't fast enough then I think the uptake on this will be negatively impacted. 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 Clayton Coleman via cncf-toc ---04/01/2017 09:24:39 AM---On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc < cncf-toc@...> wrote: From: Clayton Coleman via cncf-toc <cncf-toc@...> To: Brian Grant <briangrant@...> Cc: cncf-toc <cncf-toc@...> Date: 04/01/2017 09:24 AM Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Sent by: cncf-toc-bounces@... On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. I think this is one of the areas that the open source community could make the most impact in (relative to cloud platform implementations). Event bus and message bus are prevalent in many, many infrastructures, and FaaS practically requires easy and extensive adaptation of existing data stores to reach its potential. (This belongs under point three below for etl, but is really a larger security/interop challenge) 1. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 2. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 3. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Because as you note later all FaaS infrastructure is complementary with the point of container infrastructure optimization - each layer can benefit from the same optimizations (anticipatory scaling, wake on request, data locality, slack capacity assignment, central shard assignment and hot sharding, etc). FaaS on Kube should be better than FaaS not on Kube (to an operations team) Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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_______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
Doug Davis <dug@...> #824 Yario - exactly. Even if its too soon for standards, just having some of the key players in the same (virtual) room discussing high level topics (like terminology and usecases) might lead to the identification of areas where people will want to collaborate - with or w/o the involvement of any formal CNCF process. To me this was one of my hopes/goals for the CNCF - be a catalyst for collaboration. 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 Yaron Haviv ---04/05/2017 07:27:00 PM---Mark/Doug, I added my comments and more content to the doc From: Yaron Haviv <yaronh@...> To: Mark Peek <markpeek@...>, Doug Davis/Raleigh/IBM@IBMUS Cc: "cncf-toc@..." <cncf-toc@...> Date: 04/05/2017 07:27 PM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless 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 investments and wont be open for changes. For example, today Docker, DC/OS, & k8s each use a different Volume driver, people spent quite some time to develop those, and now CNCF works on a converged standard and we need to build a 4^th one. This could have been avoided/minimized if the community collaborated at an earlier stage. Personally, I would like to merge efforts with other serverless/FaaS providers, identify areas we can work on together to use the same components (and save VC $$) or leverage 3^rd party solutions (too old for NIH). Will also help remove end-user confusion which slows the market. I’m optimistic others will share that view. For that to happen we need a forum to identify what we all agree on and where each may have unique requirements/opinions which force us to diverge. Such a forum can also work with end users and the broader eco system to gather requirements which help us to further increase cloud native adoption. To my friend Josh, IMO Serverless/FaaS is not yet another widget/use-case, if done right it’s a real-thing that will drive Cloud-Native adoption, removing friction and complexity always win with the mainstream. Yaron Iguazio, CTO toggle quoted message Show quoted text From: Mark Peek [mailto:markpeek@...] Sent: Wednesday, April 5, 2017 10:40 PM To: Doug Davis <dug@...>; Yaron Haviv <yaronh@...> Cc: cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless For continuity on this thread, here are some quick notes from discussion in the TOC meeting today: Seeing more developers embrace serverless Most (if not all) people on the call feel it is “early days” for serverless and there is a lot of learning that needs to occur TOC is not sure whether or not a WG should be formed Debate on standardization – don’t want to constrain implementations too early but interop is always good for end users Perhaps allow a minimal scope to launch the WG and have it report back to the TOC. Need a TOC sponsor Use Doug’s doc (link below) to add information on serverless and what a CNCF WG would do in this space for further review at an upcoming TOC call Feel free to correct/augment if I captured something incorrectly. Mark From: <cncf-toc-bounces@...> on behalf of Doug Davis via cncf-toc <cncf-toc@...> Reply-To: Doug Davis <dug@...> Date: Wednesday, April 5, 2017 at 5:01 AM To: Yaron Haviv <yaronh@...> Cc: "cncf-toc@..." <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I took the liberty of starting a google doc just to have a place for people to add their thoughts on this topic: https://docs.google.com/document/d/1L9n9tkGuGtj7Ap9dVRes9RVscSoXeKsF3k-d2hJcDlg/edit# its meant to just be a single place for people to brainstorm on the various topics I've seen mentioned so far in this thread. I'd like to use it, mainly, to just gather all possible topics, just so we don't let things fall thru the cracks. 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 Yaron Haviv ---04/02/2017 10:44:58 AM---Doug, I agree, e.g. couple of 1st level topics to start with: 1. Define what constitutes the “Eve From: Yaron Haviv <yaronh@...> To: Doug Davis/Raleigh/IBM@IBMUS, "cncf-toc@..." <cncf-toc@...> Cc: Clayton Coleman <ccoleman@...> Date: 04/02/2017 10:44 AM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless Doug, I agree, e.g. couple of 1^st 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 across implementations. Will also allow dev of standalone test harnesses/tools. Define a package format for code + library/binary dependencies, so tools can commit/push functions to any framework BTW I think the “serverless” notion can be easily extended to “Micro-Batch Jobs” and “Continuous Services”, the ease of use of writing and publishing cloud-native functions doesn’t have to end with event-driven use cases. Yaron From: Doug Davis [mailto:dug@...] Sent: Sunday, April 2, 2017 4:31 PM To: Yaron Haviv <yaronh@...> Cc: Clayton Coleman <ccoleman@...>; cncf-toc@... Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless One day we may be able to leverage common infrastructure, but for now I think a more realistic goal might be to focus on the end-user and see if we can push for an interoperability statement around what they are exposed to. IOW, focus on the OCI image format equivalent for serverless that gives users the freedom to move between implementations. 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 Yaron Haviv ---04/02/2017 03:54:07 AM---"serverless" Perf is a big issue, start-up time is just part of it, most implementation have huge pe From: Yaron Haviv <yaronh@...> To: Doug Davis/Raleigh/IBM@IBMUS, Clayton Coleman <ccoleman@...>, "cncf-toc@..." <cncf-toc@...> Date: 04/02/2017 03:54 AM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless “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/@ferdingler/aws-lambda-no-thank-you-9c586990e67d I assume we don’t want “Serverless” to consume many more servers, need to address concurrency, cut redundant layers, etc’ to make it useful beyond sporadic execution and web hooks, Wrote a blog on that. My KubeCon session covered various problems in current “serverless” implementations and how we addressed them w few real examples (slide 8-13): http://www.slideshare.net/yaronhaviv/building-super-fast-cloudnative-data-platforms-yaron-haviv-kubecon-2017-eu And again, the key is collaboration, assuming there will be multiple cloud/open implementations how do we make them interchangeable, allow code portability, and leverage common infrastructure and tooling Yaron From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Doug Davis via cncf-toc Sent: Saturday, April 1, 2017 4:01 PM To: Clayton Coleman <ccoleman@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Glad to see lots of agreement on this thread and +1 to the idea of a WG/SIG. One comment though, Ryan said: > I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. I'd put performance in the core, at least w.r.t. the container start-up time. If the performance of the infrastructure to setup the container to execute the function isn't fast enough then I think the uptake on this will be negatively impacted. 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 Clayton Coleman via cncf-toc ---04/01/2017 09:24:39 AM---On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc < cncf-toc@...> wrote: From: Clayton Coleman via cncf-toc <cncf-toc@...> To: Brian Grant <briangrant@...> Cc: cncf-toc <cncf-toc@...> Date: 04/01/2017 09:24 AM Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Sent by: cncf-toc-bounces@... On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. I think this is one of the areas that the open source community could make the most impact in (relative to cloud platform implementations). Event bus and message bus are prevalent in many, many infrastructures, and FaaS practically requires easy and extensive adaptation of existing data stores to reach its potential. (This belongs under point three below for etl, but is really a larger security/interop challenge) 1. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 2. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 3. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Because as you note later all FaaS infrastructure is complementary with the point of container infrastructure optimization - each layer can benefit from the same optimizations (anticipatory scaling, wake on request, data locality, slack capacity assignment, central shard assignment and hot sharding, etc). FaaS on Kube should be better than FaaS not on Kube (to an operations team) Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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_______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
Yaron Haviv #823 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 investments and wont be open for changes. For example, today Docker, DC/OS, & k8s each use a different Volume driver, people spent quite some time to develop those, and now CNCF works on a converged standard and we need to build a 4^th one. This could have been avoided/minimized if the community collaborated at an earlier stage. Personally, I would like to merge efforts with other serverless/FaaS providers, identify areas we can work on together to use the same components (and save VC $$) or leverage 3^rd party solutions (too old for NIH). Will also help remove end-user confusion which slows the market. I’m optimistic others will share that view. For that to happen we need a forum to identify what we all agree on and where each may have unique requirements/opinions which force us to diverge. Such a forum can also work with end users and the broader eco system to gather requirements which help us to further increase cloud native adoption. To my friend Josh, IMO Serverless/FaaS is not yet another widget/use-case, if done right it’s a real-thing that will drive Cloud-Native adoption, removing friction and complexity always win with the mainstream. Yaron Iguazio, CTO toggle quoted message Show quoted text From: Mark Peek [mailto:markpeek@...] Sent: Wednesday, April 5, 2017 10:40 PM To: Doug Davis <dug@...>; Yaron Haviv <yaronh@...> Cc: cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless For continuity on this thread, here are some quick notes from discussion in the TOC meeting today: Seeing more developers embrace serverless Most (if not all) people on the call feel it is “early days” for serverless and there is a lot of learning that needs to occur TOC is not sure whether or not a WG should be formed Debate on standardization – don’t want to constrain implementations too early but interop is always good for end users Perhaps allow a minimal scope to launch the WG and have it report back to the TOC. Need a TOC sponsor Use Doug’s doc (link below) to add information on serverless and what a CNCF WG would do in this space for further review at an upcoming TOC call Feel free to correct/augment if I captured something incorrectly. Mark From: <cncf-toc-bounces@...> on behalf of Doug Davis via cncf-toc <cncf-toc@...> Reply-To: Doug Davis <dug@...> Date: Wednesday, April 5, 2017 at 5:01 AM To: Yaron Haviv <yaronh@...> Cc: "cncf-toc@..." <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I took the liberty of starting a google doc just to have a place for people to add their thoughts on this topic: https://docs.google.com/document/d/1L9n9tkGuGtj7Ap9dVRes9RVscSoXeKsF3k-d2hJcDlg/edit# its meant to just be a single place for people to brainstorm on the various topics I've seen mentioned so far in this thread. I'd like to use it, mainly, to just gather all possible topics, just so we don't let things fall thru the cracks. 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 Yaron Haviv ---04/02/2017 10:44:58 AM---Doug, I agree, e.g. couple of 1st level topics to start with: 1. Define what constitutes the “Eve From: Yaron Haviv <yaronh@...> To: Doug Davis/Raleigh/IBM@IBMUS, "cncf-toc@..." <cncf-toc@...> Cc: Clayton Coleman <ccoleman@...> Date: 04/02/2017 10:44 AM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless Doug, I agree, e.g. couple of 1^st 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 across implementations. Will also allow dev of standalone test harnesses/tools. Define a package format for code + library/binary dependencies, so tools can commit/push functions to any framework BTW I think the “serverless” notion can be easily extended to “Micro-Batch Jobs” and “Continuous Services”, the ease of use of writing and publishing cloud-native functions doesn’t have to end with event-driven use cases. Yaron From: Doug Davis [mailto:dug@...] Sent: Sunday, April 2, 2017 4:31 PM To: Yaron Haviv <yaronh@...> Cc: Clayton Coleman <ccoleman@...>; cncf-toc@... Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless One day we may be able to leverage common infrastructure, but for now I think a more realistic goal might be to focus on the end-user and see if we can push for an interoperability statement around what they are exposed to. IOW, focus on the OCI image format equivalent for serverless that gives users the freedom to move between implementations. 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 Yaron Haviv ---04/02/2017 03:54:07 AM---"serverless" Perf is a big issue, start-up time is just part of it, most implementation have huge pe From: Yaron Haviv <yaronh@...> To: Doug Davis/Raleigh/IBM@IBMUS, Clayton Coleman <ccoleman@...>, "cncf-toc@..." <cncf-toc@...> Date: 04/02/2017 03:54 AM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless “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/@ferdingler/aws-lambda-no-thank-you-9c586990e67d I assume we don’t want “Serverless” to consume many more servers, need to address concurrency, cut redundant layers, etc’ to make it useful beyond sporadic execution and web hooks, Wrote a blog on that. My KubeCon session covered various problems in current “serverless” implementations and how we addressed them w few real examples (slide 8-13): http://www.slideshare.net/yaronhaviv/building-super-fast-cloudnative-data-platforms-yaron-haviv-kubecon-2017-eu And again, the key is collaboration, assuming there will be multiple cloud/open implementations how do we make them interchangeable, allow code portability, and leverage common infrastructure and tooling Yaron From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Doug Davis via cncf-toc Sent: Saturday, April 1, 2017 4:01 PM To: Clayton Coleman <ccoleman@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Glad to see lots of agreement on this thread and +1 to the idea of a WG/SIG. One comment though, Ryan said: > I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. I'd put performance in the core, at least w.r.t. the container start-up time. If the performance of the infrastructure to setup the container to execute the function isn't fast enough then I think the uptake on this will be negatively impacted. 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 Clayton Coleman via cncf-toc ---04/01/2017 09:24:39 AM---On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc < cncf-toc@...> wrote: From: Clayton Coleman via cncf-toc <cncf-toc@...> To: Brian Grant <briangrant@...> Cc: cncf-toc <cncf-toc@...> Date: 04/01/2017 09:24 AM Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Sent by: cncf-toc-bounces@... On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. I think this is one of the areas that the open source community could make the most impact in (relative to cloud platform implementations). Event bus and message bus are prevalent in many, many infrastructures, and FaaS practically requires easy and extensive adaptation of existing data stores to reach its potential. (This belongs under point three below for etl, but is really a larger security/interop challenge) 1. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 2. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 3. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Because as you note later all FaaS infrastructure is complementary with the point of container infrastructure optimization - each layer can benefit from the same optimizations (anticipatory scaling, wake on request, data locality, slack capacity assignment, central shard assignment and hot sharding, etc). FaaS on Kube should be better than FaaS not on Kube (to an operations team) Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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_______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
Mark Peek #822 For continuity on this thread, here are some quick notes from discussion in the TOC meeting today: - Seeing more developers embrace serverless - Most (if not all) people on the call feel it is “early days” for serverless and there is a lot of learning that needs to occur - TOC is not sure whether or not a WG should be formed - Debate on standardization – don’t want to constrain implementations too early but interop is always good for end users - Perhaps allow a minimal scope to launch the WG and have it report back to the TOC. Need a TOC sponsor - Use Doug’s doc (link below) to add information on serverless and what a CNCF WG would do in this space for further review at an upcoming TOC call Feel free to correct/augment if I captured something incorrectly. Mark From: <cncf-toc-bounces@...> on behalf of Doug Davis via cncf-toc <cncf-toc@...> Reply-To: Doug Davis <dug@...> Date: Wednesday, April 5, 2017 at 5:01 AM To: Yaron Haviv <yaronh@...> Cc: "cncf-toc@..." <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I took the liberty of starting a google doc just to have a place for people to add their thoughts on this topic: https://docs.google.com/document/d/1L9n9tkGuGtj7Ap9dVRes9RVscSoXeKsF3k-d2hJcDlg/edit# its meant to just be a single place for people to brainstorm on the various topics I've seen mentioned so far in this thread. I'd like to use it, mainly, to just gather all possible topics, just so we don't let things fall thru the cracks. 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 Yaron Haviv ---04/02/2017 10:44:58 AM---Doug, I agree, e.g. couple of 1st level topics to start with: 1. Define what constitutes the “Eve From: Yaron Haviv <yaronh@...> To: Doug Davis/Raleigh/IBM@IBMUS, "cncf-toc@..." <cncf-toc@...> Cc: Clayton Coleman <ccoleman@...> Date: 04/02/2017 10:44 AM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless Doug, I agree, e.g. couple of 1^st 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 across implementations. Will also allow dev of standalone test harnesses/tools. Define a package format for code + library/binary dependencies, so tools can commit/push functions to any framework BTW I think the “serverless” notion can be easily extended to “Micro-Batch Jobs” and “Continuous Services”, the ease of use of writing and publishing cloud-native functions doesn’t have to end with event-driven use cases. Yaron toggle quoted message Show quoted text From: Doug Davis [mailto:dug@...] Sent: Sunday, April 2, 2017 4:31 PM To: Yaron Haviv <yaronh@...> Cc: Clayton Coleman <ccoleman@...>; cncf-toc@... Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless One day we may be able to leverage common infrastructure, but for now I think a more realistic goal might be to focus on the end-user and see if we can push for an interoperability statement around what they are exposed to. IOW, focus on the OCI image format equivalent for serverless that gives users the freedom to move between implementations. 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 Yaron Haviv ---04/02/2017 03:54:07 AM---"serverless" Perf is a big issue, start-up time is just part of it, most implementation have huge pe From: Yaron Haviv <yaronh@...> To: Doug Davis/Raleigh/IBM@IBMUS, Clayton Coleman <ccoleman@...>, "cncf-toc@..." <cncf-toc@...> Date: 04/02/2017 03:54 AM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless “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/@ferdingler/aws-lambda-no-thank-you-9c586990e67d I assume we don’t want “Serverless” to consume many more servers, need to address concurrency, cut redundant layers, etc’ to make it useful beyond sporadic execution and web hooks, Wrote a blog on that. My KubeCon session covered various problems in current “serverless” implementations and how we addressed them w few real examples (slide 8-13): http://www.slideshare.net/yaronhaviv/building-super-fast-cloudnative-data-platforms-yaron-haviv-kubecon-2017-eu And again, the key is collaboration, assuming there will be multiple cloud/open implementations how do we make them interchangeable, allow code portability, and leverage common infrastructure and tooling Yaron From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Doug Davis via cncf-toc Sent: Saturday, April 1, 2017 4:01 PM To: Clayton Coleman <ccoleman@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Glad to see lots of agreement on this thread and +1 to the idea of a WG/SIG. One comment though, Ryan said: > I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. I'd put performance in the core, at least w.r.t. the container start-up time. If the performance of the infrastructure to setup the container to execute the function isn't fast enough then I think the uptake on this will be negatively impacted. 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 Clayton Coleman via cncf-toc ---04/01/2017 09:24:39 AM---On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc < cncf-toc@...> wrote: From: Clayton Coleman via cncf-toc <cncf-toc@...> To: Brian Grant <briangrant@...> Cc: cncf-toc <cncf-toc@...> Date: 04/01/2017 09:24 AM Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Sent by: cncf-toc-bounces@... On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. I think this is one of the areas that the open source community could make the most impact in (relative to cloud platform implementations). Event bus and message bus are prevalent in many, many infrastructures, and FaaS practically requires easy and extensive adaptation of existing data stores to reach its potential. (This belongs under point three below for etl, but is really a larger security/interop challenge) 1. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 2. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 3. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Because as you note later all FaaS infrastructure is complementary with the point of container infrastructure optimization - each layer can benefit from the same optimizations (anticipatory scaling, wake on request, data locality, slack capacity assignment, central shard assignment and hot sharding, etc). FaaS on Kube should be better than FaaS not on Kube (to an operations team) Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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_______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
Doug Davis <dug@...> #819 I took the liberty of starting a google doc just to have a place for people to add their thoughts on this topic: https://docs.google.com/document/d/1L9n9tkGuGtj7Ap9dVRes9RVscSoXeKsF3k-d2hJcDlg/edit# its meant to just be a single place for people to brainstorm on the various topics I've seen mentioned so far in this thread. I'd like to use it, mainly, to just gather all possible topics, just so we don't let things fall thru the cracks. 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 Yaron Haviv ---04/02/2017 10:44:58 AM---Doug, I agree, e.g. couple of 1st level topics to start with: 1. Define what constitutes the “Eve From: Yaron Haviv <yaronh@...> To: Doug Davis/Raleigh/IBM@IBMUS, "cncf-toc@..." <cncf-toc@...> Cc: Clayton Coleman <ccoleman@...> Date: 04/02/2017 10:44 AM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless Doug, I agree, e.g. couple of 1^st 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 across implementations. Will also allow dev of standalone test harnesses/tools. Define a package format for code + library/binary dependencies, so tools can commit/push functions to any framework BTW I think the “serverless” notion can be easily extended to “Micro-Batch Jobs” and “Continuous Services”, the ease of use of writing and publishing cloud-native functions doesn’t have to end with event-driven use cases. Yaron toggle quoted message Show quoted text From: Doug Davis [mailto:dug@...] Sent: Sunday, April 2, 2017 4:31 PM To: Yaron Haviv <yaronh@...> Cc: Clayton Coleman <ccoleman@...>; cncf-toc@... Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless One day we may be able to leverage common infrastructure, but for now I think a more realistic goal might be to focus on the end-user and see if we can push for an interoperability statement around what they are exposed to. IOW, focus on the OCI image format equivalent for serverless that gives users the freedom to move between implementations. 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 Yaron Haviv ---04/02/2017 03:54:07 AM---"serverless" Perf is a big issue, start-up time is just part of it, most implementation have huge pe From: Yaron Haviv <yaronh@...> To: Doug Davis/Raleigh/IBM@IBMUS, Clayton Coleman <ccoleman@...>, "cncf-toc@..." <cncf-toc@...> Date: 04/02/2017 03:54 AM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless “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/@ferdingler/aws-lambda-no-thank-you-9c586990e67d I assume we don’t want “Serverless” to consume many more servers, need to address concurrency, cut redundant layers, etc’ to make it useful beyond sporadic execution and web hooks, Wrote a blog on that. My KubeCon session covered various problems in current “serverless” implementations and how we addressed them w few real examples (slide 8-13): http://www.slideshare.net/yaronhaviv/building-super-fast-cloudnative-data-platforms-yaron-haviv-kubecon-2017-eu And again, the key is collaboration, assuming there will be multiple cloud/open implementations how do we make them interchangeable, allow code portability, and leverage common infrastructure and tooling Yaron From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Doug Davis via cncf-toc Sent: Saturday, April 1, 2017 4:01 PM To: Clayton Coleman <ccoleman@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Glad to see lots of agreement on this thread and +1 to the idea of a WG/SIG. One comment though, Ryan said: > I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. I'd put performance in the core, at least w.r.t. the container start-up time. If the performance of the infrastructure to setup the container to execute the function isn't fast enough then I think the uptake on this will be negatively impacted. 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 Clayton Coleman via cncf-toc ---04/01/2017 09:24:39 AM---On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc < cncf-toc@...> wrote: From: Clayton Coleman via cncf-toc <cncf-toc@...> To: Brian Grant <briangrant@...> Cc: cncf-toc <cncf-toc@...> Date: 04/01/2017 09:24 AM Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Sent by: cncf-toc-bounces@... On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. I think this is one of the areas that the open source community could make the most impact in (relative to cloud platform implementations). Event bus and message bus are prevalent in many, many infrastructures, and FaaS practically requires easy and extensive adaptation of existing data stores to reach its potential. (This belongs under point three below for etl, but is really a larger security/interop challenge) 1. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 2. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 3. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Because as you note later all FaaS infrastructure is complementary with the point of container infrastructure optimization - each layer can benefit from the same optimizations (anticipatory scaling, wake on request, data locality, slack capacity assignment, central shard assignment and hot sharding, etc). FaaS on Kube should be better than FaaS not on Kube (to an operations team) Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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_______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
Cathy Zhang <Cathy.H.Zhang@...> #818 Hi Alexis, Thanks for being supportiveJ Looks like Brian also thinks this is in line with “Cloud Native”. I think the first step is to define the charter/scope/deliverables of the WG, i.e. the parts that CNCF can help in standardizing different serverless implementations. In general I agree with the scope that Yaron listed in one of his emails. I will elaborate a little bit more on the WG deliverables with my thought as follows (open for discussion): · specification model/APIs for Event-Function relationship, which is provided to the users/app developers to specify their serverless requirements (e.g. what events trigger what functions, the function execution pattern, event data passing to function etc.) · API between event sources and “Serverless Run-time controller”( API for things that drive function invocations). There will be many different types of event sources (eg. Storage event, video streaming event, HTTP event). If we can provide a common API interface, then CNCF can help with the interoperability of different providers’ event sources with implementation of “Serverless Run-time”. · API interface between “Serverless Run-time controller” and “container function execution engine” (eg. Synchronous vs asynchronous function execution) · Edit, build, test, tools (and how they integrate with the run-times & APIs ..) Thanks, Cathy toggle quoted message Show quoted text From: Alexis Richardson [mailto:alexis@...] Sent: Tuesday, April 04, 2017 5:40 AM To: Yaron Haviv; Cathy Zhang; Mark Peek; Dan Kohn; Ryan S. Brown; Brian Grant; cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless All, Just in terms of process: please note that a WG needs TOC support to form. I'm waving my hand and saying "I am supportive". I don't know what the rest of the TOC think yet ;) Also we need to work out some details. But, please continue to explore the idea! alexis On Tue, Apr 4, 2017 at 1:04 PM Yaron Haviv <yaronh@...> wrote: 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 framework As Alexis mentioned lets start with areas of consensus & low hanging fruits (I guess AWS, Azure, IBM won’t start dev from scratch), e.g.: what’s “Serverless”/”FaaS” scope, how users interact with those platforms in a uniform way, how CNCF or other tools can integrate and add value. We can expand it as we go. Yaron From: Alexis Richardson [mailto:alexis@...] Sent: Tuesday, April 4, 2017 9:41 AM To: Cathy Zhang <Cathy.H.Zhang@...>; Mark Peek <markpeek@...>; Yaron Haviv <yaronh@...>; Dan Kohn <dan@...>; Ryan S. Brown <ryansb@...>; Brian Grant <briangrant@...>; cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Hi all I'm in favour of a wg. But it needs to not overreach. An initial focus could be to parse the space (as Yaron and others did) and identify areas where the cncf can help. If we did this i think it would be invalid (or at least, unlikely to be useful) unless leading projects were in a position to state what would be most useful to them. At the same time people who don't run one of the new projects are keen to contribute. I need to consult with the TOC and alas won't be able to do so until the 18th as i am about to go on vacation. But please ask Chris A if you want an agenda item for tomorrow, about who might be interested in helping with a wg. Alexis On Mon, 3 Apr 2017, 23:35 Cathy Zhang, <Cathy.H.Zhang@...> wrote: +1 on a CNCF WG. Will be happy to contribute to it. I see that different people have different perspectives on serverless or FaaS. I think it will he helpful to define the semantics of serverless and the scope of serverless (I agree with Dan that we may need a better terminology) in CNCF so that we can all be on the same page when diving into serverless tech or implementation. There are already some open source serverless implementations. Most of them concentrates on event driven function hosting and execution, similar to AWS Lambda function. But in reality there are many use cases that involve multiple functions executing in sequence or in parallel or different function execution upon different events or a function execution triggered by a combination of events, etc.. CNCF can play a key role in “standardizing” a comprehensive and generic event function execution model, something like a “event+function” graph so that whatever the backend implementation, the user-facing front end will not change. Cathy From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 2:27 PM To: Yaron Haviv; Dan Kohn; Alexis Richardson; cncf-toc@...; Ryan S. Brown; Brian Grant Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless +1 on a CNCF WG for serverless. Per a side conversation with Alexis this should be discussed at the TOC so it would be nice to have this added as an agenda item for an upcoming meeting. Mark From: Yaron Haviv <yaronh@...> Date: Friday, March 31, 2017 at 1:01 PM To: Mark Peek <markpeek@...>, Dan Kohn <dan@...>, Alexis Richardson <alexis@...>, "cncf-toc@..." <cncf-toc@...>, "Ryan S. Brown" <ryansb@...>, Brian Grant <briangrant@...> Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless 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, focused on RT data processing) And its critical that we have cross platform APIs, the flexibility to use different tools, and allow incremental innovation. now every “serverless” project 100% overlaps the other, CNI/OCI as good examples for why we should have layering vs monoliths We can break Serverless tech to few sub-categorize e.g.: - Function APIs/patterns (e.g. definition of context, events, logs, ..) - “Serverless Run-time” (implementation), I guess every cloud will have its own and we will see few open with different focus areas - Edit, build, test, tools (and how they integrate with the run-times & APIs ..) - Event/data sources (API for things that drive function invocations) Its in CNCF/LF interest to foster collaboration across those areas, allow different build tool to work with multiple run times, and make sure developers don’t have to use different code for each run-time or cloud vendor. I see nice concepts in the different implementations and would be great if we can sit and agree what are the things we want to adopt in a common definition or make optional. The best next step is to form a CNCF WG/SIG, happy to contribute to such. Yaron Iguazio, CTO From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 9:59 PM To: Dan Kohn <dan@...>; Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I’m not a fan of the term “serverless” as most people tend to think “no servers” as opposed to “fewer” or “not having to deal with” servers. Of course, FaaS doesn’t quite roll off the tongue either. Definitely be nice to have better naming around it. Looking at this from an on-prem or private cloud perspective, you don’t get the same benefits as public cloud FaaS. Instead of having all of the infrastructure handled by the public cloud, the private clouds will require ease of operation and lifecycle management for the FaaS operation. And will have additional requirements around multi-tenant, RBAC, and security. While there will be multiple FaaS implementations (stand alone or on top of k8s), as Brian alluded to we should be looking at common eventing models/function execution, interoperability of the services, and common SDK’s. This would allow for the functions to have portability in mind across a variety of FaaS implementations. Also, I believe this is very pertinent to cloud native as teams are using the a variety of compute (VM/instances, containers, and FaaS) to design, develop, and deploy their applications. In other words, FaaS is a cloud native design pattern that needs to be supported across all clouds. And, since I’m replying to Dan’s email I will add this AWS re:invent video link where Coca Cola is using AWS Lambda to run payments from their machines. The beginning talks about their rationale and goes into pricing break evens on when to switch to dedicated instances. Of course the use of AWS services always need to be kept in mind. AWS re:Invent 2016: Coca-Cola: Running Serverless Applications with Enterprise Requirements (SVR303) https://www.youtube.com/watch?v=yErmil00DYs Mark From: <cncf-toc-bounces@...> on behalf of Dan Kohn via cncf-toc <cncf-toc@...> Reply-To: Dan Kohn <dan@...> Date: Friday, March 31, 2017 at 11:35 AM To: Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Yes, I find this story inspiring from Benchling of moving their genome searching to Lambda and both reducing tail latency and dropping costs from thousands of dollars per month to $60: http://benchling.engineering/crispr-aws-lambda/ -- Dan Kohn <mailto:dan@...> Executive Director, Cloud Native Computing Foundation <https://cncf.io> tel:+1-415-233-1000 On Mar 31, 2017, at 14:10, Alexis Richardson via cncf-toc <cncf-toc@...> wrote: Related to this, many FaaS proponents talk about the economics of only paying for use (function calls). But this economic model is not limited to the serverless app frameworks eg as listed below by Brian. Many container orchestrators could feasibly provide fine grained billing. On Fri, 31 Mar 2017, 19:00 Brian Grant via cncf-toc, <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. 2. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 3. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 4. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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 _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
NASSAUR, DOUGLAS C <dn283x@...> #817 Open to any approach forward. One pattern we are currently exploring has event, message bus, policy and end-point registry as a common utility service vs embedded within application “neighborhoods”. Our thinking to date has been that the function specific focus vs infra specific focus is what is unique and truly abstractive across diverse infrastructure, provider, stack and technology. Wherever we want to explore that I’m in but hope we pursue this pattern and approach with vigor. Thanks again Mark. toggle quoted message Show quoted text From: Mark Peek [mailto:markpeek@...] Sent: Tuesday, April 04, 2017 2:55 PM To: NASSAUR, DOUGLAS C <dn283x@...>; Bernstein, Joshua (EMC) <Joshua.Bernstein@...> Cc: cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I agree there is some intersection for the scaling aspect but I could see the serverless WG taking on other areas, for example common eventing and runtime. I’d like the TOC to approve a serverless WG, let us meet to understand the space, and then look for ways to converge ideas after we’ve had time to develop them more concretely. Mark From: <cncf-toc-bounces@...> on behalf of "NASSAUR, DOUGLAS C via cncf-toc" <cncf-toc@...> Reply-To: "NASSAUR, DOUGLAS C" <dn283x@...> Date: Tuesday, April 4, 2017 at 11:45 AM To: "Bernstein, Joshua (EMC)" <Joshua.Bernstein@...> Cc: "cncf-toc@..." <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Great point Josh. I’m actually advocating in your direction. For example, we are currently evaluating the applicability and influence of cloud native architecture principles for complex network services like our mobile radio access network. We are specifically comparing and contrasting the scaling of software by scaling infrastructure vs the scaling of function. The work explores the span of control across host/infrastructure foundations, distribution foundations and application/platform foundations and what the developer, the application and the infrastructure does differently in a cloud native architecture. Really like to engage more super-smart brains on this pattern. Thanks, Doug From: Bernstein, Joshua [mailto:Joshua.Bernstein@...] Sent: Tuesday, April 04, 2017 1:49 PM To: NASSAUR, DOUGLAS C <dn283x@...> Cc: Yaron Haviv <yaronh@...>; cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I would add to this discussion that we should be aware of spreading ourselves too thin. I’m not making a call that I’m in favor of severless or not, but I’m just saying we should be aware of the work involved in creating all of these WG, SIGs, etc and getting distracted away from a more tangible, immediate focus. -Josh On Apr 4, 2017, at 6:38 AM, NASSAUR, DOUGLAS C via cncf-toc <cncf-toc@...> wrote: Any opportunity to fold this line of thinking into the architecture patterns we are working as part of the architecture committee. One of the "patterns" groups represents a pivot to scaling function as opposed to scaling infrastructure. It would appear to overlap in thinking and objective with the FaaS movement. Less concerned about naming but would propose we could bring the threads together if folks are interested. Regards, Doug On Apr 4, 2017, at 8:04 AM, Yaron Haviv via cncf-toc <cncf-toc@...> wrote: 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 framework As Alexis mentioned lets start with areas of consensus & low hanging fruits (I guess AWS, Azure, IBM won’t start dev from scratch), e.g.: what’s “Serverless”/”FaaS” scope, how users interact with those platforms in a uniform way, how CNCF or other tools can integrate and add value. We can expand it as we go. Yaron From: Alexis Richardson [mailto:alexis@...] Sent: Tuesday, April 4, 2017 9:41 AM To: Cathy Zhang <Cathy.H.Zhang@...>; Mark Peek <markpeek@...>; Yaron Haviv <yaronh@...>; Dan Kohn <dan@...>; Ryan S. Brown <ryansb@...>; Brian Grant <briangrant@...>; cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Hi all I'm in favour of a wg. But it needs to not overreach. An initial focus could be to parse the space (as Yaron and others did) and identify areas where the cncf can help. If we did this i think it would be invalid (or at least, unlikely to be useful) unless leading projects were in a position to state what would be most useful to them. At the same time people who don't run one of the new projects are keen to contribute. I need to consult with the TOC and alas won't be able to do so until the 18th as i am about to go on vacation. But please ask Chris A if you want an agenda item for tomorrow, about who might be interested in helping with a wg. Alexis On Mon, 3 Apr 2017, 23:35 Cathy Zhang, <Cathy.H.Zhang@...> wrote: +1 on a CNCF WG. Will be happy to contribute to it. I see that different people have different perspectives on serverless or FaaS. I think it will he helpful to define the semantics of serverless and the scope of serverless (I agree with Dan that we may need a better terminology) in CNCF so that we can all be on the same page when diving into serverless tech or implementation. There are already some open source serverless implementations. Most of them concentrates on event driven function hosting and execution, similar to AWS Lambda function. But in reality there are many use cases that involve multiple functions executing in sequence or in parallel or different function execution upon different events or a function execution triggered by a combination of events, etc.. CNCF can play a key role in “standardizing” a comprehensive and generic event function execution model, something like a “event+function” graph so that whatever the backend implementation, the user-facing front end will not change. Cathy From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 2:27 PM To: Yaron Haviv; Dan Kohn; Alexis Richardson; cncf-toc@...; Ryan S. Brown; Brian Grant Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless +1 on a CNCF WG for serverless. Per a side conversation with Alexis this should be discussed at the TOC so it would be nice to have this added as an agenda item for an upcoming meeting. Mark From: Yaron Haviv <yaronh@...> Date: Friday, March 31, 2017 at 1:01 PM To: Mark Peek <markpeek@...>, Dan Kohn <dan@...>, Alexis Richardson <alexis@...>, "cncf-toc@..." <cncf-toc@...>, "Ryan S. Brown" <ryansb@...>, Brian Grant <briangrant@...> Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless 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, focused on RT data processing) And its critical that we have cross platform APIs, the flexibility to use different tools, and allow incremental innovation. now every “serverless” project 100% overlaps the other, CNI/OCI as good examples for why we should have layering vs monoliths We can break Serverless tech to few sub-categorize e.g.: - Function APIs/patterns (e.g. definition of context, events, logs, ..) - “Serverless Run-time” (implementation), I guess every cloud will have its own and we will see few open with different focus areas - Edit, build, test, tools (and how they integrate with the run-times & APIs ..) - Event/data sources (API for things that drive function invocations) Its in CNCF/LF interest to foster collaboration across those areas, allow different build tool to work with multiple run times, and make sure developers don’t have to use different code for each run-time or cloud vendor. I see nice concepts in the different implementations and would be great if we can sit and agree what are the things we want to adopt in a common definition or make optional. The best next step is to form a CNCF WG/SIG, happy to contribute to such. Yaron Iguazio, CTO From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 9:59 PM To: Dan Kohn <dan@...>; Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I’m not a fan of the term “serverless” as most people tend to think “no servers” as opposed to “fewer” or “not having to deal with” servers. Of course, FaaS doesn’t quite roll off the tongue either. Definitely be nice to have better naming around it. Looking at this from an on-prem or private cloud perspective, you don’t get the same benefits as public cloud FaaS. Instead of having all of the infrastructure handled by the public cloud, the private clouds will require ease of operation and lifecycle management for the FaaS operation. And will have additional requirements around multi-tenant, RBAC, and security. While there will be multiple FaaS implementations (stand alone or on top of k8s), as Brian alluded to we should be looking at common eventing models/function execution, interoperability of the services, and common SDK’s. This would allow for the functions to have portability in mind across a variety of FaaS implementations. Also, I believe this is very pertinent to cloud native as teams are using the a variety of compute (VM/instances, containers, and FaaS) to design, develop, and deploy their applications. In other words, FaaS is a cloud native design pattern that needs to be supported across all clouds. And, since I’m replying to Dan’s email I will add this AWS re:invent video link where Coca Cola is using AWS Lambda to run payments from their machines. The beginning talks about their rationale and goes into pricing break evens on when to switch to dedicated instances. Of course the use of AWS services always need to be kept in mind. AWS re:Invent 2016: Coca-Cola: Running Serverless Applications with Enterprise Requirements (SVR303) https://www.youtube.com/watch?v=yErmil00DYs Mark From: <cncf-toc-bounces@...> on behalf of Dan Kohn via cncf-toc <cncf-toc@...> Reply-To: Dan Kohn <dan@...> Date: Friday, March 31, 2017 at 11:35 AM To: Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Yes, I find this story inspiring from Benchling of moving their genome searching to Lambda and both reducing tail latency and dropping costs from thousands of dollars per month to $60: http://benchling.engineering/crispr-aws-lambda/ -- Dan Kohn <mailto:dan@...> Executive Director, Cloud Native Computing Foundation <https://cncf.io> tel:+1-415-233-1000 On Mar 31, 2017, at 14:10, Alexis Richardson via cncf-toc <cncf-toc@...> wrote: Related to this, many FaaS proponents talk about the economics of only paying for use (function calls). But this economic model is not limited to the serverless app frameworks eg as listed below by Brian. Many container orchestrators could feasibly provide fine grained billing. On Fri, 31 Mar 2017, 19:00 Brian Grant via cncf-toc, <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. 2. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 3. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 4. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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 _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc _______________________________________________ cncf-toc mailing list cncf-toc@... https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_mailman_listinfo_cncf-2Dtoc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6p0eGA_74Mh7puBbIA77IA&m=NQmI2gOnfoIAa77aHFZsE4PycfrM6ncO0eI2FxRrhiA&s=PTGKvZDiMKi_QBdB_7d6wxbke6xlMWXwo-l-Wgol2r4&e= _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
Mark Peek #816 I agree there is some intersection for the scaling aspect but I could see the serverless WG taking on other areas, for example common eventing and runtime. I’d like the TOC to approve a serverless WG, let us meet to understand the space, and then look for ways to converge ideas after we’ve had time to develop them more concretely. Mark From: <cncf-toc-bounces@...> on behalf of "NASSAUR, DOUGLAS C via cncf-toc" <cncf-toc@...> Reply-To: "NASSAUR, DOUGLAS C" <dn283x@...> Date: Tuesday, April 4, 2017 at 11:45 AM To: "Bernstein, Joshua (EMC)" <Joshua.Bernstein@...> Cc: "cncf-toc@..." <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Great point Josh. I’m actually advocating in your direction. For example, we are currently evaluating the applicability and influence of cloud native architecture principles for complex network services like our mobile radio access network. We are specifically comparing and contrasting the scaling of software by scaling infrastructure vs the scaling of function. The work explores the span of control across host/infrastructure foundations, distribution foundations and application/platform foundations and what the developer, the application and the infrastructure does differently in a cloud native architecture. Really like to engage more super-smart brains on this pattern. Thanks, Doug toggle quoted message Show quoted text From: Bernstein, Joshua [mailto:Joshua.Bernstein@...] Sent: Tuesday, April 04, 2017 1:49 PM To: NASSAUR, DOUGLAS C <dn283x@...> Cc: Yaron Haviv <yaronh@...>; cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I would add to this discussion that we should be aware of spreading ourselves too thin. I’m not making a call that I’m in favor of severless or not, but I’m just saying we should be aware of the work involved in creating all of these WG, SIGs, etc and getting distracted away from a more tangible, immediate focus. -Josh On Apr 4, 2017, at 6:38 AM, NASSAUR, DOUGLAS C via cncf-toc <cncf-toc@...> wrote: Any opportunity to fold this line of thinking into the architecture patterns we are working as part of the architecture committee. One of the "patterns" groups represents a pivot to scaling function as opposed to scaling infrastructure. It would appear to overlap in thinking and objective with the FaaS movement. Less concerned about naming but would propose we could bring the threads together if folks are interested. Regards, Doug On Apr 4, 2017, at 8:04 AM, Yaron Haviv via cncf-toc <cncf-toc@...> wrote: 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 framework As Alexis mentioned lets start with areas of consensus & low hanging fruits (I guess AWS, Azure, IBM won’t start dev from scratch), e.g.: what’s “Serverless”/”FaaS” scope, how users interact with those platforms in a uniform way, how CNCF or other tools can integrate and add value. We can expand it as we go. Yaron From: Alexis Richardson [mailto:alexis@...] Sent: Tuesday, April 4, 2017 9:41 AM To: Cathy Zhang <Cathy.H.Zhang@...>; Mark Peek <markpeek@...>; Yaron Haviv <yaronh@...>; Dan Kohn <dan@...>; Ryan S. Brown <ryansb@...>; Brian Grant <briangrant@...>; cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Hi all I'm in favour of a wg. But it needs to not overreach. An initial focus could be to parse the space (as Yaron and others did) and identify areas where the cncf can help. If we did this i think it would be invalid (or at least, unlikely to be useful) unless leading projects were in a position to state what would be most useful to them. At the same time people who don't run one of the new projects are keen to contribute. I need to consult with the TOC and alas won't be able to do so until the 18th as i am about to go on vacation. But please ask Chris A if you want an agenda item for tomorrow, about who might be interested in helping with a wg. Alexis On Mon, 3 Apr 2017, 23:35 Cathy Zhang, <Cathy.H.Zhang@...> wrote: +1 on a CNCF WG. Will be happy to contribute to it. I see that different people have different perspectives on serverless or FaaS. I think it will he helpful to define the semantics of serverless and the scope of serverless (I agree with Dan that we may need a better terminology) in CNCF so that we can all be on the same page when diving into serverless tech or implementation. There are already some open source serverless implementations. Most of them concentrates on event driven function hosting and execution, similar to AWS Lambda function. But in reality there are many use cases that involve multiple functions executing in sequence or in parallel or different function execution upon different events or a function execution triggered by a combination of events, etc.. CNCF can play a key role in “standardizing” a comprehensive and generic event function execution model, something like a “event+function” graph so that whatever the backend implementation, the user-facing front end will not change. Cathy From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 2:27 PM To: Yaron Haviv; Dan Kohn; Alexis Richardson; cncf-toc@...; Ryan S. Brown; Brian Grant Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless +1 on a CNCF WG for serverless. Per a side conversation with Alexis this should be discussed at the TOC so it would be nice to have this added as an agenda item for an upcoming meeting. Mark From: Yaron Haviv <yaronh@...> Date: Friday, March 31, 2017 at 1:01 PM To: Mark Peek <markpeek@...>, Dan Kohn <dan@...>, Alexis Richardson <alexis@...>, "cncf-toc@..." <cncf-toc@...>, "Ryan S. Brown" <ryansb@...>, Brian Grant <briangrant@...> Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless 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, focused on RT data processing) And its critical that we have cross platform APIs, the flexibility to use different tools, and allow incremental innovation. now every “serverless” project 100% overlaps the other, CNI/OCI as good examples for why we should have layering vs monoliths We can break Serverless tech to few sub-categorize e.g.: - Function APIs/patterns (e.g. definition of context, events, logs, ..) - “Serverless Run-time” (implementation), I guess every cloud will have its own and we will see few open with different focus areas - Edit, build, test, tools (and how they integrate with the run-times & APIs ..) - Event/data sources (API for things that drive function invocations) Its in CNCF/LF interest to foster collaboration across those areas, allow different build tool to work with multiple run times, and make sure developers don’t have to use different code for each run-time or cloud vendor. I see nice concepts in the different implementations and would be great if we can sit and agree what are the things we want to adopt in a common definition or make optional. The best next step is to form a CNCF WG/SIG, happy to contribute to such. Yaron Iguazio, CTO From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 9:59 PM To: Dan Kohn <dan@...>; Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I’m not a fan of the term “serverless” as most people tend to think “no servers” as opposed to “fewer” or “not having to deal with” servers. Of course, FaaS doesn’t quite roll off the tongue either. Definitely be nice to have better naming around it. Looking at this from an on-prem or private cloud perspective, you don’t get the same benefits as public cloud FaaS. Instead of having all of the infrastructure handled by the public cloud, the private clouds will require ease of operation and lifecycle management for the FaaS operation. And will have additional requirements around multi-tenant, RBAC, and security. While there will be multiple FaaS implementations (stand alone or on top of k8s), as Brian alluded to we should be looking at common eventing models/function execution, interoperability of the services, and common SDK’s. This would allow for the functions to have portability in mind across a variety of FaaS implementations. Also, I believe this is very pertinent to cloud native as teams are using the a variety of compute (VM/instances, containers, and FaaS) to design, develop, and deploy their applications. In other words, FaaS is a cloud native design pattern that needs to be supported across all clouds. And, since I’m replying to Dan’s email I will add this AWS re:invent video link where Coca Cola is using AWS Lambda to run payments from their machines. The beginning talks about their rationale and goes into pricing break evens on when to switch to dedicated instances. Of course the use of AWS services always need to be kept in mind. AWS re:Invent 2016: Coca-Cola: Running Serverless Applications with Enterprise Requirements (SVR303) https://www.youtube.com/watch?v=yErmil00DYs Mark From: <cncf-toc-bounces@...> on behalf of Dan Kohn via cncf-toc <cncf-toc@...> Reply-To: Dan Kohn <dan@...> Date: Friday, March 31, 2017 at 11:35 AM To: Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Yes, I find this story inspiring from Benchling of moving their genome searching to Lambda and both reducing tail latency and dropping costs from thousands of dollars per month to $60: http://benchling.engineering/crispr-aws-lambda/ -- Dan Kohn <mailto:dan@...> Executive Director, Cloud Native Computing Foundation <https://cncf.io> tel:+1-415-233-1000 On Mar 31, 2017, at 14:10, Alexis Richardson via cncf-toc <cncf-toc@...> wrote: Related to this, many FaaS proponents talk about the economics of only paying for use (function calls). But this economic model is not limited to the serverless app frameworks eg as listed below by Brian. Many container orchestrators could feasibly provide fine grained billing. On Fri, 31 Mar 2017, 19:00 Brian Grant via cncf-toc, <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. 2. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 3. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 4. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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 _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc _______________________________________________ cncf-toc mailing list cncf-toc@... https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_mailman_listinfo_cncf-2Dtoc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6p0eGA_74Mh7puBbIA77IA&m=NQmI2gOnfoIAa77aHFZsE4PycfrM6ncO0eI2FxRrhiA&s=PTGKvZDiMKi_QBdB_7d6wxbke6xlMWXwo-l-Wgol2r4&e= _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
NASSAUR, DOUGLAS C <dn283x@...> #815 Great point Josh. I’m actually advocating in your direction. For example, we are currently evaluating the applicability and influence of cloud native architecture principles for complex network services like our mobile radio access network. We are specifically comparing and contrasting the scaling of software by scaling infrastructure vs the scaling of function. The work explores the span of control across host/infrastructure foundations, distribution foundations and application/platform foundations and what the developer, the application and the infrastructure does differently in a cloud native architecture. Really like to engage more super-smart brains on this pattern. Thanks, Doug toggle quoted message Show quoted text From: Bernstein, Joshua [mailto:Joshua.Bernstein@...] Sent: Tuesday, April 04, 2017 1:49 PM To: NASSAUR, DOUGLAS C <dn283x@...> Cc: Yaron Haviv <yaronh@...>; cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I would add to this discussion that we should be aware of spreading ourselves too thin. I’m not making a call that I’m in favor of severless or not, but I’m just saying we should be aware of the work involved in creating all of these WG, SIGs, etc and getting distracted away from a more tangible, immediate focus. -Josh On Apr 4, 2017, at 6:38 AM, NASSAUR, DOUGLAS C via cncf-toc <cncf-toc@...> wrote: Any opportunity to fold this line of thinking into the architecture patterns we are working as part of the architecture committee. One of the "patterns" groups represents a pivot to scaling function as opposed to scaling infrastructure. It would appear to overlap in thinking and objective with the FaaS movement. Less concerned about naming but would propose we could bring the threads together if folks are interested. Regards, Doug On Apr 4, 2017, at 8:04 AM, Yaron Haviv via cncf-toc <cncf-toc@...> wrote: 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 framework As Alexis mentioned lets start with areas of consensus & low hanging fruits (I guess AWS, Azure, IBM won’t start dev from scratch), e.g.: what’s “Serverless”/”FaaS” scope, how users interact with those platforms in a uniform way, how CNCF or other tools can integrate and add value. We can expand it as we go. Yaron From: Alexis Richardson [mailto:alexis@...] Sent: Tuesday, April 4, 2017 9:41 AM To: Cathy Zhang <Cathy.H.Zhang@...>; Mark Peek <markpeek@...>; Yaron Haviv <yaronh@...>; Dan Kohn <dan@...>; Ryan S. Brown <ryansb@...>; Brian Grant <briangrant@...>; cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Hi all I'm in favour of a wg. But it needs to not overreach. An initial focus could be to parse the space (as Yaron and others did) and identify areas where the cncf can help. If we did this i think it would be invalid (or at least, unlikely to be useful) unless leading projects were in a position to state what would be most useful to them. At the same time people who don't run one of the new projects are keen to contribute. I need to consult with the TOC and alas won't be able to do so until the 18th as i am about to go on vacation. But please ask Chris A if you want an agenda item for tomorrow, about who might be interested in helping with a wg. Alexis On Mon, 3 Apr 2017, 23:35 Cathy Zhang, <Cathy.H.Zhang@...> wrote: +1 on a CNCF WG. Will be happy to contribute to it. I see that different people have different perspectives on serverless or FaaS. I think it will he helpful to define the semantics of serverless and the scope of serverless (I agree with Dan that we may need a better terminology) in CNCF so that we can all be on the same page when diving into serverless tech or implementation. There are already some open source serverless implementations. Most of them concentrates on event driven function hosting and execution, similar to AWS Lambda function. But in reality there are many use cases that involve multiple functions executing in sequence or in parallel or different function execution upon different events or a function execution triggered by a combination of events, etc.. CNCF can play a key role in “standardizing” a comprehensive and generic event function execution model, something like a “event+function” graph so that whatever the backend implementation, the user-facing front end will not change. Cathy From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 2:27 PM To: Yaron Haviv; Dan Kohn; Alexis Richardson; cncf-toc@...; Ryan S. Brown; Brian Grant Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless +1 on a CNCF WG for serverless. Per a side conversation with Alexis this should be discussed at the TOC so it would be nice to have this added as an agenda item for an upcoming meeting. Mark From: Yaron Haviv <yaronh@...> Date: Friday, March 31, 2017 at 1:01 PM To: Mark Peek <markpeek@...>, Dan Kohn <dan@...>, Alexis Richardson <alexis@...>, "cncf-toc@..." <cncf-toc@...>, "Ryan S. Brown" <ryansb@...>, Brian Grant <briangrant@...> Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless 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, focused on RT data processing) And its critical that we have cross platform APIs, the flexibility to use different tools, and allow incremental innovation. now every “serverless” project 100% overlaps the other, CNI/OCI as good examples for why we should have layering vs monoliths We can break Serverless tech to few sub-categorize e.g.: - Function APIs/patterns (e.g. definition of context, events, logs, ..) - “Serverless Run-time” (implementation), I guess every cloud will have its own and we will see few open with different focus areas - Edit, build, test, tools (and how they integrate with the run-times & APIs ..) - Event/data sources (API for things that drive function invocations) Its in CNCF/LF interest to foster collaboration across those areas, allow different build tool to work with multiple run times, and make sure developers don’t have to use different code for each run-time or cloud vendor. I see nice concepts in the different implementations and would be great if we can sit and agree what are the things we want to adopt in a common definition or make optional. The best next step is to form a CNCF WG/SIG, happy to contribute to such. Yaron Iguazio, CTO From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 9:59 PM To: Dan Kohn <dan@...>; Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I’m not a fan of the term “serverless” as most people tend to think “no servers” as opposed to “fewer” or “not having to deal with” servers. Of course, FaaS doesn’t quite roll off the tongue either. Definitely be nice to have better naming around it. Looking at this from an on-prem or private cloud perspective, you don’t get the same benefits as public cloud FaaS. Instead of having all of the infrastructure handled by the public cloud, the private clouds will require ease of operation and lifecycle management for the FaaS operation. And will have additional requirements around multi-tenant, RBAC, and security. While there will be multiple FaaS implementations (stand alone or on top of k8s), as Brian alluded to we should be looking at common eventing models/function execution, interoperability of the services, and common SDK’s. This would allow for the functions to have portability in mind across a variety of FaaS implementations. Also, I believe this is very pertinent to cloud native as teams are using the a variety of compute (VM/instances, containers, and FaaS) to design, develop, and deploy their applications. In other words, FaaS is a cloud native design pattern that needs to be supported across all clouds. And, since I’m replying to Dan’s email I will add this AWS re:invent video link where Coca Cola is using AWS Lambda to run payments from their machines. The beginning talks about their rationale and goes into pricing break evens on when to switch to dedicated instances. Of course the use of AWS services always need to be kept in mind. AWS re:Invent 2016: Coca-Cola: Running Serverless Applications with Enterprise Requirements (SVR303) https://www.youtube.com/watch?v=yErmil00DYs Mark From: <cncf-toc-bounces@...> on behalf of Dan Kohn via cncf-toc <cncf-toc@...> Reply-To: Dan Kohn <dan@...> Date: Friday, March 31, 2017 at 11:35 AM To: Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Yes, I find this story inspiring from Benchling of moving their genome searching to Lambda and both reducing tail latency and dropping costs from thousands of dollars per month to $60: http://benchling.engineering/crispr-aws-lambda/ -- Dan Kohn <mailto:dan@...> Executive Director, Cloud Native Computing Foundation <https://cncf.io> tel:+1-415-233-1000 On Mar 31, 2017, at 14:10, Alexis Richardson via cncf-toc <cncf-toc@...> wrote: Related to this, many FaaS proponents talk about the economics of only paying for use (function calls). But this economic model is not limited to the serverless app frameworks eg as listed below by Brian. Many container orchestrators could feasibly provide fine grained billing. On Fri, 31 Mar 2017, 19:00 Brian Grant via cncf-toc, <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. 2. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 3. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 4. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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 _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc _______________________________________________ cncf-toc mailing list cncf-toc@... https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_mailman_listinfo_cncf-2Dtoc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6p0eGA_74Mh7puBbIA77IA&m=NQmI2gOnfoIAa77aHFZsE4PycfrM6ncO0eI2FxRrhiA&s=PTGKvZDiMKi_QBdB_7d6wxbke6xlMWXwo-l-Wgol2r4&e= _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
Bernstein, Joshua <Joshua.Bernstein@...> #814 I would add to this discussion that we should be aware of spreading ourselves too thin. I’m not making a call that I’m in favor of severless or not, but I’m just saying we should be aware of the work involved in creating all of these WG, SIGs, etc and getting distracted away from a more tangible, immediate focus. -Josh toggle quoted message Show quoted text On Apr 4, 2017, at 6:38 AM, NASSAUR, DOUGLAS C via cncf-toc <cncf-toc@...> wrote: Any opportunity to fold this line of thinking into the architecture patterns we are working as part of the architecture committee. One of the "patterns" groups represents a pivot to scaling function as opposed to scaling infrastructure. It would appear to overlap in thinking and objective with the FaaS movement. Less concerned about naming but would propose we could bring the threads together if folks are interested. Regards, Doug On Apr 4, 2017, at 8:04 AM, Yaron Haviv via cncf-toc <cncf-toc@...> wrote: 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 framework As Alexis mentioned lets start with areas of consensus & low hanging fruits (I guess AWS, Azure, IBM won’t start dev from scratch), e.g.: what’s “Serverless”/”FaaS” scope, how users interact with those platforms in a uniform way, how CNCF or other tools can integrate and add value. We can expand it as we go. Yaron From: Alexis Richardson [mailto:alexis@...] Sent: Tuesday, April 4, 2017 9:41 AM To: Cathy Zhang <Cathy.H.Zhang@...>; Mark Peek <markpeek@...>; Yaron Haviv <yaronh@...>; Dan Kohn <dan@...>; Ryan S. Brown <ryansb@...>; Brian Grant <briangrant@...>; cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Hi all I'm in favour of a wg. But it needs to not overreach. An initial focus could be to parse the space (as Yaron and others did) and identify areas where the cncf can help. If we did this i think it would be invalid (or at least, unlikely to be useful) unless leading projects were in a position to state what would be most useful to them. At the same time people who don't run one of the new projects are keen to contribute. I need to consult with the TOC and alas won't be able to do so until the 18th as i am about to go on vacation. But please ask Chris A if you want an agenda item for tomorrow, about who might be interested in helping with a wg. Alexis On Mon, 3 Apr 2017, 23:35 Cathy Zhang, <Cathy.H.Zhang@...> wrote: +1 on a CNCF WG. Will be happy to contribute to it. I see that different people have different perspectives on serverless or FaaS. I think it will he helpful to define the semantics of serverless and the scope of serverless (I agree with Dan that we may need a better terminology) in CNCF so that we can all be on the same page when diving into serverless tech or implementation. There are already some open source serverless implementations. Most of them concentrates on event driven function hosting and execution, similar to AWS Lambda function. But in reality there are many use cases that involve multiple functions executing in sequence or in parallel or different function execution upon different events or a function execution triggered by a combination of events, etc.. CNCF can play a key role in “standardizing” a comprehensive and generic event function execution model, something like a “event+function” graph so that whatever the backend implementation, the user-facing front end will not change. Cathy From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 2:27 PM To: Yaron Haviv; Dan Kohn; Alexis Richardson; cncf-toc@...; Ryan S. Brown; Brian Grant Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless +1 on a CNCF WG for serverless. Per a side conversation with Alexis this should be discussed at the TOC so it would be nice to have this added as an agenda item for an upcoming meeting. Mark From: Yaron Haviv <yaronh@...> Date: Friday, March 31, 2017 at 1:01 PM To: Mark Peek <markpeek@...>, Dan Kohn <dan@...>, Alexis Richardson <alexis@...>, "cncf-toc@..." <cncf-toc@...>, "Ryan S. Brown" <ryansb@...>, Brian Grant <briangrant@...> Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless 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, focused on RT data processing) And its critical that we have cross platform APIs, the flexibility to use different tools, and allow incremental innovation. now every “serverless” project 100% overlaps the other, CNI/OCI as good examples for why we should have layering vs monoliths We can break Serverless tech to few sub-categorize e.g.: - Function APIs/patterns (e.g. definition of context, events, logs, ..) - “Serverless Run-time” (implementation), I guess every cloud will have its own and we will see few open with different focus areas - Edit, build, test, tools (and how they integrate with the run-times & APIs ..) - Event/data sources (API for things that drive function invocations) Its in CNCF/LF interest to foster collaboration across those areas, allow different build tool to work with multiple run times, and make sure developers don’t have to use different code for each run-time or cloud vendor. I see nice concepts in the different implementations and would be great if we can sit and agree what are the things we want to adopt in a common definition or make optional. The best next step is to form a CNCF WG/SIG, happy to contribute to such. Yaron Iguazio, CTO From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 9:59 PM To: Dan Kohn <dan@...>; Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I’m not a fan of the term “serverless” as most people tend to think “no servers” as opposed to “fewer” or “not having to deal with” servers. Of course, FaaS doesn’t quite roll off the tongue either. Definitely be nice to have better naming around it. Looking at this from an on-prem or private cloud perspective, you don’t get the same benefits as public cloud FaaS. Instead of having all of the infrastructure handled by the public cloud, the private clouds will require ease of operation and lifecycle management for the FaaS operation. And will have additional requirements around multi-tenant, RBAC, and security. While there will be multiple FaaS implementations (stand alone or on top of k8s), as Brian alluded to we should be looking at common eventing models/function execution, interoperability of the services, and common SDK’s. This would allow for the functions to have portability in mind across a variety of FaaS implementations. Also, I believe this is very pertinent to cloud native as teams are using the a variety of compute (VM/instances, containers, and FaaS) to design, develop, and deploy their applications. In other words, FaaS is a cloud native design pattern that needs to be supported across all clouds. And, since I’m replying to Dan’s email I will add this AWS re:invent video link where Coca Cola is using AWS Lambda to run payments from their machines. The beginning talks about their rationale and goes into pricing break evens on when to switch to dedicated instances. Of course the use of AWS services always need to be kept in mind. AWS re:Invent 2016: Coca-Cola: Running Serverless Applications with Enterprise Requirements (SVR303) https://www.youtube.com/watch?v=yErmil00DYs Mark From: <cncf-toc-bounces@...> on behalf of Dan Kohn via cncf-toc <cncf-toc@...> Reply-To: Dan Kohn <dan@...> Date: Friday, March 31, 2017 at 11:35 AM To: Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Yes, I find this story inspiring from Benchling of moving their genome searching to Lambda and both reducing tail latency and dropping costs from thousands of dollars per month to $60: http://benchling.engineering/crispr-aws-lambda/ -- Dan Kohn <mailto:dan@...> Executive Director, Cloud Native Computing Foundation <https://cncf.io> tel:+1-415-233-1000 On Mar 31, 2017, at 14:10, Alexis Richardson via cncf-toc <cncf-toc@...> wrote: Related to this, many FaaS proponents talk about the economics of only paying for use (function calls). But this economic model is not limited to the serverless app frameworks eg as listed below by Brian. Many container orchestrators could feasibly provide fine grained billing. On Fri, 31 Mar 2017, 19:00 Brian Grant via cncf-toc, <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. 2. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 3. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 4. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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 _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc _______________________________________________ cncf-toc mailing list cncf-toc@... https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_mailman_listinfo_cncf-2Dtoc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6p0eGA_74Mh7puBbIA77IA&m=NQmI2gOnfoIAa77aHFZsE4PycfrM6ncO0eI2FxRrhiA&s=PTGKvZDiMKi_QBdB_7d6wxbke6xlMWXwo-l-Wgol2r4&e= _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
NASSAUR, DOUGLAS C <dn283x@...> #808 Any opportunity to fold this line of thinking into the architecture patterns we are working as part of the architecture committee. One of the "patterns" groups represents a pivot to scaling function as opposed to scaling infrastructure. It would appear to overlap in thinking and objective with the FaaS movement. Less concerned about naming but would propose we could bring the threads together if folks are interested. Regards, Doug On Apr 4, 2017, at 8:04 AM, Yaron Haviv via cncf-toc <cncf-toc@...> wrote: toggle quoted message Show quoted text 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 framework As Alexis mentioned lets start with areas of consensus & low hanging fruits (I guess AWS, Azure, IBM won’t start dev from scratch), e.g.: what’s “Serverless”/”FaaS” scope, how users interact with those platforms in a uniform way, how CNCF or other tools can integrate and add value. We can expand it as we go. Yaron From: Alexis Richardson [mailto:alexis@...] Sent: Tuesday, April 4, 2017 9:41 AM To: Cathy Zhang <Cathy.H.Zhang@...>; Mark Peek <markpeek@...>; Yaron Haviv <yaronh@...>; Dan Kohn <dan@...>; Ryan S. Brown <ryansb@...>; Brian Grant <briangrant@...>; cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Hi all I'm in favour of a wg. But it needs to not overreach. An initial focus could be to parse the space (as Yaron and others did) and identify areas where the cncf can help. If we did this i think it would be invalid (or at least, unlikely to be useful) unless leading projects were in a position to state what would be most useful to them. At the same time people who don't run one of the new projects are keen to contribute. I need to consult with the TOC and alas won't be able to do so until the 18th as i am about to go on vacation. But please ask Chris A if you want an agenda item for tomorrow, about who might be interested in helping with a wg. Alexis On Mon, 3 Apr 2017, 23:35 Cathy Zhang, <Cathy.H.Zhang@...> wrote: +1 on a CNCF WG. Will be happy to contribute to it. I see that different people have different perspectives on serverless or FaaS. I think it will he helpful to define the semantics of serverless and the scope of serverless (I agree with Dan that we may need a better terminology) in CNCF so that we can all be on the same page when diving into serverless tech or implementation. There are already some open source serverless implementations. Most of them concentrates on event driven function hosting and execution, similar to AWS Lambda function. But in reality there are many use cases that involve multiple functions executing in sequence or in parallel or different function execution upon different events or a function execution triggered by a combination of events, etc.. CNCF can play a key role in “standardizing” a comprehensive and generic event function execution model, something like a “event+function” graph so that whatever the backend implementation, the user-facing front end will not change. Cathy From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 2:27 PM To: Yaron Haviv; Dan Kohn; Alexis Richardson; cncf-toc@...; Ryan S. Brown; Brian Grant Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless +1 on a CNCF WG for serverless. Per a side conversation with Alexis this should be discussed at the TOC so it would be nice to have this added as an agenda item for an upcoming meeting. Mark From: Yaron Haviv <yaronh@...> Date: Friday, March 31, 2017 at 1:01 PM To: Mark Peek <markpeek@...>, Dan Kohn <dan@...>, Alexis Richardson <alexis@...>, "cncf-toc@..." <cncf-toc@...>, "Ryan S. Brown" <ryansb@...>, Brian Grant <briangrant@...> Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless 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, focused on RT data processing) And its critical that we have cross platform APIs, the flexibility to use different tools, and allow incremental innovation. now every “serverless” project 100% overlaps the other, CNI/OCI as good examples for why we should have layering vs monoliths We can break Serverless tech to few sub-categorize e.g.: - Function APIs/patterns (e.g. definition of context, events, logs, ..) - “Serverless Run-time” (implementation), I guess every cloud will have its own and we will see few open with different focus areas - Edit, build, test, tools (and how they integrate with the run-times & APIs ..) - Event/data sources (API for things that drive function invocations) Its in CNCF/LF interest to foster collaboration across those areas, allow different build tool to work with multiple run times, and make sure developers don’t have to use different code for each run-time or cloud vendor. I see nice concepts in the different implementations and would be great if we can sit and agree what are the things we want to adopt in a common definition or make optional. The best next step is to form a CNCF WG/SIG, happy to contribute to such. Yaron Iguazio, CTO From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 9:59 PM To: Dan Kohn <dan@...>; Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I’m not a fan of the term “serverless” as most people tend to think “no servers” as opposed to “fewer” or “not having to deal with” servers. Of course, FaaS doesn’t quite roll off the tongue either. Definitely be nice to have better naming around it. Looking at this from an on-prem or private cloud perspective, you don’t get the same benefits as public cloud FaaS. Instead of having all of the infrastructure handled by the public cloud, the private clouds will require ease of operation and lifecycle management for the FaaS operation. And will have additional requirements around multi-tenant, RBAC, and security. While there will be multiple FaaS implementations (stand alone or on top of k8s), as Brian alluded to we should be looking at common eventing models/function execution, interoperability of the services, and common SDK’s. This would allow for the functions to have portability in mind across a variety of FaaS implementations. Also, I believe this is very pertinent to cloud native as teams are using the a variety of compute (VM/instances, containers, and FaaS) to design, develop, and deploy their applications. In other words, FaaS is a cloud native design pattern that needs to be supported across all clouds. And, since I’m replying to Dan’s email I will add this AWS re:invent video link where Coca Cola is using AWS Lambda to run payments from their machines. The beginning talks about their rationale and goes into pricing break evens on when to switch to dedicated instances. Of course the use of AWS services always need to be kept in mind. AWS re:Invent 2016: Coca-Cola: Running Serverless Applications with Enterprise Requirements (SVR303) https://www.youtube.com/watch?v=yErmil00DYs Mark From: <cncf-toc-bounces@...> on behalf of Dan Kohn via cncf-toc <cncf-toc@...> Reply-To: Dan Kohn <dan@...> Date: Friday, March 31, 2017 at 11:35 AM To: Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Yes, I find this story inspiring from Benchling of moving their genome searching to Lambda and both reducing tail latency and dropping costs from thousands of dollars per month to $60: http://benchling.engineering/crispr-aws-lambda/ -- Dan Kohn <mailto:dan@...> Executive Director, Cloud Native Computing Foundation <https://cncf.io> tel:+1-415-233-1000 On Mar 31, 2017, at 14:10, Alexis Richardson via cncf-toc <cncf-toc@...> wrote: Related to this, many FaaS proponents talk about the economics of only paying for use (function calls). But this economic model is not limited to the serverless app frameworks eg as listed below by Brian. Many container orchestrators could feasibly provide fine grained billing. On Fri, 31 Mar 2017, 19:00 Brian Grant via cncf-toc, <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. 2. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 3. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 4. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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 _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc _______________________________________________ cncf-toc mailing list cncf-toc@... https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.cncf.io_mailman_listinfo_cncf-2Dtoc&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6p0eGA_74Mh7puBbIA77IA&m=NQmI2gOnfoIAa77aHFZsE4PycfrM6ncO0eI2FxRrhiA&s=PTGKvZDiMKi_QBdB_7d6wxbke6xlMWXwo-l-Wgol2r4&e=
More All Messages By This Member
alexis richardson #807 All, Just in terms of process: please note that a WG needs TOC support to form. I'm waving my hand and saying "I am supportive". I don't know what the rest of the TOC think yet ;) Also we need to work out some details. But, please continue to explore the idea! alexis toggle quoted message Show quoted text On Tue, Apr 4, 2017 at 1:04 PM Yaron Haviv <yaronh@...> wrote: 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 framework As Alexis mentioned lets start with areas of consensus & low hanging fruits (I guess AWS, Azure, IBM won’t start dev from scratch), e.g.: what’s “Serverless”/”FaaS” scope, how users interact with those platforms in a uniform way, how CNCF or other tools can integrate and add value. We can expand it as we go. Yaron From: Alexis Richardson [mailto:alexis@...] Sent: Tuesday, April 4, 2017 9:41 AM To: Cathy Zhang <Cathy.H.Zhang@...>; Mark Peek <markpeek@...>; Yaron Haviv <yaronh@...>; Dan Kohn <dan@...>; Ryan S. Brown <ryansb@...>; Brian Grant <briangrant@...>; cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Hi all I'm in favour of a wg. But it needs to not overreach. An initial focus could be to parse the space (as Yaron and others did) and identify areas where the cncf can help. If we did this i think it would be invalid (or at least, unlikely to be useful) unless leading projects were in a position to state what would be most useful to them. At the same time people who don't run one of the new projects are keen to contribute. I need to consult with the TOC and alas won't be able to do so until the 18th as i am about to go on vacation. But please ask Chris A if you want an agenda item for tomorrow, about who might be interested in helping with a wg. Alexis On Mon, 3 Apr 2017, 23:35 Cathy Zhang, <Cathy.H.Zhang@...> wrote: +1 on a CNCF WG. Will be happy to contribute to it. I see that different people have different perspectives on serverless or FaaS. I think it will he helpful to define the semantics of serverless and the scope of serverless (I agree with Dan that we may need a better terminology) in CNCF so that we can all be on the same page when diving into serverless tech or implementation. There are already some open source serverless implementations. Most of them concentrates on event driven function hosting and execution, similar to AWS Lambda function. But in reality there are many use cases that involve multiple functions executing in sequence or in parallel or different function execution upon different events or a function execution triggered by a combination of events, etc.. CNCF can play a key role in “standardizing” a comprehensive and generic event function execution model, something like a “event+function” graph so that whatever the backend implementation, the user-facing front end will not change. Cathy From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 2:27 PM To: Yaron Haviv; Dan Kohn; Alexis Richardson; cncf-toc@...; Ryan S. Brown; Brian Grant Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless +1 on a CNCF WG for serverless. Per a side conversation with Alexis this should be discussed at the TOC so it would be nice to have this added as an agenda item for an upcoming meeting. Mark From: Yaron Haviv <yaronh@...> Date: Friday, March 31, 2017 at 1:01 PM To: Mark Peek <markpeek@...>, Dan Kohn <dan@...>, Alexis Richardson <alexis@...>, "cncf-toc@..." <cncf-toc@...>, "Ryan S. Brown" <ryansb@...>, Brian Grant <briangrant@...> Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless 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, focused on RT data processing) And its critical that we have cross platform APIs, the flexibility to use different tools, and allow incremental innovation. now every “serverless” project 100% overlaps the other, CNI/OCI as good examples for why we should have layering vs monoliths We can break Serverless tech to few sub-categorize e.g.: - Function APIs/patterns (e.g. definition of context, events, logs, ..) - “Serverless Run-time” (implementation), I guess every cloud will have its own and we will see few open with different focus areas - Edit, build, test, tools (and how they integrate with the run-times & APIs ..) - Event/data sources (API for things that drive function invocations) Its in CNCF/LF interest to foster collaboration across those areas, allow different build tool to work with multiple run times, and make sure developers don’t have to use different code for each run-time or cloud vendor. I see nice concepts in the different implementations and would be great if we can sit and agree what are the things we want to adopt in a common definition or make optional. The best next step is to form a CNCF WG/SIG, happy to contribute to such. Yaron Iguazio, CTO From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 9:59 PM To: Dan Kohn <dan@...>; Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I’m not a fan of the term “serverless” as most people tend to think “no servers” as opposed to “fewer” or “not having to deal with” servers. Of course, FaaS doesn’t quite roll off the tongue either. Definitely be nice to have better naming around it. Looking at this from an on-prem or private cloud perspective, you don’t get the same benefits as public cloud FaaS. Instead of having all of the infrastructure handled by the public cloud, the private clouds will require ease of operation and lifecycle management for the FaaS operation. And will have additional requirements around multi-tenant, RBAC, and security. While there will be multiple FaaS implementations (stand alone or on top of k8s), as Brian alluded to we should be looking at common eventing models/function execution, interoperability of the services, and common SDK’s. This would allow for the functions to have portability in mind across a variety of FaaS implementations. Also, I believe this is very pertinent to cloud native as teams are using the a variety of compute (VM/instances, containers, and FaaS) to design, develop, and deploy their applications. In other words, FaaS is a cloud native design pattern that needs to be supported across all clouds. And, since I’m replying to Dan’s email I will add this AWS re:invent video link where Coca Cola is using AWS Lambda to run payments from their machines. The beginning talks about their rationale and goes into pricing break evens on when to switch to dedicated instances. Of course the use of AWS services always need to be kept in mind. AWS re:Invent 2016: Coca-Cola: Running Serverless Applications with Enterprise Requirements (SVR303) https://www.youtube.com/watch?v=yErmil00DYs Mark From: <cncf-toc-bounces@...> on behalf of Dan Kohn via cncf-toc <cncf-toc@...> Reply-To: Dan Kohn <dan@...> Date: Friday, March 31, 2017 at 11:35 AM To: Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Yes, I find this story inspiring from Benchling of moving their genome searching to Lambda and both reducing tail latency and dropping costs from thousands of dollars per month to $60: http://benchling.engineering/crispr-aws-lambda/ -- Dan Kohn <mailto:dan@...> Executive Director, Cloud Native Computing Foundation <https://cncf.io> tel:+1-415-233-1000 On Mar 31, 2017, at 14:10, Alexis Richardson via cncf-toc <cncf-toc@...> wrote: Related to this, many FaaS proponents talk about the economics of only paying for use (function calls). But this economic model is not limited to the serverless app frameworks eg as listed below by Brian. Many container orchestrators could feasibly provide fine grained billing. On Fri, 31 Mar 2017, 19:00 Brian Grant via cncf-toc, <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. 2. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 3. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 4. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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 _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
Yaron Haviv #806 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 framework As Alexis mentioned lets start with areas of consensus & low hanging fruits (I guess AWS, Azure, IBM won’t start dev from scratch), e.g.: what’s “Serverless”/”FaaS” scope, how users interact with those platforms in a uniform way, how CNCF or other tools can integrate and add value. We can expand it as we go. Yaron toggle quoted message Show quoted text From: Alexis Richardson [mailto:alexis@...] Sent: Tuesday, April 4, 2017 9:41 AM To: Cathy Zhang <Cathy.H.Zhang@...>; Mark Peek <markpeek@...>; Yaron Haviv <yaronh@...>; Dan Kohn <dan@...>; Ryan S. Brown <ryansb@...>; Brian Grant <briangrant@...>; cncf-toc@... Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Hi all I'm in favour of a wg. But it needs to not overreach. An initial focus could be to parse the space (as Yaron and others did) and identify areas where the cncf can help. If we did this i think it would be invalid (or at least, unlikely to be useful) unless leading projects were in a position to state what would be most useful to them. At the same time people who don't run one of the new projects are keen to contribute. I need to consult with the TOC and alas won't be able to do so until the 18th as i am about to go on vacation. But please ask Chris A if you want an agenda item for tomorrow, about who might be interested in helping with a wg. Alexis On Mon, 3 Apr 2017, 23:35 Cathy Zhang, <Cathy.H.Zhang@...> wrote: +1 on a CNCF WG. Will be happy to contribute to it. I see that different people have different perspectives on serverless or FaaS. I think it will he helpful to define the semantics of serverless and the scope of serverless (I agree with Dan that we may need a better terminology) in CNCF so that we can all be on the same page when diving into serverless tech or implementation. There are already some open source serverless implementations. Most of them concentrates on event driven function hosting and execution, similar to AWS Lambda function. But in reality there are many use cases that involve multiple functions executing in sequence or in parallel or different function execution upon different events or a function execution triggered by a combination of events, etc.. CNCF can play a key role in “standardizing” a comprehensive and generic event function execution model, something like a “event+function” graph so that whatever the backend implementation, the user-facing front end will not change. Cathy From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 2:27 PM To: Yaron Haviv; Dan Kohn; Alexis Richardson; cncf-toc@...; Ryan S. Brown; Brian Grant Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless +1 on a CNCF WG for serverless. Per a side conversation with Alexis this should be discussed at the TOC so it would be nice to have this added as an agenda item for an upcoming meeting. Mark From: Yaron Haviv <yaronh@...> Date: Friday, March 31, 2017 at 1:01 PM To: Mark Peek <markpeek@...>, Dan Kohn <dan@...>, Alexis Richardson <alexis@...>, "cncf-toc@..." <cncf-toc@...>, "Ryan S. Brown" <ryansb@...>, Brian Grant <briangrant@...> Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless 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, focused on RT data processing) And its critical that we have cross platform APIs, the flexibility to use different tools, and allow incremental innovation. now every “serverless” project 100% overlaps the other, CNI/OCI as good examples for why we should have layering vs monoliths We can break Serverless tech to few sub-categorize e.g.: - Function APIs/patterns (e.g. definition of context, events, logs, ..) - “Serverless Run-time” (implementation), I guess every cloud will have its own and we will see few open with different focus areas - Edit, build, test, tools (and how they integrate with the run-times & APIs ..) - Event/data sources (API for things that drive function invocations) Its in CNCF/LF interest to foster collaboration across those areas, allow different build tool to work with multiple run times, and make sure developers don’t have to use different code for each run-time or cloud vendor. I see nice concepts in the different implementations and would be great if we can sit and agree what are the things we want to adopt in a common definition or make optional. The best next step is to form a CNCF WG/SIG, happy to contribute to such. Yaron Iguazio, CTO From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 9:59 PM To: Dan Kohn <dan@...>; Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I’m not a fan of the term “serverless” as most people tend to think “no servers” as opposed to “fewer” or “not having to deal with” servers. Of course, FaaS doesn’t quite roll off the tongue either. Definitely be nice to have better naming around it. Looking at this from an on-prem or private cloud perspective, you don’t get the same benefits as public cloud FaaS. Instead of having all of the infrastructure handled by the public cloud, the private clouds will require ease of operation and lifecycle management for the FaaS operation. And will have additional requirements around multi-tenant, RBAC, and security. While there will be multiple FaaS implementations (stand alone or on top of k8s), as Brian alluded to we should be looking at common eventing models/function execution, interoperability of the services, and common SDK’s. This would allow for the functions to have portability in mind across a variety of FaaS implementations. Also, I believe this is very pertinent to cloud native as teams are using the a variety of compute (VM/instances, containers, and FaaS) to design, develop, and deploy their applications. In other words, FaaS is a cloud native design pattern that needs to be supported across all clouds. And, since I’m replying to Dan’s email I will add this AWS re:invent video link where Coca Cola is using AWS Lambda to run payments from their machines. The beginning talks about their rationale and goes into pricing break evens on when to switch to dedicated instances. Of course the use of AWS services always need to be kept in mind. AWS re:Invent 2016: Coca-Cola: Running Serverless Applications with Enterprise Requirements (SVR303) https://www.youtube.com/watch?v=yErmil00DYs Mark From: <cncf-toc-bounces@...> on behalf of Dan Kohn via cncf-toc <cncf-toc@...> Reply-To: Dan Kohn <dan@...> Date: Friday, March 31, 2017 at 11:35 AM To: Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Yes, I find this story inspiring from Benchling of moving their genome searching to Lambda and both reducing tail latency and dropping costs from thousands of dollars per month to $60: http://benchling.engineering/crispr-aws-lambda/ -- Dan Kohn <mailto:dan@...> Executive Director, Cloud Native Computing Foundation <https://cncf.io> tel:+1-415-233-1000 On Mar 31, 2017, at 14:10, Alexis Richardson via cncf-toc <cncf-toc@...> wrote: Related to this, many FaaS proponents talk about the economics of only paying for use (function calls). But this economic model is not limited to the serverless app frameworks eg as listed below by Brian. Many container orchestrators could feasibly provide fine grained billing. On Fri, 31 Mar 2017, 19:00 Brian Grant via cncf-toc, <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. 2. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 3. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 4. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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 _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
alexis richardson #803 Hi all I'm in favour of a wg. But it needs to not overreach. An initial focus could be to parse the space (as Yaron and others did) and identify areas where the cncf can help. If we did this i think it would be invalid (or at least, unlikely to be useful) unless leading projects were in a position to state what would be most useful to them. At the same time people who don't run one of the new projects are keen to contribute. I need to consult with the TOC and alas won't be able to do so until the 18th as i am about to go on vacation. But please ask Chris A if you want an agenda item for tomorrow, about who might be interested in helping with a wg. Alexis toggle quoted message Show quoted text On Mon, 3 Apr 2017, 23:35 Cathy Zhang, <Cathy.H.Zhang@...> wrote: +1 on a CNCF WG. Will be happy to contribute to it. I see that different people have different perspectives on serverless or FaaS. I think it will he helpful to define the semantics of serverless and the scope of serverless (I agree with Dan that we may need a better terminology) in CNCF so that we can all be on the same page when diving into serverless tech or implementation. There are already some open source serverless implementations. Most of them concentrates on event driven function hosting and execution, similar to AWS Lambda function. But in reality there are many use cases that involve multiple functions executing in sequence or in parallel or different function execution upon different events or a function execution triggered by a combination of events, etc.. CNCF can play a key role in “standardizing” a comprehensive and generic event function execution model, something like a “event+function” graph so that whatever the backend implementation, the user-facing front end will not change. Cathy From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 2:27 PM To: Yaron Haviv; Dan Kohn; Alexis Richardson; cncf-toc@...; Ryan S. Brown; Brian Grant Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless +1 on a CNCF WG for serverless. Per a side conversation with Alexis this should be discussed at the TOC so it would be nice to have this added as an agenda item for an upcoming meeting. Mark From: Yaron Haviv <yaronh@...> Date: Friday, March 31, 2017 at 1:01 PM To: Mark Peek <markpeek@...>, Dan Kohn <dan@...>, Alexis Richardson <alexis@...>, "cncf-toc@..." <cncf-toc@...>, "Ryan S. Brown" <ryansb@...>, Brian Grant <briangrant@...> Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless 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, focused on RT data processing) And its critical that we have cross platform APIs, the flexibility to use different tools, and allow incremental innovation. now every “serverless” project 100% overlaps the other, CNI/OCI as good examples for why we should have layering vs monoliths We can break Serverless tech to few sub-categorize e.g.: - Function APIs/patterns (e.g. definition of context, events, logs, ..) - “Serverless Run-time” (implementation), I guess every cloud will have its own and we will see few open with different focus areas - Edit, build, test, tools (and how they integrate with the run-times & APIs ..) - Event/data sources (API for things that drive function invocations) Its in CNCF/LF interest to foster collaboration across those areas, allow different build tool to work with multiple run times, and make sure developers don’t have to use different code for each run-time or cloud vendor. I see nice concepts in the different implementations and would be great if we can sit and agree what are the things we want to adopt in a common definition or make optional. The best next step is to form a CNCF WG/SIG, happy to contribute to such. Yaron Iguazio, CTO From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 9:59 PM To: Dan Kohn <dan@...>; Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I’m not a fan of the term “serverless” as most people tend to think “no servers” as opposed to “fewer” or “not having to deal with” servers. Of course, FaaS doesn’t quite roll off the tongue either. Definitely be nice to have better naming around it. Looking at this from an on-prem or private cloud perspective, you don’t get the same benefits as public cloud FaaS. Instead of having all of the infrastructure handled by the public cloud, the private clouds will require ease of operation and lifecycle management for the FaaS operation. And will have additional requirements around multi-tenant, RBAC, and security. While there will be multiple FaaS implementations (stand alone or on top of k8s), as Brian alluded to we should be looking at common eventing models/function execution, interoperability of the services, and common SDK’s. This would allow for the functions to have portability in mind across a variety of FaaS implementations. Also, I believe this is very pertinent to cloud native as teams are using the a variety of compute (VM/instances, containers, and FaaS) to design, develop, and deploy their applications. In other words, FaaS is a cloud native design pattern that needs to be supported across all clouds. And, since I’m replying to Dan’s email I will add this AWS re:invent video link where Coca Cola is using AWS Lambda to run payments from their machines. The beginning talks about their rationale and goes into pricing break evens on when to switch to dedicated instances. Of course the use of AWS services always need to be kept in mind. AWS re:Invent 2016: Coca-Cola: Running Serverless Applications with Enterprise Requirements (SVR303) https://www.youtube.com/watch?v=yErmil00DYs Mark From: <cncf-toc-bounces@...> on behalf of Dan Kohn via cncf-toc <cncf-toc@...> Reply-To: Dan Kohn <dan@...> Date: Friday, March 31, 2017 at 11:35 AM To: Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Yes, I find this story inspiring from Benchling of moving their genome searching to Lambda and both reducing tail latency and dropping costs from thousands of dollars per month to $60: http://benchling.engineering/crispr-aws-lambda/ -- Dan Kohn <mailto:dan@...> Executive Director, Cloud Native Computing Foundation <https://cncf.io> tel:+1-415-233-1000 On Mar 31, 2017, at 14:10, Alexis Richardson via cncf-toc <cncf-toc@...> wrote: Related to this, many FaaS proponents talk about the economics of only paying for use (function calls). But this economic model is not limited to the serverless app frameworks eg as listed below by Brian. Many container orchestrators could feasibly provide fine grained billing. On Fri, 31 Mar 2017, 19:00 Brian Grant via cncf-toc, <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. 2. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 3. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 4. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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 _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
Cathy Zhang <Cathy.H.Zhang@...> #802 +1 on a CNCF WG. Will be happy to contribute to it. I see that different people have different perspectives on serverless or FaaS. I think it will he helpful to define the semantics of serverless and the scope of serverless (I agree with Dan that we may need a better terminology) in CNCF so that we can all be on the same page when diving into serverless tech or implementation. There are already some open source serverless implementations. Most of them concentrates on event driven function hosting and execution, similar to AWS Lambda function. But in reality there are many use cases that involve multiple functions executing in sequence or in parallel or different function execution upon different events or a function execution triggered by a combination of events, etc.. CNCF can play a key role in “standardizing” a comprehensive and generic event function execution model, something like a “event+function” graph so that whatever the backend implementation, the user-facing front end will not change. Cathy toggle quoted message Show quoted text From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 2:27 PM To: Yaron Haviv; Dan Kohn; Alexis Richardson; cncf-toc@...; Ryan S. Brown; Brian Grant Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless +1 on a CNCF WG for serverless. Per a side conversation with Alexis this should be discussed at the TOC so it would be nice to have this added as an agenda item for an upcoming meeting. Mark From: Yaron Haviv <yaronh@...> Date: Friday, March 31, 2017 at 1:01 PM To: Mark Peek <markpeek@...>, Dan Kohn <dan@...>, Alexis Richardson <alexis@...>, "cncf-toc@..." <cncf-toc@...>, "Ryan S. Brown" <ryansb@...>, Brian Grant <briangrant@...> Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless 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, focused on RT data processing) And its critical that we have cross platform APIs, the flexibility to use different tools, and allow incremental innovation. now every “serverless” project 100% overlaps the other, CNI/OCI as good examples for why we should have layering vs monoliths We can break Serverless tech to few sub-categorize e.g.: - Function APIs/patterns (e.g. definition of context, events, logs, ..) - “Serverless Run-time” (implementation), I guess every cloud will have its own and we will see few open with different focus areas - Edit, build, test, tools (and how they integrate with the run-times & APIs ..) - Event/data sources (API for things that drive function invocations) Its in CNCF/LF interest to foster collaboration across those areas, allow different build tool to work with multiple run times, and make sure developers don’t have to use different code for each run-time or cloud vendor. I see nice concepts in the different implementations and would be great if we can sit and agree what are the things we want to adopt in a common definition or make optional. The best next step is to form a CNCF WG/SIG, happy to contribute to such. Yaron Iguazio, CTO From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Mark Peek via cncf-toc Sent: Friday, March 31, 2017 9:59 PM To: Dan Kohn <dan@...>; Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless I’m not a fan of the term “serverless” as most people tend to think “no servers” as opposed to “fewer” or “not having to deal with” servers. Of course, FaaS doesn’t quite roll off the tongue either. Definitely be nice to have better naming around it. Looking at this from an on-prem or private cloud perspective, you don’t get the same benefits as public cloud FaaS. Instead of having all of the infrastructure handled by the public cloud, the private clouds will require ease of operation and lifecycle management for the FaaS operation. And will have additional requirements around multi-tenant, RBAC, and security. While there will be multiple FaaS implementations (stand alone or on top of k8s), as Brian alluded to we should be looking at common eventing models/function execution, interoperability of the services, and common SDK’s. This would allow for the functions to have portability in mind across a variety of FaaS implementations. Also, I believe this is very pertinent to cloud native as teams are using the a variety of compute (VM/instances, containers, and FaaS) to design, develop, and deploy their applications. In other words, FaaS is a cloud native design pattern that needs to be supported across all clouds. And, since I’m replying to Dan’s email I will add this AWS re:invent video link where Coca Cola is using AWS Lambda to run payments from their machines. The beginning talks about their rationale and goes into pricing break evens on when to switch to dedicated instances. Of course the use of AWS services always need to be kept in mind. AWS re:Invent 2016: Coca-Cola: Running Serverless Applications with Enterprise Requirements (SVR303) https://www.youtube.com/watch?v=yErmil00DYs Mark From: <cncf-toc-bounces@...> on behalf of Dan Kohn via cncf-toc <cncf-toc@...> Reply-To: Dan Kohn <dan@...> Date: Friday, March 31, 2017 at 11:35 AM To: Alexis Richardson <alexis@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Yes, I find this story inspiring from Benchling of moving their genome searching to Lambda and both reducing tail latency and dropping costs from thousands of dollars per month to $60: http://benchling.engineering/crispr-aws-lambda/ -- Dan Kohn <mailto:dan@...> Executive Director, Cloud Native Computing Foundation <https://cncf.io> tel:+1-415-233-1000 On Mar 31, 2017, at 14:10, Alexis Richardson via cncf-toc <cncf-toc@...> wrote: Related to this, many FaaS proponents talk about the economics of only paying for use (function calls). But this economic model is not limited to the serverless app frameworks eg as listed below by Brian. Many container orchestrators could feasibly provide fine grained billing. On Fri, 31 Mar 2017, 19:00 Brian Grant via cncf-toc, <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. 2. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 3. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 4. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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 _______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
Yaron Haviv #800 Doug, I agree, e.g. couple of 1^st 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 across implementations. Will also allow dev of standalone test harnesses/tools. Define a package format for code + library/binary dependencies, so tools can commit/push functions to any framework BTW I think the “serverless” notion can be easily extended to “Micro-Batch Jobs” and “Continuous Services”, the ease of use of writing and publishing cloud-native functions doesn’t have to end with event-driven use cases. Yaron toggle quoted message Show quoted text From: Doug Davis [mailto:dug@...] Sent: Sunday, April 2, 2017 4:31 PM To: Yaron Haviv <yaronh@...> Cc: Clayton Coleman <ccoleman@...>; cncf-toc@... Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless One day we may be able to leverage common infrastructure, but for now I think a more realistic goal might be to focus on the end-user and see if we can push for an interoperability statement around what they are exposed to. IOW, focus on the OCI image format equivalent for serverless that gives users the freedom to move between implementations. 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 Yaron Haviv ---04/02/2017 03:54:07 AM---"serverless" Perf is a big issue, start-up time is just part of it, most implementation have huge pe From: Yaron Haviv <yaronh@...> To: Doug Davis/Raleigh/IBM@IBMUS, Clayton Coleman <ccoleman@...>, "cncf-toc@..." <cncf-toc@...> Date: 04/02/2017 03:54 AM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless “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/@ferdingler/aws-lambda-no-thank-you-9c586990e67d I assume we don’t want “Serverless” to consume many more servers, need to address concurrency, cut redundant layers, etc’ to make it useful beyond sporadic execution and web hooks, Wrote a blog on that. My KubeCon session covered various problems in current “serverless” implementations and how we addressed them w few real examples (slide 8-13): http://www.slideshare.net/yaronhaviv/building-super-fast-cloudnative-data-platforms-yaron-haviv-kubecon-2017-eu And again, the key is collaboration, assuming there will be multiple cloud/open implementations how do we make them interchangeable, allow code portability, and leverage common infrastructure and tooling Yaron From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Doug Davis via cncf-toc Sent: Saturday, April 1, 2017 4:01 PM To: Clayton Coleman <ccoleman@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Glad to see lots of agreement on this thread and +1 to the idea of a WG/SIG. One comment though, Ryan said: > I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. I'd put performance in the core, at least w.r.t. the container start-up time. If the performance of the infrastructure to setup the container to execute the function isn't fast enough then I think the uptake on this will be negatively impacted. 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 Clayton Coleman via cncf-toc ---04/01/2017 09:24:39 AM---On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc < cncf-toc@...> wrote: From: Clayton Coleman via cncf-toc <cncf-toc@...> To: Brian Grant <briangrant@...> Cc: cncf-toc <cncf-toc@...> Date: 04/01/2017 09:24 AM Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Sent by: cncf-toc-bounces@... On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: 1. Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. I think this is one of the areas that the open source community could make the most impact in (relative to cloud platform implementations). Event bus and message bus are prevalent in many, many infrastructures, and FaaS practically requires easy and extensive adaptation of existing data stores to reach its potential. (This belongs under point three below for etl, but is really a larger security/interop challenge) 1. Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. 2. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. 3. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Because as you note later all FaaS infrastructure is complementary with the point of container infrastructure optimization - each layer can benefit from the same optimizations (anticipatory scaling, wake on request, data locality, slack capacity assignment, central shard assignment and hot sharding, etc). FaaS on Kube should be better than FaaS not on Kube (to an operations team) Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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_______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
Doug Davis <dug@...> #799 One day we may be able to leverage common infrastructure, but for now I think a more realistic goal might be to focus on the end-user and see if we can push for an interoperability statement around what they are exposed to. IOW, focus on the OCI image format equivalent for serverless that gives users the freedom to move between implementations. 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 Yaron Haviv ---04/02/2017 03:54:07 AM---"serverless" Perf is a big issue, start-up time is just part of it, most implementation have huge pe From: Yaron Haviv <yaronh@...> To: Doug Davis/Raleigh/IBM@IBMUS, Clayton Coleman <ccoleman@...>, "cncf-toc@..." <cncf-toc@...> Date: 04/02/2017 03:54 AM Subject: RE: [cncf-toc] The Cloud-Nativity of Serverless “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/@ferdingler/aws-lambda-no-thank-you-9c586990e67d I assume we don’t want “Serverless” to consume many more servers, need to address concurrency, cut redundant layers, etc’ to make it useful beyond sporadic execution and web hooks, Wrote a blog on that. My KubeCon session covered various problems in current “serverless” implementations and how we addressed them w few real examples (slide 8-13): http://www.slideshare.net/yaronhaviv/building-super-fast-cloudnative-data-platforms-yaron-haviv-kubecon-2017-eu And again, the key is collaboration, assuming there will be multiple cloud/open implementations how do we make them interchangeable, allow code portability, and leverage common infrastructure and tooling Yaron toggle quoted message Show quoted text From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Doug Davis via cncf-toc Sent: Saturday, April 1, 2017 4:01 PM To: Clayton Coleman <ccoleman@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Glad to see lots of agreement on this thread and +1 to the idea of a WG/SIG. One comment though, Ryan said: > I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. I'd put performance in the core, at least w.r.t. the container start-up time. If the performance of the infrastructure to setup the container to execute the function isn't fast enough then I think the uptake on this will be negatively impacted. 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 Clayton Coleman via cncf-toc ---04/01/2017 09:24:39 AM---On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc < cncf-toc@...> wrote: From: Clayton Coleman via cncf-toc <cncf-toc@...> To: Brian Grant <briangrant@...> Cc: cncf-toc <cncf-toc@...> Date: 04/01/2017 09:24 AM Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Sent by: cncf-toc-bounces@... On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. I think this is one of the areas that the open source community could make the most impact in (relative to cloud platform implementations). Event bus and message bus are prevalent in many, many infrastructures, and FaaS practically requires easy and extensive adaptation of existing data stores to reach its potential. (This belongs under point three below for etl, but is really a larger security/interop challenge) Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Because as you note later all FaaS infrastructure is complementary with the point of container infrastructure optimization - each layer can benefit from the same optimizations (anticipatory scaling, wake on request, data locality, slack capacity assignment, central shard assignment and hot sharding, etc). FaaS on Kube should be better than FaaS not on Kube (to an operations team) Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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_______________________________________________ cncf-toc mailing list cncf-toc@... https://lists.cncf.io/mailman/listinfo/cncf-toc
More All Messages By This Member
Yaron Haviv #798 “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/@ferdingler/aws-lambda-no-thank-you-9c586990e67d I assume we don’t want “Serverless” to consume many more servers, need to address concurrency, cut redundant layers, etc’ to make it useful beyond sporadic execution and web hooks, Wrote a blog on that. My KubeCon session covered various problems in current “serverless” implementations and how we addressed them w few real examples (slide 8-13): http://www.slideshare.net/yaronhaviv/building-super-fast-cloudnative-data-platforms-yaron-haviv-kubecon-2017-eu And again, the key is collaboration, assuming there will be multiple cloud/open implementations how do we make them interchangeable, allow code portability, and leverage common infrastructure and tooling Yaron toggle quoted message Show quoted text From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Doug Davis via cncf-toc Sent: Saturday, April 1, 2017 4:01 PM To: Clayton Coleman <ccoleman@...> Cc: cncf-toc <cncf-toc@...> Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Glad to see lots of agreement on this thread and +1 to the idea of a WG/SIG. One comment though, Ryan said: > I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. I'd put performance in the core, at least w.r.t. the container start-up time. If the performance of the infrastructure to setup the container to execute the function isn't fast enough then I think the uptake on this will be negatively impacted. 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 Clayton Coleman via cncf-toc ---04/01/2017 09:24:39 AM---On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc < cncf-toc@...> wrote: From: Clayton Coleman via cncf-toc <cncf-toc@...> To: Brian Grant <briangrant@...> Cc: cncf-toc <cncf-toc@...> Date: 04/01/2017 09:24 AM Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Sent by: cncf-toc-bounces@... On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. I think this is one of the areas that the open source community could make the most impact in (relative to cloud platform implementations). Event bus and message bus are prevalent in many, many infrastructures, and FaaS practically requires easy and extensive adaptation of existing data stores to reach its potential. (This belongs under point three below for etl, but is really a larger security/interop challenge) Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Because as you note later all FaaS infrastructure is complementary with the point of container infrastructure optimization - each layer can benefit from the same optimizations (anticipatory scaling, wake on request, data locality, slack capacity assignment, central shard assignment and hot sharding, etc). FaaS on Kube should be better than FaaS not on Kube (to an operations team) Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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`_______________________________________________` `cncf-toc mailing list` `cncf-toc@...` `https://lists.cncf.io/mailman/listinfo/cncf-toc`
More All Messages By This Member
Doug Davis <dug@...> #797 Glad to see lots of agreement on this thread and +1 to the idea of a WG/SIG. One comment though, Ryan said: > I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. I'd put performance in the core, at least w.r.t. the container start-up time. If the performance of the infrastructure to setup the container to execute the function isn't fast enough then I think the uptake on this will be negatively impacted. 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 Clayton Coleman via cncf-toc ---04/01/2017 09:24:39 AM---On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc < cncf-toc@...> wrote: From: Clayton Coleman via cncf-toc <cncf-toc@...> To: Brian Grant <briangrant@...> Cc: cncf-toc <cncf-toc@...> Date: 04/01/2017 09:24 AM Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless Sent by: cncf-toc-bounces@... toggle quoted message Show quoted text On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote: I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS. I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades. Even Functions as a Service specially addresses multiple overlapping areas: Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions. I think this is one of the areas that the open source community could make the most impact in (relative to cloud platform implementations). Event bus and message bus are prevalent in many, many infrastructures, and FaaS practically requires easy and extensive adaptation of existing data stores to reach its potential. (This belongs under point three below for etl, but is really a larger security/interop challenge) Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions. Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors. Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers. Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS. Because as you note later all FaaS infrastructure is complementary with the point of container infrastructure optimization - each layer can benefit from the same optimizations (anticipatory scaling, wake on request, data locality, slack capacity assignment, central shard assignment and hot sharding, etc). FaaS on Kube should be better than FaaS not on Kube (to an operations team) Is FaaS "cloud native"? Yes. Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does. On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <cncf-toc@...> wrote: [inlined] On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper <anthony@...> wrote: > We would like to see a separate group working on serverless as well. At > Galactic Fog we have had a serverless implementation on DCOS for about 6 > months, and we plan to release our Kubernetes native implementation in the > next couple weeks in the runup to dockercon. > > From our perspective we would like the following things: > > Agreement on marketing terms. (Call it Serverless or Lambda, everyone > hates FAAS, but serverless is problematic as well) Agreement on these terms is probably a bit much to expect. For some time I was hoping we'd settle on "Jeff". While I'm not a lawyer, Lambda seems like the kind of thing that will turn into a trademark issue at some point. I think we're stuck with serverless, and when offering components that fit in a serverless stack we'll have to stick with things like "serverless function runtime," FaaS, and similar with a mind to two different audiences. Audience A: Technical audience, knows serverless well, and wants to know exactly what piece your project is providing. So you can say things like "event router" and function runtime to explain where it fits exactly. This audience also has some potential contributors in it if the project is OSS. Audience B: Thinks of serverless-the-concept as it relates to developer experience, and would be looking to figure out what they can do with it generally. The focus for those materials has to be on distinguishing from plain containers, PaaS, etc more than on the underlying thing your project is going to provide. Already it's getting kind of muddy, since Amazon and others are rebranding other aaS offerings as "serverless," such as DynamoDB. > Agreement on core capabilities, from our perspective they are: > > Runtime Support > API Gateway Support > Config / Secret Capabilities > Security Implementation > Logging Support > Monitoring Support > Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple > order of magnitude faster than Amazon, and that changes the art of the > possible) I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much. Think about the class of back-office examples that are common: transforming streams, resizing images, propagating changes to other systems. As long as they get done, the difference between 100ms and 1000ms can pass unnoticed since each event is eventually spawning a new function, and the queue/event system handles backpressure transparently. Then there's the category of user-facing synchronous workloads that you'd see an API Gateway used for, where perf matters and users just abandon anything that's perceivably slow. > None Core Capabilities > > Ability to inter-operate between serverless implementations (eg, migration > between them, include up to ad back from public cloud) > Lambda Chaining > Data management capabilities (exposing filesystems or other services in) > Making the implementation of the serveless solution portable across > platforms. > Data Layer Integration approaches. I'd probably bump chaining up to core, since all but the very simplest projects end up with a series of functions that either call each other, or create events that invoke others. > I wouldn't worry to much about the other big vendor stuff right now. > Serverless is at such an early stage any R&D done by anyone is really > helpful and not really competitive or problematic. (eg Openwhisk has > really cool ideas, and Amazon's attempts to standardize lambda portability > show an approach that is helpful for discussion) > > > Regards, > Anthony > > > > > On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc > <cncf-toc@...> wrote: >> >> Hello all, >> >> If haven't heard Amazon&others raising a general ruckus about serverless >> lately, I sincerely hope your vacation to the backwoods was relaxing. >> >> I'm Ryan, and I've been interested in FaaS/serverless for a while now. >> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski >> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has >> been picking up significantly in addition to all the use in the public >> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] & >> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4] >> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS. >> >> A cynical observer might say that the MS/IBM efforts are open to help >> compensate for them starting so late relative to Lambda, but either way the >> result is a lot of open or nominally open projects in the FaaS/serverless >> area. And with cloud providers looking to embed their various FaaS deeper >> into their clouds by integrating their FaaS with cloud-specific events, >> making their FaaS the way into customizing how their infra reacts to events. >> >> So why am I writing this email? Well I've been thinking about serverless >> as the next step in "cloud native" developer tooling. Look back to the state >> of the art in the 00's and you'll see the beginnings of >> autoscaling/immutable infrastructure, then move ahead a bit to containerized >> applications, then container schedulers, and you can see a trend towards >> shorter and shorter lifespans of persistent machines/processes. >> Function-as-a-Service is another step in that direction where containers >> live for seconds rather than persistently listening. This trajectory seems >> pretty intuitive as a developer: as lower layers of the stack become more >> standard I should be able to automate/outsource management of them. >> >> I'd like to help the TOC think about where (or whether) serverless/FaaS >> should fit into the CNCF's plans for the future. Do you want to talk about >> what serverless actually is? Figure out how various OSS fits into a >> serverless ecosystem? Compare how FaaS provided in the public cloud differs >> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete, >> and I are all here to help out. >> >> Cheers, >> Ryan >> >> >> >> 1: http://fission.io/ >> 2: https://funktion.fabric8.io/ >> 3: http://blog.alexellis.io/functions-as-a-service/ >> 4: https://developer.ibm.com/openwhisk/ >> 5: https://azure.microsoft.com/en-us/services/functions/ >> >> -- >> Ryan Brown / Senior Software Engineer / Red Hat, Inc. >> >> _______________________________________________ >> cncf-toc mailing list >> cncf-toc@... >> https://lists.cncf.io/mailman/listinfo/cncf-toc >> > -- Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc. _______________________________________________ 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`_______________________________________________ cncf-toc mailing list cncf-toc@...https://lists.cncf.io/mailman/listinfo/cncf-toc`
More All Messages By This Member