WEBVTT
00:00:00.150 --> 00:00:02.540
Good afternoon, welcome to
Build, and thank you for
00:00:02.540 --> 00:00:04.860
coming to this session
on Azure Service Fabric.
00:00:04.860 --> 00:00:05.906
Great to have you here.
00:00:05.906 --> 00:00:08.556
My name is Mark Fussell, I'm the
program manager that works on
00:00:08.556 --> 00:00:10.180
the Azure Service Fabric team.
00:00:10.180 --> 00:00:11.489
>> And I'm Vaclav Turecek,
00:00:11.489 --> 00:00:13.757
I'm also a program
manager on the same team.
00:00:13.757 --> 00:00:15.408
>> And we're gonna take
you on a journey today.
00:00:15.408 --> 00:00:18.682
We're gonna take you on
a journey of how you modernize
00:00:18.682 --> 00:00:20.371
some of the applications.
00:00:20.371 --> 00:00:21.945
How you may have started
the executables, or
00:00:21.945 --> 00:00:23.750
have something that's
running today.
00:00:23.750 --> 00:00:25.380
And through that journey
we're gonna talk a lot about
00:00:25.380 --> 00:00:28.418
containers and other things
to help you on that journey.
00:00:28.418 --> 00:00:31.370
And particularly, we want to
take away from this, how is it
00:00:31.370 --> 00:00:34.398
that Service Fabric helps you
build these distribute apps.
00:00:34.398 --> 00:00:37.649
Along this journey we'll expose
this with a number of different
00:00:37.649 --> 00:00:40.671
things about the future looking
inside of Service Fabric.
00:00:40.671 --> 00:00:41.892
This is an [INAUDIBLE] talk.
00:00:41.892 --> 00:00:44.464
We're expecting you to
have some familiarity with
00:00:44.464 --> 00:00:45.670
Service Fabric today.
00:00:45.670 --> 00:00:47.133
If you're totally new to this,
00:00:47.133 --> 00:00:49.841
there's going to be a lot of
stuff inside here that builds on
00:00:49.841 --> 00:00:51.920
some of the concepts
we have today.
00:00:51.920 --> 00:00:54.580
But, it's a journey and we'll
take you from the beginning and
00:00:54.580 --> 00:00:56.740
you'll see a lot of
stuff that we do.
00:00:56.740 --> 00:00:58.030
So, to recap,
00:00:58.030 --> 00:01:01.060
Azure Service Fabric, it's
a distributed systems platform.
00:01:01.060 --> 00:01:03.920
We use it to build a lot of
services at Microsoft and
00:01:03.920 --> 00:01:06.070
encompasses everything from
a developer side of things up to
00:01:06.070 --> 00:01:07.680
the other side of things.
00:01:07.680 --> 00:01:09.690
This time last year,
00:01:09.690 --> 00:01:12.210
we released Service Fabric
as service inside Azure.
00:01:12.210 --> 00:01:14.536
So you can go and
host a cluster of machines.
00:01:14.536 --> 00:01:19.280
And inside Azure there,
you can run it on Windows.
00:01:19.280 --> 00:01:21.927
And then we also,
at the same time, of course, and
00:01:21.927 --> 00:01:24.216
you can run it on your
single Dev Box as well.
00:01:24.216 --> 00:01:27.696
But back at Ignite, we released
our on-premise version so
00:01:27.696 --> 00:01:31.257
you can deploy Service Fabric
inside your own data centers.
00:01:31.257 --> 00:01:34.188
And that's had a huge adoption
with people, it's been extremely
00:01:34.188 --> 00:01:36.858
successful because you can run
Service Fabric just by taking
00:01:36.858 --> 00:01:39.263
a set of machines, hook them
together with a network,
00:01:39.263 --> 00:01:40.834
run a single
PowerShell command and
00:01:40.834 --> 00:01:43.689
you have a cluster running up in
under a minute on five machines.
00:01:44.725 --> 00:01:46.130
At Ignite last year,
00:01:46.130 --> 00:01:49.560
we also released Linux
preview inside Azure.
00:01:49.560 --> 00:01:52.860
You can go into Azure, you
can create inside our portal,
00:01:52.860 --> 00:01:55.960
you can create a cluster there
with a Linux Ubuntu machine,
00:01:55.960 --> 00:01:59.560
deploy that and
inside that of course, we have
00:01:59.560 --> 00:02:03.440
based around Java and in Jenkins
for the CIT pipeline and Slew of
00:02:03.440 --> 00:02:06.790
staff effect fully allowing you
to have a full Java experience.
00:02:06.790 --> 00:02:10.060
And as we get towards the end of
this year, you know, we're super
00:02:10.060 --> 00:02:15.490
excited that we're on the home
stretch for our Linux offering.
00:02:15.490 --> 00:02:17.820
You'll see our Linux
offering GA this year.
00:02:17.820 --> 00:02:20.090
You know, we've only got
six months left now.
00:02:20.090 --> 00:02:21.640
So we're on the final run for
that.
00:02:21.640 --> 00:02:24.100
And you'll also see
Service Fabric become part of
00:02:24.100 --> 00:02:24.970
Azure Stack.
00:02:24.970 --> 00:02:27.870
So as well as the standalone
experience where you just take
00:02:27.870 --> 00:02:29.490
the set of machines and
deploy it.
00:02:29.490 --> 00:02:31.910
Actually, we've come down to our
booth, you'll see our Mini Stack
00:02:31.910 --> 00:02:33.490
is running there if
you've seen that.
00:02:33.490 --> 00:02:36.950
You'll also have an experience
of Azure Stack is an appliance
00:02:36.950 --> 00:02:38.260
that you can have
Service Fabric in.
00:02:38.260 --> 00:02:42.440
So we love to think that Service
Fabric is available everywhere
00:02:42.440 --> 00:02:44.499
and on any OS as long as
it's Windows or Linux.
00:02:45.580 --> 00:02:48.200
And you can deploy those
into a number of different
00:02:48.200 --> 00:02:48.850
environments.
00:02:48.850 --> 00:02:51.620
And so you can progressively
start inside your own data
00:02:51.620 --> 00:02:54.520
center, build them and
take advantage of things that
00:02:54.520 --> 00:02:57.730
are running there, and move to
Azure and making it your choice
00:02:57.730 --> 00:03:00.330
of Windows or Linux, and
then different environments.
00:03:00.330 --> 00:03:03.990
And we don't pretend that there
are other people who've taken
00:03:03.990 --> 00:03:06.280
Service Fabric and
run it in other clouds as well.
00:03:06.280 --> 00:03:08.710
And we have other customers who
run Service Fabric in production
00:03:08.710 --> 00:03:09.520
in other clouds.
00:03:09.520 --> 00:03:14.590
You can do that, it runs best
on Azure, but you can do it all.
00:03:14.590 --> 00:03:17.709
So it's a very flexible offering
around all these things.
00:03:19.030 --> 00:03:22.100
When you look at the spectrum
of what you can do in terms of
00:03:22.100 --> 00:03:24.900
Service Fabric as well as being
a distributed system platform
00:03:24.900 --> 00:03:26.880
which contains orchestrators,
and
00:03:26.880 --> 00:03:29.790
the fact that it can deploy
sorta processes on machines, we
00:03:29.790 --> 00:03:34.110
provide a rich set of productive
programming models and
00:03:34.110 --> 00:03:37.040
we provide reliable services
programming model that helps you
00:03:37.040 --> 00:03:40.000
build instances of stateless and
stateful services.
00:03:40.000 --> 00:03:42.840
We layer on top of that our
hugely popular Actor Model
00:03:42.840 --> 00:03:44.990
that allows you to create these
individual little objects that
00:03:44.990 --> 00:03:48.440
have their states and
code encapsulated.
00:03:48.440 --> 00:03:51.480
And you can create millions
of those across a cluster.
00:03:51.480 --> 00:03:54.599
And then we're great advocates,
we love asp.net core, and
00:03:54.599 --> 00:03:57.730
.net core run time and
hosting all those onto WebX.
00:03:57.730 --> 00:03:59.950
But of course on this journey
often you don't necessarily
00:03:59.950 --> 00:04:02.470
start with that, often you
start with some existing code.
00:04:02.470 --> 00:04:04.010
And so
you can bring executables,
00:04:04.010 --> 00:04:05.620
and run that on Service Fabric.
00:04:05.620 --> 00:04:08.210
And now increasingly
we've embraced and
00:04:08.210 --> 00:04:11.590
brought containers to Service
Fabric so you can run containers
00:04:11.590 --> 00:04:12.980
there as a first class, and
that's where we are gonna
00:04:12.980 --> 00:04:16.470
spend a lot of our time talking
about today and show how you
00:04:16.470 --> 00:04:19.130
augment that with our
programming models to take you
00:04:19.130 --> 00:04:21.789
on this journey of building a
microservices based application.
00:04:23.630 --> 00:04:25.050
Now it's hopeless
many of you know,
00:04:25.050 --> 00:04:27.610
you heard in Scott Guthrie's
keynotes we build
00:04:27.610 --> 00:04:30.060
our services on top
of Service Fabric.
00:04:30.060 --> 00:04:33.650
This things no longer called
.DB it's called Cosmos DB
00:04:33.650 --> 00:04:36.520
which is far more
flashy as a name.
00:04:36.520 --> 00:04:40.730
But nevertheless Service Fabric
is the underlying infrastructure
00:04:40.730 --> 00:04:44.370
on which these services
are built and huge numbers,
00:04:44.370 --> 00:04:47.080
millions of calls, obviously,
are run on Service Fabric.
00:04:47.080 --> 00:04:50.320
We say 30% of all Azure's
compute is actually running on
00:04:50.320 --> 00:04:53.220
Service Fabric in some form
with a lot of hosted services.
00:04:53.220 --> 00:04:56.790
So we truly think about this
thing as being designed for
00:04:56.790 --> 00:05:00.270
mission critical services
we bet our business on it.
00:05:00.270 --> 00:05:02.880
We be on our services on it and
we totally treat this in
00:05:02.880 --> 00:05:05.870
the same category that you
can build mission critical,
00:05:05.870 --> 00:05:08.570
tier one services on this
platform and that's exactly,
00:05:08.570 --> 00:05:10.530
what it's designed for.
00:05:10.530 --> 00:05:13.610
So we're unique we believe
amongst the cloud providers to
00:05:13.610 --> 00:05:17.020
give you the same code and the
same platform that we've just
00:05:17.020 --> 00:05:20.230
rolled out across our services a
few days before in many cases or
00:05:20.230 --> 00:05:21.470
weeks before in testing.
00:05:21.470 --> 00:05:24.530
And then give it to on
regular cadenced pace, so
00:05:24.530 --> 00:05:27.230
it's a very interesting platform
in a way we're looking at.
00:05:28.470 --> 00:05:29.970
We've had a slew of customers,
00:05:29.970 --> 00:05:32.380
huge numbers since we
released GA last year.
00:05:32.380 --> 00:05:35.405
This is a few of them who've
got into production or
00:05:35.405 --> 00:05:36.675
close into production.
00:05:36.675 --> 00:05:38.275
And we've been working very
closely with them all and
00:05:38.275 --> 00:05:40.755
we love nothing more to engage
with you as a customer,
00:05:40.755 --> 00:05:43.235
either down at the booth or
send us direct with email.
00:05:43.235 --> 00:05:45.195
Be more than happy to
spend time with you and
00:05:45.195 --> 00:05:46.625
to make you successful
with this platform,
00:05:46.625 --> 00:05:48.885
it's one of our joys
that we effectively do.
00:05:48.885 --> 00:05:52.385
So let's take you on
this journey about
00:05:52.385 --> 00:05:55.130
what you're gonna do and what
you can do with service fabric.
00:05:55.130 --> 00:05:58.050
and how is it we
think about migrating
00:05:58.050 --> 00:06:00.960
traditional applications and
code you have today.
00:06:00.960 --> 00:06:03.910
So typically you might
have some code today,
00:06:03.910 --> 00:06:06.230
wrapped up in some packages and
execute below some form.
00:06:06.230 --> 00:06:09.430
And the first step we talked
about is how you can move that
00:06:09.430 --> 00:06:11.790
to service summary and
just use it for
00:06:11.790 --> 00:06:14.790
distributed systems platform
in order for deployment and
00:06:14.790 --> 00:06:16.360
management of that
piece of code.
00:06:16.360 --> 00:06:19.350
You can deploy executables
across this cluster of machines,
00:06:19.350 --> 00:06:20.280
you can do upgrades,
00:06:20.280 --> 00:06:21.740
you can do health
monitoring around them all,
00:06:21.740 --> 00:06:24.570
and you get all the benefits of
a platform effectively but you
00:06:24.570 --> 00:06:27.880
can manage and deploy that code
whatever that piece of code is.
00:06:27.880 --> 00:06:30.395
Customers who do JVM's and
executables and
00:06:30.395 --> 00:06:33.120
Node.js applications and
they just bundle them all up and
00:06:33.120 --> 00:06:35.030
then host them on
Service Fabric and
00:06:35.030 --> 00:06:36.960
get them all running
as our first step.
00:06:36.960 --> 00:06:38.790
Of course increasingly
as well now this is
00:06:38.790 --> 00:06:42.260
becoming containerised and
00:06:42.260 --> 00:06:45.530
after that we see people go
now I've got my code running
00:06:45.530 --> 00:06:49.800
I now want to take advantage of
adding new little pieces around.
00:06:49.800 --> 00:06:53.270
So typically using service
product program models, but
00:06:53.270 --> 00:06:56.960
you don't have to, you know, you
can deploy other services around
00:06:56.960 --> 00:07:00.250
all this, where those services
are independently scalable,
00:07:00.250 --> 00:07:03.950
versionable and deployable as
individual micro services.
00:07:03.950 --> 00:07:06.950
You could choose to tackle that
big model and then decide,
00:07:06.950 --> 00:07:10.230
because of deployment agility or
because of scale out,
00:07:10.230 --> 00:07:13.700
you tease a piece of that out,
and finally you might end up in
00:07:13.700 --> 00:07:17.060
this fully Microservices world
where you end up with a full
00:07:17.060 --> 00:07:20.530
application is distributed or
a numerous little bits of code,
00:07:20.530 --> 00:07:22.800
our independent versionable,
scalable.
00:07:22.800 --> 00:07:25.380
But the point is as you can stop
any point in this journey it
00:07:25.380 --> 00:07:26.440
doesn't matter.
00:07:26.440 --> 00:07:28.080
Here you can take
advantage of the platform.
00:07:28.080 --> 00:07:30.270
We are not telling you to go lay
to the right or to the left.
00:07:30.270 --> 00:07:31.880
Its just the thing that
you choose depending
00:07:31.880 --> 00:07:33.480
on your business need.
00:07:33.480 --> 00:07:35.960
Now last time,
we spent a lot of time on
00:07:35.960 --> 00:07:39.020
talking about Microservices and
the platform we build it all.
00:07:39.020 --> 00:07:41.710
We're gonna spend now
a bit of time to go back
00:07:41.710 --> 00:07:44.850
to updating the journey to
talk about Service Fabric and
00:07:44.850 --> 00:07:46.730
how it works as
a container orchestrator.
00:07:48.590 --> 00:07:49.510
So I'm sure
00:07:49.510 --> 00:07:51.540
many of you are aware of
containers and what they do.
00:07:51.540 --> 00:07:52.660
It's an image based format,
00:07:52.660 --> 00:07:54.930
Docker being one of the most
popular types of things.
00:07:54.930 --> 00:07:57.170
It's built into Windows Server,
and in Windows Server,
00:07:57.170 --> 00:07:58.240
you can take a base image and
00:07:58.240 --> 00:08:00.310
layer a number of different
images on top of that,
00:08:00.310 --> 00:08:02.370
push out into some
registry either Azure.
00:08:02.370 --> 00:08:04.380
Container registry,
Docker or Hub, and
00:08:04.380 --> 00:08:06.490
pull down those images and
deploy them all, and
00:08:06.490 --> 00:08:10.060
you get a lot of the benefits
of a self contained package,
00:08:10.060 --> 00:08:12.068
with all those dependencies
with inside this all,
00:08:12.068 --> 00:08:14.804
that you can deploy and
provide result constraints to.
00:08:14.804 --> 00:08:17.396
You know, wonderful technology
if it fits your particular
00:08:17.396 --> 00:08:19.988
scenario, and so this is the
classic way that we think about
00:08:19.988 --> 00:08:23.790
containers Now Service Fabric
has been a container
00:08:23.790 --> 00:08:25.890
orchestrator for
many, many years, and
00:08:25.890 --> 00:08:29.380
it's been highly optimized over
all these large workloads.
00:08:29.380 --> 00:08:32.260
If you think about how we run
millions of Azure databases,
00:08:32.260 --> 00:08:34.140
some of them are ginormous,
some of them are small.
00:08:34.140 --> 00:08:37.310
We gotta think about
all the packing density
00:08:37.310 --> 00:08:38.010
around these things.
00:08:38.010 --> 00:08:40.570
We have to highly optimize
the efficiency of these clusters
00:08:40.570 --> 00:08:41.750
because it costs us money.
00:08:42.840 --> 00:08:45.360
We've got to make sure we can
get the best we can out of our
00:08:45.360 --> 00:08:49.095
several hundred machine cluster
when we run Azure databases.
00:08:49.095 --> 00:08:52.480
And we've done that a lot with
processes over the years and
00:08:52.480 --> 00:08:54.130
we've put other constraints
around them all.
00:08:54.130 --> 00:08:57.780
But, we're super excited that
Service Fabric now is GA,
00:08:58.830 --> 00:09:01.670
is a Windows Container
Orchestrator and you can take
00:09:01.670 --> 00:09:04.750
this into production and
orchestrate containers as well
00:09:04.750 --> 00:09:07.990
as processes inside your
applications that you deploy.
00:09:07.990 --> 00:09:09.820
And that was the announcement
that Scott and
00:09:09.820 --> 00:09:12.890
Guthrie did in the keynote, and
we've followed that a little
00:09:12.890 --> 00:09:14.380
more with other
announcements around here.
00:09:14.380 --> 00:09:18.150
So this is a great achievement
that we're looking forward to,
00:09:18.150 --> 00:09:20.780
to bringing all your
Windows workloads.
00:09:20.780 --> 00:09:23.990
And as we look towards the rest
of the year, you'll be able to
00:09:23.990 --> 00:09:27.590
do full orchestration as
well on top of Linux and
00:09:27.590 --> 00:09:28.610
our other platforms.
00:09:28.610 --> 00:09:31.790
In fact, it's worth noting that
every time we build features.
00:09:31.790 --> 00:09:33.530
Every time we talk
about a feature
00:09:33.530 --> 00:09:35.150
that feature is in
Windows Analytics.
00:09:35.150 --> 00:09:37.780
We don't differentiate
between those in any way.
00:09:37.780 --> 00:09:40.600
So if you go and take our
Linux offering right now,
00:09:40.600 --> 00:09:41.760
it's a container orchestrate.
00:09:41.760 --> 00:09:43.000
And same about to
talk about today.
00:09:44.730 --> 00:09:47.630
Okay, let's just briefly go
through some of the capabilities
00:09:47.630 --> 00:09:50.770
of what we mean by you've now
got a container orchestrator.
00:09:50.770 --> 00:09:51.690
What does it do for me?
00:09:51.690 --> 00:09:52.387
What have been given?
00:09:52.387 --> 00:09:55.358
So, clearly, the most obvious
one is it'll pull down container
00:09:55.358 --> 00:09:57.681
images, deploy them across
a set of machines, and
00:09:57.681 --> 00:09:59.465
orchestrate them and
activate them And
00:09:59.465 --> 00:10:01.519
it'll do the image-based
deployment, and
00:10:01.519 --> 00:10:04.167
it'll also do the authentication
against the registry or
00:10:04.167 --> 00:10:05.730
wherever you have your images.
00:10:05.730 --> 00:10:08.700
You can also provide a set of
environment variables, and
00:10:08.700 --> 00:10:11.680
that's a very common way of
configuring the container
00:10:11.680 --> 00:10:13.430
in terms of some settings
that you may have.
00:10:14.780 --> 00:10:18.290
The next thing it does,
we can hook up volume drivers.
00:10:18.290 --> 00:10:21.190
We've been create volume driver
support in the Linux as well as
00:10:21.190 --> 00:10:22.800
quite a lot of volume
drivers there already for
00:10:22.800 --> 00:10:23.950
different external storage or
00:10:23.950 --> 00:10:25.440
storage options that
you can hook up to.
00:10:25.440 --> 00:10:27.570
It's also a predominant thing.
00:10:27.570 --> 00:10:30.080
You'll see volume drivers
coming out from us.
00:10:31.210 --> 00:10:32.690
We've got networking
capabilities.
00:10:32.690 --> 00:10:37.926
The networking is
built in the container
00:10:37.926 --> 00:10:42.854
ports as a bridge
type network where it
00:10:42.854 --> 00:10:48.398
maps the container
ports to the underlined
00:10:48.398 --> 00:10:53.942
host to their ports so
you do that container
00:10:53.942 --> 00:10:59.870
to port mapping around
the [INAUDIBLE].
00:10:59.870 --> 00:11:02.320
And then because the naming
service is our central,
00:11:03.770 --> 00:11:06.380
resolver for all the names
inside the service.
00:11:06.380 --> 00:11:08.460
In order to make your
lives easier with existing
00:11:08.460 --> 00:11:11.820
applications we
included as part of
00:11:11.820 --> 00:11:15.340
the service fabric offering in
this release a DNS service now.
00:11:15.340 --> 00:11:17.530
So if you want to
use DNS protocol for
00:11:17.530 --> 00:11:20.460
resolving the location
between your containers.
00:11:20.460 --> 00:11:23.550
And then that will call down on
to the underlying naming service
00:11:23.550 --> 00:11:24.810
to be able to do the resolution.
00:11:24.810 --> 00:11:27.590
It makes it consumably
easier to effectively
00:11:27.590 --> 00:11:30.580
do cross container cost for
particularly for stateless apps.
00:11:31.870 --> 00:11:34.500
Of course to get results
governance on those containers
00:11:34.500 --> 00:11:36.630
we apply resource
governance policies for
00:11:36.630 --> 00:11:39.280
CPU and for
memory and the things
00:11:39.280 --> 00:11:41.850
that come out of the box really
with the Windows Containers.
00:11:41.850 --> 00:11:44.210
But we've also gone and done
it where we've provided those
00:11:44.210 --> 00:11:46.730
resource constraints
on processes as well.
00:11:46.730 --> 00:11:49.610
So if you're still in that wanna
just launch a set of processes
00:11:49.610 --> 00:11:52.360
and I don't wanna go through
the whole build process and
00:11:52.360 --> 00:11:55.050
things with a container, we've
allowed you to do that as well.
00:11:55.050 --> 00:11:57.820
Which is a unique offering
because that allows
00:11:57.820 --> 00:12:00.350
you to progressively just
do it to existing workloads
00:12:00.350 --> 00:12:00.879
that might be running.
00:12:02.550 --> 00:12:06.540
We worked with Hyper-V, in terms
of Hyper-V isolation mode.
00:12:06.540 --> 00:12:08.850
Corey Sanders yesterday
announced a couple of new SKUs
00:12:08.850 --> 00:12:12.980
that are coming, sorry image
sort of VM types that are coming
00:12:12.980 --> 00:12:16.020
to Azure,
which are DB3 series and
00:12:16.020 --> 00:12:19.040
EV3 series which have
Hyper-V isolation turned on.
00:12:19.040 --> 00:12:22.020
So you wanna have
a hyper V isolation mode
00:12:22.020 --> 00:12:23.690
on your containers when
they run inside Azure,
00:12:23.690 --> 00:12:26.240
you can pick those queues
outside of that of course
00:12:26.240 --> 00:12:29.970
you can just take your own
premise hardware turn on hyper V
00:12:29.970 --> 00:12:33.900
isolation and run there as
free isolated containers after
00:12:33.900 --> 00:12:34.860
running that with
their own kernel.
00:12:34.860 --> 00:12:37.390
And then finally,
the interesting
00:12:37.390 --> 00:12:40.050
things that we've added in a
special release that we've done
00:12:40.050 --> 00:12:42.950
as part of our preview release
Is that we've added support for
00:12:42.950 --> 00:12:43.860
Docker Compose.
00:12:44.990 --> 00:12:48.070
And what this means is that we
first class understand what
00:12:48.070 --> 00:12:50.500
Docker Compose looks like,
the model for
00:12:50.500 --> 00:12:53.160
it as a deploying model, and
we'll understand that and
00:12:53.160 --> 00:12:55.780
use that as a way of launching
instead of containers that you
00:12:55.780 --> 00:13:00.160
can pull down and effectively
you can take existing lift and
00:13:00.160 --> 00:13:03.080
shift applications because you
run them on Docker Enterprise or
00:13:03.080 --> 00:13:06.240
some other orchestrator that
has the composer built in.
00:13:06.240 --> 00:13:12.000
And use those to launch
inside service farming.
00:13:12.000 --> 00:13:15.370
So let's talk about [CROSSTALK]
So here's where we start.
00:13:15.370 --> 00:13:17.451
So you have some
like Mark mentioned,
00:13:17.451 --> 00:13:20.052
you have some application
that you have today,
00:13:20.052 --> 00:13:23.043
it's not built on service
fabric, it's not meant for
00:13:23.043 --> 00:13:26.510
service fabric but You wanna get
the benefits of the platform.
00:13:26.510 --> 00:13:28.470
You wanna run it on Service
Fabric for all the benefits,
00:13:28.470 --> 00:13:30.270
fail over, upgrades,
that sort of thing.
00:13:30.270 --> 00:13:33.390
So we start with our
existing application, and
00:13:33.390 --> 00:13:36.210
what we do is we take this,
like Mark was saying,
00:13:36.210 --> 00:13:37.430
we put this into Docker Compose.
00:13:37.430 --> 00:13:40.410
So this is that Docker Compose
capability we added just
00:13:40.410 --> 00:13:42.020
recently In this case,
00:13:42.020 --> 00:13:44.210
this is an example application
that we're gonna actually today,
00:13:44.210 --> 00:13:47.300
we're gonna kinda walk through
it where we've taken a legacy or
00:13:47.300 --> 00:13:51.110
we'll say a classic ASP.NET
application which runs on iOS,
00:13:51.110 --> 00:13:53.000
could be on web forms,
could be on classic MVC,.
00:13:53.000 --> 00:13:55.540
The point is,
it's not running ASP.NET Core.
00:13:55.540 --> 00:13:57.200
So it's not self hostable and
00:13:57.200 --> 00:13:59.880
if you used service fabric in
the past, you've probably heard
00:13:59.880 --> 00:14:03.390
say something like sorry
you can't use IIS.
00:14:03.390 --> 00:14:05.870
Because IIS is
an EXC orchestrator.
00:14:05.870 --> 00:14:07.460
We're on EXC orchestrator.
00:14:07.460 --> 00:14:08.680
They don't really work
well all together.
00:14:08.680 --> 00:14:11.990
So the answer to that is you pop
those things into containers and
00:14:11.990 --> 00:14:13.750
now it's easier than ever
to just take that and
00:14:13.750 --> 00:14:16.540
host it on service fabric
by using Docker compose.
00:14:16.540 --> 00:14:19.310
Or perhaps you have
a Docker compose already.
00:14:19.310 --> 00:14:22.220
Now the way this particular
application works that we're
00:14:22.220 --> 00:14:23.800
going to show is there's
a client application.
00:14:23.800 --> 00:14:26.950
There's a client,
it's a single-page application.
00:14:26.950 --> 00:14:29.180
Now, when this thing makes a
connection out to our front-end
00:14:29.180 --> 00:14:31.690
service, what we've added in
Service Fabric is a DNS service.
00:14:31.690 --> 00:14:34.620
So, the way these two back end
services communicate now is
00:14:34.620 --> 00:14:35.440
through this DNS.
00:14:35.440 --> 00:14:39.330
And the DNS service runs as
a service in Service Fabric.
00:14:39.330 --> 00:14:42.270
And it works like
anyway DNS does right?
00:14:42.270 --> 00:14:44.840
So it'll give you an IP address
when you try to resolve hostname
00:14:44.840 --> 00:14:47.980
and then you can connect
directly to that backend service
00:14:47.980 --> 00:14:51.460
so I think Mark's
going to show us that
00:14:51.460 --> 00:14:52.510
>> Let's do demo time
00:14:52.510 --> 00:14:54.820
>> That's enough talk let's see
00:14:54.820 --> 00:14:57.400
it￼ yet here you go
>> Okay,
00:14:57.400 --> 00:14:57.940
here we have-
>> Thank you.
00:14:57.940 --> 00:14:59.120
>> These are our applications.
00:14:59.120 --> 00:15:00.240
So as you can see
here on the right,
00:15:00.240 --> 00:15:01.640
we have our two
legacy applications.
00:15:01.640 --> 00:15:04.690
We have our Web App and
we have our Desktop App here.
00:15:04.690 --> 00:15:07.400
And all we did is when creating
these apps, we went in and
00:15:07.400 --> 00:15:10.750
did add Docker Compose
all of these.
00:15:10.750 --> 00:15:14.130
It creates a Docker Compose file
for these legacy applications.
00:15:14.130 --> 00:15:16.420
And as you can see inside here,
inside the controllers,
00:15:16.420 --> 00:15:18.220
if you look at this
web app inside here,
00:15:18.220 --> 00:15:20.970
I just have this controller
inside here, and all it simply
00:15:20.970 --> 00:15:24.730
does is it just uses a DNS
call to my other service.
00:15:24.730 --> 00:15:28.270
So it just does
a call here to say
00:15:28.270 --> 00:15:30.450
to my enterprise data app
here in a particular port.
00:15:31.660 --> 00:15:34.230
And my other controller here
00:15:34.230 --> 00:15:36.920
does some data processing
in spite all of this.
00:15:36.920 --> 00:15:39.950
So nothing changes about my
application just doing straight
00:15:39.950 --> 00:15:40.910
http call.
00:15:40.910 --> 00:15:43.320
Of course my docker compose for
00:15:43.320 --> 00:15:47.100
this particular app that I have
consists of these two services.
00:15:47.100 --> 00:15:51.210
My legacy enterprise data app,
my legacy enterprise web app
00:15:51.210 --> 00:15:54.260
These two things are the DNS
names that get resolved.
00:15:54.260 --> 00:15:56.930
And of course, I can tell it
where to pull the image down
00:15:56.930 --> 00:16:00.340
from, the Docker hub, and
to open up some ports.
00:16:00.340 --> 00:16:02.310
So, I haven't touched
anything by this application.
00:16:02.310 --> 00:16:03.130
There's nothing in here
00:16:03.130 --> 00:16:05.330
particularly about
the Service Fabric just yet.
00:16:05.330 --> 00:16:07.460
But, what I'm able to do
is I'm able to go and
00:16:07.460 --> 00:16:08.970
look in this cluster
here that I have.
00:16:08.970 --> 00:16:11.570
This is a Service Fabric
cluster I'm hooked up to.
00:16:11.570 --> 00:16:15.050
you see now that inside here
I have a DNS service running.
00:16:15.050 --> 00:16:16.980
Which can do all our
name resolution for me.
00:16:16.980 --> 00:16:20.590
I've got no app deployed so how
is it that I can deploy my app.
00:16:20.590 --> 00:16:23.750
I can now go back and
take a docu command, sorry,
00:16:23.750 --> 00:16:28.690
service command here called,
new service compose application.
00:16:28.690 --> 00:16:30.540
And I can simply give you
the name of the application I
00:16:30.540 --> 00:16:34.210
wanna launch and say here's
that compose file that you just
00:16:34.210 --> 00:16:35.900
pulled down and
you already had running.
00:16:35.900 --> 00:16:38.830
So let's take this thing here,
just run this and
00:16:38.830 --> 00:16:40.460
what this will do is it will
00:16:41.480 --> 00:16:44.320
deploy that application instance
inside the cluster here.
00:16:44.320 --> 00:16:45.480
It's creating here.
00:16:45.480 --> 00:16:47.520
It'll create an instance
of the Legacy app and
00:16:47.520 --> 00:16:51.240
it pulls down two instances
of the front end service and
00:16:51.240 --> 00:16:52.700
the back end service here.
00:16:52.700 --> 00:16:53.880
These are the ones
running here and for
00:16:53.880 --> 00:16:56.730
each of these has launched
a single instance inside here.
00:16:56.730 --> 00:16:57.250
So here we are.
00:16:57.250 --> 00:16:58.770
We have a single
instance as web app and
00:16:58.770 --> 00:17:02.880
a single instance of
this legacy data app.
00:17:02.880 --> 00:17:04.080
Now I can go in here actually.
00:17:04.080 --> 00:17:06.200
I can do a I can do a new
action we added in here.
00:17:06.200 --> 00:17:07.750
I can do scale service.
00:17:07.750 --> 00:17:11.460
I can do minus one Inside here,
now I can hit scale service.
00:17:11.460 --> 00:17:14.760
And what that will do is it
will scale out this particular
00:17:14.760 --> 00:17:17.520
service across the set of
front end machines here now.
00:17:17.520 --> 00:17:20.400
And you'll see that getting
deployed there in a moment
00:17:20.400 --> 00:17:21.540
as it scales them
out across there.
00:17:21.540 --> 00:17:23.760
And the minus one indicates,
for you who don't know,
00:17:23.760 --> 00:17:25.840
deploy these across all
the machines inside my cluster.
00:17:25.840 --> 00:17:28.350
So now it's deploy the
containerized image across each
00:17:28.350 --> 00:17:29.900
one of those is
downloading it and
00:17:29.900 --> 00:17:32.920
deploying it on those
particular machines.
00:17:32.920 --> 00:17:35.950
So, now I've got my web front
and running my own machines and
00:17:35.950 --> 00:17:37.510
have a single back
end at the back here.
00:17:37.510 --> 00:17:42.470
Now, so I've just deployed my
app I can go into the site here.
00:17:42.470 --> 00:17:45.710
I can do refresh on
the end point here.
00:17:45.710 --> 00:17:47.570
This will hit me as
your load balancer.
00:17:47.570 --> 00:17:49.840
It will hit one of
those end points.
00:17:49.840 --> 00:17:52.600
It will start accessing
the container on there.
00:17:52.600 --> 00:17:56.690
It will load up the container on
the first time it comes through
00:17:56.690 --> 00:17:59.750
with the,
hit one of the sites that is yet
00:17:59.750 --> 00:18:00.760
to warm up to this container.
00:18:00.760 --> 00:18:02.670
And we'll launch it in
the moment inside here.
00:18:02.670 --> 00:18:04.150
There we go,
there's out app running.
00:18:04.150 --> 00:18:05.900
From our web front end.
00:18:05.900 --> 00:18:08.120
Now what I can do is I can
generate report here so
00:18:08.120 --> 00:18:10.470
I can do one, new report.
00:18:10.470 --> 00:18:15.510
This is just a little UI
that we have, reports and
00:18:15.510 --> 00:18:18.490
I can say start and call on
that backend service here.
00:18:18.490 --> 00:18:20.840
And there it is as I was calling
on to the backend service
00:18:20.840 --> 00:18:23.800
through the DNS resolution
between these two services.
00:18:23.800 --> 00:18:26.846
No change of code, nothing to
Service Fabric, just compose,
00:18:26.846 --> 00:18:30.302
deploy the side there, running
my legacy IaaS applications.
00:18:30.302 --> 00:18:38.010
>> [APPLAUSE]
>> So how do you get rid of it?
00:18:38.010 --> 00:18:39.900
You get rid of it with
a single PowerShell command.
00:18:39.900 --> 00:18:42.800
Remove Service
Fabric PowerShell.
00:18:42.800 --> 00:18:45.370
And so
I can just kill this thing here.
00:18:45.370 --> 00:18:49.610
And we switch back here and
wrong one.
00:18:49.610 --> 00:18:52.840
Go back here and
it's disappeared already.
00:18:52.840 --> 00:18:54.710
Well, there you go so
it's no longer here.
00:18:54.710 --> 00:18:57.570
So that's as
straightforward as it is to
00:18:57.570 --> 00:19:00.710
deploy compose as an application
inside of these and
00:19:00.710 --> 00:19:04.500
it makes it extremely simple for
you to take those legacy apps.
00:19:04.500 --> 00:19:05.769
That's part one of your journey.
00:19:06.950 --> 00:19:07.770
Let us switch back.
00:19:07.770 --> 00:19:09.030
>> Switching back.
00:19:09.030 --> 00:19:11.660
Here you go.
00:19:11.660 --> 00:19:14.560
>> What are we up to next?
00:19:14.560 --> 00:19:17.300
So, okay, a customer who
effectively has service fabric
00:19:17.300 --> 00:19:19.150
running in production today.
00:19:19.150 --> 00:19:23.330
If you go to http://alaska.com
and you buy a ticket for
00:19:23.330 --> 00:19:26.510
Alaska Airlines They set up
a Service Fabric cluster.We've
00:19:26.510 --> 00:19:27.730
been working with them for
awhile now.
00:19:27.730 --> 00:19:29.290
They've been having this
running in production for
00:19:29.290 --> 00:19:30.210
several months.
00:19:30.210 --> 00:19:32.850
We gave them early preview
bits that we stood by
00:19:32.850 --> 00:19:35.540
in terms of guarantees
around it all.
00:19:35.540 --> 00:19:38.850
And they launched and
run alaska.com as a website.
00:19:38.850 --> 00:19:42.250
It's a critical business
to Alaska in terms of how
00:19:42.250 --> 00:19:44.220
all their revenue comes
through all of that.
00:19:44.220 --> 00:19:45.453
It's hosted on
Service Fabric cluster.
00:19:45.453 --> 00:19:48.439
They simply took their IIS
applications Hosted them inside
00:19:48.439 --> 00:19:51.006
Docker containers and
did exactly what I just did to
00:19:51.006 --> 00:19:53.169
deploy that across
a cluster of machines.
00:19:53.169 --> 00:19:55.793
And now they can just scale
it up and scale it down.
00:19:55.793 --> 00:19:58.471
And for them what was exciting
for them is that they have a lot
00:19:58.471 --> 00:20:01.365
of Black Friday events and times
when they will have big demand,
00:20:01.365 --> 00:20:04.203
they can scale a cluster up and
then when they have less demand,
00:20:04.203 --> 00:20:07.038
they scale it down and
save themselves a bit of money.
00:20:07.038 --> 00:20:10.010
So, it was a great example of
one of the many customers now
00:20:10.010 --> 00:20:12.830
that are starting to move these
IS workloads and hostable
00:20:12.830 --> 00:20:16.400
service [INAUDIBLE] and we're
very excited, able to do this.
00:20:16.400 --> 00:20:18.480
And we're hoping in
the next few weeks,
00:20:18.480 --> 00:20:19.470
well actually even
less than a week,
00:20:19.470 --> 00:20:22.450
we'll publish a technical
about how they did all that.
00:20:24.020 --> 00:20:25.260
As we look towards the future,
00:20:25.260 --> 00:20:26.870
what are we going to
do with containers?
00:20:26.870 --> 00:20:28.520
And this is rapidly coming.
00:20:28.520 --> 00:20:30.140
We're talking about
in the next release.
00:20:30.140 --> 00:20:31.710
We release every eight weeks.
00:20:31.710 --> 00:20:33.190
We just go bang, bang, bang.
00:20:33.190 --> 00:20:35.600
New releases, actually it
will be four weeks release.
00:20:35.600 --> 00:20:38.840
Release features, and then
bug updates every four weeks.
00:20:38.840 --> 00:20:39.580
But in the next one,
00:20:39.580 --> 00:20:41.320
we're going to do a huge
amount with networks.
00:20:41.320 --> 00:20:44.170
First, we're going to allow you
to specify an isolated network.
00:20:44.170 --> 00:20:46.420
So when you deploy
an application,
00:20:46.420 --> 00:20:49.690
you can set an isolated network
within all the services that
00:20:49.690 --> 00:20:51.010
run inside your application.
00:20:51.010 --> 00:20:52.950
So only those services,
00:20:52.950 --> 00:20:55.850
only those containers or those
services can see each other
00:20:55.850 --> 00:20:57.520
inside that application
deployment.
00:20:57.520 --> 00:21:00.060
So it allows you to be
fully isolated multi-tenant
00:21:00.060 --> 00:21:02.920
environment or
any application can only see
00:21:02.920 --> 00:21:04.760
the other services
within inside at all.
00:21:04.760 --> 00:21:07.620
Super cool because now you can
truly run all those independent
00:21:07.620 --> 00:21:11.548
workloads without them seeing
the NS calls or other ones.
00:21:11.548 --> 00:21:16.170
[APPLAUSE] So, this is cool.
00:21:16.170 --> 00:21:18.950
This is a bit like overlay
networking you know this.
00:21:18.950 --> 00:21:20.460
But we're going to go
further than that.
00:21:20.460 --> 00:21:21.620
The other thing that
we're going to do,
00:21:21.620 --> 00:21:24.310
is we allow you to host all your
containers inside your cluster.
00:21:24.310 --> 00:21:26.330
And whatever this
networking mode is,
00:21:26.330 --> 00:21:29.270
take your cluster of 20
machines or whatever it is.
00:21:29.270 --> 00:21:30.920
And all the containers
that get launched inside
00:21:30.920 --> 00:21:33.710
of that will have
fixed IP addresses.
00:21:33.710 --> 00:21:36.680
And, you'll treat them all
under a single IP network.
00:21:36.680 --> 00:21:38.810
You'll think of them, just
think of them like VMs now, but
00:21:38.810 --> 00:21:39.570
they're just containers.
00:21:39.570 --> 00:21:41.830
They're all addressable
with fixed IP address.
00:21:41.830 --> 00:21:43.992
You can include them in part
of any of the networking
00:21:43.992 --> 00:21:46.509
technologies inside Azure
like network security groups,
00:21:46.509 --> 00:21:47.275
load balancers.
00:21:47.275 --> 00:21:50.430
You'll be able to call for them
from the outside world as well.
00:21:50.430 --> 00:21:53.200
And if the containers failover
when they start up on another
00:21:53.200 --> 00:21:55.830
machine, they'll retain
that fixed IP address.
00:21:55.830 --> 00:21:58.960
So now you'll have this world of
effectively containers that have
00:21:58.960 --> 00:22:01.690
visible across the cluster
machines with fixed IP
00:22:01.690 --> 00:22:04.800
addresses, as if you're
completely obstructed away from
00:22:04.800 --> 00:22:06.360
the underline host itself.
00:22:06.360 --> 00:22:08.770
And you're just dealing with
containers inside there.
00:22:08.770 --> 00:22:11.340
A super cool features
capabilities is how you can undo
00:22:11.340 --> 00:22:13.230
networking capabilities
inside here.
00:22:13.230 --> 00:22:15.630
These Win developments now, and
00:22:15.630 --> 00:22:18.040
you'll see them
coming very soon.
00:22:18.040 --> 00:22:20.430
We actually even try to get them
in for this last release but
00:22:20.430 --> 00:22:21.570
it was just not possible.
00:22:21.570 --> 00:22:22.790
But, active and
00:22:22.790 --> 00:22:27.770
development and we think this
the bridge network full of its
00:22:27.770 --> 00:22:31.850
host network path of mapping
wonders is a bit awkward to use.
00:22:31.850 --> 00:22:33.210
These are the ones that
effectively that will be
00:22:33.210 --> 00:22:36.180
the ones that will be
the predominant use of network
00:22:36.180 --> 00:22:37.650
inside there for containers.
00:22:38.800 --> 00:22:39.778
But, we're going to do more.
00:22:39.778 --> 00:22:42.700
We're going to make sure that
when you deploy a cluster inside
00:22:42.700 --> 00:22:45.170
Azure, we're going to configure
those machines with the right
00:22:45.170 --> 00:22:47.400
resource governance
metrics inside there.
00:22:47.400 --> 00:22:50.610
So that already in advance,
we know that this machine has
00:22:50.610 --> 00:22:53.650
the metrics for the number of
CPUs or the number of memory so
00:22:53.650 --> 00:22:56.820
it gets precalculated for you so
when you say, my cluster or
00:22:56.820 --> 00:22:59.940
my container just needs one
call, it's already preconfigured
00:22:59.940 --> 00:23:02.958
the number of calls it knows
about for some of the VMs.
00:23:02.958 --> 00:23:04.480
We're going to make sure
that the service Fabric
00:23:04.480 --> 00:23:07.200
programming models reliable
actors and reliable containers
00:23:07.200 --> 00:23:10.698
run inside containers and
you can deploy them inside here.
00:23:10.698 --> 00:23:13.200
We're going to make sure that we
have deeper integration with VS
00:23:13.200 --> 00:23:14.200
tooling.
00:23:14.200 --> 00:23:16.850
It's a little bit awkward
right now because we have
00:23:16.850 --> 00:23:19.430
project outside of
Service Fabric.
00:23:19.430 --> 00:23:21.220
We're going to integrate and
pull those together.
00:23:21.220 --> 00:23:21.740
And of course,
00:23:21.740 --> 00:23:24.510
we'll always make sure that
Service Fabric explorer
00:23:24.510 --> 00:23:26.890
has more container capabilities.
00:23:26.890 --> 00:23:29.180
And then we are going to do
exciting things as well for
00:23:29.180 --> 00:23:30.040
stateful compute.
00:23:30.040 --> 00:23:33.720
We are stateful compute lovers.
00:23:33.720 --> 00:23:36.300
And we know that a lot of
people have difficulty with
00:23:36.300 --> 00:23:37.790
state management.
00:23:37.790 --> 00:23:39.280
And so one thing we
are going to build and
00:23:39.280 --> 00:23:43.460
have building, a volume driver
that you can connect up to
00:23:43.460 --> 00:23:46.220
your container, where the volume
driver, there is going to be
00:23:46.220 --> 00:23:48.910
a volume driver for Azure by the
way to externalize storage but
00:23:48.910 --> 00:23:50.740
service fabric is
a storage technology.
00:23:50.740 --> 00:23:53.540
It replicates the state, so
we can put a volume driver
00:23:53.540 --> 00:23:55.690
effectively, onto
your container,
00:23:55.690 --> 00:23:58.120
to replicate this state
across the local machines and
00:23:58.120 --> 00:23:59.910
make them highly available for
you.
00:23:59.910 --> 00:24:02.060
And it is incredibly fast.
00:24:02.060 --> 00:24:06.830
And the failover times of your
container will be the fact
00:24:06.830 --> 00:24:10.770
that it moves over to another
machine, and then remounts
00:24:10.770 --> 00:24:13.220
the volume, and it recovers
all the data from there.
00:24:13.220 --> 00:24:16.824
So let me show you a little
demo of what this pre-prototype
00:24:16.824 --> 00:24:17.630
looks like.
00:24:17.630 --> 00:24:20.818
Press that eight, go.
00:24:20.818 --> 00:24:24.546
So here I have here I have
a cluster and this is nearly
00:24:24.546 --> 00:24:29.450
prototype by the way so please
don't judge it on just yet.
00:24:29.450 --> 00:24:31.480
But it's a cluster
of machines and
00:24:31.480 --> 00:24:35.160
inside here is the containerized
application and all I have to do
00:24:35.160 --> 00:24:37.170
inside my containerized
application that's running.
00:24:37.170 --> 00:24:39.210
And there's a single instance
that's running here,
00:24:39.210 --> 00:24:42.250
is I put this volume driver
statement inside here.
00:24:42.250 --> 00:24:45.825
I've just said this container
is going to write everything to
00:24:45.825 --> 00:24:48.916
its C drive or
the data drive and when it does,
00:24:48.916 --> 00:24:51.252
it's going to write it
all out to this and
00:24:51.252 --> 00:24:54.910
you're gonna deal with all the
replication of all the states.
00:24:54.910 --> 00:24:57.630
So as a developer,
I just deal with the file IO.
00:24:57.630 --> 00:25:00.430
But the volume drive deals
with all the hard problems of
00:25:00.430 --> 00:25:01.470
replicating that state and
00:25:01.470 --> 00:25:06.850
making sure it gets recovered
this actual little app is
00:25:06.850 --> 00:25:09.150
I've got a little web endpoint
pointing on to this container,
00:25:09.150 --> 00:25:12.320
which shows a counter that's
counting away, that's connected.
00:25:12.320 --> 00:25:14.170
In fact, I can even reset
the counter here, so
00:25:14.170 --> 00:25:15.120
it's not from the beginning.
00:25:15.120 --> 00:25:18.400
So what I'm going to do, this is
running on node number two here.
00:25:18.400 --> 00:25:19.590
I can actually just go over and
00:25:19.590 --> 00:25:21.820
I'm going to restart
node number two.
00:25:21.820 --> 00:25:23.800
In the classic way we do all
of our fail over and and
00:25:23.800 --> 00:25:26.120
service fabric because we like,
we love fail over.
00:25:27.390 --> 00:25:29.730
I tell you what this We don't
like clicking on things though
00:25:29.730 --> 00:25:30.600
>> No I don't like clicking on
00:25:30.600 --> 00:25:32.820
anything, okay here we go,
there we go.
00:25:32.820 --> 00:25:35.310
I just found that this is the
easiest way of doing this thing.
00:25:35.310 --> 00:25:37.430
So we're going to
fail over node two,
00:25:37.430 --> 00:25:40.420
let's watch this counter over
here, so we've disabled node
00:25:40.420 --> 00:25:43.890
number two on this machine as it
shuts down Node number 2, you'll
00:25:43.890 --> 00:25:46.930
see that the container has
now been forced to fail over.
00:25:46.930 --> 00:25:50.151
It'll failover from 2 to some
of the nodal pick inside here.
00:25:50.151 --> 00:25:52.367
It'll probably pick 4 or 3 and
00:25:52.367 --> 00:25:55.990
then overcome as it'll
start the container again.
00:25:55.990 --> 00:25:58.450
Watch the counter on the right
here, as it keeps counting and
00:25:58.450 --> 00:26:02.540
then recover and starts that
container and when it recovers
00:26:02.540 --> 00:26:04.790
because of we going to do
some more perf optimization.
00:26:04.790 --> 00:26:06.540
There's my account so
that's recovered and
00:26:06.540 --> 00:26:09.020
I kept to my state inside
my volume container
00:26:09.020 --> 00:26:12.125
across a volume drive build
on service fabric storage.
00:26:12.125 --> 00:26:14.580
[APPLAUSE] Pretty cool stuff.
00:26:16.310 --> 00:26:19.720
>> This is cool stuff and
this is going to be low latency,
00:26:19.720 --> 00:26:23.140
super fast And you know, you'll
be able to use the Azure one as
00:26:23.140 --> 00:26:25.280
well, but you'll be able
to take advantage of both.
00:26:25.280 --> 00:26:26.280
And so now,
00:26:26.280 --> 00:26:28.750
that state management is
like containers for you.
00:26:28.750 --> 00:26:31.990
You're going to have
a fun time with this one.
00:26:31.990 --> 00:26:34.278
Let's switch back
to those slides.
00:26:40.361 --> 00:26:41.684
I think you were up next.
00:26:41.684 --> 00:26:44.565
>> I knew I was up for more
than just clicking the mouse.
00:26:44.565 --> 00:26:46.090
>> [LAUGH]
>> Okay, good.
00:26:46.090 --> 00:26:48.750
Okay, so continuing,
continuing on our journey now.
00:26:48.750 --> 00:26:50.775
So we've shown you how to
take an existing Application,
00:26:50.775 --> 00:26:51.455
put it on Service Fabric.
00:26:51.455 --> 00:26:52.975
Now we're gonna do
the step three,
00:26:52.975 --> 00:26:55.705
which is we still don't want to
change this main application,
00:26:55.705 --> 00:26:58.355
but we want to add a couple
new modern services to it,
00:26:58.355 --> 00:26:59.635
kinda enhance the functionality.
00:26:59.635 --> 00:27:01.325
So, we're adding
new functionality,
00:27:01.325 --> 00:27:04.975
but we're going to do it in
services on Service Fabric.
00:27:04.975 --> 00:27:06.635
So we take our
Docker-composed application.
00:27:06.635 --> 00:27:08.285
And basically, what we're going
to do is we're going to turn
00:27:08.285 --> 00:27:10.325
this into a Service Fabric
application.
00:27:10.325 --> 00:27:11.915
So we're really just
moving these over,
00:27:11.915 --> 00:27:13.330
still not touching those.
00:27:13.330 --> 00:27:16.310
But, then we're going to add
additional services built on our
00:27:16.310 --> 00:27:19.680
reliable services SDK and
using ASP.NET Core
00:27:19.680 --> 00:27:21.490
as the application
framework on top of that.
00:27:21.490 --> 00:27:24.210
So, let's talk a little bit
about how ASP.NET Core actually
00:27:24.210 --> 00:27:25.798
works on Service Fabric.
00:27:25.798 --> 00:27:29.670
Traditionally with
ASP.NET Core the web
00:27:29.670 --> 00:27:32.040
host part is something that you
spin up in your process, and
00:27:32.040 --> 00:27:33.550
this is actually the reason
that it works so
00:27:33.550 --> 00:27:36.010
well on Service fabric is
because it's all self-hosted so
00:27:36.010 --> 00:27:39.860
when your program main you spin
out these netcore webpost and
00:27:39.860 --> 00:27:41.970
that starts up web server and
00:27:41.970 --> 00:27:43.872
your application NBC and
all that stuff.
00:27:43.872 --> 00:27:46.500
So, this is what we
call self hosting
00:27:46.500 --> 00:27:49.530
as opposed to an IAS where
IAS host the process for
00:27:49.530 --> 00:27:52.260
you loads up a bunch of DOLs but
then manages this.
00:27:52.260 --> 00:27:54.690
So your server is running
in your own process here.
00:27:54.690 --> 00:27:57.980
Now in Service Fabric, we still
do something very similar but
00:27:57.980 --> 00:28:00.680
what we really want to do
is we want to host this
00:28:00.680 --> 00:28:03.380
in our Reliable Services
because we have a slightly
00:28:03.380 --> 00:28:05.930
different life cycle than
just an ordinary process.
00:28:05.930 --> 00:28:09.370
So ASP.NET expects you to
follow the process life cycle.
00:28:09.370 --> 00:28:10.470
Process spins up.
00:28:10.470 --> 00:28:11.940
The web application comes up.
00:28:11.940 --> 00:28:13.040
The process goes down.
00:28:13.040 --> 00:28:14.300
The web application goes down.
00:28:14.300 --> 00:28:17.741
In our world, the host process
can stay up for a long period of
00:28:17.741 --> 00:28:20.711
time And we will actually
activate multiple service
00:28:20.711 --> 00:28:24.440
instances in that process before
you can do exclusive by the way.
00:28:24.440 --> 00:28:26.670
But the point is tat you're
gonna get multiple things coming
00:28:26.670 --> 00:28:28.530
up in that process over and
over and over again.
00:28:28.530 --> 00:28:31.760
So you have to get ASP.NET Core
kind of participate in that
00:28:31.760 --> 00:28:32.740
life cycle.
00:28:32.740 --> 00:28:34.450
And so
we have this plug-in model for
00:28:34.450 --> 00:28:36.180
opening up all kinds of
network communication.
00:28:36.180 --> 00:28:38.394
Again this is, you can use
whatever you want in here, but
00:28:38.394 --> 00:28:40.659
we have this interface called
ICommunicationListener,
00:28:40.659 --> 00:28:41.826
which you maybe seen before.
00:28:41.826 --> 00:28:44.640
This is where you actually
bootstrap ASP.NET Core.
00:28:44.640 --> 00:28:47.430
So when this starts up, then you
start up the ASP.NET Core web
00:28:47.430 --> 00:28:49.130
host and you can see from here,
00:28:49.130 --> 00:28:50.850
it's actually fairly
familiar at this point.
00:28:50.850 --> 00:28:53.920
So, we'll switch over to
Visual Studio real quick and
00:28:53.920 --> 00:28:56.000
you'll be able to see what
that looks like here.
00:28:56.000 --> 00:28:58.001
So okay, so
on the screen I have,
00:28:58.001 --> 00:29:01.435
this is just a traditional
Service Fabric application.
00:29:03.643 --> 00:29:06.245
And inside I have two
ASP.NET Core services, so
00:29:06.245 --> 00:29:08.528
if I expand one of these
what you'll see and
00:29:08.528 --> 00:29:11.270
this is actually just
ASP.NET Core project type.
00:29:11.270 --> 00:29:14.000
This is the regular ASP.NET
Core Visual Studio project type
00:29:14.000 --> 00:29:18.260
with dependencies, controllers,
dbudburoot if I had one.
00:29:18.260 --> 00:29:19.280
All that stuff is the same,
00:29:19.280 --> 00:29:22.220
the real difference as I
talk about is in the program
00:29:22.220 --> 00:29:27.070
entry point here Instead of
bootstrapping ASP.NET Core,
00:29:27.070 --> 00:29:32.244
we bootstrap the service fabric
reliable services with the run
00:29:32.244 --> 00:29:35.640
time, and then that loads up
your service instance in here.
00:29:35.640 --> 00:29:38.160
And then this is that I/O
communication listener plugin
00:29:38.160 --> 00:29:40.944
interface, but at this point we
essentially kick control back
00:29:40.944 --> 00:29:43.460
to you and say, all right,
now you can set up your web host
00:29:43.460 --> 00:29:45.530
just like you do with
a core normally.
00:29:45.530 --> 00:29:47.894
So you still have that
full level of control,
00:29:47.894 --> 00:29:51.130
it's really just getting this
piece in here to participate in
00:29:51.130 --> 00:29:52.449
our service lifecycle.
00:29:52.449 --> 00:29:53.726
So that's all that is.
00:29:53.726 --> 00:29:57.095
And we support Castro,
we support Web Listener.
00:29:57.095 --> 00:30:00.273
We actually have this Service
Fabric Integration which does
00:30:00.273 --> 00:30:03.386
a little bit of work to ensure
that there is unique mapping of
00:30:03.386 --> 00:30:06.626
services so that clients don't
actually connect to the wrong
00:30:06.626 --> 00:30:09.920
service because we are in
a shared posting environment.
00:30:09.920 --> 00:30:11.483
So that handles that stuff for
you.
00:30:11.483 --> 00:30:13.361
Okay, so
I have two of these services.
00:30:13.361 --> 00:30:16.403
Now, the last thing we
need to do is we just need
00:30:16.403 --> 00:30:18.990
to add our old legacy
services in here.
00:30:18.990 --> 00:30:21.380
So this is something that's
built into Visual Studio.
00:30:21.380 --> 00:30:24.240
We can just say, go and
add a new service,
00:30:24.240 --> 00:30:27.150
like we normally do, and
we have a container template.
00:30:27.150 --> 00:30:29.630
The container template actually
just takes an image name, so
00:30:29.630 --> 00:30:32.640
if I switch over
to here I can grab
00:30:32.640 --> 00:30:35.660
one of Mark's container images,
that he has up on Docker Hub and
00:30:35.660 --> 00:30:37.410
just say this is the image
that I want to use.
00:30:37.410 --> 00:30:39.590
And then I give
a service name down here,
00:30:39.590 --> 00:30:43.130
so we'll call it
LegacyWebService, like so.
00:30:43.130 --> 00:30:47.760
So what this does is this
doesn't actually create
00:30:47.760 --> 00:30:51.240
a service project because there
is no service project, we don't
00:30:51.240 --> 00:30:54.740
need one, there's no code, it's
just the package, the service
00:30:54.740 --> 00:30:57.950
Package itself which contains
hours of service manifest.
00:30:57.950 --> 00:31:00.380
This is just the definition of
how the servers should run.
00:31:00.380 --> 00:31:04.310
And you can see here where you
would normally have an EXC host
00:31:04.310 --> 00:31:05.940
instead we have
a container host.
00:31:05.940 --> 00:31:09.015
And inside the container host
we specified the location and
00:31:09.015 --> 00:31:12.104
the version of the container
image that we wanna pull down.
00:31:12.104 --> 00:31:14.223
Now this gets pulled
down at runtime.
00:31:14.223 --> 00:31:15.790
You don't actually see
it on your machine.
00:31:15.790 --> 00:31:17.510
Once you go and deploy this,
00:31:17.510 --> 00:31:20.220
then when we activate it
we go up to doctor hub,
00:31:20.220 --> 00:31:22.540
we grab the container image,
pull it down and activate it.
00:31:22.540 --> 00:31:23.520
So that's how that works.
00:31:23.520 --> 00:31:25.680
That's why you don't actually
have a project here so
00:31:25.680 --> 00:31:27.110
that's all that is and
that's really all that takes.
00:31:27.110 --> 00:31:28.810
If I want to add
a legacy application or
00:31:28.810 --> 00:31:31.320
existing application
to a service fabric,
00:31:31.320 --> 00:31:32.730
that's it that right there.
00:31:32.730 --> 00:31:35.590
So there's a little additional
configuration that you can do
00:31:35.590 --> 00:31:36.710
for port mapping.
00:31:36.710 --> 00:31:38.700
I'm not gonna do that today
because I know you guys
00:31:38.700 --> 00:31:40.640
didn't come here to
watch me edit XML.
00:31:40.640 --> 00:31:43.250
So what I'll do instead is I'll
just add that second one that
00:31:43.250 --> 00:31:47.110
Mark has and that's just for
completeness here.
00:31:47.110 --> 00:31:51.560
So I'll take number two and
we'll plot that in here.
00:31:51.560 --> 00:31:57.310
Call that our legacy data
service there you go,
00:31:57.310 --> 00:31:59.910
and that's it.
00:31:59.910 --> 00:32:03.260
Now we have our two legacy
applications, still talking to
00:32:03.260 --> 00:32:06.030
each other over DNS, but we've
added two additional ASP.NET
00:32:06.030 --> 00:32:08.700
core services as supplementary
services they expose some
00:32:08.700 --> 00:32:11.880
functionality over web API
just like you're used to.
00:32:11.880 --> 00:32:14.520
And before I run that, I'm
going to switch back over and
00:32:14.520 --> 00:32:17.300
talk a little more about
how this actually works,
00:32:17.300 --> 00:32:22.060
so the question then is,
what do you do, how do you
00:32:22.060 --> 00:32:24.350
expose that new functionality
to your application?
00:32:24.350 --> 00:32:25.270
I've added these services,
00:32:25.270 --> 00:32:27.600
but how do I actually modify
the app to expose that?
00:32:27.600 --> 00:32:29.756
So there's a couple
things you can do.
00:32:29.756 --> 00:32:31.285
The kinda traditional
way to do this, is your
00:32:31.285 --> 00:32:33.815
client application will go
through the Azure Load Balancer
00:32:33.815 --> 00:32:36.455
as it normally does to
the back end application.
00:32:36.455 --> 00:32:39.145
And at this point it's always
gonna reach your legacy service.
00:32:39.145 --> 00:32:41.115
Now, how do you expose
that new functionality.
00:32:41.115 --> 00:32:43.215
One thing you can always do,
is you can just go and
00:32:43.215 --> 00:32:45.595
talk directly to
that new service.
00:32:45.595 --> 00:32:46.665
But the question is, how?
00:32:46.665 --> 00:32:48.690
Because you have to go and
resolve the service.
00:32:48.690 --> 00:32:49.640
This isn't using DNS.
00:32:49.640 --> 00:32:50.950
This is a staple service.
00:32:50.950 --> 00:32:51.900
It's a little more complicated.
00:32:51.900 --> 00:32:54.660
So we have this thing in Service
Fabric called a reverse proxy
00:32:54.660 --> 00:32:56.200
that you may have
used in the past.
00:32:56.200 --> 00:32:59.320
This knows how to forward
requests on to a new service,
00:32:59.320 --> 00:33:01.200
and that way,
your legacy service or
00:33:01.200 --> 00:33:03.890
existing service can consume
a new functionality that way.
00:33:03.890 --> 00:33:06.810
So this is an example of a kind
of a gateway pattern that we
00:33:06.810 --> 00:33:09.150
call, which is we use a staple
service as a gateway.
00:33:09.150 --> 00:33:11.050
And the reason you do this,
00:33:11.050 --> 00:33:14.250
if you look at this from a
actual deployment point of view,
00:33:14.250 --> 00:33:18.070
the legacy application that you
deploy is a stateless service.
00:33:18.070 --> 00:33:18.693
It runs on every node.
00:33:18.693 --> 00:33:21.666
And this is important because
the Azure Load Balancer is
00:33:21.666 --> 00:33:22.430
a level four.
00:33:22.430 --> 00:33:23.600
It's a layer four load balancer.
00:33:23.600 --> 00:33:25.130
And it doesn't know anything
about service fabric,
00:33:25.130 --> 00:33:26.680
it doesn't know anything
about services,
00:33:26.680 --> 00:33:29.500
all it knows about is
IP addresses and ports.
00:33:29.500 --> 00:33:30.890
So when requests come in,
00:33:30.890 --> 00:33:33.110
it just sprays it
across all your nodes.
00:33:33.110 --> 00:33:35.510
And there better be a service
there listening otherwise you're
00:33:35.510 --> 00:33:37.440
gonna see time-out.
00:33:37.440 --> 00:33:40.313
So when the request
reach this service,
00:33:40.313 --> 00:33:43.114
they end up having to go
the server's proxy, so
00:33:43.114 --> 00:33:46.643
that the server's proxy can
route them to the right place.
00:33:46.643 --> 00:33:48.400
Now this is a very
traditional thing,
00:33:48.400 --> 00:33:51.660
we see this a lot and
everybody has to do this
00:33:51.660 --> 00:33:54.520
today because there is no
other way to expose that back
00:33:54.520 --> 00:33:56.770
end functionality directly
out to your clients.
00:33:56.770 --> 00:33:58.800
You always need something in
the middle to do this work.
00:33:58.800 --> 00:34:02.230
Now we got kinda tired of
having to do this all the time
00:34:02.230 --> 00:34:04.580
our customers got kinda tired of
having to write these gateways
00:34:04.580 --> 00:34:05.490
again, and again, and again.
00:34:05.490 --> 00:34:08.610
So announcing today
what we are introducing
00:34:08.610 --> 00:34:11.210
is service fabric
with API management.
00:34:11.210 --> 00:34:12.320
Integration.
00:34:12.320 --> 00:34:15.630
You can now use API management
to route calls directly
00:34:15.630 --> 00:34:16.960
to your back end services.
00:34:16.960 --> 00:34:19.750
We built this in as a custom
back end in API management.
00:34:19.750 --> 00:34:21.090
You can do service discovery and
00:34:21.090 --> 00:34:23.630
routing in your API
management policies.
00:34:23.630 --> 00:34:25.520
You can do partition
resolution back there, so
00:34:25.520 --> 00:34:26.970
you can route calls to
the direct partition.
00:34:26.970 --> 00:34:28.840
You can do a replica selection,
00:34:28.840 --> 00:34:32.090
you can even select which
replica you wanna route to and
00:34:32.090 --> 00:34:36.150
of course we have resolve and
retry policies that allow you to
00:34:36.150 --> 00:34:39.570
make your endpoints a little
more available for your users.
00:34:39.570 --> 00:34:41.490
So this is something
we're working on now.
00:34:41.490 --> 00:34:44.580
It'll be available to you in
probably about a month's time.
00:34:44.580 --> 00:34:46.890
It's not out in production yet,
but it's coming soon.
00:34:46.890 --> 00:34:49.840
So here's how this works.
00:34:49.840 --> 00:34:50.474
Service discovery and routing.
00:34:53.146 --> 00:34:55.352
On your client's end,
if you make a request for
00:34:55.352 --> 00:34:58.220
something like you can set up
an operation in API Management,
00:34:58.220 --> 00:34:59.950
something like API
users with an ID.
00:34:59.950 --> 00:35:04.350
And then in API Management
you can set up a policy
00:35:04.350 --> 00:35:08.280
where you take that ID value and
you can add that anywhere you
00:35:08.280 --> 00:35:11.030
want into a service name and
this allows API Management
00:35:11.030 --> 00:35:14.500
to actually route calls to
a specific service instance.
00:35:14.500 --> 00:35:16.600
You may have thousands of
service instances running in
00:35:16.600 --> 00:35:17.420
the back end.
00:35:17.420 --> 00:35:20.770
This allows API management
to intelligently
00:35:20.770 --> 00:35:23.010
request all the way to
the back end services.
00:35:23.010 --> 00:35:26.130
Same thing with partition
resolution when a request comes
00:35:26.130 --> 00:35:29.029
in again for that same URI you
can write question functions.
00:35:30.120 --> 00:35:33.250
Where you can compute partition
keys based on that ID, and then
00:35:33.250 --> 00:35:37.070
route that again to the correct
partition of a specific service.
00:35:37.070 --> 00:35:38.730
So these are all policies
that are built in.
00:35:38.730 --> 00:35:39.614
So, if we go back and
00:35:39.614 --> 00:35:42.163
look at our overall architecture
diagram, the way it'll
00:35:42.163 --> 00:35:44.763
work now is the API calls that
come from the client instead of
00:35:44.763 --> 00:35:46.688
going directly to that
stateless service,
00:35:46.688 --> 00:35:48.769
they're going to go
through API management and
00:35:48.769 --> 00:35:51.360
that's going to do
the routing for you.
00:35:51.360 --> 00:35:54.260
Okay, so how does this work?
00:35:55.520 --> 00:35:57.020
If we look at our
deployment again,
00:35:57.020 --> 00:35:58.320
the same thing as we saw before,
00:35:58.320 --> 00:35:59.910
our state less service
on a state full backend.
00:35:59.910 --> 00:36:01.900
The way this works is when
a request comes in to
00:36:01.900 --> 00:36:05.760
API Management, API Management
is now aware of Service Fabric's
00:36:05.760 --> 00:36:07.760
naming service and so
it does the lookup.
00:36:07.760 --> 00:36:09.740
It does the resolution,
it does the lookup and
00:36:09.740 --> 00:36:13.080
then it can intelligently route
that call to the right place.
00:36:13.080 --> 00:36:15.922
And in order to enable this,
we've actually developed a new
00:36:15.922 --> 00:36:18.832
client library that's based
entirely on our HTTP protocol.
00:36:18.832 --> 00:36:21.375
This is something we'll
be releasing fairly soon,
00:36:21.375 --> 00:36:24.089
just as a set of standalone
NuGet Packages get back so you
00:36:24.089 --> 00:36:27.036
can do API or you can do service
fabric management operations
00:36:27.036 --> 00:36:29.926
without having to install the
entire runtime and the entire
00:36:29.926 --> 00:36:33.140
SDK on the machines, which is
great for your build systems.
00:36:33.140 --> 00:36:35.250
It's great for API management
and it's standalone and
00:36:35.250 --> 00:36:37.890
very lightweight, so that's also
coming out fairly soon, and
00:36:37.890 --> 00:36:38.980
so that's how that all works.
00:36:40.240 --> 00:36:45.900
Now, missed one thing here, yes,
the vnet, the vnet's important.
00:36:45.900 --> 00:36:47.180
These two things live
in the same vnet,
00:36:47.180 --> 00:36:48.470
that's how they see each other.
00:36:48.470 --> 00:36:50.940
This is something API management
has been able to do for a while.
00:36:50.940 --> 00:36:52.700
So basically, we just took
advantage of this and said hey,
00:36:52.700 --> 00:36:54.710
if you deploy these
in the same vnet,
00:36:54.710 --> 00:36:55.740
why not let them
talk to each other?
00:36:55.740 --> 00:36:57.300
And that's how that works, okay,
00:36:57.300 --> 00:37:01.200
so let's take a look at our
legacy application again now.
00:37:01.200 --> 00:37:04.240
So here's what we can do,
so we have our web service,
00:37:04.240 --> 00:37:05.670
we have our data
service in containers.
00:37:05.670 --> 00:37:07.560
We don't need to touch these,
we don't need to change these.
00:37:07.560 --> 00:37:09.490
They can still talk to each
other over DNS the way they did
00:37:09.490 --> 00:37:11.580
before for
the existing functionality.
00:37:11.580 --> 00:37:14.920
When you load up your UI you
go through Load Balancer,
00:37:14.920 --> 00:37:17.270
Load Balancer hits your web
service, loads up the webpage.
00:37:17.270 --> 00:37:17.880
Great.
00:37:17.880 --> 00:37:19.840
Now, our new services,
this is where it gets cool, so
00:37:19.840 --> 00:37:22.280
we introduce this new
service with ASP.NET Core.
00:37:22.280 --> 00:37:25.130
It exposes web APIs that will
00:37:25.130 --> 00:37:28.230
actually dynamically create new
services to do processing jobs.
00:37:28.230 --> 00:37:30.220
So, when you hit one of those
APIs, it's going to go on
00:37:30.220 --> 00:37:32.960
create new service fabric
service dynamically and
00:37:32.960 --> 00:37:34.960
each one of those will be
doing some processing work.
00:37:34.960 --> 00:37:35.750
Now, here's the cool thing,
00:37:35.750 --> 00:37:39.400
since those services are created
dynamically, they are all named
00:37:39.400 --> 00:37:42.300
with the kind of the name of
the processing job you're doing.
00:37:42.300 --> 00:37:44.760
So API managing does this
rubbing very intelligently.
00:37:44.760 --> 00:37:47.300
So, when API calls come in
through our single page
00:37:47.300 --> 00:37:50.180
application through JavaScript,
they will hit API Management and
00:37:50.180 --> 00:37:52.120
that's gonna route them
to the right place.
00:37:52.120 --> 00:37:54.270
And the really cool one is
down the very last one there.
00:37:54.270 --> 00:37:57.200
API reports name status
that name is being
00:37:57.200 --> 00:38:01.880
translated into a service name
so it goes to the right one.
00:38:01.880 --> 00:38:03.460
And then gets
a result from that.
00:38:03.460 --> 00:38:07.784
So, I'll show you how it works
real quick here in a live demo,
00:38:07.784 --> 00:38:10.749
which we'll see.
00:38:10.749 --> 00:38:12.550
Okay, so I got this running.
00:38:12.550 --> 00:38:15.130
Here's what it ends up looking
like in the Azure Portal.
00:38:15.130 --> 00:38:17.010
You can see this is
my deployment here.
00:38:17.010 --> 00:38:20.710
I have API Manager, here's
my service fabric cloth and
00:38:20.710 --> 00:38:22.740
here's API Manager and I have
them in the same resource group.
00:38:22.740 --> 00:38:25.180
But more importantly they're
running in the same vnet.
00:38:25.180 --> 00:38:28.040
They each get a separate subnets
so they can run side by side and
00:38:28.040 --> 00:38:29.190
they get each of their own NSG.
00:38:29.190 --> 00:38:30.800
Their own network
security group but
00:38:30.800 --> 00:38:32.010
they can still talk
to each other.
00:38:32.010 --> 00:38:33.230
So, that's how
the deployment looks.
00:38:33.230 --> 00:38:37.030
Now if we go check out our
application again and I was
00:38:37.030 --> 00:38:39.530
sneaky, I went and create an
instance while Mark was talking.
00:38:39.530 --> 00:38:41.020
See we have to wait for
it to deploy.
00:38:41.020 --> 00:38:42.880
So, here's what it
looks like now so
00:38:42.880 --> 00:38:45.920
we did have to make a UI
obviously you can to expose some
00:38:45.920 --> 00:38:48.140
functionality probably
you'll need an UI for it.
00:38:48.140 --> 00:38:51.482
So now, instead of just creating
TPS reports this way which still
00:38:51.482 --> 00:38:54.094
should work, this is still
going through DNS and so
00:38:54.094 --> 00:38:55.887
this function should still work.
00:38:55.887 --> 00:38:58.920
But the really cool part
here is if I go on here and
00:38:58.920 --> 00:39:03.470
say I want my report here,
I might say, now, do it for me.
00:39:03.470 --> 00:39:05.560
So this is going
through AP managing.
00:39:05.560 --> 00:39:07.260
See this URL right here,
there it is.
00:39:08.580 --> 00:39:11.850
Go back to
Service Fabric Explorer.
00:39:11.850 --> 00:39:14.370
That actually just created
a brand-new service
00:39:14.370 --> 00:39:15.380
in Service Fabric, and
00:39:15.380 --> 00:39:18.710
that request was routed
through API management.
00:39:18.710 --> 00:39:20.780
Here it is,
there is this post request,
00:39:20.780 --> 00:39:23.790
this is my API Management
endpoint here.
00:39:24.800 --> 00:39:27.660
And I sent the post request and
I said, here's the report name,
00:39:27.660 --> 00:39:31.230
I extracted that and I created
a new service using that name.
00:39:31.230 --> 00:39:32.710
And that now kind
of just spun up.
00:39:32.710 --> 00:39:35.050
So I can create as many
of those as I want.
00:39:35.050 --> 00:39:40.100
This is a very typical use
case we for job processing.
00:39:40.100 --> 00:39:41.730
If I want to do job processing,
00:39:41.730 --> 00:39:43.990
I dynamically spin up a new
source fabrics service.
00:39:43.990 --> 00:39:44.674
Let it do its work.
00:39:44.674 --> 00:39:45.204
In this case,
00:39:45.204 --> 00:39:47.333
I use reliable connections
to checkpoint along the way.
00:39:47.333 --> 00:39:49.349
So if it dies at some point,
it fails over,
00:39:49.349 --> 00:39:51.036
I haven't lost any
of my progress.
00:39:51.036 --> 00:39:52.639
That's essentially
what its doing.
00:39:52.639 --> 00:39:54.299
Now, so I can create as
many of these as I want.
00:39:54.299 --> 00:39:57.027
If I click get status,
this is actually just showing
00:39:57.027 --> 00:39:59.941
the services, so if I click
get status that's going and
00:39:59.941 --> 00:40:03.103
talking to this service directly
through API management and
00:40:03.103 --> 00:40:05.720
here's that request
on the backend here.
00:40:05.720 --> 00:40:08.350
I just did a get, here's that
name of the report that got
00:40:08.350 --> 00:40:12.250
routed to that service, now I
don't actually want to go to it.
00:40:12.250 --> 00:40:13.060
And then it came back.
00:40:13.060 --> 00:40:14.790
So that's all going for
API management.
00:40:14.790 --> 00:40:17.360
No stale in gateways, I didn't
have to write any routing,
00:40:17.360 --> 00:40:19.150
I didn't have to write
anything like that.
00:40:19.150 --> 00:40:21.240
API management handles
all that stuff for me.
00:40:21.240 --> 00:40:22.840
So, that's all, it works.
00:40:22.840 --> 00:40:25.285
>> [APPLAUSE]
>> That is fabulous, yeah.
00:40:25.285 --> 00:40:28.154
>> [APPLAUSE]
>> We're pretty obsessed with
00:40:28.154 --> 00:40:30.285
gateways aren't we?
00:40:30.285 --> 00:40:31.258
>> Really.
>> [CROSSTALK] We had a lot of
00:40:31.258 --> 00:40:33.049
gateways, I mean that's-
>> They like to make sure that
00:40:33.049 --> 00:40:34.490
we work pretty well
with those things.
00:40:34.490 --> 00:40:36.460
>> Yeah, I mean,
this is a very common thing and
00:40:36.460 --> 00:40:39.070
there is a lot of options to how
you write gateways into your
00:40:39.070 --> 00:40:41.060
applications to get
to the backend, and
00:40:41.060 --> 00:40:42.120
the most common one, of course,
00:40:42.120 --> 00:40:44.880
is you have write a stateless
web service yourself, but
00:40:44.880 --> 00:40:45.400
it's work.
00:40:45.400 --> 00:40:47.490
It's work you have to do, it's
a lot of code you have to write.
00:40:47.490 --> 00:40:49.530
And so API management that
was the other option.
00:40:49.530 --> 00:40:51.480
Of course there are a couple
more of these, like IoT and
00:40:51.480 --> 00:40:52.350
Event Hub.
00:40:52.350 --> 00:40:54.960
These also work as gateways
into your application.
00:40:54.960 --> 00:40:55.980
These are a little
bit different,
00:40:55.980 --> 00:40:58.180
because instead of
taking requests in,
00:40:58.180 --> 00:41:00.610
you're actually listening and
pulling out.
00:41:00.610 --> 00:41:04.620
But those are other
examples of gateways, so.
00:41:04.620 --> 00:41:05.597
>> Yeah.
00:41:05.597 --> 00:41:07.450
>> Okay.
00:41:07.450 --> 00:41:08.020
Wolters Kluwer.
00:41:08.020 --> 00:41:09.450
This is a customer of ours.
00:41:09.450 --> 00:41:12.600
A lot of the concepts that
we've been talking about today,
00:41:12.600 --> 00:41:14.390
they are actually doing
this in practice today.
00:41:14.390 --> 00:41:16.420
Dynamic service creation for
job processing,
00:41:16.420 --> 00:41:17.600
that's something they do, and
00:41:17.600 --> 00:41:19.825
modernizing their application
using that in a containers.
00:41:19.825 --> 00:41:22.375
Very big customers, so
that was very important.
00:41:22.375 --> 00:41:24.515
They were using some of
these concepts here as well.
00:41:24.515 --> 00:41:26.025
>> And they had a talk.
00:41:26.025 --> 00:41:28.635
>> Yeah, that's right, they had
a talk yesterday, I think, yeah.
00:41:28.635 --> 00:41:29.852
>> Yeah, so
if you want to go back and
00:41:29.852 --> 00:41:31.464
listen to that talk
about how they did that.
00:41:31.464 --> 00:41:33.045
And then they also
just published,
00:41:33.045 --> 00:41:34.836
if you know our service
Havoc Team Blog,
00:41:34.836 --> 00:41:37.122
we just published an article-
>> [CROSSTALK] [INAUDIBLE] up
00:41:37.122 --> 00:41:37.716
there, yeah.
00:41:37.716 --> 00:41:38.809
>> The case study
of that [CROSSTALK]
00:41:38.809 --> 00:41:40.014
>> [INAUDIBLE]
00:41:40.014 --> 00:41:40.989
>> So, go and check out that
00:41:40.989 --> 00:41:43.710
case study, go and listen to
their talk again and recording.
00:41:43.710 --> 00:41:45.870
And they've gone through
a similar journey like this in
00:41:45.870 --> 00:41:46.750
terms of the modernization.
00:41:46.750 --> 00:41:49.590
>> Yeah, that's right,
that's right, okay, so
00:41:49.590 --> 00:41:50.880
where are we with
programming models?
00:41:50.880 --> 00:41:52.900
Let's switch gears
a little bit now.
00:41:52.900 --> 00:41:54.470
So this is our current
Windows Stack,
00:41:54.470 --> 00:41:56.538
this is what you're
probably all familiar with.
00:41:56.538 --> 00:41:59.492
And Mark mentioned a little bit
earlier mostly .NET full of
00:41:59.492 --> 00:42:01.499
framework, and
then on the other side,
00:42:01.499 --> 00:42:04.334
if you wanna use any language
of your choice, of course,
00:42:04.334 --> 00:42:06.128
guest executables, containers.
00:42:06.128 --> 00:42:09.660
On the Linux side, this is
just a preview that we have.
00:42:09.660 --> 00:42:10.930
It's a little bit
fragmented right now,
00:42:10.930 --> 00:42:13.130
it's a work in progress.
00:42:13.130 --> 00:42:14.930
Just Java,
a little bit of .NET Core,
00:42:14.930 --> 00:42:17.630
but still only stateless on
the reliable services side but
00:42:17.630 --> 00:42:20.300
stateful on the actor side,
of course.
00:42:20.300 --> 00:42:21.660
Now the more interesting
question is,
00:42:21.660 --> 00:42:22.730
where are we going
with all this?
00:42:22.730 --> 00:42:24.760
Here's where we're going,
.NET standard 2.0.
00:42:24.760 --> 00:42:26.420
This is what we ultimately want,
00:42:26.420 --> 00:42:29.480
the full cross-platform
story with .NET.
00:42:29.480 --> 00:42:31.360
Everything will be built
on .NET standards so
00:42:31.360 --> 00:42:34.390
you can compile your services
against .NET core, and
00:42:34.390 --> 00:42:37.340
then have them cross-compatible
between Linux and Windows.
00:42:37.340 --> 00:42:40.600
And eventually when we get to
clusters that span multiple
00:42:40.600 --> 00:42:43.410
operating systems, you'll be
able to write your services once
00:42:43.410 --> 00:42:46.290
and run them everywhere, so
that's kind of the idea.
00:42:46.290 --> 00:42:47.880
And eventually of course
all this stuff will be
00:42:47.880 --> 00:42:49.990
containerizable as well.
00:42:49.990 --> 00:42:52.860
Not today, but eventually we'll
build you reliable services and
00:42:52.860 --> 00:42:54.480
actors inside of containers.
00:42:54.480 --> 00:42:56.660
Yeah, I mean NBC really isn't
far away if you think about it.
00:42:56.660 --> 00:42:57.480
>> It's not too far away.
00:42:57.480 --> 00:42:57.980
>> No.
>> It's actually pretty close.
00:42:57.980 --> 00:42:59.210
>> Yeah, we're a few months away
00:42:59.210 --> 00:43:00.110
from getting to that.
00:43:00.110 --> 00:43:02.850
>> Yeah, now the standard 2.0
is just around the corner, so
00:43:02.850 --> 00:43:04.280
we're getting there pretty fast.
00:43:04.280 --> 00:43:05.570
>> Yeah, so then think about it,
00:43:05.570 --> 00:43:06.670
you're going to
build those apps and
00:43:06.670 --> 00:43:08.410
run that across
all our platforms.
00:43:08.410 --> 00:43:10.450
You did one, set this hub
against the one platform across.
00:43:10.450 --> 00:43:11.860
>> Yep.
And in the meantime,
00:43:11.860 --> 00:43:15.440
we have open sourced our program
models, actor, services, and
00:43:15.440 --> 00:43:17.290
are ASP core integration.
00:43:17.290 --> 00:43:19.600
All this is open source, so
come check that out on GitHub.
00:43:19.600 --> 00:43:23.027
We have a home repo, which is
just kind of jumping off point,
00:43:23.027 --> 00:43:26.389
no code in there, but that'll
link you off to all the others
00:43:26.389 --> 00:43:29.552
and that's just on
Azure/service-fabric [CROSSTALK]
00:43:29.552 --> 00:43:31.992
we have, yeah,
that's great, why not?
00:43:31.992 --> 00:43:32.620
All right.
00:43:32.620 --> 00:43:33.190
>> All right, yeah, so
00:43:33.190 --> 00:43:35.620
let's talk a little bit
about where we've gone.
00:43:35.620 --> 00:43:37.676
Services, I mean most of them
[INAUDIBLE] I knew we've
00:43:37.676 --> 00:43:40.490
talked about so
far was from the developer side.
00:43:40.490 --> 00:43:42.110
Let me just touch
briefly on some
00:43:42.110 --> 00:43:43.890
of these we have done
inside management side.
00:43:45.480 --> 00:43:48.200
We had a little, there is a
little theta earlier talk today
00:43:48.200 --> 00:43:51.030
done by Chuckie Daniel's, a guy
on our team who touched down
00:43:51.030 --> 00:43:53.694
some of these things, but
I wanted to highlight them here
00:43:53.694 --> 00:43:56.357
cuz we hear a lot of people talk
about how much they managed
00:43:56.357 --> 00:43:59.109
underlying cluster itself and
the things they have to do.
00:43:59.109 --> 00:44:01.870
We've added now Powershell
commands that allow you
00:44:01.870 --> 00:44:03.820
to manage the cluster
through arms.
00:44:03.820 --> 00:44:07.650
So, effectively, I can now
create secure clusters and
00:44:07.650 --> 00:44:10.540
manage those clusters
by adding new nodes,
00:44:10.540 --> 00:44:11.730
creating certificates,
00:44:11.730 --> 00:44:14.540
adding new node types all
through Powershell commands.
00:44:14.540 --> 00:44:17.878
So, if you go and
check this little video out now,
00:44:17.878 --> 00:44:19.476
understand your talk.
00:44:19.476 --> 00:44:22.586
You can add a single PowerShell
command that says, create
00:44:22.586 --> 00:44:26.269
the cluster, here's the name of
the cluster, here's the location
00:44:26.269 --> 00:44:30.130
for it, Sol, generate me a cert
and put that inside Key Vault.
00:44:30.130 --> 00:44:32.640
Make the cluster secure,
give me back the cert, and
00:44:32.640 --> 00:44:35.220
standing there is a five machine
cluster all with a single
00:44:35.220 --> 00:44:36.470
PowerShell command.
00:44:36.470 --> 00:44:37.730
And it makes your
life incredibly
00:44:37.730 --> 00:44:40.410
easy around all of that and
how to manage it all.
00:44:40.410 --> 00:44:43.990
Plus, of course, adding new
nodes now can be done safely,
00:44:43.990 --> 00:44:46.480
by simply doing, Add new node,
00:44:46.480 --> 00:44:48.480
with the Service Fabric
power user command,
00:44:48.480 --> 00:44:51.890
from 5 machines to 10 machines
to scroll all by down again.
00:44:51.890 --> 00:44:54.235
Same with the Agile CLI,
the Agile CLI for
00:44:54.235 --> 00:44:57.654
managing the clusters is not
there just yet, it's coming,
00:44:57.654 --> 00:45:00.014
it will be coming in
the next SDK release.
00:45:00.014 --> 00:45:02.870
But the Agile CLI there for
managing the applications,
00:45:02.870 --> 00:45:05.970
where you directly connect to
the clusters themselves and be
00:45:05.970 --> 00:45:08.888
able to deploy the application
packages into the cluster
00:45:08.888 --> 00:45:09.450
is there.
00:45:09.450 --> 00:45:13.210
So that Azure CLI is there and
by the time we get to the next
00:45:13.210 --> 00:45:16.120
Azure SDK, you'll have both
the CLI and the Powershell
00:45:16.120 --> 00:45:19.110
all available for both
the application deployment and
00:45:19.110 --> 00:45:22.930
management as well as the custom
management and scale out.
00:45:22.930 --> 00:45:26.190
We had a lot of people ask us as
well about creating single-node
00:45:26.190 --> 00:45:29.420
clusters because they said, well
there's this scenario I have
00:45:29.420 --> 00:45:31.780
were I just want to
stand up one machine.
00:45:31.780 --> 00:45:35.200
And on that one machine,
just test it inside Azure and
00:45:35.200 --> 00:45:37.120
just use it as a dev
test side of things.
00:45:37.120 --> 00:45:40.520
So we made that a super
simple option inside Azure.
00:45:40.520 --> 00:45:43.020
And that allows you
to effectively now
00:45:43.020 --> 00:45:46.960
create a resource group with
a single machine inside it all.
00:45:46.960 --> 00:45:48.450
This all hooked up
to a key volt but
00:45:48.450 --> 00:45:50.108
now it can just do
deployment to that scene.
00:45:50.108 --> 00:45:51.510
So basically it's a cost thing,
00:45:51.510 --> 00:45:54.370
they can just do to get to
the next level of testing.
00:45:54.370 --> 00:45:55.490
A great way of going
through that and
00:45:55.490 --> 00:45:57.690
again you can do that
through PowerShell as well.
00:45:57.690 --> 00:46:01.470
If you'd looked to our blog
in how we posting in our fair
00:46:01.470 --> 00:46:05.140
regular basis, we release and
we've just releasing it GA now
00:46:05.140 --> 00:46:08.420
this week a Windows
Update Patching service.
00:46:08.420 --> 00:46:10.090
And you can take
this service and
00:46:10.090 --> 00:46:11.970
you can run it
inside your cluster.
00:46:11.970 --> 00:46:15.222
And what it does is it turns,
coordinates Windows Update
00:46:15.222 --> 00:46:18.488
patching across the clusters
of machines effectively.
00:46:18.488 --> 00:46:21.578
It doesn't allow you to turn
on Windows Update Patching on
00:46:21.578 --> 00:46:24.226
machines but it talks to
Windows Update itself and
00:46:24.226 --> 00:46:27.189
then it does the patching of and
update of these clusters
00:46:27.189 --> 00:46:29.470
machines in
a coordinated fashion.
00:46:29.470 --> 00:46:33.080
So if want to run and have your
clusters made secure as updates
00:46:33.080 --> 00:46:35.990
get pushed to Windows, just
take this service, deploy it
00:46:35.990 --> 00:46:38.450
into your machines just like
you see with any other service,
00:46:38.450 --> 00:46:41.000
it will run and it will take
care of all of it for you.
00:46:41.000 --> 00:46:42.320
And by the way,
you can do that in premises,
00:46:42.320 --> 00:46:43.405
as well as inside Azure.
00:46:43.405 --> 00:46:48.309
It's a Windows' only features I
can say in this point [LAUGH]
00:46:48.309 --> 00:46:49.300
cuz of Windows Update.
00:46:49.300 --> 00:46:50.420
>> That make sense.
00:46:50.420 --> 00:46:52.194
>> Yeah.
[LAUGH] As well as the Windows
00:46:52.194 --> 00:46:55.040
builder not available
on Linux yet.
00:46:55.040 --> 00:46:55.920
>> Yet.
00:46:55.920 --> 00:46:56.620
>> Linux update?
00:46:56.620 --> 00:46:57.950
>> Yes, Linux update yes.
00:46:57.950 --> 00:47:00.278
>> [INAUDIBLE]
>> Hm.
00:47:00.278 --> 00:47:02.700
>> Then we've done
a whole bunch of work and
00:47:02.700 --> 00:47:05.977
I show you a little bit here
just to make sure that we work
00:47:05.977 --> 00:47:07.914
well with AppInsights and OMS.
00:47:07.914 --> 00:47:10.542
In AppInsights, actually let us
flip over to the portal here,
00:47:10.542 --> 00:47:11.979
just flip over to
my machine here,
00:47:11.979 --> 00:47:14.460
I just want to show you this
what we have done here.
00:47:14.460 --> 00:47:15.400
Inside the portal now here,
00:47:15.400 --> 00:47:17.930
I have just started creating
a new application and
00:47:17.930 --> 00:47:21.140
you can now put your
AppInsight ID here,
00:47:21.140 --> 00:47:23.170
directly into when you
create a new cluster.
00:47:23.170 --> 00:47:25.530
So that means, that by default,
00:47:25.530 --> 00:47:28.620
anything that we write out from
cluster events like node up,
00:47:28.620 --> 00:47:31.990
node down and things get
pushed out to AppInsights.
00:47:31.990 --> 00:47:33.909
And you can go into
your application and
00:47:33.909 --> 00:47:36.933
if you go and look at our docs,
says there's great technology
00:47:36.933 --> 00:47:39.667
called Event Flow, that allows
you to basically hook up
00:47:39.667 --> 00:47:42.110
a number of different ways
that you write events,
00:47:42.110 --> 00:47:45.219
like through iLogger and through
event source or your choice.
00:47:45.219 --> 00:47:48.239
And it will direct those out
to number of different syncs
00:47:48.239 --> 00:47:51.773
whether there's AppInsights or
L'core or some other source and
00:47:51.773 --> 00:47:54.023
you can put that into
your application and
00:47:54.023 --> 00:47:56.980
pump all your diagnostics
through and reconfigure and
00:47:56.980 --> 00:48:00.290
make sure all those diagnostics
go through to AppInsights.
00:48:00.290 --> 00:48:03.860
So, extremely easy now to use
AppInsights cuz it's safe
00:48:03.860 --> 00:48:05.170
which is now very scalable for
00:48:05.170 --> 00:48:07.190
all your events inside
your application.
00:48:07.190 --> 00:48:10.310
If I actually just go and
select inside here, as well,
00:48:10.310 --> 00:48:13.440
I go to the next new tab,
you see that option here for
00:48:13.440 --> 00:48:16.820
that Single Node Cluster,
where I can say!
00:48:16.820 --> 00:48:18.860
Checking Single Node Cluster
triggered a bit of a warning,
00:48:18.860 --> 00:48:19.900
don't run this in production.
00:48:20.940 --> 00:48:23.490
One node is not really
good in production.
00:48:23.490 --> 00:48:27.360
One nodes not going to don't
use that [INAUDIBLE] And
00:48:27.360 --> 00:48:30.360
by the way, you can upgrade from
this, if you choose one node for
00:48:30.360 --> 00:48:32.390
testing you're stuck
with one node.
00:48:32.390 --> 00:48:35.300
Yes, you can't go, we just
made sure that was the case.
00:48:35.300 --> 00:48:36.992
Actually, another
little thing in here,
00:48:36.992 --> 00:48:38.033
look that reverse proxy.
00:48:38.033 --> 00:48:38.686
>> Yeah, that's right.
00:48:38.686 --> 00:48:40.793
We've added this as well so
it's a lot easier now to enable
00:48:40.793 --> 00:48:42.990
reverse proxy for creating-
>> Turn it on
00:48:42.990 --> 00:48:43.895
through the portal.
00:48:43.895 --> 00:48:44.660
[CROSSTALK] Wow, look at that.
00:48:44.660 --> 00:48:45.950
It just turned it on for you and
00:48:45.950 --> 00:48:48.530
you just do those simple URL
calls between all the servers in
00:48:48.530 --> 00:48:49.920
your backend cluster.
00:48:49.920 --> 00:48:52.430
And we will have a little check
box here coming in the next few
00:48:52.430 --> 00:48:53.480
weeks that will have DNS.
00:48:53.480 --> 00:48:55.830
So you just click DNS and
turn DNS on.
00:48:55.830 --> 00:48:57.650
Right now, you just have
to go into the R Model, so
00:48:57.650 --> 00:48:59.000
that is coming soon.
00:48:59.000 --> 00:49:00.710
We do updates like this fairly
regularly, so that's sort of
00:49:00.710 --> 00:49:04.020
some of the things that we
do inside the portal there.
00:49:04.020 --> 00:49:05.570
What have we got next?
00:49:05.570 --> 00:49:07.969
>> With respect to slides,
we've got something pretty fun.
00:49:07.969 --> 00:49:11.946
>> Is the, uh-uh-huh.
00:49:11.946 --> 00:49:17.550
>> [CROSSTALK]
>> Okay, let's do one more demo.
00:49:17.550 --> 00:49:21.712
So we love, let me just get
this all sorted here a moment.
00:49:21.712 --> 00:49:23.115
I want to make sure
I get the right.
00:49:25.280 --> 00:49:27.890
Where's my cluster gone?
00:49:30.239 --> 00:49:32.686
>> We stand up a lot of
clusters in our daily work.
00:49:32.686 --> 00:49:39.710
>> Yeah, it's here, right, okay,
so we love scale, we love perf,
00:49:39.710 --> 00:49:41.720
we're a distributed systems
team, we like that stuff.
00:49:41.720 --> 00:49:43.860
So we stood up a thousand
machine cluster,
00:49:43.860 --> 00:49:44.900
just because you can?
00:49:44.900 --> 00:49:46.003
>> Yes.
00:49:46.003 --> 00:49:49.440
>> And we wanna show that
these things run at scale.
00:49:49.440 --> 00:49:50.067
>> Yeah.
00:49:50.067 --> 00:49:51.030
>> A 1,000 machines.
00:49:51.030 --> 00:49:53.863
Anyway that's, we've said it
before, we're showing it now.
00:49:53.863 --> 00:49:55.419
This is 1,000 machine cluster.
00:49:55.419 --> 00:49:58.879
Now, I'm running [INAUDIBLE]
this gb 12 machines.
00:49:58.879 --> 00:50:00.254
>> This is a Windows cluster.
00:50:00.254 --> 00:50:01.367
Windows server, yeah.
00:50:01.367 --> 00:50:02.960
>> We have this
application running out.
00:50:02.960 --> 00:50:06.190
There's Billblar
engineering team and
00:50:06.190 --> 00:50:08.810
every instance where
application, I guess deployed,
00:50:08.810 --> 00:50:11.860
we'll deploy a number of
container inside all that.
00:50:11.860 --> 00:50:14.450
So we'll deploy, every time I
deploy an instances of this
00:50:14.450 --> 00:50:17.540
application, it will
deploy 5,000 containers.
00:50:17.540 --> 00:50:20.680
You see at the moment
there's a whole bunch of
00:50:20.680 --> 00:50:23.470
containers running inside
this pretty large cluster.
00:50:23.470 --> 00:50:26.250
I've got this wonderful little
graph that was being drawn
00:50:26.250 --> 00:50:27.710
inside here.
00:50:27.710 --> 00:50:30.600
If I move this to one side over
here you'll see if I move this
00:50:30.600 --> 00:50:33.080
over here I've got this graph.
00:50:33.080 --> 00:50:36.210
Effectively now we're showing
a Windows Cluster that's running
00:50:36.210 --> 00:50:38.070
with 30,000 machine clusters.
00:50:38.070 --> 00:50:41.620
Running with 30,000
containers inside it all.
00:50:41.620 --> 00:50:42.420
We're hosting this.
00:50:42.420 --> 00:50:44.210
It's been running for
several days.
00:50:44.210 --> 00:50:45.780
What we've actually
been doing is,
00:50:45.780 --> 00:50:48.330
when you come down to our booth
is that we've been able to show
00:50:48.330 --> 00:50:51.480
you the initial thing
where I can actually do,
00:50:51.480 --> 00:50:56.100
l need to add more
continuous to this, so
00:50:56.100 --> 00:51:01.140
here we go I'm going to add live
on stage 10,000 containers.
00:51:01.140 --> 00:51:02.060
Okay, all right.
00:51:02.060 --> 00:51:02.855
I go login first.
00:51:02.855 --> 00:51:03.930
>> [LAUGH].
>> All right, you go.
00:51:03.930 --> 00:51:05.490
>> Here we go.
00:51:05.490 --> 00:51:07.260
Yes, l am still logged in.
00:51:07.260 --> 00:51:09.991
Okay, here we go, so 10,
0000 containers coming up.
00:51:13.694 --> 00:51:15.480
Here we go.
>> There it goes.
00:51:15.480 --> 00:51:16.810
Look at that.
>> So we're going to add.
00:51:16.810 --> 00:51:18.970
>> The graph, just add here.
00:51:18.970 --> 00:51:20.433
How many do we have?
Scroll up, let's see.
00:51:22.773 --> 00:51:23.450
>> Yeah, it looks.
00:51:23.450 --> 00:51:24.070
>> The number.
00:51:24.070 --> 00:51:24.740
>> Keep going.
00:51:24.740 --> 00:51:28.230
>> Let's just do this here.
00:51:28.230 --> 00:51:30.558
So it's going here there we go.
00:51:30.558 --> 00:51:32.160
This is up to 32,000.
00:51:32.160 --> 00:51:35.706
It refreshes every five seconds.
00:51:35.706 --> 00:51:42.850
So 35,000 I'm scared
she won't hold.
00:51:42.850 --> 00:51:44.416
>> Yes [LAUGH].
00:51:44.416 --> 00:51:49.220
>> [LAUGH] There we go, 36,000,
00:51:49.220 --> 00:51:54.404
coming up to 38,000
>> We're coming up to,
00:51:54.404 --> 00:51:56.520
[INAUDIBLE] 38,317.
00:51:56.520 --> 00:51:57.200
>> Look at that.
>> Yes, and 13,
00:51:57.200 --> 00:51:58.100
getting up there a bit.
00:51:58.100 --> 00:52:03.700
You see this graph down
on the bottom here, and
00:52:03.700 --> 00:52:06.470
can you see this is 39,000.
00:52:06.470 --> 00:52:09.390
>> Let me just do this
right here, there we go,
00:52:09.390 --> 00:52:10.150
now you should be able
00:52:10.150 --> 00:52:12.680
to see the whole graph down
on the bottom here as well.
00:52:12.680 --> 00:52:14.550
And you're going to be
able to see the road.
00:52:14.550 --> 00:52:16.569
Just close now to 40,000,
00:52:16.569 --> 00:52:18.588
so there we are in
about a minute or
00:52:18.588 --> 00:52:22.784
just less we've started 10,000
containers to this cluster.
00:52:22.784 --> 00:52:30.585
That's the rate of speed that
we can deploy these things.
00:52:30.585 --> 00:52:32.250
>> [APPLAUSE]
>> And just because we can.
00:52:32.250 --> 00:52:34.064
>> And less than 10,000 more.
00:52:34.064 --> 00:52:35.540
>> [LAUGH]
>> Very secure.
00:52:35.540 --> 00:52:36.326
>> There we go.
00:52:36.326 --> 00:52:37.260
[LAUGH] We got 10,000 more.
00:52:37.260 --> 00:52:39.420
This is Windows cluster and
00:52:39.420 --> 00:52:45.220
we take the sub cluster in
several 10,000 of containers.
00:52:45.220 --> 00:52:47.180
And that's the time
things are finishing up.
00:52:48.260 --> 00:52:48.875
A 100,000 K.
00:52:48.875 --> 00:52:49.760
100,000 containers.
00:52:49.760 --> 00:52:52.830
You can run on a thousand
machine cluster.
00:52:52.830 --> 00:52:55.118
>> For with the Gb 12
series inside that.
00:52:55.118 --> 00:52:58.790
Now, we're gonna publish number
number of benchmark around all
00:52:58.790 --> 00:53:01.660
this and we'll show you how
we did all this on our blog.
00:53:01.660 --> 00:53:03.300
And as it goes there,
here's the graph,
00:53:03.300 --> 00:53:06.870
it keeps going with publishing
more containers inside that.
00:53:06.870 --> 00:53:09.520
But pretty much, this is
demonstrating effectively that
00:53:09.520 --> 00:53:12.260
we are obsessed with
making sure that service
00:53:12.260 --> 00:53:14.080
traffic [INAUDIBLE]
deployment times.
00:53:14.080 --> 00:53:16.680
But the important thing is for
our fail over times as well.
00:53:16.680 --> 00:53:18.600
We're gonna show you that when
you start killing machines
00:53:18.600 --> 00:53:19.590
inside here,
00:53:19.590 --> 00:53:22.040
we're gonna replace those
containers incredibly fast.
00:53:22.040 --> 00:53:25.130
We detect a machine failure
in less than two seconds.
00:53:25.130 --> 00:53:29.160
We start replacing containers
in seconds across all those.
00:53:29.160 --> 00:53:31.550
And you need to have good
algorithms effectively,
00:53:31.550 --> 00:53:33.990
to make decisions about where
those things are placed.
00:53:33.990 --> 00:53:36.130
You're gonna make
intelligent decisions.
00:53:36.130 --> 00:53:38.320
You can't just randomly place
them all around the place and
00:53:38.320 --> 00:53:39.340
hope for the best.
00:53:39.340 --> 00:53:41.530
Especially when they're
stateful as well.
00:53:41.530 --> 00:53:44.915
So there we are, we've gone
up from 200 now to 50,000
00:53:44.915 --> 00:53:48.900
containers, so this is something
that we're pretty sure that
00:53:48.900 --> 00:53:52.100
you want to know that we bet,
when we talk about it,
00:53:52.100 --> 00:53:54.770
its just being a mission
critical application platform.
00:53:54.770 --> 00:53:57.440
This is some of the things that
we have to do is testing on
00:53:57.440 --> 00:54:00.650
because we effectively run and
bet our own business on this.
00:54:00.650 --> 00:54:02.640
And we're gonna make sure
that Windows Containers and
00:54:02.640 --> 00:54:05.230
Service Fabric are the best
orchestrator in your work.
00:54:05.230 --> 00:54:06.550
>> Hey Mark, what about Linux?
00:54:06.550 --> 00:54:08.710
>> We haven't talked about
Linux very much, have we?
00:54:08.710 --> 00:54:09.610
>> Not really.
00:54:09.610 --> 00:54:11.131
So yeah, we haven't, yeah,
00:54:11.131 --> 00:54:13.006
we could have mostly
done [CROSSTALK].
00:54:13.006 --> 00:54:14.690
>> We did something
cool in Linux.
00:54:14.690 --> 00:54:17.440
>> Well on Linux,
we did actually
00:54:17.440 --> 00:54:20.900
stand up a 3,500 node cluster
on Linux a couple of weeks ago.
00:54:20.900 --> 00:54:24.040
And on that cluster we ran and
00:54:24.040 --> 00:54:25.840
did this similar
sort of application.
00:54:25.840 --> 00:54:29.622
And on that cluster we
placed 1 million containers.
00:54:29.622 --> 00:54:32.390
>> [LAUGH]
>> [APPLAUSE]
00:54:32.390 --> 00:54:37.550
>> This now will thanks you.
00:54:37.550 --> 00:54:39.070
So is small skill thing.
00:54:39.070 --> 00:54:43.250
Yeah, the cluster was that
small size of a machines but
00:54:43.250 --> 00:54:46.020
we have to get to a median just
because it was there because we
00:54:46.020 --> 00:54:47.250
had believe in so.
00:54:47.250 --> 00:54:50.073
>> Aren't you glad we did
not do the Dr. Evil thing?
00:54:50.073 --> 00:54:51.162
>> [LAUGH] Yeah.
00:54:51.162 --> 00:54:51.833
>> A Million.
00:54:51.833 --> 00:54:52.836
>> Yes.
>> [LAUGH].
00:54:52.836 --> 00:54:55.800
>> So that is a million, and
we are pretty pleased with that,
00:54:55.800 --> 00:54:57.360
but we think we are just
getting going, and
00:54:57.360 --> 00:54:58.930
warmed up on this
whole thing yes.
00:54:58.930 --> 00:55:02.095
And the particularly on our
Linux side we are gonna start
00:55:02.095 --> 00:55:04.586
pushing that but
Windows as well and Linux,
00:55:04.586 --> 00:55:06.420
we are open to all
of this stuff.
00:55:06.420 --> 00:55:09.235
But yeah, we are pretty
excited about all of this.
00:55:09.235 --> 00:55:10.980
So this is mostly what we have.
00:55:10.980 --> 00:55:13.530
Here's some sessions that we'd
love you to kind of go to.
00:55:13.530 --> 00:55:14.600
This was the one you went to.
00:55:14.600 --> 00:55:16.570
These other service
public sessions.
00:55:16.570 --> 00:55:18.370
That have happened in here.
00:55:18.370 --> 00:55:20.620
I'd love you to go to
the one tomorrow at 9:00.
00:55:20.620 --> 00:55:23.490
Where Taylor Brown is gonna talk
about the future of Windows
00:55:23.490 --> 00:55:24.410
containers.
00:55:24.410 --> 00:55:27.430
Some very exciting developments
as you look towards that.
00:55:27.430 --> 00:55:31.210
And please go back and listen
to some of our further talks.
00:55:31.210 --> 00:55:35.070
Swiss Re is a customer of ours
who've used Service Fabric and
00:55:35.070 --> 00:55:37.520
they're talking a lot
about IoT solution, and
00:55:37.520 --> 00:55:40.096
how to integrate with the Vim
Hub that happens tomorrow.
00:55:40.096 --> 00:55:44.220
And of course please, give us
some evaluations, and believe
00:55:44.220 --> 00:55:48.060
you were effectively with some
resources around all of this.
00:55:48.060 --> 00:55:49.360
So thank you very much.
00:55:49.360 --> 00:55:49.915
>> Thanks, everybody.
00:55:49.915 --> 00:55:50.415
>> [APPLAUSE]