- Good morning everyone and thank you so

much for coming.

And thank you for having me here at GOTO Amsterdam

I'm very, very happy to be here.

My name is Ray, I'm a developer advocate

for the Google Cloud Platform.

And there are two things that I do, that I enjoy doing.

Number one is I love to bring some of the latest

and greatest technology from Google that

we have to offer to developers all around the world.

And the second thing I love to do is to hear about

your experiences and your feedback about the session

today upon the technology

I'm going to show you today.

And also about the Google Cloud Platform as well.

And the best way to reach me is on Twitter

@saturnism, that is my Twitter handle.

So if you have any questions, please feel free

to reach out from there.

An aspect of technology, I mean I've been

doing technology for a very long time, 22 plus years or so.

And prior to Google, I was working at

an open source company.

Prior to that I was at a consulting company.

But the other true passion of mine is actually traveling.

I love to travel and I often take photographs as well.

And if you'd like to see some of the photos in places

I've been to, feel free to check out my Flickr at

flickr.com/saturnism as well.

If you have any questions about these photos, especially

where I'm holding a compass in the middle of the desert.

I don't have the time to talk about it today.

But, I think my sound just went away.

There you go.

But if you have time, just come up and ask me about

this story and what it's about.

So I'm here to talk about microservices today.

And I'm assuming that many of you

have already heard of microservices, right?

How many people here knows about microservices?

Yeah, I know, I know.

So I'm not here to talk about the theories behind it.

I'm not here to convince you one way or the other of

what you should be doing.

But, if you do want to explore and create microservices

on Azure, here are a few things I'd like to share.

And this is going to be mostly a how-to and experiences

that we are happy to share with everyone.

The first problem that you're going to run into

is that as you are decomposing or as you are

creating a new application, new system with microservices.

The first problem you're going to run into is

there are going to be so many services.

If you decompose a simple application into say two services.

You have the front end,

and you have like multiple back ends, say two back ends.

And that's already three instances of your application

you have to deploy and manage; rather than just one.

And of course for redundancy reasons, you probably have

multiple instances of each of those services.

Well and now you're looking at potentially a

multiplication problem.

You have three different services, you have to deploy

two each, that's six you already have to manage.

Well two is probably not enough.

In my scale, some of these layer out more than the other,

and eventually you're going to see maybe 30, you know,

40, 100, instances that you all have to deploy and manage.

And that will be fun.

And the traditional way of managing these services

just don't work anymore.

Why?

Well typically what's gonna happen is that before

your project even starts, maybe even now.

You have to request the servers to be procured

Right I don't know if that happened to you,

but when I was doing my project as a consultant,

I have to order the number of servers

even before the project starts.

Maybe nine months before the project finishes.

And then the servers would come in

and what I have do is do what?

I have to write the little documentation that's

very, very low of how you are able to install the servers.

And put the right components onto them,

and then finally deploy out your application

So like the company insisted that you do a piece you

have to install.

How you want to configure the hosting, the network,

the firewall, and then you probably lay down like

you're using a Java application,

you lay down the application server,

like Tomcat or WebLogic or whatever.

And then you configure it, and finally you deploy your

application onto it.

And then very quickly, you're going to find out that the

group woman probably doesn't work the very first time.

How many people have that happen to them before?

Yeah, I though so.

And the other problem you're going to find out,

is that in that in the production environment, you are going

to run into the trouble where it just doesn't work.

And it works in your house of set up production.

Or how many people have that happen to them as well?

Yeah, (laughs) it happens all the time.

And the problem with that is that usually that this

long and complicated procedure is either done through

manually, where somebody actually follows it to

create that environment.

And it's not very consistent.

And if you're scripted also, you have to write that script.

And if you make any mistake in that script, then you're

also going to run into troubles.

And those scripts may even run differently from

environment to environment.

So one of the first things that we need to solve

is how do you actually deploy the same application

multiple times at this scalable fashion?

And one of the first things that you

