the cluster. Cloud Run on Anthos Deploy into Anthos, run serverless side-by-side with your existing workloads. Knative Everywhere Use the same APIs and tooling anywhere you run Kubernetes with Knative. Serverless containers with Knative and Cloud Run
for the application Configuration Current/desired state of an application Code & configuration separated (a la 12-factor) Revision Point in time snapshots for your code and configuration Route Maps traffic to revisions
coupled, event-driven services A number of different delivery methods Scales from just few events to live streams Uses standard CloudEvents Delivery Methods Event source(s) Event type(s) Event consumer(s)
to use Apache Camel components for pushing events into Knative Apache Kafka Brings Apache Kafka messages into Knative AWS SQS Brings AWS Simple Queue Service messages into Knative Cron Job Uses an in-memory timer to produce events on the specified Cron schedule. GCP PubSub Brings GCP PubSub messages into Knative GitHub Brings GitHub organization/repository events into Knative GitLab Brings GitLab repository events into Knative. Google Cloud Scheduler Google Cloud Scheduler events in Knative when jobs are triggered Google Cloud Storage Brings Google Cloud Storage bucket/object events into Knative Kubernetes Brings Kubernetes cluster/infrastructure events into Knative https://github.com/knative/docs/tree/master/docs/eventing/sources
and consumption of Google Cloud Platform events in Knative Ready to use event sources: 1. CloudPubSubSource 2. CloudStorageSource 3. CloudSchedulerSource 4. CloudAuditLogsSource 5. CloudBuildSource
services Private alpha since early 2020 as Events for Cloud Run Public GA as Eventarc in J Public GA as Eventarc in Jan 2021 Inspired by Knative Eventing an 202 Eventarc
your language cloudevents.io Google Events Library Type library for CloudEvent#data Event parsing libraries HTTP POST to Cloud Run URL HTTP body is a CloudEvent with event data ("binary" CloudEvent V1) (optional) (optional) github.com/googleapis/google-cloudevents
context) { // Read CloudEvent using CloudEvents SDK var cloudEvent = await context.Request.ReadCloudEventAsync(); // Read Pub/Sub message using Google.Events library for .NET var messagePublishedData = CloudEventConverters.ConvertCloudEventData<MessagePublishedData>(cloudEvent); // Extract the Pub/Sub message var pubSubMessage = messagePublishedData.Message;
➕ Services can be changed / scaled independently ➕ No single point of failure ➕ Events are useful to extend the system Cons ➖ Difficult to monitor the whole system ➖ Errors / retries / timeouts are hard ➖ The business flow is not captured explicitly ➖ Who ensures the whole transaction is successful?
and source controlled ➕ Each step can be monitored ➕ Errors / retries / timeouts are centralized ➕ Use simple REST, no need for events ➕ Services are still independent Cons ➖ A new orchestrator service to worry about ➖ Orchestrator could be a single point of failure ➖ Reliance on REST means more tight-coupling
exist in different bounded contexts Orchestration Can you describe the business logic in a flow chart? Are services closely related? Do you want to stay in REST?
CC Notifier Cloud Run Notify user Shipper Cloud Functions Prepare & ship items MAX: 5 times BACKOFF Payment Processor Cloud Run Authorize & charge CC Notifier Cloud Run Notify user Shipper Cloud Functions Prepare & ship items Pager Cloud Run Escalate to support SUCCESS ERROR Configurable retries Configurable exception handling
Shipper Cloud Functions Prepare & ship items Pager Cloud Run Escalate to support SUCCESS ERROR Out of Stock? No Request from the supplier Yes Read inventory Inventory DB Update inventory Inventory DB Supplier API