Before we get into the gory details of the sample application,
let's make sure we understand why it was designed the way it was.
It's always best to consult with an expert.
So, let's ask Adrian Cockcroft about the evolution of the applications.
Hi, Adrian.
>> Hi, Kevin.
>> Thanks for being here.
Adrian is the former cloud architect of Netflix and
the guy who Kelsey says made micro services mainstream.
What have you doing since you left Netflix?
>> So I work for
a venture capital company Battery Ventures about last two years.
What I mostly do is I help up a portfolio companies help with
the technology consult with them and spend time looking for
interesting new companies to invest in.
>> Very cool, very cool.
Well, let's get right into it.
Over the last decade or so, there's been a ton happening in application space.
Can we talk about some of those changes?
>> Well if you think about the way things were put together years ago,
we had huge applications.
Think of 5 million lines of Java or something like that, and it would take
I was to just do a build and then you'd have to go and find somewhere to run it
and it would take a long time to work through all these things.
So typically you would release software relatively infrequently,
because it was a lot of work to do it, right?
What's happened more recently is that we've broken the software into smaller
and smaller chunks.
So part of micro services is making the chunk smaller.
So if your build time is now going from hours to seconds and then you wrap it in
a container and you deploy the container it takes seconds to do a deployment.
If you're doing it yourself and you're doing it, you write some two
piece of code you think that should work you put it through and test it and
it takes seconds to do, then you want to do that as often as makes sense.
You don't want to wait a month or three months to release your code.
>> Is that why people have been using though?
>> So the main reason for micro services is speeding up development.
If you think if you go to let's say one hundred people building a monolithic
application and somebody checks in something that's broken.
And then in testing they find it's broken that delays the release
for a week.
99 people work didn't get out, right, or
you put it at production it blows up you have to roll it back another week or so.
So what happens when you have too many people contributing to a single large
piece of code is that any small thing that blocks it is blocking huge amounts
of work from getting out.
And you've created a choke point that overly coordinates everything.
So breaking it into micro services is really about freeing up
everybody to run at their own speed.
You can have somebody with a brand new thing they've just started building,
they might do ten releases a day as they're just trying to get it
into shape.
Something else that's very mature might be updating once a month.
Other pieces in between, right?
>> Right.
So then how do you coordinate all those pieces that are out there?
>> You don't coordinate, right?
So if you coordinate them you're going back to the monolith right.
And that's what slows things down so
the point really is to let everybody release on their own cycle
which means you need to make sure that the interfaces are relatively stable.
And you can deploy any piece of it independently of any other piece
typically without sort of asking permission.
But you typically let people know.
>> Okay, that makes a lot of sense.
So then what about all the infrastructure that goes into
being able to roll back, deploy, monitor or test these?
>> You need a lot of automation to do it effectively.
So think of what used to be meetings with operations teams
as being turned into APIs and automation and scripts.
Right, so the exact way you can figure something complicated might be like
a Chef script or something like that does all of the set up on something or
it might be baked into a container.
If it say the chunk of code that you want to deploy.
So those sorts of things will all tie together and
then if you want to coordinate a lot of things and release them at once,
then you need some sort of container scheduler with
some way to compose them together and link everything together.
So like a Docker compose file, or a kubernetes configuration file.
>> Thank you, I've learned a lot.
Thank you so much Adrian.
>> Okay, thanks very much, cheers.
>> After talking with Adrian it seems like we need to explore this micro
services pattern more.