The Cloud-Nativity of Serverless


Ryan S. Brown <ryansb@...>
 

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


Anthony Skipper <anthony@...>
 

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: 

  1.  Agreement on marketing terms.  (Call it Serverless or Lambda, everyone hates FAAS, but serverless is problematic as well)
  2.  Agreement on core capabilities, from our perspective they are:
    1. Runtime Support
    2. API Gateway Support
    3. Config / Secret Capabilities
    4. Security Implementation
    5. Logging Support
    6. Monitoring Support
    7. Performance/Scalability  Capabilities (eg. Gestalt and Fission are a couple order of magnitude faster than Amazon, and that changes the art of the possible) 
  3. None Core Capabilities
    1. Ability to inter-operate between serverless implementations (eg, migration between them, include up to ad back from public cloud)
    2. Lambda Chaining 
    3. Data management capabilities (exposing filesystems or other services in)
    4. Making the implementation of the serveless solution portable across platforms.
    5. Data Layer Integration approaches.

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

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc



Mark Coleman <mark@...>
 

Thanks for kicking this off Ryan.

To provide a little more context for the rest of the TOC, I worked on the first ServerlessConf with Peter Sbarski (in CC) and Alexis asked if it would be possible to find some knowledgable Serverless folks to start a conversation here in the TOC.

This is the beginning of that conversation.


On Fri, Mar 31, 2017 at 5:17 PM 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
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
--
+31 652134960
Co-Founder www.softwarecircus.io
Marketing Chair www.cncf.io


alexis richardson
 

+1


On Fri, 31 Mar 2017, 17:17 Mark Coleman via cncf-toc, <cncf-toc@...> wrote:
Thanks for kicking this off Ryan.

To provide a little more context for the rest of the TOC, I worked on the first ServerlessConf with Peter Sbarski (in CC) and Alexis asked if it would be possible to find some knowledgable Serverless folks to start a conversation here in the TOC.

This is the beginning of that conversation.


On Fri, Mar 31, 2017 at 5:17 PM 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
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc
--
+31 652134960
Co-Founder www.softwarecircus.io
Marketing Chair www.cncf.io
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


Ryan S. Brown <ryansb@...>
 

[inlined]

On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper
<anthony@galacticfog.com> 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@lists.cncf.io> 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@lists.cncf.io
https://lists.cncf.io/mailman/listinfo/cncf-toc


--
Ryan Brown / Senior Software Engineer, Ansible / Red Hat, Inc.


sebastien goasguen <sebgoa@...>
 

Hi, 

I have been lurking on this list for sometime now. Skippbox which I founded was recently acquired by Bitnami (a recent member of CNCF). At Kubecon thursday I introduced kubeless[1] which leverages k8s primitives to provide a serverless framework. We are quite excited by it as we see a potential to use our work on k8s charts to provide more complex applications.

Definitely if there was a working group on serverless being formed we would love to join, share our early ideas and learn from others.


Best,

-Sebastien

On Fri, Mar 31, 2017 at 6:28 PM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:

+1


On Fri, 31 Mar 2017, 17:17 Mark Coleman via cncf-toc, <cncf-toc@...> wrote:
Thanks for kicking this off Ryan.

To provide a little more context for the rest of the TOC, I worked on the first ServerlessConf with Peter Sbarski (in CC) and Alexis asked if it would be possible to find some knowledgable Serverless folks to start a conversation here in the TOC.

This is the beginning of that conversation.


On Fri, Mar 31, 2017 at 5:17 PM 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
_______________________________________________
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




--

--

Sebastien Goasguen

http://www.skippbox.com

@skippbox

+41 79 367 38 25


Pini Reznik
 

Two weeks ago, we at Container Solutions, had an internal hackaton around serverless.
Tried most of the tools listed by you Ryan.
We are going to publish some blog posts about our findings later on.

We would love to see functions/serverless technologies becoming more generic and universal. Something that can be used across clouds, schedulers, IoT or anything else.

I believe independant organisation such as CNCF may contribute a lot to this subject

On Fri, Mar 31, 2017 at 6:29 PM Alexis Richardson via cncf-toc <cncf-toc@...> wrote:

+1


On Fri, 31 Mar 2017, 17:17 Mark Coleman via cncf-toc, <cncf-toc@...> wrote:
Thanks for kicking this off Ryan.

To provide a little more context for the rest of the TOC, I worked on the first ServerlessConf with Peter Sbarski (in CC) and Alexis asked if it would be possible to find some knowledgable Serverless folks to start a conversation here in the TOC.

This is the beginning of that conversation.


On Fri, Mar 31, 2017 at 5:17 PM 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
_______________________________________________
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
--
Pini Reznik
CTO

T. +31 (0) 6 317 99 811




Brian Grant
 

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


alexis richardson
 

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


Brian Grant
 

On Fri, Mar 31, 2017 at 11:10 AM, Alexis Richardson <alexis@...> 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.

I agree. As well as fast startup time and zero cost for idle workloads. 



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


Dan Kohn <dan@...>
 

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@linuxfoundation.org>
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


Mark Peek
 

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


Yaron Haviv
 

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


Mark Peek
 

+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


Clayton Coleman
 



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


Doug Davis <dug@...>
 

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




Yaron Haviv
 

‚Äú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

 


Doug Davis <dug@...>
 

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




Yaron Haviv
 

Doug, I agree, e.g. couple of 1st level topics to start with:

 

  1. 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.
  2. 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




Cathy zhang
 

+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