WEBVTT
00:00:03.482 --> 00:00:05.432
Hello and welcome.
My name is Matt McSpirit,
00:00:05.432 --> 00:00:07.514
technical evangelist
for our data center technologies
00:00:07.514 --> 00:00:09.617
here at Microsoft,
and today we're going to be talking
00:00:09.617 --> 00:00:12.412
all about Containers.
I'm joined my Taylor Brown
00:00:12.412 --> 00:00:14.781
from Microsoft
and Chad Metcalf from Docker.
00:00:14.781 --> 00:00:16.371
- Welcome guys.
- Thank you.
00:00:16.371 --> 00:00:19.224
And as I said, today, it's all about Containers.
00:00:19.224 --> 00:00:22.106
So guys, the first obvious question for people
00:00:22.106 --> 00:00:25.416
is what are Containers all about?
What is this thing called Containers?
00:00:26.985 --> 00:00:29.281
Yeah, I mean this has been a question
that we're getting a lot right now
00:00:29.281 --> 00:00:34.013
as people are starting to—
especially the Microsoft faithful,
00:00:34.013 --> 00:00:36.060
you folks are starting to look at.
00:00:36.060 --> 00:00:39.192
What is this thing of a Container?
They're hearing the buzz about it.
00:00:39.192 --> 00:00:42.373
I think it's really useful to actually think about it
in two different ways.
00:00:43.501 --> 00:00:45.834
You've got to break it down
into the operating system perimeters.
00:00:45.834 --> 00:00:48.758
There is a set of core things
that are just built into the operating system
00:00:48.758 --> 00:00:50.989
that make Containers work.
00:00:51.438 --> 00:00:54.400
And if we look at Linux
as kind of the proxy for this,
00:00:54.400 --> 00:00:57.161
they've had Container technology
for 6-7 years,
00:00:57.161 --> 00:00:59.761
started with IBM, added to by Google.
00:01:00.596 --> 00:01:02.916
But they weren't really heavily utilized
00:01:02.916 --> 00:01:05.214
until tool sets like Docker came along.
00:01:06.117 --> 00:01:09.066
And that's kind of the second part of Containers
is that tool set.
00:01:09.902 --> 00:01:12.888
And what my team is working on right now
is building the core perimeters
00:01:12.888 --> 00:01:16.758
added to the Windows operating system
such that we can create Containers
00:01:16.758 --> 00:01:18.904
and have containerization as well
00:01:18.904 --> 00:01:21.387
and then working with folks like Docker
on that as well.
00:01:22.198 --> 00:01:24.706
OK, so Chad, bring us up to speed,
what is Docker?
00:01:24.706 --> 00:01:26.706
What does Docker provide
as Taylor was mentioning?
00:01:27.375 --> 00:01:29.654
Well, there's really two sides to Docker.
00:01:29.654 --> 00:01:32.786
Docker originated as an open source project.
00:01:32.786 --> 00:01:37.663
So Solomon Hykes is the founder of our project
00:01:37.663 --> 00:01:41.942
and basically realized that development
00:01:41.942 --> 00:01:46.027
was still too difficult
and started a project
00:01:46.027 --> 00:01:49.736
and over the course of time
just very quickly, that project to off.
00:01:49.736 --> 00:01:52.801
So then there's also Docker Inc.,
00:01:52.801 --> 00:01:56.923
the company that now
is leading that charge,
00:01:56.923 --> 00:02:01.879
and that's building an enterprise-grade tool set
00:02:01.879 --> 00:02:03.750
around the open source project.
00:02:03.750 --> 00:02:06.347
But if you look at, like, Docker,
just the open source project,
00:02:06.347 --> 00:02:10.260
what it is is it's a set of tools and APIs
00:02:10.260 --> 00:02:13.024
to help our customers or users
00:02:13.024 --> 00:02:15.415
build, ship, and run their applications.
00:02:15.415 --> 00:02:19.583
So from a developers laptop,
whatever application they're developing,
00:02:19.583 --> 00:02:22.156
put that into a Container.
00:02:22.156 --> 00:02:25.282
And in this case, a Container
is really just a format
00:02:25.282 --> 00:02:28.974
to describe an application
and all of its dependencies.
00:02:29.425 --> 00:02:33.000
And then ship that to, say, test,
ship that to stage,
00:02:33.000 --> 00:02:36.087
and ship that to prod,
but sort of the magic of Docker
00:02:36.087 --> 00:02:38.766
is the thing you're shipping
isn't just the application code.
00:02:38.766 --> 00:02:42.312
It's the application and all of its dependencies
down to the bottom.
00:02:42.312 --> 00:02:45.975
So as it runs on your laptop,
this is the same way it will run in test,
00:02:45.975 --> 00:02:48.075
the same way it will run
in stage and prod.
00:02:48.075 --> 00:02:54.770
So these sort of problems worked in dev,
failed in prod, are oftentimes mitigated.
00:02:54.770 --> 00:02:57.112
- You've got that consistency across—
- All the way across.
00:02:57.112 --> 00:02:59.684
—with the Container.
So what are some of the—
00:02:59.684 --> 00:03:02.002
explain to us what makes up a Container.
What is it?
00:03:02.002 --> 00:03:06.088
You touched on a few different terms there,
so help us understand
00:03:06.088 --> 00:03:08.740
what makes up a Container.
You've got the run time, dependencies,
00:03:08.740 --> 00:03:10.109
but what are they?
Have you got a good example
00:03:10.109 --> 00:03:12.109
you could perhaps give us for people watching?
00:03:12.650 --> 00:03:16.708
Yeah, but I think there's a couple key components
to kind of what makes a Container
00:03:16.708 --> 00:03:20.970
an ecosystem or what makes
the entire Container system work?
00:03:20.970 --> 00:03:23.948
There's that of run time,
the operating system perimeters,
00:03:23.948 --> 00:03:27.173
the things that allow us to easily separate out
00:03:27.173 --> 00:03:30.013
a set of processes and make them pretend
like they're in their own operating system
00:03:30.721 --> 00:03:32.462
which is ultimately what Containers are about.
00:03:32.462 --> 00:03:34.620
It's actually virtualizing the operating system layer
00:03:34.620 --> 00:03:38.465
so that every Container thinks that it's running
on its own copy of the operating system.
00:03:38.465 --> 00:03:41.727
It's got its own file system, its own registry,
00:03:41.727 --> 00:03:44.310
its own name spaces, its own network address.
00:03:44.310 --> 00:03:47.225
It thinks it's on its own copy
of the operating system
00:03:47.225 --> 00:03:50.324
which is kind of a lie.
It's actually being virtualized
00:03:50.324 --> 00:03:52.483
and there's potentially mini-Containers
running next to it.
00:03:53.946 --> 00:03:55.946
And that's kind of the core run time.
00:03:55.946 --> 00:03:58.824
And then there's Container images.
00:03:59.612 --> 00:04:02.803
And as Chad of described,
these images are what you actually move around.
00:04:02.803 --> 00:04:05.917
They're the transportable
kind of view of the Container.
00:04:05.917 --> 00:04:08.551
There are all the files
and registry keys and settings
00:04:08.551 --> 00:04:11.811
and descriptors of kind of
what this Container looks like
00:04:11.811 --> 00:04:15.324
so that I can do something
like Docker pull my SQL
00:04:15.324 --> 00:04:17.612
and have that run on my laptop
00:04:17.612 --> 00:04:20.040
just the same way it ran on Chad's laptop
when he built it.
00:04:21.439 --> 00:04:23.513
It's that common format that we exchange.
00:04:23.513 --> 00:04:25.833
And what's really neat about the way
that Docker has built that
00:04:25.833 --> 00:04:29.128
is that these images actually
build on top of each other.
00:04:29.128 --> 00:04:31.229
So as Chad built MySQL,
00:04:31.229 --> 00:04:34.475
now I can build my database
on top of Chad's MySQL layer.
00:04:34.475 --> 00:04:36.541
You can build your layer on top of that.
00:04:36.541 --> 00:04:39.639
And when we share those around,
we only have to share what's changed.
00:04:39.639 --> 00:04:42.314
You only have to share that top layer.
So it becomes a very, very
00:04:42.314 --> 00:04:44.265
efficient means to share these things.
00:04:44.265 --> 00:04:47.256
So efficient from capacity
perspective exclusively
00:04:47.256 --> 00:04:49.517
because I think I relate
some of this to virtual machines.
00:04:49.517 --> 00:04:52.558
In my mind, I create lots of VMs in each one,
00:04:52.558 --> 00:04:54.451
let's say a ten gigabyte footprint.
00:04:54.451 --> 00:04:56.716
Even though I want them to be more or less the same,
00:04:56.716 --> 00:04:59.592
you're saying that we can be
a lot more efficient with that through Containers.
00:04:59.592 --> 00:05:02.578
Yeah, it could be more efficient on the transport.
00:05:02.578 --> 00:05:06.180
So if I have a base Container
which is maybe the base operating system
00:05:06.180 --> 00:05:09.532
and on top of that I might have Redis;
00:05:09.532 --> 00:05:13.763
I might have MySQL;
I might have an application stack like a JVM.
00:05:13.763 --> 00:05:17.409
When I ship those around,
I will only ship the base once
00:05:17.409 --> 00:05:20.242
because I already have it.
They all depend on the base.
00:05:20.242 --> 00:05:24.396
And then each of those applications
which ship its own layer,
00:05:24.396 --> 00:05:28.786
as that keeps going, I only have to ship those
if something is changed.
00:05:28.786 --> 00:05:33.092
So you get a very, very quick time
to actually transport those.
00:05:33.092 --> 00:05:37.360
And also it does reduce storage
on disk requirement.
00:05:37.360 --> 00:05:39.995
Right. So when you say
you've already got the base,
00:05:39.995 --> 00:05:41.632
what do you mean?
Is that on my laptop;
00:05:41.632 --> 00:05:44.287
is that your laptop; is it on a server?
What is the base?
00:05:44.287 --> 00:05:47.823
So the base Container is the place where
00:05:47.823 --> 00:05:53.127
oftentimes it's a very minimal
operating system image
00:05:53.127 --> 00:05:55.379
that you can start from.
It doesn't have to be.
00:05:55.379 --> 00:05:58.926
It turns out the only thing
that needs to be in a Docker image
00:05:58.926 --> 00:06:01.535
is everything that that application needs to run.
00:06:01.535 --> 00:06:05.228
So if you have a statically linked binary,
you could just put that in there.
00:06:05.228 --> 00:06:10.647
But oftentimes, what we see is it's
a very minimal distribution of an operating system.
00:06:10.647 --> 00:06:14.883
Once I have that, what happens
is I just use any tool
00:06:14.883 --> 00:06:17.146
that I already use to build the next piece, right?
00:06:17.146 --> 00:06:21.198
So in Linux-land, I might install
additional packages
00:06:21.198 --> 00:06:24.875
which represent some service
that I would like that Container to become.
00:06:24.875 --> 00:06:29.836
So the resulting image or the result—
yeah the resulting image now has two pieces.
00:06:29.836 --> 00:06:33.272
It has that common base,
and it has a new thing on top
00:06:33.272 --> 00:06:35.102
which is the new application.
00:06:35.102 --> 00:06:38.923
So that image is defined by two layers.
00:06:38.923 --> 00:06:42.267
And when I shop those around,
I only have to ship them once.
00:06:42.267 --> 00:06:45.229
And that's from your laptop to his laptop,
00:06:45.229 --> 00:06:47.398
you would basically copy two layers.
00:06:47.795 --> 00:06:52.034
Let's say you made a change to that top application,
you updated the version.
00:06:52.625 --> 00:06:55.479
When you ship that to his laptop,
you would only ship the top layer
00:06:55.479 --> 00:06:57.905
- because he's already got the base.
- Right. That makes sense.
00:06:57.905 --> 00:07:00.077
And for Windows Containers,
what we're doing is we're shipping
00:07:00.077 --> 00:07:02.511
that base layer as Server Core
00:07:02.511 --> 00:07:05.430
for the Technical Preview 3 which you all have.
00:07:06.333 --> 00:07:10.396
And then over time we'll get nano as well,
so we'll actually have a nano base layer as well.
00:07:10.396 --> 00:07:13.403
And we'll update those
and distribute those as necessary
00:07:13.403 --> 00:07:15.526
with updates and whatnot.
00:07:15.526 --> 00:07:18.520
So anybody can get those for free
through our distribution
00:07:18.520 --> 00:07:20.598
of the images.
00:07:20.598 --> 00:07:22.978
So that's a layering approach
that will provide that base.
00:07:22.978 --> 00:07:25.935
They could then introduce
their own layers on top
00:07:25.935 --> 00:07:28.233
and as you say construct the applications
that they're looking to.
00:07:28.233 --> 00:07:30.867
I think there's another part
of the efficiency story that's really—
00:07:30.867 --> 00:07:33.471
that has kind of been touched on
that's really powerful
00:07:33.471 --> 00:07:36.849
is that as things change, it's the person
who's affecting that layer
00:07:36.849 --> 00:07:38.497
that makes that change.
00:07:38.497 --> 00:07:42.639
So if I'm the guy who's responsible
for creating the SQL install—
00:07:42.639 --> 00:07:45.199
everybody's going to use
the same SQL install on our team—
00:07:45.199 --> 00:07:48.116
when I make an update to that, that SQL layer,
which is what I know how to do,
00:07:48.116 --> 00:07:51.730
then you all pull the latest version of that
and you build on top of that each time.
00:07:51.730 --> 00:07:54.997
It's not me going around and saying,
"Oh, I need to install an update
00:07:54.997 --> 00:07:57.984
on top of Matt's layer
that has all of his databases
00:07:57.984 --> 00:08:00.493
and everything on it,
and I don't know anything about it."
00:08:00.871 --> 00:08:05.596
So I'm coming in kind of black-boxed
just hoping and praying that it's going to work.
00:08:05.596 --> 00:08:08.554
Well, we find that oftentimes doesn't work very well.
00:08:08.554 --> 00:08:10.876
And that's how we end up
with these production outages, right?
00:08:11.411 --> 00:08:15.023
So how does containerization
00:08:15.023 --> 00:08:18.003
help with density?
So we mentioned it's more efficient.
00:08:18.893 --> 00:08:23.456
If I'm used to, again, deploying lots of applications
and workloads in VMs
00:08:23.456 --> 00:08:26.043
and maybe I want to deploy now with Containers,
00:08:26.043 --> 00:08:29.139
do I see greater levels of density
for my applications and workloads?
00:08:29.776 --> 00:08:33.306
You can certainly.
I mean as we've kind of got this image in the background,
00:08:33.306 --> 00:08:35.197
we've got the Windows Kernel down here,
00:08:35.197 --> 00:08:40.712
and this is really where the Container APIs,
the meat of Container run time, works,
00:08:40.712 --> 00:08:42.798
and then Containers layer on top of that.
00:08:43.541 --> 00:08:46.659
Unlike a virtual machine where I have to have
a new copy of the Kernel
00:08:46.659 --> 00:08:49.131
for each and every instance I'm running,
00:08:49.131 --> 00:08:52.971
with a Container, I've got the same Kernel
and actually most of the same operating system.
00:08:52.971 --> 00:08:56.074
I'm just isolating the pieces of that application
00:08:56.074 --> 00:08:58.392
that I need in their own Container.
00:08:58.392 --> 00:09:00.553
- So that unique Container that you're making.
- Right, right.
00:09:00.553 --> 00:09:05.186
So I do get a pretty significant benefit
in terms of density.
00:09:05.186 --> 00:09:08.761
OK, just density, or can we boot them faster
or get them going quicker,
00:09:08.761 --> 00:09:11.974
that kind of stuff beneficial as well—
obviously beneficial.
00:09:11.974 --> 00:09:15.174
Very much so, Containers—
because I don't have to boot a whole operating system,
00:09:15.174 --> 00:09:17.958
all I have to do is start the processes.
00:09:17.958 --> 00:09:21.249
So Containers start considerably faster
on the order of seconds
00:09:21.249 --> 00:09:24.923
as opposed to virtual machines
that are on the order of potentially minutes.
00:09:24.923 --> 00:09:28.673
Yeah, exactly. So Chad, explain some
of your components on this graphics here
00:09:28.673 --> 00:09:30.905
because we've the Docker client;
we've got the Docker engine.
00:09:30.905 --> 00:09:33.043
What are some of those building blocks
that you've got there?
00:09:33.043 --> 00:09:35.854
So the Docker engine
00:09:35.854 --> 00:09:38.390
is really the core of Docker.
00:09:38.390 --> 00:09:43.288
So it's a service that runs on basically every host
that you want to run Containers on.
00:09:43.288 --> 00:09:49.150
So in TB3, you'll be able to do that in Windows,
on Linux,
00:09:49.150 --> 00:09:51.247
basically any modern Linux Kernel,
00:09:51.247 --> 00:09:54.349
so 310 or later you'll be able to run an engine.
00:09:54.349 --> 00:09:56.563
And then once you have an engine,
00:09:56.563 --> 00:10:00.407
you can run those Containers into that engine.
00:10:00.407 --> 00:10:04.351
And you do that by using an API
that the Docker engine presents.
00:10:04.351 --> 00:10:08.934
So you can either use that restful API directly
or you can use it through a client.
00:10:08.934 --> 00:10:11.680
And so the average—
sort of the average developer
00:10:11.680 --> 00:10:14.612
will often interact with an engine through a client
00:10:14.612 --> 00:10:16.701
which is just a command line set of tools
00:10:16.701 --> 00:10:20.689
or maybe potentially integration
into studio
00:10:20.689 --> 00:10:24.741
or another IDE to get that up and running.
00:10:24.741 --> 00:10:26.852
One of the cool things about Docker
00:10:26.852 --> 00:10:31.611
at least on the—
actually on the Linux side
00:10:31.611 --> 00:10:34.364
and certainly on the Windows side—
it doesn't matter
00:10:34.364 --> 00:10:38.858
on the Linux side what the underlying
operating system is.
00:10:38.858 --> 00:10:41.670
Wherever I have a Docker engine,
I can run a Container.
00:10:41.912 --> 00:10:45.088
So in Azure
00:10:45.088 --> 00:10:48.872
if I an Ubuntu engine up and running,
00:10:48.872 --> 00:10:51.181
I can run whatever Containers
I want in there
00:10:51.181 --> 00:10:54.720
regardless of what's inside that Container
because in the end, it's all Linux.
00:10:54.720 --> 00:10:57.727
And so the same thing will be—
same thing for Windows
00:10:57.727 --> 00:11:02.556
is it doesn't matter what the underlying
Windows operating system looks like
00:11:02.556 --> 00:11:06.176
so long as I have a Docker engine there,
I'll be able to run Windows Containers in that.
00:11:06.176 --> 00:11:10.851
And so from the client, I'm executing commands
to start Containers, stop Containers.
00:11:10.851 --> 00:11:12.951
What else can I do from the client?
What else is typical?
00:11:12.951 --> 00:11:16.898
So you can attach to log output
of that Container
00:11:16.898 --> 00:11:19.089
to see what logs it's casting off.
00:11:19.089 --> 00:11:23.938
You can look at stats to understand
what its CPU and memory
00:11:23.938 --> 00:11:26.191
and other statistics are.
00:11:27.107 --> 00:11:31.983
One of the cool features is
you can actually attach other Containers.
00:11:31.983 --> 00:11:34.873
So if you were to debug a Container
00:11:34.873 --> 00:11:38.181
so you have a network issue,
you can run another Container
00:11:38.181 --> 00:11:41.039
that shares that Containers network.
00:11:41.039 --> 00:11:45.008
And you can debug it without ever touching
the running Container.
00:11:45.401 --> 00:11:49.173
So there's lots of new ways
when you have this technology
00:11:49.173 --> 00:11:52.631
that you get to start to think differently
about how to interact with Containers.
00:11:52.631 --> 00:11:54.631
So speaking of thinking differently,
00:11:54.631 --> 00:11:58.904
how is Docker enabling developers
to think differently generally speaking?
00:11:59.635 --> 00:12:06.112
Well, I think part of it is just the ability
to rapidly self-serve.
00:12:06.112 --> 00:12:09.442
So I have—I can have
a full stacked development environment
00:12:09.442 --> 00:12:12.346
on my laptop.
I can pull down all the pieces and parts.
00:12:12.346 --> 00:12:14.558
Maybe I don't know
how those pieces and part work,
00:12:14.558 --> 00:12:18.262
but I know that my application consists
of these five Containers
00:12:18.262 --> 00:12:21.085
with these versions, and they're wired up this way.
00:12:21.085 --> 00:12:24.708
Docker takes care of that for me,
so I can actually do what I want to do
00:12:24.708 --> 00:12:27.862
which is just work on the feature and the service.
00:12:27.862 --> 00:12:32.269
That feature—or that service oftentimes
doesn't exist in a bubble, right?
00:12:32.269 --> 00:12:34.637
So I need other pieces to make that happen,
00:12:34.637 --> 00:12:36.637
and I can do that on a laptop very quickly.
00:12:38.042 --> 00:12:41.453
It's very trivial to spin up a new Docker environment.
00:12:41.453 --> 00:12:44.357
Play around with it.
If you break it, throw it away and try again, right?
00:12:44.357 --> 00:12:47.920
So you get that sort of quit iterative
development experience
00:12:47.920 --> 00:12:50.116
that everybody really wants.
00:12:50.116 --> 00:12:52.961
So when we think about—
you mentioned using the client
00:12:52.961 --> 00:12:55.711
to deploy new Containers.
Where are they coming from?
00:12:55.711 --> 00:12:58.404
So where are they originating?
Are they originating in the cloud?
00:12:58.404 --> 00:13:02.303
If you're an enterprise,
are they somewhere located on premises?
00:13:02.303 --> 00:13:05.428
- What's the flexibility you've got there?
- Yeah, so I think the answer is all of the above.
00:13:05.428 --> 00:13:08.666
So they might generate from my own environment.
00:13:08.666 --> 00:13:11.407
I might build my own Container then run it, test it.
00:13:11.407 --> 00:13:14.465
But that's only interesting for my laptop, right?
00:13:14.465 --> 00:13:17.274
So then where else can I get Containers?
00:13:17.274 --> 00:13:22.168
First would be the hub which is our SAS offering,
so hub.docker.com.
00:13:22.168 --> 00:13:27.623
Right now in the hub,
there's about 80,000 different Containers
00:13:27.623 --> 00:13:30.536
that are just publicly facing.
00:13:30.536 --> 00:13:32.821
So you can also have private repositories as well,
00:13:32.821 --> 00:13:36.522
but everything you could ever want
from databases
00:13:36.522 --> 00:13:38.854
through middleware,
through messaging systems,
00:13:38.854 --> 00:13:41.530
- you can just search and find what you want—
- But people have already built those—
00:13:41.530 --> 00:13:42.831
- Absolutely.
- —loaded them.
00:13:42.831 --> 00:13:44.359
Yeah. And we have an interesting program.
00:13:44.359 --> 00:13:48.152
We have the Official Images program,
and there's about eighty official images.
00:13:48.152 --> 00:13:53.224
And what these are, the upstream IP holder
has built the Container, right?
00:13:53.224 --> 00:13:56.186
So Oracle has stepped up
to do the MySQL Container,
00:13:56.186 --> 00:13:58.786
Mongo folks have done MongoDB,
00:13:58.786 --> 00:14:04.957
and they represent the best practice way
of building this.
00:14:04.957 --> 00:14:09.634
So if it's my IP, generally speaking,
I should probably know really well how to run it.
00:14:09.634 --> 00:14:13.962
So then you can just consume those
as just Lego bricks
00:14:13.962 --> 00:14:17.382
that you want to snap together
and I just need a Redis,
00:14:17.382 --> 00:14:20.689
I need a Python stack,
I need a Go stack
00:14:20.689 --> 00:14:22.763
- and just consume them down.
- And combine them together
00:14:22.763 --> 00:14:24.729
and filter out the application.
00:14:24.729 --> 00:14:27.968
Oftentimes though, enterprises want
maybe a little more control than that.
00:14:27.968 --> 00:14:31.683
So from Docker, there's Docker Trusted Registry
00:14:31.683 --> 00:14:35.603
which is sort of the hub but in a network that I control.
00:14:35.603 --> 00:14:38.448
So whether that's in a cloud or in a data center,
it doesn't really matter.
00:14:38.448 --> 00:14:40.548
It's a version of the registry
00:14:40.548 --> 00:14:44.856
that is behind something that I control,
that I can decide what goes into it,
00:14:44.856 --> 00:14:49.115
what comes out of it,
that integrates into the company's existing directories
00:14:49.115 --> 00:14:51.832
for access control and all those pieces.
00:14:51.832 --> 00:14:55.304
But these things aren't one or the other.
00:14:55.304 --> 00:14:57.311
You can use any combination.
00:14:57.311 --> 00:15:00.827
OK. So you mentioned before
around having an application
00:15:00.827 --> 00:15:02.532
that's made up of lots of Containers.
00:15:02.532 --> 00:15:04.645
Is that the same as microservices?
00:15:04.645 --> 00:15:07.674
Tell us a little bit about that
and microservices,
00:15:07.674 --> 00:15:09.396
how they relate to Containers.
00:15:09.396 --> 00:15:11.322
We've been having this conversation
a lot with folks
00:15:11.322 --> 00:15:14.718
is that they come in and say,
"OK, yeah, Containers,
00:15:14.718 --> 00:15:16.850
they look interesting,
but I'm not really into microservice,
00:15:16.850 --> 00:15:19.009
so I guess I don't need them.
00:15:19.009 --> 00:15:22.180
And really microservice is a design pattern.
00:15:22.180 --> 00:15:24.291
It's a way to design an application.
00:15:24.291 --> 00:15:26.706
It existed before Containers were really a big thing.
00:15:26.706 --> 00:15:30.468
It doesn't have to—
it's not one or the other.
00:15:30.468 --> 00:15:33.301
It's a design pattern, and then Containers
happen to be a tool
00:15:33.301 --> 00:15:35.307
that can enable that design pattern.
00:15:35.307 --> 00:15:40.146
So we see people do microservices
with platforms and service offerings.
00:15:40.146 --> 00:15:42.306
We've got Azure Service Fabric
00:15:42.306 --> 00:15:44.675
which is a microservice architecture.
00:15:44.675 --> 00:15:47.309
And ultimately that's going to use Containers
00:15:47.309 --> 00:15:49.630
as an efficient way to run the service,
00:15:49.630 --> 00:15:52.337
but they really are kind of a separate entity.
00:15:52.337 --> 00:15:56.862
And I think Chad was mentioning earlier
that he's been talking to a lot of customers
00:15:56.862 --> 00:15:59.111
that are using Containers,
and ultimately
00:15:59.111 --> 00:16:01.710
they end up getting to a microservice, right?
00:16:01.710 --> 00:16:05.276
So if you think about at least
what Docker wants to present
00:16:05.276 --> 00:16:08.582
as two key values to our customers,
00:16:08.582 --> 00:16:11.035
it's choice and portability.
00:16:11.035 --> 00:16:13.376
So what do you want to do with the technology
00:16:13.376 --> 00:16:14.663
and where do you want to run it?
00:16:14.663 --> 00:16:17.285
So what we see oftentimes with our customers
00:16:17.285 --> 00:16:20.395
when they start, they just put their large applications
00:16:20.395 --> 00:16:23.181
into Containers
because it makes it easy to move them
00:16:23.181 --> 00:16:27.559
between their environments,
so between dev and test and stage and prod
00:16:27.559 --> 00:16:30.437
and potentially on-premise to a cloud.
00:16:30.437 --> 00:16:34.095
And it's still the old monolithic application
00:16:34.095 --> 00:16:36.893
or just maybe just a very large application
00:16:36.893 --> 00:16:40.329
that they would like to migrate
to more of a services architecture.
00:16:40.329 --> 00:16:42.599
So what do you classify
as a large application as an example?
00:16:42.599 --> 00:16:45.363
A full-on MySQL database or—
00:16:45.363 --> 00:16:47.146
Well, I think it's even bigger than that, right?
It might be—
00:16:47.146 --> 00:16:50.477
it might be a number of components,
00:16:50.477 --> 00:16:54.060
so it might be, say,
a very large Java application
00:16:54.060 --> 00:16:56.277
that has an authentication service built in,
00:16:56.277 --> 00:16:58.004
- it has a lobbying service—
- You get a lot of business applications?
00:16:58.004 --> 00:17:02.263
Yeah, exactly, a lot of business service.
So maybe I even have, like,
00:17:02.263 --> 00:17:04.933
seven or eight of those
that all have their own services
00:17:04.933 --> 00:17:06.663
that are duplicated across.
00:17:06.663 --> 00:17:10.074
So we have one customer in mind
00:17:10.074 --> 00:17:12.978
that had seven of these big monoliths,
00:17:12.978 --> 00:17:16.621
and they each had duplicate services
that they were maintaining.
00:17:16.621 --> 00:17:20.441
And they wanted to move
to a different architecture
00:17:20.441 --> 00:17:23.657
but they needed to be able
to move those pieces first.
00:17:23.657 --> 00:17:26.836
So if I can't ship to production,
00:17:26.836 --> 00:17:29.041
I can't even—I don't have time
to do anything else.
00:17:29.041 --> 00:17:31.526
So once they had that working in Docker,
00:17:31.526 --> 00:17:36.074
they were able to go back and identify
these five of the seven
00:17:36.074 --> 00:17:38.603
are using different authentication services,
00:17:38.603 --> 00:17:41.563
so let's rip that out into a new authentication service
00:17:41.563 --> 00:17:43.210
that they all can share.
00:17:43.210 --> 00:17:46.136
And now we only have to maintain
one authentication service.
00:17:46.136 --> 00:17:47.657
- In its own Container.
- In its own Container.
00:17:47.657 --> 00:17:49.665
So now I have eight Containers.
00:17:49.665 --> 00:17:52.589
So I have the original seven
plus the new authentication service
00:17:52.589 --> 00:17:54.991
and we'll just migrate that through.
00:17:54.991 --> 00:17:57.673
And over time, rinse and repeat that same piece,
00:17:57.673 --> 00:18:00.303
and maybe those seven Containers
end up being
00:18:00.303 --> 00:18:02.393
tens or hundreds of Containers at the end.
00:18:02.812 --> 00:18:07.431
OK. So does the Docker technology help me
with the packaging of the application
00:18:07.431 --> 00:18:11.201
into a Container, or is just about the running
and the deploying
00:18:11.201 --> 00:18:13.022
and the managing and starting and stopping?
00:18:13.022 --> 00:18:18.374
Yeah, so Docker gives you basically
what we call a Docker file
00:18:18.374 --> 00:18:21.572
which is a manifest to describe
how you want to build your application.
00:18:21.572 --> 00:18:26.575
And so that basically lives in parallel
with the application itself,
00:18:26.575 --> 00:18:30.489
so it's probably in the same version control
and you use that
00:18:30.489 --> 00:18:33.763
to say, OK, now build this application
and it just describes through.
00:18:33.763 --> 00:18:37.049
So whatever—if you have a scripting service,
00:18:37.049 --> 00:18:42.492
if you're using existing PowerShell scripts
or other tools,
00:18:42.492 --> 00:18:48.180
you can just use those and the Docker file
will walk you through building the application.
00:18:48.180 --> 00:18:51.519
And something we showed at DockerCon
00:18:51.519 --> 00:18:53.422
that I think was pretty neat around the same thing
00:18:53.422 --> 00:18:56.457
is we showed actually building the application
Visual Studio,
00:18:56.457 --> 00:18:58.674
right click Deploy into a Docker Container,
00:18:58.674 --> 00:19:01.958
but then we followed that up
into Visual Studio Online
00:19:01.958 --> 00:19:05.446
where we can actually automatically
have a Docker bill kick off
00:19:05.446 --> 00:19:07.685
every time a check-in is made.
So that Docker image
00:19:07.685 --> 00:19:11.579
actually gets updated automatically
every time someone does a check-in
00:19:11.579 --> 00:19:17.021
and then could get pulled back down
into QA, into other developer scenarios
00:19:17.021 --> 00:19:18.912
or even all the way into production, right?
00:19:18.912 --> 00:19:20.864
So you've got some automation
around your bill process there
00:19:20.864 --> 00:19:24.369
which sounds to me a bit like DevOps.
00:19:24.369 --> 00:19:27.562
And are these two technologies—
00:19:27.562 --> 00:19:30.540
so Containers and DevOps
being a process as well as people
00:19:30.540 --> 00:19:33.981
and other technology—
are they—
00:19:33.981 --> 00:19:37.436
do they have to exist together
or are one reliant on the other?
00:19:37.436 --> 00:19:39.723
I think it's the same as kind of the microservices.
00:19:40.601 --> 00:19:44.594
DevOps is a great thing, and people
are doing that without Containers.
00:19:44.594 --> 00:19:47.114
They have been doing it
since before Containers were around.
00:19:47.114 --> 00:19:49.540
Containers are a really,
really helpful tool in it.
00:19:49.540 --> 00:19:52.164
It's something we can all talk about
in the same way, right?
00:19:52.164 --> 00:19:55.345
I can say, "Hey Matt, I'm giving you a Container,"
and you know what that means.
00:19:55.345 --> 00:19:57.914
- You'd hope so.
- Well, yeah.
00:19:57.914 --> 00:20:00.006
Or I can at least explain it and say,
"Here's a Container.
00:20:00.006 --> 00:20:02.444
You can start it; you can stop it;
you can deploy it;
00:20:02.444 --> 00:20:04.437
you can move around,"
and you can understand,
00:20:04.437 --> 00:20:06.980
- "OK, I know how to do that now."
- Yeah.
00:20:06.980 --> 00:20:10.231
And whereas before it's "OK, here's a script,
00:20:10.231 --> 00:20:12.239
and if the script doesn't work,
00:20:12.239 --> 00:20:15.617
I don't know, your environment's messed up
because it worked on my machine."
00:20:16.089 --> 00:20:18.827
- Lots of finger pointing and all that.
- Yeah. And the 2 am phone calls
00:20:18.827 --> 00:20:23.043
and the 3 am phone calls
and the escalations the next day
00:20:23.043 --> 00:20:25.294
of why was this down?
All those can go away
00:20:25.294 --> 00:20:27.291
when we actually have a common language
to talk about,
00:20:27.291 --> 00:20:29.833
when we all understand each other
and can work together.
00:20:29.833 --> 00:20:33.343
I think that's really what Containers have helped
is providing some of that common language.
00:20:33.955 --> 00:20:37.680
But they are not mutually—
they are mutually exclusive.
00:20:37.680 --> 00:20:41.173
Right. I think the—
so the common language
00:20:41.173 --> 00:20:43.379
is a big piece to this.
00:20:43.379 --> 00:20:48.045
So if you have sort of
a very forward DevOps team
00:20:48.045 --> 00:20:50.436
where you have Ops embedded in Dev,
00:20:50.436 --> 00:20:52.310
that's great and everyone
can understand that.
00:20:52.310 --> 00:20:56.209
We also see that in, say,
financial or government sector,
00:20:56.209 --> 00:20:59.841
customers that have a mandated bright line
between the two teams,
00:20:59.841 --> 00:21:03.067
it still helps them because it gives them
a common interface
00:21:03.067 --> 00:21:05.227
and a common language to do this piece.
00:21:05.227 --> 00:21:07.794
And if you think about, like an example,
00:21:07.794 --> 00:21:10.206
an additional tool from
in the Docker ecosystem
00:21:10.206 --> 00:21:12.861
is called Docker Compose,
and it's a—
00:21:12.861 --> 00:21:16.721
basically gives you a manifest
to describe an entire application,
00:21:16.721 --> 00:21:20.076
where that application
might be many different Containers.
00:21:20.076 --> 00:21:23.570
So I might have fifty different Containers
00:21:23.570 --> 00:21:27.687
at these various versions,
and they might have these dependencies between them
00:21:27.687 --> 00:21:30.657
and they might have these links
that use these ports.
00:21:30.657 --> 00:21:34.929
And if you can imagine when we talk
to folks on the Dev side,
00:21:34.929 --> 00:21:37.656
they can just say "Docker Compose up"
00:21:37.656 --> 00:21:39.667
and it spins up their entire application,
00:21:39.667 --> 00:21:41.986
and they can test it and build it.
00:21:42.438 --> 00:21:44.792
Then hand that same manifest to the Ops side
00:21:44.792 --> 00:21:46.899
and ask them, "When was the last time you got
00:21:46.899 --> 00:21:49.106
a machine-readable specification of an application,
00:21:49.106 --> 00:21:51.601
all its dependencies, all of its networks,
00:21:51.601 --> 00:21:55.013
all of its ports?"
Basically never.
00:21:55.013 --> 00:21:58.717
And you can use that same tooling
to spin up the application, right?
00:21:58.717 --> 00:22:03.500
There's no more—it's in the code,
it lives with the application itself,
00:22:03.500 --> 00:22:05.927
and I understand I can read it,
I can reason about it.
00:22:05.927 --> 00:22:11.984
And I can take a laptop,
run it the same way that I would in my data center
00:22:11.984 --> 00:22:14.015
which might be very different,
00:22:14.015 --> 00:22:16.870
but Docker helps abstract away that difference.
00:22:16.870 --> 00:22:20.372
OK, so it's a real enabler for IT
and that relationship with Dev
00:22:20.372 --> 00:22:22.945
and speeding up the rate
that they can deploy applications
00:22:22.945 --> 00:22:25.312
and provide in that standardized platform.
00:22:25.312 --> 00:22:27.645
Now when we think about Containers,
00:22:27.645 --> 00:22:30.871
we started talking briefly
about Windows Server Containers initially,
00:22:30.871 --> 00:22:34.526
and it's a new technology.
You'll be able to play with it in TP3.
00:22:35.872 --> 00:22:39.285
The graphic depicts architecturally
some of those key components
00:22:39.285 --> 00:22:41.376
from a Windows Server perspective.
00:22:41.376 --> 00:22:43.547
But we announced a couple of months back
00:22:43.547 --> 00:22:46.411
a different type of Container
within the Microsoft offering
00:22:46.411 --> 00:22:48.537
and that's a Hyper-V Container.
00:22:48.537 --> 00:22:51.650
Tell us a bit more about Hyper-V Containers,
how they differ,
00:22:51.650 --> 00:22:54.341
what their intended purpose is.
And then we can talk about
00:22:54.341 --> 00:22:56.685
how Docker provides value
in that space as well.
00:22:57.185 --> 00:22:59.171
Yeah, and some of you
might have already read a blog post
00:22:59.171 --> 00:23:02.119
that we did on kind of
what is a Hyper-V Container,
00:23:02.119 --> 00:23:04.442
and I think that's a really helpful post to read
00:23:04.442 --> 00:23:06.442
and we'll have a link to it at the end if you haven't.
00:23:06.442 --> 00:23:11.079
But the easiest way for me to explain
what a Hyper-V Container is
00:23:11.079 --> 00:23:14.551
is we basically took a virtual machine,
00:23:14.551 --> 00:23:18.301
we stripped it down to its very,
very, very minimal surface,
00:23:18.301 --> 00:23:20.301
just enough for it to run a Container,
00:23:20.301 --> 00:23:22.580
and then we took Windows and we did the same thing.
00:23:22.580 --> 00:23:25.518
We made Windows just enough to run a Container,
00:23:25.518 --> 00:23:28.009
and then we run a Container
inside that virtual machine.
00:23:28.009 --> 00:23:33.892
And so what that gives us is it gives us
all of the same kind of isolation of benefits
00:23:33.892 --> 00:23:36.794
that a virtual machine would have.
We can run it across different versions like Kernel;
00:23:36.794 --> 00:23:41.808
we can check all the security boxes
for this needs to be HIPAA compliant
00:23:41.808 --> 00:23:44.731
and it has to run in this.
Get all those of check boxes checked.
00:23:46.575 --> 00:23:49.417
But we still have the same process
and the same tool
00:23:49.417 --> 00:23:52.839
and the same commands that we would have
with a Windows Server Container.
00:23:53.303 --> 00:23:54.741
In fact, it's the same image format.
00:23:54.741 --> 00:23:59.187
So if you build a Container
using a Hyper-V Container,
00:23:59.187 --> 00:24:02.772
it will run as Windows Server Container,
or if you build it as Wow Server Container,
00:24:02.772 --> 00:24:04.872
it will run as a Hyper-V Container.
00:24:04.872 --> 00:24:08.031
So it's just a run-time option
between the two.
00:24:08.031 --> 00:24:11.188
And we'll have a lot more to talk about
with Hyper-V Containers
00:24:11.188 --> 00:24:13.741
as we get those into a preview later this year.
00:24:13.741 --> 00:24:17.372
But we really think they're
a pretty neat technology.
00:24:17.372 --> 00:24:21.759
We built them largely because we saw
a need for our own workloads.
00:24:21.759 --> 00:24:24.295
As we looked around Azure
and how we were running things in Azure,
00:24:24.295 --> 00:24:27.338
we saw a need for it.
And as soon as we identified that,
00:24:27.338 --> 00:24:31.504
started talking to customers,
we identified that they also had a similar need.
00:24:32.349 --> 00:24:33.869
So we're really excited about them.
00:24:33.869 --> 00:24:39.448
One of the interesting pieces is that
the customers that we see are very different, right?
00:24:39.448 --> 00:24:44.674
So in the retail space or even in sort of Silicon Valley,
00:24:44.674 --> 00:24:47.530
those customers and their requirements
look very different
00:24:47.530 --> 00:24:50.908
than say the financial space or government sector.
00:24:51.798 --> 00:24:55.573
And one of the pieces I like the best
is it's a run-time option, right?
00:24:55.573 --> 00:24:58.418
So if I have a business case
00:24:58.418 --> 00:25:01.797
that requires me to do that,
I can flip a flag.
00:25:01.797 --> 00:25:03.801
But if I don't, I don't have to do it.
00:25:03.801 --> 00:25:07.271
I can still use just
the standard Windows Container
00:25:07.271 --> 00:25:10.254
and I can still get that density,
I can still have all those pieces
00:25:10.254 --> 00:25:14.840
which goes back to sort of
one of Docker's core mission
00:25:14.840 --> 00:25:17.226
which was choice
which is where do you want to run it
00:25:17.226 --> 00:25:19.061
and what are your requirements
around running it?
00:25:19.061 --> 00:25:23.201
- And we should run it there.
- And did you think that's the biggest,
00:25:23.201 --> 00:25:26.876
most significant Docker has had
on both the Linux development community
00:25:26.876 --> 00:25:29.995
and going forward to Windows is just that flexibility?
00:25:29.995 --> 00:25:34.407
I think the first one was just reducing Dev friction.
00:25:35.300 --> 00:25:37.031
The second one is portability,
00:25:37.031 --> 00:25:39.812
so my data center Azure,
00:25:39.812 --> 00:25:42.515
and I think the third is choice.
00:25:42.515 --> 00:25:46.578
So if you look at large enterprises,
it's not going to be one answer.
00:25:46.578 --> 00:25:48.660
They're going to have many different environments,
00:25:48.660 --> 00:25:51.631
and we don't think that they should have to re-tool
00:25:51.631 --> 00:25:54.196
just because they want to run it in a different place.
00:25:54.196 --> 00:25:58.931
So my on-prem story shouldn't have to be different
than my Azure story.
00:25:59.498 --> 00:26:02.261
And I think one of the things
when we started first talking to Docker
00:26:02.261 --> 00:26:06.638
one of the key kind of turning points
and kind of visionary moments in that
00:26:06.638 --> 00:26:09.459
was when we talked about our vision,
our Microsoft vision,
00:26:09.459 --> 00:26:12.488
of an application that spanned both Linux Containers
and Windows Containers.
00:26:12.488 --> 00:26:16.574
And we demonstrated that kind of realization
at DockerCon this year
00:26:16.574 --> 00:26:19.489
where we spun up the first application
that used components
00:26:19.489 --> 00:26:21.555
in both Windows and Linux, right?
00:26:21.555 --> 00:26:24.051
And we think for our customers,
that's really valuable
00:26:24.051 --> 00:26:27.301
because there's some great technology
that's available in Linux today
00:26:27.301 --> 00:26:30.378
that enables them to build really,
really great apps.
00:26:30.378 --> 00:26:33.268
Same thing for Windows.
We've got great technology
00:26:33.268 --> 00:26:35.636
in Windows for building applications.
00:26:35.636 --> 00:26:38.690
And when we can marry those together
and let customers use both of them together,
00:26:38.690 --> 00:26:41.149
they win, right?
00:26:41.149 --> 00:26:46.537
And Docker's been a great enabler
for that vision to come to fruition.
00:26:46.537 --> 00:26:52.210
I think it's exactly because
you can stop having conversations
00:26:52.210 --> 00:26:54.637
about Linux or Windows
00:26:54.637 --> 00:26:57.204
or on-prem or a cloud,
00:26:57.204 --> 00:27:00.745
and you can start having conversations about
what's the best place to run my workload.
00:27:00.745 --> 00:27:03.613
Yeah, so thinking about the application,
00:27:03.613 --> 00:27:07.978
financial, where it's better in the cloud or on-prem,
security, whatever it may be.
00:27:07.978 --> 00:27:10.447
And if your business requirements change tomorrow,
00:27:10.447 --> 00:27:12.607
Docker's going to help you move.
00:27:12.607 --> 00:27:15.191
Correct, and the flexibility of move the Container.
00:27:15.191 --> 00:27:18.699
And we were already talking to a lot of customers
that are in this world today.
00:27:18.699 --> 00:27:21.830
They've got an investment
in Docker and in Containers,
00:27:21.830 --> 00:27:24.441
and they're using that where they can,
00:27:24.441 --> 00:27:27.111
but they have a huge investment in software
that they've written for Windows
00:27:27.111 --> 00:27:30.235
that their choices were either rewrite it
00:27:30.235 --> 00:27:32.235
so that we can continue to use Docker
00:27:32.235 --> 00:27:35.042
or forego Containers.
00:27:35.042 --> 00:27:39.359
And that was a really bad choice for them,
so they're really excited about what we're doing
00:27:39.359 --> 00:27:42.865
because it moves that kind of painful choice
and just says,
00:27:42.865 --> 00:27:45.279
"Well, I can continue to use the best tool I've got."
00:27:45.279 --> 00:27:48.214
So if people want to get started,
00:27:48.214 --> 00:27:50.409
how can they get started
with the Windows Server Containers?
00:27:50.409 --> 00:27:52.741
- What advice would you give people?
- Well, the first thing I would do
00:27:52.741 --> 00:27:54.909
is take a look at our documentation site.
00:27:54.909 --> 00:27:59.416
The short link is aka.ms/Windowscontainers.
00:27:59.416 --> 00:28:03.408
So we've actually spent a bunch of time
making better documentation,
00:28:03.408 --> 00:28:06.341
I think better documentation
than typically we've seen in Windows.
00:28:07.316 --> 00:28:10.254
And so we're trying really hard to make sure
that that documentation is really good
00:28:10.254 --> 00:28:12.693
and that we can get feedback from you on it.
00:28:12.693 --> 00:28:14.748
So there's also links on there to the forums
00:28:14.748 --> 00:28:17.233
where we can ask questions and have Q&A.
00:28:18.208 --> 00:28:20.355
So that's definitely the first place to look.
00:28:20.355 --> 00:28:23.618
- People can make use of it in TP3.
- Yeah, the Technical Preview 3, yep, absolutely.
00:28:23.618 --> 00:28:26.442
And for Docker, where can people get started there?
00:28:26.442 --> 00:28:28.877
Well, the easiest way to get started with Docker
00:28:28.877 --> 00:28:33.020
is just go to Docker.com/tryit
and just get the technology.
00:28:33.020 --> 00:28:37.117
What we see is that usually you put Docker
in the hands of Dev
00:28:37.117 --> 00:28:39.529
and then it just spreads like wildfire.
00:28:39.529 --> 00:28:41.838
OK. Great. That's a good thing.
OK. Well, thank you guys.
00:28:41.838 --> 00:28:43.485
- Thank you.
- Thanks for coming along.
00:28:43.485 --> 00:28:48.652
And hopefully that's been useful
for you at home as well in this Containers 101, if you will.
00:28:48.652 --> 00:28:50.174
We've gone through a lot:
What are Containers,
00:28:50.174 --> 00:28:52.796
how Hyper-V
and Windows Server Containers differ,
00:28:52.796 --> 00:28:55.778
the impact that Docker has made
in the Container ecosystem.
00:28:55.778 --> 00:28:58.306
And it's all great stuff,
and there's lots more resources
00:28:58.306 --> 00:29:01.693
out there the guys have provided,
so get your hands on TP3,
00:29:01.693 --> 00:29:03.842
read the Windows Server documentation
00:29:03.842 --> 00:29:06.735
written by Taylor himself,
and his team obviously as well.
00:29:06.735 --> 00:29:10.826
- No, my team.
- Get onto the Docker website as well, /tryit.
00:29:10.826 --> 00:29:13.559
Go to Docker.com/tryit
and download their bits as well.
00:29:13.559 --> 00:29:17.468
And obviously use the image, the hub,
to pull down some Containers
00:29:17.468 --> 00:29:19.406
that you can use for your apps
and try it all out.
00:29:19.406 --> 00:29:22.228
And with that, that's Matt McSpirit signing off.
00:29:22.228 --> 00:29:23.981
Thanks for joining us again,
and we'll see you again.
00:29:23.981 --> 00:29:24.468
- Thank you very much.
- Thanks.