MARK MIRCHANDANI: Uh-oh.
I just got an email that our app is down.
Apparently, the database is hanging,
and we're losing transactions.
MATT DAY: If we set up a circuit breaker,
the app can respond to the error, rather than hanging.
MARK MIRCHANDANI: But then each of our services
has to implement its own logic for circuit breaking?
MATT DAY: This is an infrastructure problem.
Why don't we solve it with Kubernetes and Istio?
Let me show you.
[MUSIC PLAYING]
So here's my website.
As you can see, it's a one-stop shop for everything
you need to buy in order to be the best
hipster that you can be.
It's built on Google Kubernetes Engine,
with the optional Istio add-on enabled.
One of the neat things Istio gives
is visibility into everything that's going on.
In this case, I'm going to use the open source Kiali
console to show that.
As you can see, I have two microservices--
my front end, which is talking to Cloud Memorystore
for session caching, and my product catalog,
which is talking to Cloud SQL for product information,
pricing, and that kind of thing.
Istio has a concept of versions.
And I have two versions of my product catalog--
the working version and the broken version.
The broken version simulates the kind
of issues I've seen in the past, where service
takes too long to respond.
This could be due to a stressed out database
with millions of transactions waiting to be processed.
Perhaps there's infrastructure issues or networking problems.
Whatever it is, it's things that make my entire website fail.
I can tell you, if I went to a website that
took 15 plus seconds to render a web page every time I clicked
a link, I'd probably go to one of their competitors.
And that's exactly what my broken service simulates.
It takes a connection, holds it for 15 seconds,
and eventually replies.
MARK MIRCHANDANI: So even if a service is down,
we can have our application handle the error,
rather than just hanging?
MATT DAY: Right.
With Istio, you could enforce a blackout, rather than
a brownout, when the service is misbehaving.
In the past, you'd have had to include all sorts of libraries
to do that.
And it can get really complicated.
Let me show you how to do it.
So let's turn on that broken version,
send some traffic to it, and show how Istio can help.
One of the core concepts in Istio is a virtual service.
A virtual service defines where my traffic
is routed within the mesh.
So I'm going to say, send 100% of my traffic
to the broken version of my microservice.
If I apply that change and go back to my app and refresh it,
you'll see Chrome is hanging because my back end
service is hanging.
At this point, you've lost me as a customer.
But worse, if this was a payment service,
you may have even lost a sales record.
I've seen all of this and worse in the past
due to these kind of bugs.
So what can we do to mitigate it?
In the past, we might have used circuit breaker libraries.
The problem with this approach is that they're
very language-specific.
So if one app is written in Java and another in Go,
they'll have different libraries,
and sharing state between them is difficult.
Istio gives me a way to solve this with circuit breaker
patterns.
There are two cool things at play here.
The first is my destination rule.
The destination rule defines not only
the versions of my application, but also characteristics
on how they receive traffic.
In this case, I'm saying allow a maximum
of 200 pending requests.
But I could also put things like TCP session information
and all kinds of settings for my mesh
to understand what this app can deal with
and what its tolerances are.
In this case, I can never have more than 200 pending requests.
The 201st request will simply see my app is down.
A blackout, not a brownout.
The second thing I can do is modify my virtual service
to change the maximum amount of time a request can
wait for my app to reply.
By default, this could be virtually infinite.
But for some apps, that's not appropriate.
In the case of my catalog service,
I never want to wait for more than one second.
If I apply this change now, Istio,
with that maximum of one second, will
intercept the call, which is taking 15 seconds,
and say no, and instead give me a 503 gateway
error to my app, which I can deal with very easily,
and I can just show that my catalog is offline.
The cool thing about this is I've not
changed a single line of code.
And the very neat thing is in my console,
I have visibility of these broken requests.
I can see my service is down without waiting for my users
to go to a competitor.
MARK MIRCHANDANI: Great.
So now our application is able to properly handle the errors.
MATT DAY: Right, and you only need
to change a little bit of config.
Didn't have to touch any of your code.
MARK MIRCHANDANI: Don't forget to subscribe for more great
Google Cloud Platform content.
[MUSIC PLAYING]