Mete Atamel

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.

Challenges in connecting services

When I think about my recent projects, I probably spent half of my time coding new services and the other half in connecting services. Service A calling Service B, or Service C calling an external service and using the result to feed into another Service D.

Connecting services is one of those things that ‘should be easy’ but in reality, it takes a lot of time and effort. You need to figure out a common connection format for services to use, make the connection, parse the results, and pass the results on. I’m not even mentioning error handling, retries and all those production readiness type features that you ultimately need to do.

My colleague Felipe Hoffa recently published a blog post titled Get started with BigQuery and dbt, the easy way. More specifically, he showed how to install dbt in Google Cloud Shell, configure it and manually run it to create a temporary dataset in BigQuery. This is great for testing dbt + BigQuery but how do you run this kind of setup in production?

dbt documentation states that Running dbt in production simply means setting up a system to run a dbt job on a schedule, rather than running dbt commands manually from the command line.