PRASHANT GULATI: Hello and welcome to Event-Driven
Microservices with Cloud Run.
My name is Prashant Gulati.
So how do you know if you're in the right session today?
You're in the right session today
If you're looking to learn more about working with events
for use cases and video analysis,
file conversion, new user sign up, application monitoring,
or hundreds of others, if you're looking
to learn about how to act on events originating from Cloud
Storage, BigQuery, or dozens of other Google Cloud sources,
and if you're looking to modernize
to event-driven architectures and improve both developer
productivity and your bottom line.
Let's get started.
I'm going to be covering four topics today.
We'll start by describing the rise of Microservices
and some of the problems inherent in them.
We'll then move on to describe event-driven architectures
and how they solve some of those problems.
We'll introduce you to Google Cloud's new offerings
in this space, Events for Cloud Run,
and events for Cloud Run for Anthos.
And we'll conclude by showing you a Sentiment Analysis
demo, which takes in a complex image
and performs Sentiment Analysis on it.
Let's start by describing the rise of microservices.
There are several architectural styles in software.
Monoliths, for instance.
Perhaps, your organization has monoliths.
We're going to take you on a journey today from Monoliths
to microservices to event-driven microservices.
Let's start with monoliths.
They're fairly easy to understand.
As you can see on the screen here,
here's an e-commerce store with six component services.
There's a few problems that are inherent in any monolith.
Scalability.
Component services scale as a group and not individually.
Extensibility.
It's hard to add or update services.
And lastly, coupling.
There are often coupled dependencies between services
that you have to deal with in a monolith.
So to address some of these problems,
you might want to chart a migration to microservices
by pulling out component services
into separate services.
Let's take a look at the example over here.
We've pulled out a couple of component services--
the newsletter and the shop.
As we continue this migration and pull out a third service,
you start to see the connections between the services develop.
As we pull out a fourth service, the connections between them
deepen further.
We've now completed the migration to microservices.
While we've started to address some of the issues
with scalability, extensibility, and coupling,
we haven't done so completely.
We've improved on scalability, but there's still
the question of whether the communication between services
is synchronous or asynchronous.
That makes a difference.
We've improved on extensibility.
However, the new services that we add
may still require that we make updates
to existing services that are going to communicate
with that new service.
And lastly, while we've made coupling looser,
it's possible that different services may still
have couple dependencies--
on a message cue, for instance, which
you may want to take a dependency on if you're
looking to protect against intermittent failure
of services.
In addition to the three problems
that we've only solved partially,
microservices also introduce three new problems.
For one, there's a spider web of point-to-point integrations
like you saw in the previous slide.
There is the potential for expensive inter-service
communication, especially if the communication between services
is pull-style, saved via polling.
There's also the potential for a non-uniform communication
format between services.
We continue our evolution onto event-driven architectures.
But first, let's start by describing, what is an event?
There's three concepts to think about here--
occurrences, events, and actions.
In the operation of a software system,
an occurrence is when something happens, a statement of fact
about something happening.
An event is a record expressing that occurrence
and its context.
And an action will take place based
on an occurrence, which is communicated to a service
through an event.
Now, events originate asynchronously.
And with events, a producer has no expectation
of how the event might be handled by a consumer.
Let's take a look at a typical event-driven architecture,
or an EDA.
Multiple Event Producers go ahead and produce events
and send them on to Event Intermediaries.
At the other end, Event Consumers
subscribe to the events in particular
that they're interested in from specific producers.
Now, EDAs solve several of the problems
that we identified earlier.
Let's start by looking at scalability.
Take a look at these two systems that you see in front of you.
One can handle 200 transactions a second,
and the second can handle 100 transactions a second.
Now, with just a microservices architecture
where the communication between them is synchronous,
a request response style, the weakest link
dictates the peak throughput of the system.
But if you then graduate onto event-driven microservices,
the weakest link now dictates the sustained throughput
of the system.
Let's take a look at extensibility
and how it's easier to add services
with event-driven architectures.
We have a couple of Event Producers
and a couple of Event Consumers.
We're going to go ahead and add another Event Consumer.
When we add an Event Consumer, no changes
need to be made to any producer, thus making extensibility
a lot easier.
Let me highlight some of the other benefits
of event-driven architectures.
We can now decouple from dependencies completely.
The Event Intermediary can handle
intermittent unavailability of services.
There's no more spider web.
No more point-to-point integrations.
Event Producers can just fire events and forget about them.
Events are pushed, and this replaces pull-based polling.
And lastly, there's an opportunity
to introduce a standardized format, a uniform communication
format between services.
For instance, Cloud Events format.
With an ideal event-driven architecture system,
users no longer have to be experts
in distributed computing.
They can take event ingestion, delivery, security,
authorization, observability, and error handling for granted
and just focus on their application code for their use
case.
This brings us to Google Cloud's new offerings in this space.
You're already familiar with some
of Google Cloud's offerings to help you with microservices.
Cloud Run.
Cloud Run helps you run any stateless container on Google's
fully managed infrastructure.
And there's Cloud Run for Anthos,
which helps you on any stateless container on Google Kubernetes
engine, is Knative conformant, and helps
you achieve portability to other clouds or on prem.
Today, we introduce to you two new capabilities
to help you with event-driven microservices,
Events for Cloud Run, and Events for Cloud Run for Anthos.
Both these capabilities help you easily build
event-driven architectures.
Let's take a look at both of these capabilities one
after the other.
With Events for Cloud Run, you can set up
triggers to act on events sourced from all Google Cloud
sources via Cloud Audit Logs--
for instance, Cloud storage, a popular Google Cloud Source,
via Cloud Audit Logs.
You can also act on events from custom applications that
publish events to Cloud PubSub.
Events for Cloud Run delivers these events
to Cloud Run targets.
Let's now talk about Events for Cloud Run for Anthos.
Events for Cloud run for Anthos is Knative
based and incorporates the concepts of Knative brokers
and triggers.
With Events for Cloud Run for Anthos,
you can act on events sourced from all Google Cloud
sources via Cloud Audit Logs, Cloud Storage and Cloud
Scheduler in particular, which are native integrations,
custom applications that are publishing events
to Cloud Pub/Sub, and also custom events.
You can target Cloud Run for Anthos targets, Kubernetes
services, and also any URL.
With both Events for Cloud Run and events
for Cloud Run for Anthos, they both handle event ingestion,
delivery, security, authorization, observability,
and error handling for you.
They both have the same delivery guarantees as Cloud Pub/Sub.
At least once delivery, for example.
They both provide on demand scalability and cost.
And you can operate both of them through a UI, CLI, or API
interface.
Both Events for Cloud Run and Events for Cloud Run for Anthos
deliver events in CloudEvents format.
This also allows you, the user, to use
CloudEvents available SDKs in multiple languages
to be able to work with your CloudEvents.
We also provide libraries to help you unmarshal the event
data within CloudEvents.
I'd now like to take you through a Sentiment Analysis demo,
showing you the use of Events for Cloud Run
and Events for Cloud Run for Anthos.
We're going to take a complex image
and process it with an event driven architecture system
that we're going to build.
For example, take a look at this image here of a family.
Now, the holidays bring out all kinds of different emotions
in different members of the family.
What we're going to try to do here is from an input image,
draw out each family member and determine what
their sentiments are, what their sentiment score
is, all using event-driven architectures.
Now, to accomplish such an event driven architecture,
there's a few microservices that we're going to need.
A Cloud Storage Bucket, a Firestore Database,
and a few different compute services.
Now, these can be Cloud Run services or Cloud Run
for Anthos services.
To start, we need one service which
can help us extract the bounding boxes of faces
from the original image.
We need another that can extract face images
from those bounding boxes.
A third that can run those faces through an open neural network
exchange model, and then generate an emotion
score from them.
A fourth that can write those scores to a Firestore database.
And a fifth to render a user interface.
Now, let's take a look at how we can
stitch these services together in
an event-driven architecture.
Let's go back to this diagram, which
you're familiar with from earlier in the presentation.
We have Event Producers and Event Consumers,
with an Event Intermediary in the middle.
Let's now bring in some of the microservices
we need for our specific demo.
Here, you see the Cloud Storage Bucket, the Firestore Database,
and the five compute services that we identified.
As a reminder, these can be Cloud Run,
Cloud Run for Anthos, or a combination of the two.
As we start to put this service together,
let's walk through the flow and start to stitch it together.
A user uploads an image to a Cloud Storage Bucket.
This should then fire an event to an Event Intermediary.
That event is then sent to the first compute service.
The first compute service then sends a custom event
published to Pub/Sub back to the Event Intermediary.
This, then, reaches the second service.
The second service extracts face images
and places them in a Cloud Storage
Bucket, which then fires another event back
to the Event Intermediary.
This then moves on to the third service,
which runs those faces through the open neural network
exchange model and generates the emotion scores.
An event is then sent to the Event Intermediary
once again, which then reaches the fourth compute service.
The fourth compute service writes a score
to the Firestore Database, which then
fires another event to the Event Intermediary
and updates the user interface.
I'm now going to show you a demo in which we've already
put together several of the components of the architecture
I described, but it's missing one trigger.
So we're going to wire up that trigger,
and then we're going to also show you the entire system
in operation.
We're now going to head to the user interface of one
of our Cloud Run services.
This is the second Cloud Run service,
and we need to add a trigger to it
to allow it to receive events from the first Cloud Run
service.
To do this, we're going to head to the trigger step.
We're going to start by clicking on Add Trigger.
We're asked to specify a trigger name.
We're going to leave the default suggested value as is.
We'll head to Event Type, where we're
going to pick Cloud Pub/Sub.
This allows us to receive events published as specific Cloud
Pub/Sub topics.
We're asked to select a Cloud Pub/Sub topic,
and I'm going to select one that I'd already created earlier.
As I click on Save, this will complete trigger creation
and complete the setup of our event driven architecture.
I am now ready to head over to our cloud storage
bucket, to which I'm going to add
the original image of the family that we showed you earlier.
Once again, here's the image of the family.
I'm going to take this and drag this into the Cloud Storage
Bucket.
Now that we've added this image to the Cloud Storage Bucket,
it's going to kick off a series of events
as we described in the setup earlier.
If all is well and working well, when I move over
to the next tab which represents the fifth Cloud Run
service for the user interface, we
should see images for each of the family
members along with their sentiment scores.
So let's go take a look.
Here we are.
You see images of each of the family members,
the two parents on the right, and the two children
on the left.
The parents have higher happiness scores.
Right after their happiness scores,
that have neutrality scores.
And the two children, as you can see
from their facial expressions, have higher neutrality scores
followed by sadness scores.
So what did we just see right now?
We created an event-driven, rapid autoscaling
scale-to-zero service.
We created an event trigger, and we
triggered CloudEvents to be sent to Cloud Run services.
There's a few key takeaways I'd like you to take away
from today's presentation.
You as a user can transform your company's IT systems
to enable real time business so your customers and business
users can get what they want when they want it.
And in doing so, this enables a layer of high value services
that really make a difference to the bottom line
of your business.
I invite you to try both offerings
we've discussed today.
Events for Cloud Run is in Private Preview,
and you can sign up by going to bit.ly/events-cr.
Events for Cloud Run for Anthos is also in Private Preview,
and you can access it bit.ly/events-cr-anthos.
Both offerings are coming to Public Preview
by the end of September of this year,
and we invite you to join us when
they come to Public Preview.
Once again, my name is Prashant Gulati.
My email address is my first name, last name, at Google.com.
I would love to hear from you comments, questions
and feedback.
Thank you very much.
I hope you enjoy the rest of Next.