need to look into of course, is the container.

How many people here know about back end containers?

Oh everyone, yay!

All right, so not going to into those in detail,

but just remember--

(disruptive scuffling)

Hello, hi.

(laughs)

Just remember that

if you're using containers your back end--

(disruptive scuffling)

The insulation procedures in a sequential order.

Just checking if there's another sound, yeah?

And that is still that kind of thing in terms of

what you want to run.

And that image can be deployed anywhere else.

And you can very quickly send out new application instances

very, very quickly.

The other problem you're going to see is that

if you have so many services,

you don't want to put all of them individually

one on a single machine, right?

Because if you have 100 servers,

you don't want to have 100 machines.

So what you need to do is to bean pack them as

efficiently as possible into a single,

or the fewest machine possible, so that you have

less infrastucture to manage.

And when you do that, then you're going to run

into issues where occasionally you may have multiple

instances on the same machine.

The first thing you're going to run into is

the port conflicts.

And you want to avoid those as much as possible.

And then you have other challenges as well.

How do you make sure that they're all up and running?

There are so many to monitor.

How do you do that?

You cannot do that manually, of course.

You need to be able to check the health

of these systems and individual services,

so that when they have issues,

maybe you need to restart it.

And then again, you don't want to do it mentally.

You might want to do this automatically as well.

And one particular challenge that I see

and they need to ask me is about environments.

If you have say 30, 20 services in your environment

that you have to run and manage.

How do you create more of these environments

and reproduce it in a consistent fashion?

Remember, deploying one application is hard enough

when you don't have the right tooling to do so.

You'll embrace your hand.

Now you're going to be dealing with hundreds of them,

and you have to think about the tools

that you're going to use.

So today is all about the tools I'm going to share.

Many of the dotcoms, the technology companies,

have the tools to this, including Google of course.

And I think it's partially what makes microservices

architecture successful.

If you actually go into this architecture without

the right tooling, you may actually eventually find

yourself in a situation that you just simply

cannot manage any of these at scale.

So at Google, just remember this.

Everything at Google, all open services that we offer,

including Search, YouTube, Gmail.

I'm assuming everyone in here uses some of these things,

they all run in containers in Google.

And we're not using docker containers,

but we're using the fundamental container technology.

In fact, Google contributed the fundamental technology

that makes containers possible, which is called cgroups.

We contributed cgroups into the Linux credo

many, many years ago.

And that is the fundamental technology that all of the new

container products are kind of using today.

At Google, we launched about

two billion containers per week.

Now this number is not as impressive as it sounds.

Why, because this is the US billion.

It's not the European billion.

I know there's a very big difference.

(laughing) Yeah I know.

It's not two million million,

it's only two thousand million.

It's not, yeah there's a worldwide huge difference here,

but we know how to manage containers.

We know how to manage all services at scale.

This is what we do at Google, as engineers.

We cannot possibly deploy the application

the traditional way, that is why,

this is what we do.

If I have a Hello service, Hello application .

A very easy one.

It's the only one I could write.

Rather than deploying into individual machines ourselves

or with a script of some sort specifically designed for

those machines.

We deploy to a target of a cell.

A cell is really just a cluster of machines.

And a single cluster of machines at Google like single cell

can be composed of up to 10,000 machines, okay?

So we don't deal with each machine individually,

'cause that would be just way too many.

But what we do is we run tools to do this for me.

We can say how many veers across are to deploy to?

Go figure it out.

We specify the binary number we want to deploy.

These are potentially static binaries that can just be

copied and deployed on any of the servers.

We can specify arguments, but most importantly

we are able to specify the resource requirements.

And this is where containerization is going to be

really helpful because when running multiple

services, multiple applications,

you don't want them to step over each other's toes

when they are fighting and competing for resources, right?

You don't want one wrong way service to take 100% of the CPU

and like all of the other applications

just don't work anymore.

So with resource isolation, you're able to contain them

so that they don't exceed their boundaries.