Re: The Cloud-Nativity of Serverless

Home Messages Hashtags Subgroups

#799

Re: The Cloud-Nativity of Serverless

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

Show quoted text

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Doug Davis via cncf-toc
Sent: Saturday, April 1, 2017 4:01 PM
To: Clayton Coleman <ccoleman@...>
Cc: cncf-toc <cncf-toc@...>
Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless

Glad to see lots of agreement on this thread and +1 to the idea of a WG/SIG.

One comment though, Ryan said:
> I agree with these, but I'd put performance as non-core because there are plenty of workloads where it doesn't matter all that much.

I'd put performance in the core, at least w.r.t. the container start-up time. If the performance of the infrastructure to setup the container to execute the function isn't fast enough then I think the uptake on this will be negatively impacted.

thanks
-Doug
_______________________________________________________
STSM | IBM Open Source, Cloud Architecture & Technology
(919) 254-6905 | IBM 444-6905 | dug@...
The more I'm around some people, the more I like my dog

Clayton Coleman via cncf-toc ---04/01/2017 09:24:39 AM---On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc < cncf-toc@...> wrote:

From: Clayton Coleman via cncf-toc <cncf-toc@...>
To: Brian Grant <briangrant@...>
Cc: cncf-toc <cncf-toc@...>
Date: 04/01/2017 09:24 AM
Subject: Re: [cncf-toc] The Cloud-Nativity of Serverless
Sent by: cncf-toc-bounces@...

On Mar 31, 2017, at 8:00 PM, Brian Grant via cncf-toc <cncf-toc@...> wrote:

I don't find the term "serverless" to be useful. It's too broad, and could encompass purely client-based computations and web hosting as well as FaaS.

I see Functions as a Service as an instance of Application Framework as a Service. Data-processing frameworks that support dynamic code loading and managed execution would also qualify. The services that we have today that support dynamically pushed code are natural evolutions of servlet engines, application frameworks, data-processing frameworks, and plugin-centric systems that have been developed over the past couple decades.

Even Functions as a Service specially addresses multiple overlapping areas:

Event-driven automation. People are using FaaS for simple automation tasks. For these scenarios, the most critical determinant of utility is relevant event sources. In the FaaS space, Openwhisk is most obviously aimed at this use case. Automation systems such as StackStorm are fairly similar. The main limitation of a system like Stackstorm is that the actions are pre-packaged plugins rather than dynamically provided functions. IFTTT and Microsoft Flow address points in this spectrum, as well, and configurable actuators capable of talking to any OpenAPI-compatible API are one reasonable method of linking triggers and actions.

I think this is one of the areas that the open source community could make the most impact in (relative to cloud platform implementations). Event bus and message bus are prevalent in many, many infrastructures, and FaaS practically requires easy and extensive adaptation of existing data stores to reach its potential. (This belongs under point three below for etl, but is really a larger security/interop challenge)

Extension implementations. Something to receive extension web hooks from some other service without the need to operate a full-blown application deployment. The main difference with the event-driven automation use case is that some other system defines the invocation conditions.
Data-driven processing and simple ETL workflows. Not unlike Bigtable coprocessors.
Rapid application development and deployment, especially for mobile apps, home assistants, and IoT. It's similar to website hosting, but for application frameworks / servlet engines. As with web app mashups, this model is facilitated by the availability of APIs for other services to do much of the heavy lifting. The line between this scenario and a full-blown PaaS is not about features, agility, the deployment model, or execution artifacts (most PaaSes support pushing code, and people load and run executable binaries on FaaS), but about who operates the deployed application servers.

Container-based technologies are still improving and I think you'll find that container-centric infrastructure will eventually provide most of the core infrastructure capabilities required by FaaS.

Because as you note later all FaaS infrastructure is complementary with the point of container infrastructure optimization - each layer can benefit from the same optimizations (anticipatory scaling, wake on request, data locality, slack capacity assignment, central shard assignment and hot sharding, etc). FaaS on Kube should be better than FaaS not on Kube (to an operations team)

Is FaaS "cloud native"? Yes.

Does FaaS make sense in local development, on prem, hybrid and multi-cloud scenarios? Yes, for all the same reasons that Kubernetes does.

On Fri, Mar 31, 2017 at 9:43 AM, Ryan S. Brown via cncf-toc <

cncf-toc@...

> wrote:

[inlined]

On Fri, Mar 31, 2017 at 11:37 AM, Anthony Skipper
<

anthony@...

> wrote:
> We would like to see a separate group working on serverless as well. At
> Galactic Fog we have had a serverless implementation on DCOS for about 6
> months, and we plan to release our Kubernetes native implementation in the
> next couple weeks in the runup to dockercon.
>
> From our perspective we would like the following things:
>
> Agreement on marketing terms. (Call it Serverless or Lambda, everyone
> hates FAAS, but serverless is problematic as well)

Agreement on these terms is probably a bit much to expect. For some
time I was hoping we'd settle on "Jeff". While I'm not a lawyer,
Lambda seems like the kind of thing that will turn into a trademark
issue at some point. I think we're stuck with serverless, and when
offering components that fit in a serverless stack we'll have to stick
with things like "serverless function runtime," FaaS, and similar with
a mind to two different audiences.

