Draft design goals for CloudEvents specification

Signed-off-by: Sarah Allen <sarahallen@google.com>

about/design-goals.md

@@ -0,0 +1,29 @@
+# CloudEvents Specification Design Goals
+
+CloudEvents are typically used in a distributed system to allow for services to be loosely coupled during development, then then configured with tight-coupling for specific applications.
+
+The goal of the CloudEvents specification is to allow for different cloud providers to create interoperable event systems, that allow for third-party tools and services to provide:
+- new event sources
+- new event consumers
+- observability, such as monitoring, debugging and visualization,
+- developer tools and libraries
+
+Key properties of the system:
+- Source & action may be developed and deployed independently
+- Trigger configuration allows for actions to be invoked based on a condition (e.g. for a specific event type generated by a source, optionally filtered by specific attribute values, such as a Function which is invoked when an image is uploaded to specific S3 or Google Cloud Storage “bucket” path
+- Events are uniquely identified so that developers can write code that is idempotent
+- Common meta-data attributes allow for observability via tools that are developed without knowledge of the specific implementation of an event system
+- CloudEvents may be transported from source to action with different protocols.
+
+In order to achieve the above goals and desired system properties, the Serverless WG must agree on a common vocabulary with precise definitions describing the key elements of the system including:
+- Source
+- Action
+- Trigger: the condition that causes an event to be transmitted from source to action
+- Rule: the association of trigger + action
+
+In order to achieve the interoperability goals, the Serverless WG must describe:
+- One or more common architectures that are in active use today or planned to be built by WG members
+- How events are transported from source to action via at least one protocol
+- Whether a shared trigger specification is needed, or if runtime interoperaability can be achieved independently, then shared configuration and/or API definition can be addressed as follow-on work
+- Authorization model(s)
+