SANDEEP DINESH: All right, good morning.

My name is Sandeep.

Today, I want to talk to you about microservices

with Kubernetes and Istio.

So I'm a developer advocate on the Google Cloud.

I've been working with Kubernetes for the past three

years.

It's grown a lot.

And Istio is the next new hot thing coming out,

so you're all here to learn about it.

So let's go.

Because we all know microservices are awesome--

when you have a traditional application, like a monolith,

you'd have all of your logic in one app,

so a Java app, Ruby app, node, whatever.

You would have all the code in your one app.

It would do all the parts.

Maybe you're using object orientation,

so you have different classes that do different things.

But at the end of the day, it's like one big program

that does all the stuff.

And there's a lot of advantages to doing this monolithic type

of development-- it's easier to debug, it's easier to deploy.

You just have one thing, you just push it out,

and you're done.

And then you have a really small team,

and you have a very small app, it's really easy to do.

But the problem with the monolith

comes when your app starts to grow a little bigger.

So now you have all of these things

and all these different pieces.

But you still have one app that's doing all of it.

So any time you want to make a change in invoicing, that

means you have to redeploy the whole thing,

even though the ETL pipeline might

have not been affected at all.

And maybe the invoicing part is really good to be done in Java,

the ETL pipeline you want to use Python, and the front end,

you want to use Node.js.

But if you have a monolithic app, you can't really do that.

You're kind of stuck into using one language.

So a team that wants to make an update to one little part

has to touch the whole thing, and things

start to get really hairy really quickly.

So with microservices, each one of these

becomes its own individual component

that can be written in its own language, that can be updated

and deployed independently of the others.

And so this gives you a lot more agility, a lot more

flexibility, a lot more speed, and a lot more cool

things like that.

And so you're like, yes, that sounds really good, why

isn't anyone using monoliths?

Because once you start growing even bigger,

it gets even more complicated.

Honestly, a monolith would fall apart at this point too.

But even all the advantages of the microservice

start to get really hard to manage,

because now you don't have just 20 services,

you have 2,000 microservices.

And how do you know which one talks to which one

and how the intricate spider web of connections even works?

You might have a single request that

comes into your load balancer that

gets sent to like 20,000 different microservices

and then all the way back up.

And anywhere that chain breaks, your whole application

looks like it's broken.

And so debugging this becomes super hard.

Deploying things, making sure everything's in lockstep

with each other, it becomes really

difficult to try to manage this huge stack of services.

So are microservices terrible?

Maybe, but we can use a lot of tooling to try

to make them more manageable.

So let's use tools to automate this infrastructure components,

automate the networking components,

automate the management side of things.

And so when you look at a monolith versus a microservice,

they both have a lot of complexity.

The difference is-- and unless you know something

that I don't, there is no tools out there

that automatically write code for you

and can maintain a 2 million line Java app, right?

It's like some magic AI that can write code,

we'd all be out of jobs maybe in a few years.

But now we do have tools like Kubernetes, like Docker,

like Istio, like Google Cloud that

can automate infrastructure a lot more easily.

So a lot of the issues that we have with microservice

can be automated away.

So let's take a look at some of those tools.

So how many people are familiar with Docker?

I expect a lot of hands to go up.

So for those of you who are not familiar with Docker,

Docker is basically a way to package your application.

So it doesn't matter if you're writing Node code, Python,

Java, whatever.

It doesn't matter if you have ImageMagick,

some random library that some 13-year-old kid in Ukraine

compiled-- doesn't matter, you put it

in your Docker container, and you're good to go.

All you have to do is care about running the container,

you don't have to care about running what's inside of it.

So basically, you take your code and your dependencies,

and you put it into some sort of generic container format.

And so it doesn't matter what's inside.

As long as you can run a container,

you can run all the containers.

So now you have a container, you've

got to actually run it on your cluster, because logging

into a single machine, and then running Docker run,

and then doing that 1,000 times, it seems like a waste of time

to me.

So instead, we can use something like Kubernetes,

which is a container orchestration system.

And what we can do with that is we can say,

