Re: The Cloud-Nativity of Serverless

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) 




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.


cncf-toc mailing list

Join { to automatically receive all group messages.