MARTIN OMANDER: Hi, Jason!
What's the weather like in London?
JASON BERRYMAN: Well, Martin, it's the UK,
so of course it's raining outside.
How about you?
How's your weather in California?
MARTIN OMANDER: You know, I've had the curtains drawn all day
because I'm recording videos, so I really don't know.
But today, we're talking about how
to coordinate microservices.
Is it better to have a central coordinator-- orchestration--
or is it better for control to be
distributed among the services-- choreography?
JASON BERRYMAN: Well, with so many things in life,
it depends.
I'd be happy to share what I've learned
from a recent large project.
[MUSIC PLAYING]
MARTIN OMANDER: Thanks for joining me on the show, Jason.
You're a freelance Google Cloud architect at 418.dev?
JASON BERRYMAN: Yes, that's right.
I'm also a Google Developers expert for both Firebase
and Google Cloud platform, and I run the Google Developer
group in Milton Keynes, which is just outside London.
MARTIN OMANDER: Nice.
I love Google Developer groups.
They're great places for meeting other developers
and learning from each other.
Now, you're helping your parking company in the UK
build their system on top of Google Cloud platform, right?
JASON BERRYMAN: Yes.
The company collects vehicle movement and parking permit
data from car parks and motorway services.
MARTIN OMANDER: OK.
And what is that data used for?
JASON BERRYMAN: They use the data with serverless Google
Cloud products to provide analytics and metrics
to their customers.
The data can also be used for parking enforcement.
MARTIN OMANDER: Ooh, you mentioned serverless.
I love that stuff.
Why did they pick serverless?
JASON BERRYMAN: They're using serverless
so that they can focus their engineering
hours on new feature development,
and to minimize the operations work for their running systems.
MARTIN OMANDER: Got it.
Now there are two ways of coordinating microservices.
Orchestration-- a central coordinator
calls all the microservices in the right order,
or choreography-- microservices send and receive
events and act on them, so control is distributed.
Which one did you pick for the parking company, Jason?
JASON BERRYMAN: Well, each one has particular strengths
and weaknesses.
So we used both.
MARTIN OMANDER: Hmm.
Tell me more about that.
JASON BERRYMAN: Well, for example,
when a car enters a parking lot, a camera
takes a picture of their license plate.
The picture of the vehicle going in
gets matched with the picture of the vehicle going out.
And that matched visit then gets linked to one or more parking
permits.
MARTIN OMANDER: Hmm, that sounds kind of complicated.
JASON BERRYMAN: Yes.
And to make it simpler, we have multiple services, each one
doing part of the work.
So for example, we've got one service which
ingests the data from the cameras
and passes it through the visit-matching service,
then another one which ingests the permit data
and matches it with the visits.
MARTIN OMANDER: Got it.
Now, how do you coordinate these services?
I imagine the camera ingestion service
needs to let the matching service know that a vehicle has
entered or exited?
JASON BERRYMAN: Well, we use orchestration,
where a central controller calls a series of services
in a pipeline and returns a result.
MARTIN OMANDER: OK.
That sounds pretty straightforward.
It's nice to have control of the business logic in one place,
right?
JASON BERRYMAN: Yes.
But sometimes, that isn't optimal.
We are using a NoSQL document database
that is optimized for reads.
So we can sometimes need to normalize data.
For example, an administrator may update the expiry date
for a whole group of parking permits.
If the expiry date has been extended,
a visit that was beyond the expiry date
may now be within it.
So the driver shouldn't have to pay a parking penalty charge.
MARTIN OMANDER: Everyone hates paying parking penalties,
especially if their permit was just extended.
Now, how do you prevent that?
JASON BERRYMAN: When the permit group is updated,
we trigger updates of all the permits in that group.
This, in turn, means that we have
to match the permits against the visits again.
MARTIN OMANDER: OK.
But why can't you use a central coordinator for this?
JASON BERRYMAN: If we only want to change
the expiry date of one permit, we
don't need to update any other permits--
we only need to trigger the visit-matching again.
A central coordinator would become very complex
if it should be able to handle both updates to many permits
and updates just to individual permits.
MARTIN OMANDER: Ah, I see.
So if you don't use orchestration,
what do you use instead?
JASON BERRYMAN: Then we use the other method, choreography,
where each service receives messages,
takes action on those messages, and sends
new messages to the other services.
MARTIN OMANDER: So in what situations
do you pick orchestration, and when do you
pick choreography instead?
JASON BERRYMAN: When the process is always the same,
orchestration shines.
For example, when a car enters, we always
save the raw camera data.
The data is transformed from each camera's manufactured,
proprietary format to our standard data format.
And then we extract the images from that
and save them into Google Cloud Storage.
Finally, we send the event data to Cloud Pub/Sub for processing
further down the pipeline.
MARTIN OMANDER: That makes sense.
And when do you use choreography?
JASON BERRYMAN: When we have services
which may form part of a workflow,
but may also be triggered individually.
A good example is the permit group scenario
we talked about earlier.
MARTIN OMANDER: Got it.
Now, it sounds like choreography is
based on having many triggers.
Is it messy to have lots of triggers all over the system?
How do you manage that complexity?
JASON BERRYMAN: If you're using Cloud Functions or Cloud Run
services directly in Google Cloud,
it's really essential to maintain good documentation
and use a tool like Deployment Manager or Terraform
to deploy them.
However, if you're using the Firebase suite,
it's much easier to develop, test, and deploy
your Cloud Functions.
There's even a great local emulator.
MARTIN OMANDER: OK.
Does that mean that you prefer to use Cloud Functions
for Firebase all the time?
JASON BERRYMAN: Cloud Functions for Firebase only support
Node.js and TypeScript, which is great for web developers,
but if your team uses another language--
such as Go or Python--
it may not be such a great fit.
MARTIN OMANDER: Got it.
And which Google products do you recommend
for orchestration and for choreography, respectively?
JASON BERRYMAN: For orchestration, Workflows
is a great product for designing orchestration pipelines.
Workflows can be triggered by other services,
such as Cloud Functions, Cloud Run, or Cloud Scheduler.
For choreography, you can use Eventarc
to trigger individual Cloud Run or Cloud Function services,
based on individual events.
However, there are some services,
like Cloud Firestore and Cloud Storage,
which can trigger Cloud Functions directly
without Eventarc, whenever an event happens.
MARTIN OMANDER: OK.
And to recap, when would you recommend
using orchestration versus a choreography architecture?
JASON BERRYMAN: If you're developing
a traditional n-tier system on Google Cloud,
it's probably best to use the orchestration model.
However, if you're building a user
interface-focused application with something
like the Firebase suite, this is where choreography works really
well.
However, there may be times that you
need to create a hybrid app, in which case,
you can leverage the best of both worlds.
MARTIN OMANDER: The best of both worlds--
I like that.
Thank you for joining me and sharing
your real-world experience, Jason.
JASON BERRYMAN: Happy to do it.
MARTIN OMANDER: And thank you, everyone, for watching.
If you have any questions for Jason or me,
add a comment below.
Also, let me know if there are other serverless topics you'd
like to see in future episodes.
Bye for now.
[MUSIC PLAYING]