MARTIN: Hey, [? Meta. ?] I heard you built a cool application
recently.
SPEAKER: Hi, Martin.
Yes, my colleague Guillaume and I built a serverless app.
It has multiple [INAUDIBLE] services communicating
in a nice choreography.
MARTIN: Choreography?
Can you explain that a little?
SPEAKER: Sure.
When you have a set of [INAUDIBLE] services,
how do you get those [INAUDIBLE] services
to interact with each other toward a common goal?
There are two approaches, choreography and orchestration.
[MUSIC PLAYING]
In choreography, each service works independently
and interacts with other services in a loosely coupled
way through events.
In orchestration, there is a central orchestrator
controlling all interactions between services.
In our app called [? Picadaily, ?] we
decided to go with choreography.
MARTIN: [? Picadaily, ?] what does that mean?
SPEAKER: Good question.
It's a picture-sharing app.
We built it as a prototype for a customer in London.
We combined Picadilly Circus from London
with picture sharing and decided to call it [? Picadaily. ?]
MARTIN: Oh, cool.
Can I see a demo, [INAUDIBLE]?
SPEAKER: Of course.
Let's take a look.
I already have some pictures uploaded in the app.
Under each picture, you can see some labels.
These are labels extracted by Vision API telling us
what the picture is about.
Around each picture, you can also see a colored border.
This is the dominant color of the picture, again extracted
by the Vision API.
The app also creates a collage of four most recent pictures.
And you can see that under the Collage tab.
MARTIN: Oh, nice app.
So can you tell us what's happening behind the scenes
and how you used this choreography pattern?
SPEAKER: Let's look at that architecture diagram.
First, users upload pictures to a Cloud Storage bucket
using an App Engine frontend.
That triggers an event to a cloud function.
This cloud function uses Vision API
to extract labels and colors of the image
and saves them to Cloud Firestore.
The same event triggers a Cloud Run service
that creates a thumbnail of the image.
There is a second Cloud Run service
that gets triggered by Cloud Scheduler
to create a collage of four most-recent pictures
on a schedule.
Finally, a third Cloud Run service
gets triggered by deletion events.
It does some cleanup after an image is deleted.
We are using built-in events for cloud functions
and Event [INAUDIBLE] for Cloud Run.
The whole architecture is event driven,
also known as choreography.
MARTIN: I see.
So what are the pros and cons of choreography?
SPEAKER: Yeah, in choreography, services are loosely coupled.
And because they are loosely coupled,
they can be changed and scaled independently.
If a service fails, the rest of the services
can still send and receive events,
so there is no single point of failure.
And if you want to add a new service
or remove an existing service to a new domain,
eventing makes that really easy.
MARTIN: All right, so then how do you monitor
event-driven systems like this?
SPEAKER: Well, with all the events flying around,
it's actually quite hard to monitor event-driven systems.
It's also not so easy to catch errors or apply global error
and retry policies.
MARTIN: Mmm, I see.
And where is the business logic captured?
SPEAKER: Business logic ends up being a side
effect of the architecture.
It's spread out to each service.
And there is no single central place that you can point to.
MARTIN: Got it.
So can we fix these cons somehow?
SPEAKER: Yes, we can.
Need to keep the loosely coupled nature
of event-driven services, but also bring some structure
in the flow of events.
We need some kind of an orchestrator.
Check out the next episode for details.
MARTIN: Cool, Thanks, [INAUDIBLE]..
And thank you, everyone, for watching.
If you want to build this app, there
is a hands-on workshop with a series of labs.
The code is open source on GitHub as well.
All the links are in the show notes.
Bye.
[MUSIC PLAYING]