Audience A: Technical audience, knows serverless well, and wants to
know exactly what piece your project is providing. So you can say
things like "event router" and function runtime to explain where it
fits exactly. This audience also has some potential contributors in it
if the project is OSS.

Audience B: Thinks of serverless-the-concept as it relates to
developer experience, and would be looking to figure out what they can
do with it generally. The focus for those materials has to be on
distinguishing from plain containers, PaaS, etc more than on the
underlying thing your project is going to provide. Already it's
getting kind of muddy, since Amazon and others are rebranding other
aaS offerings as "serverless," such as DynamoDB.

> Agreement on core capabilities, from our perspective they are:
>
> Runtime Support
> API Gateway Support
> Config / Secret Capabilities
> Security Implementation
> Logging Support
> Monitoring Support
> Performance/Scalability Capabilities (eg. Gestalt and Fission are a couple
> order of magnitude faster than Amazon, and that changes the art of the
> possible)

I agree with these, but I'd put performance as non-core because there
are plenty of workloads where it doesn't matter all that much. Think
about the class of back-office examples that are common: transforming
streams, resizing images, propagating changes to other systems. As
long as they get done, the difference between 100ms and 1000ms can
pass unnoticed since each event is eventually spawning a new function,
and the queue/event system handles backpressure transparently.

Then there's the category of user-facing synchronous workloads that
you'd see an API Gateway used for, where perf matters and users just
abandon anything that's perceivably slow.

> None Core Capabilities
>
> Ability to inter-operate between serverless implementations (eg, migration
> between them, include up to ad back from public cloud)
> Lambda Chaining
> Data management capabilities (exposing filesystems or other services in)
> Making the implementation of the serveless solution portable across
> platforms.
> Data Layer Integration approaches.

I'd probably bump chaining up to core, since all but the very simplest
projects end up with a series of functions that either call each
other, or create events that invoke others.

> I wouldn't worry to much about the other big vendor stuff right now.
> Serverless is at such an early stage any R&D done by anyone is really
> helpful and not really competitive or problematic. (eg Openwhisk has
> really cool ideas, and Amazon's attempts to standardize lambda portability
> show an approach that is helpful for discussion)
>
>
> Regards,
> Anthony
>
>
>
>
> On Fri, Mar 31, 2017 at 11:17 AM, Ryan S. Brown via cncf-toc
> <

cncf-toc@...

> wrote:
>>
>> Hello all,
>>
>> If haven't heard Amazon&others raising a general ruckus about serverless
>> lately, I sincerely hope your vacation to the backwoods was relaxing.
>>
>> I'm Ryan, and I've been interested in FaaS/serverless for a while now.
>> Also CC'd on this message are Ben Kehoe (iRobot) and Peter Sbarski
>> (ServerlessConf/A Cloud Guru). Lately, it seems the open-source interest has
>> been picking up significantly in addition to all the use in the public
>> cloud. Just to name a few FaaS/serverless provider projects: Fission[1] &
>> Funktion[2] on Kubernetes, FaaS[3] on Swarm, and standalone OpenWhisk[4]
>> (primarily IBM-driven). Even Microsoft's Azure Functions is OSS.
>>
>> A cynical observer might say that the MS/IBM efforts are open to help
>> compensate for them starting so late relative to Lambda, but either way the
>> result is a lot of open or nominally open projects in the FaaS/serverless
>> area. And with cloud providers looking to embed their various FaaS deeper
>> into their clouds by integrating their FaaS with cloud-specific events,
>> making their FaaS the way into customizing how their infra reacts to events.
>>
>> So why am I writing this email? Well I've been thinking about serverless
>> as the next step in "cloud native" developer tooling. Look back to the state
>> of the art in the 00's and you'll see the beginnings of
>> autoscaling/immutable infrastructure, then move ahead a bit to containerized
>> applications, then container schedulers, and you can see a trend towards
>> shorter and shorter lifespans of persistent machines/processes.
>> Function-as-a-Service is another step in that direction where containers
>> live for seconds rather than persistently listening. This trajectory seems
>> pretty intuitive as a developer: as lower layers of the stack become more
>> standard I should be able to automate/outsource management of them.
>>
>> I'd like to help the TOC think about where (or whether) serverless/FaaS
>> should fit into the CNCF's plans for the future. Do you want to talk about
>> what serverless actually is? Figure out how various OSS fits into a
>> serverless ecosystem? Compare how FaaS provided in the public cloud differs
>> from what users need in a hybrid/on-prem environment? Ask away - Ben, Pete,
>> and I are all here to help out.
>>
>> Cheers,
>> Ryan
>>
>>
>>
>> 1:

http://fission.io/

>> 2:

https://funktion.fabric8.io/

>> 3:

http://blog.alexellis.io/functions-as-a-service/

>> 4:

https://developer.ibm.com/openwhisk/

>> 5:

https://azure.microsoft.com/en-us/services/functions/

>>
>> --
>> Ryan Brown / Senior Software Engineer / Red Hat, Inc.
>>
>> _______________________________________________
>> cncf-toc mailing list
>>

cncf-toc@...

https://lists.cncf.io/mailman/listinfo/cncf-toc