hey Kubernetes, run this container like five times

somewhere in my cluster.

So what it'll do is it'll run your containers for you

automatically.

And so let's say you wanted to run

this container, that container, that container,

and that container, and you want two copies of each.

You just tell Kubernetes that, and it figures out

how to run them.

And so the really nice thing about this

is if a server crashes, it will figure out

that the server crashed and run them somewhere else.

If an application crashes, it'll figure that out.

If you want to scale it up, you want to go from two copies

to four copies, you can say, hey, make it four,

and it'll spin up two more.

You want to go down to one, because you

want to save some money, you can say, hey, make one.

It will remove three.

And so this is like a declarative syntax

that makes it really easy to manage these containers running

on your cluster.

You might have thousands of these running.

Trying to do it manually is going to be impossible.

And how many people have heard of Kubernetes.

And keep your hands up if you've used it before.

About half, OK, cool.

But that's kind of just a starting point.

Now that you have these containers running,

you actually have to manage the services,

because you have a container A talking to container B talking

to container C talking to container D,

how do you manage that set of points

going between each other?

How do you set rules on who can talk

to who, who can talk to what, how many tries should you have,

how much network traffic should you send?

All this kind of stuff becomes really complicated,

and that's where Istio comes into play.

So Istio is a service mesh, which at the end of the day,

it means that it manages your services and the connections

that they make between themselves.

So if you look at it, we take orchestration,

and we go to management and communication.

So you want to manage how these services

interact with each other, because that's

what really causes microservices to be so useful,

is the communication between each other.

You can reuse one service, it can

talk to three different ones, give the same information,

you can mix and match, you can do all

these really powerful things.

But it becomes hard to really understand what's happening,

and Istio makes it a lot easier to understand what's happening

and control what's happening.

So that's enough of me just talking about random things.

Let's actually move to a demo.

And if we can go to the screen, thank you very much, OK,

and I can't see anything.

Let me-- sweet.

So what we're going to do first--

actually, can we go back to the slides real quick?

I didn't tell you what we're going to do.

So what we're going to do is walk through

the end-to-end story of taking an app

and making it into a microservice.

So we're going to take an app, put it into a container,

run that container locally, store

the container on the cloud.

Then, we're going to create a Kubernetes cluster,

run our app on that cluster, then scale it out.

And then, we're going to do something a little bit more

interesting, we're going to run multiple apps that

work together, a true microservices services pattern.

And then, we're going to monitor and manage them with Istio.

Awesome.

So let's move back to the demo.

So here, I am using Google Cloud Shell.

If you haven't used it before, it's

basically a free VM in the cloud that lets

you do your development work.

I'm on a Chromebook right now running the dev build.

If it all crashes, we're going to like jumping jacks

until it comes back or something, I don't know.

It happens before.

So basically, here I have some code.

It's a little Node.js application.

If you don't know JavaScript, that's fine.

It's a really simple app.

Basically, it's a web server that listens to slash.

And it will basically ping a downstream.

So in this case, it'll ping time.jsontest.com.

And then, it'll concatenate that response,

and then send it to us.

So let's run this locally right now.

Nope, don't want node modules.

OK, internet-- so if I go npm-start--

let's see what happens.

Cool.

So it's listening on port 3000.

So I will-- that's fine, I'll do this.

Let's go to port 3000.

So on Cloud Shell, we can do a web preview,

so it looks like we're basically running a local machine.

Awesome.

So you can see here that we go to time.jsontest.com,

and we print out our current service name, which

is test-1 version 1.

And we're seeing the current time.

So if I refresh this, the time will change.

Awesome, cool.

So now, let's take this and put it into a Docker container.

So to make a Docker container, basically what we do is,

we make something called a Docker file.

So a Docker file is basically a set of instructions

that creates this endpoint.

So you can almost think of it like a bash script,

it's basically what it is.

So here we start with node/8/alpine.

So that's kind of a base image.

It gives us a bunch of the Node stuff out of the box,

so we don't have to worry about installing Node.js.

Then, we copy in our package.json,

which has our dependencies.

Run npm install to install those dependencies,