Mete Atamel

Eventarc enables you to read events from Google Cloud sources (via its Audit Logs integration) and custom sources (via its Pub/Sub integration) and then route them to Cloud Run services.

https://storage.googleapis.com/gweb-cloudblog-publish/images/eventarc-architecture.max-2000x2000.png The event routing rules are defined with a trigger. In a trigger, you specify the right event filters such as service name, method name, resource (which effectively defines the event source) and the target of the events (which can only be a Cloud Run service as of today).

Over the past year, we (Mete and Guillaume) have developed a picture sharing application, named Pic-a-Daily, to showcase Google Cloud serverless technologies such as Cloud Functions, App Engine, and Cloud Run. Into the mix, we’ve thrown a pinch of Pub/Sub for interservice communication, a zest of Firestore for storing picture metadata, and a touch of machine learning for a little bit of magic.

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_Shqfx7L.max-1400x1400.png We also created a hands-on workshop to build the application, and slides with explanations of the technologies used. The workshop consists of codelabs that you can complete at your own pace. All the code is open source and available in a GitHub repository.

Back in October, we announced the public preview of Eventarc, as new eventing functionality that lets developers route events to Cloud Run services. In a previous post, we outlined more benefits of Eventarc: a unified eventing experience in Google Cloud, centralized event routing, consistency with eventing format, libraries and an ambitious long term vision.

Today, we’re happy to announce that Eventarc is now generally available. Developers can focus on writing code to handle events, while Eventarc takes care of the details of event ingestion, delivery, security, observability, and error handling.

I recently talked about orchestration versus choreography in connecting microservices and introduced Workflows for use cases that can benefit from a central orchestrator. I also mentioned Eventarc and Pub/Sub in the choreography camp for more loosely coupled event-driven architectures.

In this blog post, I talk more about the unified eventing experience by Eventarc.

What is Eventarc? We announced Eventarc back in October as a new eventing functionality that enables you to send events to Cloud Run from more than 60 Google Cloud sources. It works by reading Audit Logs from various sources and sending them to Cloud Run services as events in CloudEvents format. It can also read events from Pub/Sub topics for custom applications.

Going from a single monolithic application to a set of small, independent microservices has clear benefits. Microservices enable reusability, make it easier to change and scale apps on demand. At the same time, they introduce new challenges. No longer is there a single monolith with all the business logic neatly contained and services communicating with simple method calls. In the microservices world, communication has to go over the wire with REST or some kind of eventing mechanism and you need to find a way to get independent microservices to work toward a common goal.

Pic-a-Daily Serverless Workshop

As you might know, Guillaume Larforge and I have a Pic-a-Daily Serverless Workshop. In this workshop, we build a picture sharing application using Google Cloud serverless technologies such as Cloud Functions, App Engine, Cloud Run and more.

We recently added a new service to the workshop. In this blog post, I want to talk about the new service. I also want to talk about Eventarc and how it helped us to get events to the new service.

.NET 5.0 was released just a few days ago with many new features, improvements, C# 9 support, F# 5 support, and more. .NET 5.0 is the first release of the unified .NET vision that was announced last year. Going forward, there will be just one .NET targeting Windows, Linux, macOS, and more.

Google Cloud already has support for different versions of .NET. You can run traditional Windows based .NET apps on Windows Servers in Compute Engine or on Windows Containers in Google Kubernetes Engine (GKE). For modern Linux based containerized .NET apps, there’s more choice with App Engine (Flex), GKE and my favorite Cloud Run. Not to mention, the .NET Core 3.1 support in Cloud Functions is currently in preview for serverless .NET functions.

I got around to updating my Knative Tutorial from Knative v0.16.0 to the latest Knative Serving v0.18.0 release and Knative Eventing v0.18.1 release.

In this short blog post, I want to outline a couple of minor issues I encountered during my upgrade. Note that I skipped v0.17 altogether, some of these changes might have happened in that release.

Istio Installation

The biggest change I encountered is how Istio is installed for Knative. In previous releases, I simply pointed to the yaml files in the latest Istio version in third_party folder of Knative Serving.

Introduction

We recently announced a new feature, Events for Cloud Run for Anthos, to build event driven systems on Google Kubernetes Engine (GKE). In the announcement, we also stated that the solution is based on open-source Knative.

In this blog post, I want to further explain the relationship between this new feature and Knative. I also want to convince you that our solution is an easier way to deploy Knative compliant event consuming services on Google Cloud.

Building microservices on Google Kubernetes Engine (GKE) provides you with maximum flexibility to build your applications, while still benefiting from the scale and toolset that Google Cloud has to offer. But with great flexibility comes great responsibility. Orchestrating microservices can be difficult, requiring non-trivial implementation, customization, and maintenance of messaging systems.

Cloud Run for Anthos now includes an events feature that allows you to easily build event-driven systems on Google Cloud. Now in beta, Cloud Run for Anthos’ event feature assumes responsibility for the implementation and management of eventing infrastructure, so you don’t have to.