Proposed SIG-Serverless Charter

sig-serverless.md

CNCF Serverless SIG Charter

Introduction

This is the charter referred to in “CNCF SIGs” by the CNCF TOC, and consistent with the proposed SIG definition.

Borrowing from the Serverless Whitepaper, Serverless computing refers to the concept of building and running applications that do not require server management. Allowing developers to focus on writing their applications’ business logic rather than the complexities of the platform hosting/managing their applications. As such, this SIG will focus on technologies related to enabling this simplified developer experience.

Areas Considered In Scope

Technologies related to hosting, managing, developing and integrating of Serverless applications from an application developer's perspective. The following are example areas that are considered in scope:

• container hosting platforms that attempt to abstract their complexities away from the application developer
• orchestration and management of workloads running on those platforms from the application developer's perspective
• tooling to aid in the development and deployment of those workloads
• integration technologies that aim to promote interoperability between the various systems that an application developer may interact with during the management of their applications on those platforms
• workload interoperability - e.g. portability of functions, interaction with hosting environment/runtime
• interoperability and connectivity with backend services used by worloads

Areas Considered Out Of Scope

Anything not considered in scope above is out of scope. See also “Interfaces with Related Groups” below.

An example would include technology related to the inner-workings of a particular platform. For example, a new autoscaler for Kubernetes.

SIG Mission Statement

To enable application developers to more easily create, deploy and manage their applications without the need to become experts in the hosting technologies being used.

Developers should focus their attention on the development of their applications. When they are required to spend a significant portion of their time learning and interacting with the hosting platform of those applications then that is time that should have been spent working on their business objective.

To that end, the SIG will:

1. Provide valuable and unbiased information to the TOC, End Users and Projects of the CNCF regarding areas considered in scope (see above).
2. Collaborate effectively with other related groups (see below).
3. Help to maintain the continued health of the CNCF Projects deemed to be within the scope of this SIG (see below)
4. Identify and fill gaps in the landscape of CNCF Projects within scope either through encouragement of existing projects to join the CNCF or through development of new artifacts (e.g. specs, code, papers).
5. Maintain any "living" documentation, such as landscape and state of the community documents.

Specific SIG deliverables are as per the above, and the general SIG responsibilities set out by the CNCF TOC.

Current CNCF Projects Considered To Be Within The Scope Of This SIG

• CloudEvents
• Serverless Workflow
• CloudEvents Discovery API
• CloudEvents Subscription API

Interfaces With Other Related Groups

It is not always clear where the line is between Serverless and other cloud native hosting technologies, therefore the exact choice of a project being within scope of SIG-Serverless versus one of the other CNCF SIGs will need to be consider on a case by case basis. Often the decision might be based on the project's relationship to existing projects within the SIG.

• Several Kubernetes SIGs cover Kubernetes-specific workload, scheduling, autoscaling, execution and other related abstractions, interfaces, and implementations of these interfaces. We will maintain communication with these Kubernetes SIGs where needed. Our aim is to avoid unnecessary duplication of effort by the two groups and maintain clear and consistent messaging to our end user community and projects.
• CNCF Security SIG works on the more general area of cloud-native security including authentication, authorization, encryption, accounting, auditing, and related topics. We defer as much as possible to this group to deal with general security-related issues and liaise closely with them on how to deal with security areas where these arise.
• CNCF App Delivery SIG is focussed on the development, deployment, operation and testing of cloud-native applications. We collaborate with this SIG where it pertains to helping to ensure that the required underlying workload execution abstractions and mechanisms are suitably provided to support these application-level delivery needs.

Operating Model

This SIG follows the standard operating guidelines provided by the TOC unless otherwise stated here.

Current TOC Liaison: ????

Co-Chairs: Doug Davis, Mark Peek, Ken Owens

Tech Leads: Doug Davis, Mark Peek

Other named roles: None at present; will be identified as needed

Meeting Schedule

The CNCF SIG-Serverless group meets every Thursday at 12pm Eastern.

Zoom: https://zoom.us/my/cncfsigserverless

Mailing list: Join SIG-Serverless mailing list at lists.cncf.io

Slack channel: TBD

Awesome work :) What is the main difference of a WG and a SIG?

@jonatasbaldin not sure I have a great answer, but I believe that SIGs are meant to manage all of the work scoped to one particular domain. They were mainly established to help distribute the work of the TOC as they were a bit overloaded. In some ways, SIGs today overlap with what WGs used to do, which is part of the reason we're looking at SIG-Serverless as a replacement for (or morphing of) Serverless-WG. Where does this leave WGs in the future? I believe WGs will still exist but I think they'll be more focused and more short-lived with the goal of trying to address one particular question or task - at the discretion of its owning SIG. Hope that helps - if others have a different view please chime in.

check out.

wow, awesome! thanks @duglin for the comment :D

Couple of comments

1. It would be good to define "Serverless"
2. I think that "function signatures" as a method of portability might be too much detail to write into the charter. This has been an extremely contentious area in the work that I've done. Focusing on CloudEvents network protocol bindings as the unit of interpretability will I think be less controversial.

@mikehelmick I added a def'n of serverless to the intro - I think that helps it flow better, see what you think.
I also remove function signatures. I didn't add a reference to CE because as I was removing "function signatures", while I like your reasoning for removing fn sig, I also think that not picking a technology winner in the charter would be good and while I'm sure we all love CE, we shouldn't promote it in the charter as the winner :-)

thanks - LGTM