WEBVTT
00:00:00.130 --> 00:00:02.170
Welcome to this
Serverless Focus Session.
00:00:03.737 --> 00:00:08.636
I'm kinda curious, because of
the type of event this is, how
00:00:08.636 --> 00:00:13.201
many people had to take a flight
to join us here for Build.
00:00:13.201 --> 00:00:17.196
Wow, and how many of you
took a direct flight?
00:00:18.894 --> 00:00:21.270
Okay, so
you had to make a choice.
00:00:21.270 --> 00:00:24.447
You can choose to take
a direct flight or
00:00:24.447 --> 00:00:26.765
to take an indirect flight.
00:00:26.765 --> 00:00:29.171
And because so many of
you took a direct flight,
00:00:29.171 --> 00:00:32.410
it sounds like you're familiar
with the convenience.
00:00:32.410 --> 00:00:35.540
You only have to make it
on time for one flight, and
00:00:35.540 --> 00:00:38.110
you only have to mind
your luggage once.
00:00:38.110 --> 00:00:39.900
But if you take
a connected flight,
00:00:39.900 --> 00:00:43.310
you have a few more
things to manage, right?
00:00:43.310 --> 00:00:47.200
You have to make it on time for
every flight, you have to mind
00:00:47.200 --> 00:00:52.210
your luggage, you have to manage
your time in those airports, and
00:00:52.210 --> 00:00:54.830
maybe you have to pay for
other expenses like meals.
00:00:56.420 --> 00:00:58.460
So, why am I talking about this?
00:00:58.460 --> 00:01:01.360
I'm talking about this because
it’s a very good analogy for
00:01:01.360 --> 00:01:02.430
today’s topic.
00:01:04.570 --> 00:01:07.260
Choosing Serverless, it's almost
00:01:07.260 --> 00:01:10.120
like choosing a direct flight
to your business goals.
00:01:11.450 --> 00:01:16.448
Not choosing Serverless is
almost taking an indirect flight
00:01:16.448 --> 00:01:18.510
to your business goals.
00:01:20.850 --> 00:01:24.978
Both of those are valid choices,
and you should arrive to
00:01:24.978 --> 00:01:29.708
the same destination, but there
is additional management costs
00:01:29.708 --> 00:01:33.841
and maybe there's additional
risk associated with it.
00:01:33.841 --> 00:01:38.967
And maybe, just maybe,
you have to be mindful
00:01:38.967 --> 00:01:44.170
about what your
competition is doing.
00:01:44.170 --> 00:01:48.028
In this market landscape,
the choices you make and
00:01:48.028 --> 00:01:51.716
the choices they make can
affect your business.
00:01:51.716 --> 00:01:54.240
So, let's talk about Serverless.
00:01:54.240 --> 00:01:58.178
As you can see, there are lot of
people talking of Serverless in
00:01:58.178 --> 00:02:02.284
the news, and that means there's
great momentum in the market.
00:02:02.284 --> 00:02:05.742
That means it's a great time to
get on board of this flight.
00:02:08.388 --> 00:02:12.340
So, for this session, we will
talk a little bit about what it
00:02:12.340 --> 00:02:14.700
means to run
Serverless on Azure.
00:02:14.700 --> 00:02:19.507
We will talk about the building
blocks, and we will also talk
00:02:19.507 --> 00:02:23.951
about the Serverless
application lifecycle in Azure.
00:02:23.951 --> 00:02:28.112
We will focus on designing,
developing,
00:02:28.112 --> 00:02:33.320
deploying, monitoring
Serverless applications.
00:02:33.320 --> 00:02:39.232
So how many of you have already
tried a function app in Azure?
00:02:39.232 --> 00:02:44.275
Okay, how many of you
have tried a logic app?
00:02:44.275 --> 00:02:46.534
Okay, that's kind
of what we expected
00:02:50.109 --> 00:02:54.780
My name is Daria Grigoriu,
I'm a Senior Program Manager
00:02:54.780 --> 00:02:59.270
with the Azure App Service and
Azure Functions teams.
00:02:59.270 --> 00:03:01.598
I've been on this team since
the very beginning, and
00:03:01.598 --> 00:03:04.340
I really love this technology,
but more than the technology,
00:03:04.340 --> 00:03:05.957
I love to see what
people do to use it.
00:03:05.957 --> 00:03:09.838
And I hope that,
at the end of this session, and
00:03:09.838 --> 00:03:13.429
will choose to reach out
to me and our team and
00:03:13.429 --> 00:03:16.728
let us know how this
is working for you and
00:03:16.728 --> 00:03:21.030
how our team can help you
reach your business goals.
00:03:21.030 --> 00:03:22.710
And joining me on stage
is Yochay Kiriatry.
00:03:22.710 --> 00:03:25.500
>> Hey, everybody,
thank you for coming.
00:03:25.500 --> 00:03:27.105
It's a full house, it's great.
00:03:27.105 --> 00:03:29.380
There's people still coming in.
00:03:29.380 --> 00:03:30.330
Awesome, thank you.
00:03:30.330 --> 00:03:31.890
Sorry for the late start.
00:03:31.890 --> 00:03:34.800
We had some network issues,
we still have some problems.
00:03:34.800 --> 00:03:36.420
Anyway, long story short,
thanks.
00:03:36.420 --> 00:03:37.490
My name is Yochay Kiriatry,
00:03:37.490 --> 00:03:39.330
I'm a program manager
on the Azure team,
00:03:39.330 --> 00:03:41.830
specifically working
on Azure Functions.
00:03:41.830 --> 00:03:43.890
I've been working on Azure
Functions App Service reports
00:03:43.890 --> 00:03:47.380
for some time now, and we're
very happy to be here to talk.
00:03:47.380 --> 00:03:50.363
Our team blogs a lot on
blogs.msdn.microsoft.com
00:03:50.363 --> 00:03:53.147
/appserviceteam where
all the announcements,
00:03:53.147 --> 00:03:56.728
the latest Visual Studio tooling
app [INAUDIBLE] integration and
00:03:56.728 --> 00:03:59.151
a bunch of other stuff,
which is awesome.
00:03:59.151 --> 00:04:00.150
This is my Twitter handle,
00:04:00.150 --> 00:04:03.990
if you want my email you
can see it right there, and
00:04:03.990 --> 00:04:09.430
with that, I think we're moving
on, forward, not backward.
00:04:09.430 --> 00:04:10.664
Okay, so let's go through it.
00:04:10.664 --> 00:04:13.582
Let's go through a brief
quick wake of evaluation of
00:04:13.582 --> 00:04:16.965
the application platform, how
we evolve and got to the point
00:04:16.965 --> 00:04:20.980
where we're gonna actually
talk to you about Serverless.
00:04:20.980 --> 00:04:23.630
About half of the room raised
their hand when we talked about
00:04:23.630 --> 00:04:26.820
that, so we'll see how we
smooth the transition to
00:04:26.820 --> 00:04:28.060
everybody else.
00:04:28.060 --> 00:04:30.220
So, we started on premise,
and we had hardware, and
00:04:30.220 --> 00:04:35.040
basically with the evolution of
all the different platforms,
00:04:35.040 --> 00:04:39.230
their optimization happening
both on hardware and software.
00:04:39.230 --> 00:04:41.690
With the hardware, we definitely
saw what people are doing,
00:04:42.880 --> 00:04:45.120
virtualization, and then they
took this virtualization to
00:04:45.120 --> 00:04:47.740
the cloud where we
have basically ILs.
00:04:47.740 --> 00:04:50.140
Then, later on, we distanced
ourselves even further, and
00:04:50.140 --> 00:04:52.010
we went to platform
as a service.
00:04:52.010 --> 00:04:54.540
Fully managed service where
you're don't even manage,
00:04:54.540 --> 00:04:56.580
not just the hardware, but
you're managing the OS,
00:04:56.580 --> 00:04:58.390
the patches, anything like that.
00:04:58.390 --> 00:05:00.770
Now we're moving into
the Serverless scene,
00:05:00.770 --> 00:05:04.280
which is basically giving you
completely fully managed.
00:05:04.280 --> 00:05:05.070
You don't even care for
00:05:05.070 --> 00:05:07.890
the application, your platform
which is running on there.
00:05:07.890 --> 00:05:12.210
You just write your functions,
all goes there, all goes great.
00:05:13.260 --> 00:05:17.173
With that in mind, basically,
if you look at Serverless
00:05:17.173 --> 00:05:20.933
fundamentally, we look at
Serverless in a nutshell.
00:05:20.933 --> 00:05:23.977
We basically abstract all
the service program, so
00:05:23.977 --> 00:05:26.324
it's a fully managed system,
right?
00:05:26.324 --> 00:05:29.764
You don't do any, you have
basically zero administrative
00:05:29.764 --> 00:05:32.375
tasks to be able to manage
any of the service,
00:05:32.375 --> 00:05:34.520
all being managed for you.
00:05:34.520 --> 00:05:36.100
Your OS, the attaching,
00:05:36.100 --> 00:05:38.960
the servers,
everything then goes with it.
00:05:38.960 --> 00:05:42.687
And our fundamental issue,
sorry, our fundamental concept
00:05:42.687 --> 00:05:45.346
of server lists is
that it's event driven.
00:05:45.346 --> 00:05:47.480
What does it mean?
It means if there are no events,
00:05:47.480 --> 00:05:49.360
if nothing triggers
your function,
00:05:49.360 --> 00:05:52.010
nothing invokes your function,
your function doesn't run.
00:05:52.010 --> 00:05:53.730
And there is some events.
00:05:53.730 --> 00:05:55.250
Some of your
00:05:55.250 --> 00:05:56.960
function [INAUDIBLE]
hitting all the events.
00:05:56.960 --> 00:05:58.210
And when there's
a lot of events,
00:05:58.210 --> 00:06:00.310
then basically, the system
will scale everything for you.
00:06:00.310 --> 00:06:04.260
It will just run as much scale
as needed and be able to just
00:06:04.260 --> 00:06:08.020
absorb all the function,
all the invocation for you.
00:06:08.020 --> 00:06:10.740
Coupled with the micro-billing,
basically what happen is
00:06:10.740 --> 00:06:12.669
that you don't pay if
there are no events.
00:06:12.669 --> 00:06:15.140
There's not reserve
capacity in advance.
00:06:15.140 --> 00:06:15.640
Right?
00:06:15.640 --> 00:06:17.420
No events,
you're not paying anything.
00:06:17.420 --> 00:06:20.110
Some events, you're paying for
whatever's actually being run.
00:06:20.110 --> 00:06:22.100
And combined together,
that's where the servers and
00:06:22.100 --> 00:06:23.780
the powers come together.
00:06:23.780 --> 00:06:26.640
And serverless is great, because
all of that basically allows you
00:06:26.640 --> 00:06:27.790
to reduce everything you do.
00:06:27.790 --> 00:06:29.670
You don't need to
manage infrastructure.
00:06:29.670 --> 00:06:30.810
You don't need to
manage your OS,
00:06:30.810 --> 00:06:33.000
you don't need to
package the whole thing.
00:06:33.000 --> 00:06:35.700
So we're reducing to your dev
apps and devops productivity
00:06:35.700 --> 00:06:39.080
basically increases and focuses
only on what you need to build.
00:06:39.080 --> 00:06:40.310
Which is basically will just
00:06:40.310 --> 00:06:42.120
enable you to focus on
your business logic.
00:06:42.120 --> 00:06:45.170
You can go ahead and just drive
and build your application.
00:06:45.170 --> 00:06:48.350
Literally from the first line
of code, you're adding volume.
00:06:48.350 --> 00:06:51.489
You're building business logic
versus management aspect or
00:06:51.489 --> 00:06:55.120
be able to handle a bunch of
other stuff without Serverless.
00:06:55.120 --> 00:06:58.620
And all of that together
basically is making your
00:06:58.620 --> 00:07:00.680
time to market a lot faster.
00:07:00.680 --> 00:07:01.490
And it's all awesome.
00:07:02.510 --> 00:07:03.710
Okay, so on Azure.
00:07:05.380 --> 00:07:06.890
What do we got?
00:07:06.890 --> 00:07:11.180
So the application platform
on Azure is composed of two
00:07:12.650 --> 00:07:16.390
main building blocks, Azure
Functions and Azure Logic Apps.
00:07:16.390 --> 00:07:17.790
Azure Functions
maybe would expect
00:07:17.790 --> 00:07:18.730
is where you write in code.
00:07:18.730 --> 00:07:20.520
You can define yourself and
write code and
00:07:20.520 --> 00:07:23.625
you can express yourself
in JavaScript, C#,
00:07:23.625 --> 00:07:27.550
F# And we have other languages
as well in preview, and
00:07:27.550 --> 00:07:29.330
we're adding more and
more languages.
00:07:29.330 --> 00:07:30.670
We have amazing
developer tooling,
00:07:30.670 --> 00:07:32.680
as we're gonna show
in some demos.
00:07:32.680 --> 00:07:35.150
Bindings and triggers
are awesome with functions.
00:07:35.150 --> 00:07:38.120
And then the whole thing is open
source, and it's all documented.
00:07:38.120 --> 00:07:39.768
So if you're really interested,
go there.
00:07:39.768 --> 00:07:41.490
And Logic Apps
are another amazing tools,
00:07:41.490 --> 00:07:43.420
again we'll see a demo later.
00:07:43.420 --> 00:07:47.370
Logic Apps basically
a fully managed workflow,
00:07:47.370 --> 00:07:49.800
fully managed
Serverless workflow,
00:07:49.800 --> 00:07:52.040
orchestration engine for
function and other services,
00:07:52.040 --> 00:07:57.220
has an amazing visual designer,
has 125 connectors, and
00:07:57.220 --> 00:08:01.040
works well with functions and
any other data services.
00:08:01.040 --> 00:08:04.550
However, while you can do
this for your compute aspect
00:08:04.550 --> 00:08:07.980
you still need a whole platform
actually to build an app, right?
00:08:07.980 --> 00:08:08.540
You need data,
00:08:08.540 --> 00:08:10.980
you need messaging,
you need intelligence,
00:08:10.980 --> 00:08:13.170
you want to add bots,
you need to do the whole thing.
00:08:13.170 --> 00:08:16.390
So to be able to have the whole
package Azure provide you this
00:08:16.390 --> 00:08:20.930
fully managed set of services
that basically together with
00:08:20.930 --> 00:08:23.130
the core serverless
component of function and
00:08:23.130 --> 00:08:26.100
logic gives you
a full-blown kind
00:08:26.100 --> 00:08:29.560
of serverless architecture
that you can build on Azure.
00:08:29.560 --> 00:08:30.400
It's fully managed for
00:08:30.400 --> 00:08:32.510
you, you don't need to manage
any of the services or
00:08:32.510 --> 00:08:35.040
underlying infrastructure
to make that work.
00:08:35.040 --> 00:08:37.580
As again, we will see in some
of the demos we're going to run.
00:08:37.580 --> 00:08:40.688
And obviously Microsoft
has been, from day one,
00:08:40.688 --> 00:08:42.686
a developer focused company and
00:08:42.686 --> 00:08:46.312
everything we have around
the development experience for
00:08:46.312 --> 00:08:49.802
both function logic and
the entire ecosystem is great.
00:08:49.802 --> 00:08:51.898
We have support for
Visual Studio, local tooling,
00:08:51.898 --> 00:08:52.708
local debugging and
00:08:52.708 --> 00:08:54.868
bunch of other stuff that
we'll be able to see later.
00:08:54.868 --> 00:09:00.080
All right so
what we've seen customer's been
00:09:00.080 --> 00:09:02.560
using over the last year,
year and
00:09:02.560 --> 00:09:04.860
a half we've been working,
we've seen a lot of customers.
00:09:04.860 --> 00:09:07.360
And these are some of the common
scenarios that we've seen.
00:09:07.360 --> 00:09:09.950
Top left,
you see the web version,
00:09:09.950 --> 00:09:12.640
which is a fully serverless
web application.
00:09:12.640 --> 00:09:15.080
Dia will demo that during the,
00:09:15.080 --> 00:09:18.270
we'll see a demo through
the rest of the presentation.
00:09:18.270 --> 00:09:20.874
What we also see is a lot of
what we call glue rn cloud
00:09:20.874 --> 00:09:23.450
scripting, whatever
you want to call this.
00:09:23.450 --> 00:09:24.710
A lot of companies
are basically saying,
00:09:24.710 --> 00:09:27.020
hey we already have
an existing application.
00:09:27.020 --> 00:09:28.980
How can slowly go
into Serverless?
00:09:28.980 --> 00:09:30.850
We don't wanna
rewrite everything.
00:09:30.850 --> 00:09:34.402
So the glue is a great example
of if some event is happening
00:09:34.402 --> 00:09:38.324
here or there and you basically
add Serverless slowly into your
00:09:38.324 --> 00:09:41.375
application portfolio to
ease your way into it.
00:09:41.375 --> 00:09:42.980
Obviously bots and AI,
00:09:42.980 --> 00:09:46.275
you've seen through
the keynotes yesterday and
00:09:46.275 --> 00:09:50.614
today a rising platform nuisance
and there's nothing more easy
00:09:50.614 --> 00:09:54.406
than just basically integrate
the function with bots.
00:09:54.406 --> 00:09:58.680
Actually Azure Service is
built on Azure functions.
00:09:58.680 --> 00:10:02.740
And IoT is another very
common scenario where we
00:10:02.740 --> 00:10:05.950
see a lot of companies going
into IoT because the nature of
00:10:05.950 --> 00:10:08.270
the Serverless with
the spikiness and the scale.
00:10:08.270 --> 00:10:10.420
You don't need to manage any
infrastructure before, so
00:10:10.420 --> 00:10:12.450
it perfectly fits with IoT and
00:10:12.450 --> 00:10:14.290
a lot of streaming and
all of that.
00:10:14.290 --> 00:10:15.580
So with that in mind,
00:10:15.580 --> 00:10:18.000
Ardai will take you through
a customer example.
00:10:20.170 --> 00:10:24.950
>> You might've heard about
Domino's in the keynote.
00:10:24.950 --> 00:10:27.550
For this particular
session we will focus
00:10:27.550 --> 00:10:29.240
on one way they use
Azure functions.
00:10:33.013 --> 00:10:36.950
Domino's has changed the way
they move their data from their
00:10:36.950 --> 00:10:40.020
stores to their data warehouse.
00:10:40.020 --> 00:10:43.060
So what they do is they drop
files from their stores
00:10:43.060 --> 00:10:47.310
onto an SMB share, and the
presence of those files triggers
00:10:47.310 --> 00:10:50.560
Azure Functions to excrypt
the data and move it to SQL.
00:10:52.010 --> 00:10:55.475
This is a great illustration of
the Serverless model because you
00:10:55.475 --> 00:10:57.409
see entirely a Ven
driven compute.
00:10:57.409 --> 00:11:00.350
And you see this focus
on the business logic.
00:11:03.450 --> 00:11:07.000
Also the demand for compute is
not constant throughout the day.
00:11:07.000 --> 00:11:09.400
So they can scale
when they need to and
00:11:09.400 --> 00:11:12.010
it's great that they only have
to pay for what they use.
00:11:14.250 --> 00:11:17.174
We also learned that
their demand for
00:11:17.174 --> 00:11:21.986
continuous integration unwinds
well with the model of Azure
00:11:21.986 --> 00:11:26.704
functions because they can
update their functions through
00:11:26.704 --> 00:11:28.226
gate check-ins.
00:11:33.941 --> 00:11:38.253
So we will look at a simple
demo that we can leverage
00:11:38.253 --> 00:11:40.616
throughout the session for
00:11:40.616 --> 00:11:46.570
us to be able to illustrate the
concepts that we need to cover.
00:11:46.570 --> 00:11:50.650
This is a simple pizza ordering
app that will help us navigate
00:11:50.650 --> 00:11:53.858
Serverless concepts
throughout the session.
00:11:53.858 --> 00:11:57.740
You might ask,
how can a simple app be useful?
00:11:57.740 --> 00:12:02.570
Believe or not, it contains
all of the building blocks
00:12:02.570 --> 00:12:07.088
that we need for a basic
Azure server application.
00:12:07.088 --> 00:12:10.140
You can see how we
have a web client.
00:12:10.140 --> 00:12:14.330
This is hosted in storage and
you will talk about how we use
00:12:14.330 --> 00:12:18.740
proxies with Azure functions
to access this content.
00:12:19.840 --> 00:12:22.830
You can see that we have
the ability to order a coupon.
00:12:24.450 --> 00:12:28.686
Here we can provide an email
address and request for
00:12:28.686 --> 00:12:32.736
a coupon to be emailed to
the address we provide.
00:12:32.736 --> 00:12:36.652
Behind the scenes our
application is calling a logic
00:12:36.652 --> 00:12:40.835
app that orchestrates a workflow
requesting the coupon
00:12:40.835 --> 00:12:43.060
from a function app.
00:12:43.060 --> 00:12:50.070
And then calling into Office 365
in order to obtain the coupon.
00:12:54.550 --> 00:12:57.300
You can see we also have
the ability to place an order.
00:12:58.520 --> 00:13:02.130
When you place an order, behind
the scenes the application is
00:13:02.130 --> 00:13:04.955
calling into a function app.
00:13:04.955 --> 00:13:09.730
This function app also connects
with SQL in order to store
00:13:09.730 --> 00:13:11.120
the order that was placed.
00:13:13.230 --> 00:13:18.680
So we will take each component
throughout the session and
00:13:18.680 --> 00:13:22.290
we will explore how
the application was created.
00:13:22.290 --> 00:13:26.055
And might the capabilities and
the workflows that we use for
00:13:26.055 --> 00:13:27.340
these components.
00:13:28.770 --> 00:13:30.440
>> Okay, so basically,
00:13:31.850 --> 00:13:36.070
what you should've seen
is a web application,
00:13:36.070 --> 00:13:39.840
a single page application that
is actually hosted on storage.
00:13:39.840 --> 00:13:42.894
And with specific
proxies definition,
00:13:42.894 --> 00:13:47.200
we'll show you in a second,
you'll be able to see that we
00:13:47.200 --> 00:13:51.510
can actually have an Azure
function proxy front almost,
00:13:51.510 --> 00:13:55.574
not almost, basically anything,
any back end URL.
00:13:55.574 --> 00:13:58.978
And you can host a single
page application from storage
00:13:58.978 --> 00:14:00.300
as an example.
00:14:00.300 --> 00:14:01.820
And then the order
processing and
00:14:01.820 --> 00:14:05.110
the coupon processing basically
one goes into a function data
00:14:05.110 --> 00:14:06.780
one goes into a logic apps.
00:14:06.780 --> 00:14:09.770
And again we'll see some
of those components come
00:14:09.770 --> 00:14:13.370
into play later through
the other demos assuming
00:14:13.370 --> 00:14:15.490
everything will work for us.
00:14:15.490 --> 00:14:18.740
So with that in mind basically
we go to build serverless
00:14:19.840 --> 00:14:21.030
application.
00:14:21.030 --> 00:14:25.090
We work through some specific
life cycle like design, develop,
00:14:25.090 --> 00:14:26.380
deploy, and monitor.
00:14:26.380 --> 00:14:29.422
And basically the rest of
the session is focused on
00:14:29.422 --> 00:14:31.306
specifically those assets and
00:14:31.306 --> 00:14:33.414
all the demos that
goes with that.
00:14:33.414 --> 00:14:34.528
So we'll start with design.
00:14:38.634 --> 00:14:41.350
When you come to talk about
Serverless application and
00:14:41.350 --> 00:14:43.533
design, the thing you
need to remember is,
00:14:43.533 --> 00:14:46.340
Serverless is a distributed
system by definition.
00:14:46.340 --> 00:14:47.040
Right?
00:14:47.040 --> 00:14:50.940
Your app should be stateless
async, ideally, for scaling.
00:14:50.940 --> 00:14:53.520
So you need to remember
that when you run Azure
00:14:53.520 --> 00:14:56.810
functions one invocation can
happen on one machine, the other
00:14:56.810 --> 00:14:59.060
invocation can happen on a
different machine and so forth.
00:14:59.060 --> 00:15:01.370
So it can bounce between
all those machines.
00:15:01.370 --> 00:15:03.810
So you need to be able
to design stateless and
00:15:03.810 --> 00:15:07.750
ASync solutions to be able
to scale, to take advantage
00:15:07.750 --> 00:15:11.130
of the fact that this
event-driven programming model
00:15:11.130 --> 00:15:13.551
behind the scene that allows you
to actually scale enormously.
00:15:15.470 --> 00:15:19.500
Obviously you can connect with a
bunch of other services, either
00:15:19.500 --> 00:15:21.900
Azure Services or third-party
services through trigger and
00:15:21.900 --> 00:15:23.650
binding on Azure function and
00:15:23.650 --> 00:15:25.968
with Logic Apps you
have connectors.
00:15:25.968 --> 00:15:28.325
It's tremendously powerful.
00:15:28.325 --> 00:15:29.783
Figure out how do you
want to use proxies.
00:15:29.783 --> 00:15:33.172
Proxies is again, was showing
the demos to give you ability to
00:15:33.172 --> 00:15:34.745
expose a single API server.
00:15:34.745 --> 00:15:37.285
So then you can manage
multiple different backend and
00:15:37.285 --> 00:15:40.175
you have multiple different
function or any other entities
00:15:40.175 --> 00:15:43.455
that you want to work with
which is again very powerful.
00:15:43.455 --> 00:15:46.855
Logic Apps amazing way
to basically orchestrate
00:15:46.855 --> 00:15:47.940
a workflow.
00:15:47.940 --> 00:15:50.570
You can orchestrate function,
orchestrate other data services.
00:15:50.570 --> 00:15:52.910
It works hand-in-hand
with Azure Functions.
00:15:52.910 --> 00:15:54.530
Really a great
serverless solution for
00:15:54.530 --> 00:15:57.540
managing workflows and accessing
data services on-prem and
00:15:57.540 --> 00:15:59.708
through the cloud.
00:15:59.708 --> 00:16:02.230
And Logic App are basically
a bunch of connections you
00:16:02.230 --> 00:16:03.270
can use all of that.
00:16:03.270 --> 00:16:05.200
And when talking about
services in the cloud,
00:16:05.200 --> 00:16:09.350
obviously you need to remember
the DevCloud is DevOps.
00:16:09.350 --> 00:16:12.830
So everything will auto merging
from Azure Resource Manager.
00:16:12.830 --> 00:16:15.900
Everything we're gonna show
basically are all Azure
00:16:15.900 --> 00:16:19.110
resources, function app, logic
app, all the other components,
00:16:19.110 --> 00:16:20.170
obviously.
00:16:20.170 --> 00:16:24.550
It's all built and
design around DevOps.
00:16:24.550 --> 00:16:27.650
So you can have multiple
deployments, versioning.
00:16:27.650 --> 00:16:31.948
Basically we enable slots
on functions, right?
00:16:31.948 --> 00:16:33.593
We enabled Slots
couple days ago.
00:16:33.593 --> 00:16:36.670
So now I have Slots, which is,
if you're familiar with
00:16:36.670 --> 00:16:40.010
App Service, same concept so
you can have safe deployment,
00:16:40.010 --> 00:16:43.415
you can deploy, test it kind of
in a production environment on
00:16:43.415 --> 00:16:46.361
the cloud and be able to
Safely swapping between, and
00:16:46.361 --> 00:16:48.980
obviously you can monitor and
have alerts, and
00:16:48.980 --> 00:16:52.030
very recent information
with obligation insights.
00:16:52.030 --> 00:16:53.370
So moving on very quick.
00:16:53.370 --> 00:16:54.450
So Triggers and binding.
00:16:54.450 --> 00:16:57.300
Triggers is basically what
invoke your functions.
00:16:57.300 --> 00:16:59.658
They are also consider
input bindings, and
00:16:59.658 --> 00:17:01.770
then you have output
bindings as well.
00:17:01.770 --> 00:17:04.592
And triggers and binding
combines together are a great
00:17:04.592 --> 00:17:07.167
concept because you can
actually with triggers,
00:17:07.167 --> 00:17:09.820
get data from the service
of the triggers you.
00:17:09.820 --> 00:17:12.650
You can use binding as
an instructional data services
00:17:12.650 --> 00:17:14.070
where you write in and out data.
00:17:14.070 --> 00:17:15.500
So instead of writing
to your queue,
00:17:15.500 --> 00:17:16.590
they'll need to bring SDK,
00:17:16.590 --> 00:17:18.830
you just write it directly and
so forth.
00:17:18.830 --> 00:17:22.459
This is a partial list,
we actually have more and
00:17:22.459 --> 00:17:24.238
it's going over time.
00:17:24.238 --> 00:17:29.494
Okay, so for a very long time
Azure functions was running
00:17:29.494 --> 00:17:34.315
supporting scripts,
whether it's JavaScripts or
00:17:34.315 --> 00:17:36.953
whether it's C# scripts.
00:17:36.953 --> 00:17:41.517
With the Visual Studio release
yesterday, of Big Three for
00:17:41.517 --> 00:17:46.445
Visual Studio 2017, and
with updates Azure Core runtime,
00:17:46.445 --> 00:17:48.726
or Core function something,
00:17:48.726 --> 00:17:51.847
what used to be
the Azure Functions CLI.
00:17:51.847 --> 00:17:55.427
The local tooling basically,
we have enabled the ability,
00:17:55.427 --> 00:17:57.953
this was already existing for
a while, but
00:17:57.953 --> 00:17:59.723
now it's official and easy.
00:17:59.723 --> 00:18:03.117
Enabled basically, for a .NET
developer to use attribute in
00:18:03.117 --> 00:18:06.705
addition, because what we have
heard from .NET developers that
00:18:06.705 --> 00:18:10.230
they're more comfortable with
attributes versus running back
00:18:10.230 --> 00:18:11.615
and forth with the JSON.
00:18:11.615 --> 00:18:14.540
What you see is very simple,
hey, here's your function app.
00:18:14.540 --> 00:18:16.060
Your function name,
you can define it.
00:18:16.060 --> 00:18:19.120
What do you expect, you have
attributes that are defining,
00:18:19.120 --> 00:18:20.380
basically for example,
00:18:20.380 --> 00:18:22.910
HTTP trigger is that a request
it maps to the JSON.
00:18:22.910 --> 00:18:24.400
You don't need to write
the JSON anymore.
00:18:24.400 --> 00:18:30.274
We are doing the compilation
of your function.
00:18:30.274 --> 00:18:34.090
We are building
the function JSON for you.
00:18:34.090 --> 00:18:36.060
Function's JSON is still
required because we need it to
00:18:36.060 --> 00:18:37.960
support other languages as well.
00:18:37.960 --> 00:18:39.440
So here's direct as an example,
and
00:18:39.440 --> 00:18:41.610
you can use it as
you would expect.
00:18:41.610 --> 00:18:45.480
And here are the queues, so
there is an output queue here.
00:18:45.480 --> 00:18:49.650
As you can see, define the queue
name, the department you work
00:18:49.650 --> 00:18:52.380
with, the connection screen, all
of those information is again,
00:18:52.380 --> 00:18:57.550
mapped through the function JSON
which again, being created for
00:18:57.550 --> 00:18:58.250
you automatically.
00:19:01.196 --> 00:19:06.195
All right, so with that, we'll
see a demo of all of the local
00:19:06.195 --> 00:19:09.738
debugging, so
we'll see the specifics.
00:19:09.738 --> 00:19:11.700
We said we'll skip
some of the demo order.
00:19:12.790 --> 00:19:15.430
Next, I wanted to run through
API abstraction and composition.
00:19:15.430 --> 00:19:18.540
So let's say you
have a function app.
00:19:18.540 --> 00:19:22.780
Function App exposing HTTP
endpoints on Function A.
00:19:22.780 --> 00:19:25.110
Let's say you have
additional Function App,
00:19:25.110 --> 00:19:28.150
because you want to build kind
of a microservices architecture.
00:19:28.150 --> 00:19:30.121
You want to be able to
compartmentalizing your
00:19:30.121 --> 00:19:31.826
application, you have to
have different things,
00:19:31.826 --> 00:19:35.058
do different things, so you
have Function a and Function b.
00:19:35.058 --> 00:19:35.860
But also expose an API.
00:19:35.860 --> 00:19:40.793
And you want the client to be
able to manage all of that,
00:19:40.793 --> 00:19:43.583
so with Azure function proxy,
00:19:43.583 --> 00:19:48.304
you can actually produce and
show a single surface,
00:19:48.304 --> 00:19:53.476
you can expose a singe API
surface for your application.
00:19:53.476 --> 00:19:57.056
On the functioning in this
example which provide a single
00:19:57.056 --> 00:20:00.710
unified API service to any kind
of back end URL if you want to
00:20:00.710 --> 00:20:04.439
use and there is a lot more you
can do other than just expose it
00:20:04.439 --> 00:20:05.500
back in the URL.
00:20:05.500 --> 00:20:06.450
There is a lot of
00:20:06.450 --> 00:20:08.070
transformation that you can
do in management of API.
00:20:08.070 --> 00:20:10.550
So assuming we have network.
00:20:10.550 --> 00:20:14.220
>> Our demo application
is as proxies.
00:20:14.220 --> 00:20:17.510
Proxies is a preview feature for
Function Apps and
00:20:17.510 --> 00:20:21.460
it allows us to do pattern
matching on incoming requests
00:20:23.000 --> 00:20:25.610
in order to expose
a unified API.
00:20:26.630 --> 00:20:32.360
Our demo app uses proxies for
content or coupon processing so
00:20:32.360 --> 00:20:36.040
it's pointing to a logic app in
the case of coupon processing.
00:20:37.620 --> 00:20:42.460
And for order processing it's
pointing to a Function App in
00:20:42.460 --> 00:20:43.910
the case of order processing.
00:20:45.580 --> 00:20:48.560
You can see that we have
access keys that we're
00:20:48.560 --> 00:20:53.590
abstracting away from
the client by using proxies.
00:20:53.590 --> 00:20:57.840
And you can see also that we
have the ability to repoint
00:20:57.840 --> 00:21:02.340
the back end if we look at how
proxies are actually defined.
00:21:03.760 --> 00:21:06.670
For each proxy we have a proxy
definition that involves
00:21:06.670 --> 00:21:09.650
a match condition, where we can
00:21:09.650 --> 00:21:13.740
decide what kind of distributive
methods we want to respond to.
00:21:13.740 --> 00:21:17.740
And we also have the ability to
rewrite parts of the requester,
00:21:17.740 --> 00:21:20.724
parts of the response.
00:21:23.220 --> 00:21:27.314
The value of proxies doesn't
stop at the unified API surface.
00:21:27.314 --> 00:21:30.110
You can also do versioning.
00:21:30.110 --> 00:21:32.860
You can also do
things like mocks.
00:21:32.860 --> 00:21:37.113
Where you might be nabled
development across the system,
00:21:37.113 --> 00:21:39.903
by creating mocks,
such as this one.
00:21:39.903 --> 00:21:46.931
So here we can go and we can
access one of our proxies.
00:21:46.931 --> 00:21:52.044
And we don't have to have an
actual backing associated with
00:21:52.044 --> 00:21:57.011
it, but we have enabled
development across the system.
00:21:57.011 --> 00:22:04.578
>> So- While variuos setting
up the workflow demo,
00:22:04.578 --> 00:22:06.976
which will hopefully work,
it's partially local, right?
00:22:06.976 --> 00:22:09.920
We can show some of that,
at least, hopefully.
00:22:09.920 --> 00:22:14.201
>> Yeah, so workflow,
Logic Apps offer a serverless
00:22:14.201 --> 00:22:19.086
workflow orchestration for
function and data services.
00:22:19.086 --> 00:22:21.126
And it's amazing tool
basically to go ahead and
00:22:21.126 --> 00:22:22.510
integrate with bunch of stuff.
00:22:24.050 --> 00:22:27.310
It's a fully managed workflow
as a service in the cloud.
00:22:27.310 --> 00:22:30.323
It provide you full control,
all the flow.
00:22:30.323 --> 00:22:32.710
The designer is amazing.
00:22:32.710 --> 00:22:34.411
And the designer can
do a lot of the stuff,
00:22:34.411 --> 00:22:35.680
a lot of workflow conditions.
00:22:35.680 --> 00:22:41.750
But there is a rich declarative
language behind to support this.
00:22:41.750 --> 00:22:44.184
And you can use that if the
designer is not good enough, or
00:22:44.184 --> 00:22:46.230
doesn't capable of
everything you want to do.
00:22:46.230 --> 00:22:49.136
So there is a very
declarative definition,
00:22:49.136 --> 00:22:51.840
persistent between the states.
00:22:51.840 --> 00:22:55.944
Really, really cool and you can
orchestrate, not just function,
00:22:55.944 --> 00:22:57.530
but other data services.
00:22:57.530 --> 00:23:00.212
And this is important
because this is again,
00:23:00.212 --> 00:23:03.739
this is just a partial list of
much of the connectors with our
00:23:03.739 --> 00:23:05.800
available with Azure Logic Apps.
00:23:05.800 --> 00:23:09.419
And 125 connectors right now but
were actually adding more and
00:23:09.419 --> 00:23:10.482
more all the time.
00:23:10.482 --> 00:23:12.556
You can see here a lot
of Azure names, but
00:23:12.556 --> 00:23:14.990
you can see also
a lot of third party.
00:23:14.990 --> 00:23:18.996
So we can very easily connect
to other services, other non
00:23:18.996 --> 00:23:23.248
Microsoft services and use them
to be able to push data towards
00:23:23.248 --> 00:23:27.780
them, get data from them,
whether it's SDP, Twitter, SAAP.
00:23:27.780 --> 00:23:30.996
There's a bunch of starts Spark,
or Trello, Twilio and
00:23:30.996 --> 00:23:32.750
a bunch of other stuff.
00:23:32.750 --> 00:23:35.220
As well as there is a whole slew
00:23:35.220 --> 00:23:37.780
of hybrid connections you
can connect to on prem.
00:23:37.780 --> 00:23:38.453
And basically,
00:23:38.453 --> 00:23:41.008
Logic Apps allow you to connect
trough literally everything.
00:23:41.008 --> 00:23:43.328
So you can connect to
other Azure services,
00:23:43.328 --> 00:23:46.400
you can compose functioning in
between if you want to, you
00:23:46.400 --> 00:23:49.535
can connect to a lot of other
third party services and you can
00:23:49.535 --> 00:23:52.630
connect to on premise as well
with the on premise gateway.
00:23:52.630 --> 00:23:54.639
And for that,
are we ready with the demo?
00:23:55.760 --> 00:23:58.648
>> We mentioned our demo
app uses a Logic Apps for
00:23:58.648 --> 00:24:00.170
combined processing.
00:24:00.170 --> 00:24:04.750
This is a workflow that is very
easy to see, when you look at
00:24:04.750 --> 00:24:09.060
the Logic App Designer
available in the Azure Portal.
00:24:10.210 --> 00:24:14.306
Here you can see that
we can add actions, and
00:24:14.306 --> 00:24:19.530
we can also add control flow
elements like conditions.
00:24:19.530 --> 00:24:25.084
In this case, we are looking for
a valid email in order for
00:24:25.084 --> 00:24:29.250
us to send,
provided by the function app,
00:24:29.250 --> 00:24:33.910
to the address that was
shared by the customer.
00:24:36.020 --> 00:24:40.206
It's very easy to add more
elements to this flow.
00:24:40.206 --> 00:24:47.630
We can add actions, we can add
conditions and you can see-
00:24:48.960 --> 00:24:53.567
As we mentioned earlier, you
have so many options to choose
00:24:53.567 --> 00:24:59.110
from as far as connectors that
are available are concerned.
00:24:59.110 --> 00:25:02.680
Soon you can enable a wide
variety of business workflows.
00:25:06.646 --> 00:25:11.066
This information that
is represented as
00:25:11.066 --> 00:25:18.080
the Logic App Designer, is
actually persistent a code view.
00:25:18.080 --> 00:25:20.304
Now you can also edit, and
00:25:20.304 --> 00:25:24.754
this is where it enables
mobility and it enables us to
00:25:24.754 --> 00:25:30.030
have a much deeper view into how
the concepts are abstracted.
00:25:30.030 --> 00:25:36.264
And we are ready to start
talking about the development
00:25:36.264 --> 00:25:40.879
segment of our
application lifecycle.
00:25:40.879 --> 00:25:47.129
For development, you have great
local development options.
00:25:47.129 --> 00:25:51.497
We have the Azure functions
Core tools and these used to be
00:25:51.497 --> 00:25:56.602
called the Azure function CLI if
you've tried it in that version.
00:25:56.602 --> 00:25:59.889
They provide the entire
functions runtime running
00:25:59.889 --> 00:26:00.580
locally.
00:26:00.580 --> 00:26:02.761
And they can trigger
from local events and
00:26:02.761 --> 00:26:04.700
they can trigger
from Azure events.
00:26:05.760 --> 00:26:09.380
This is a feature complete
that commands our established.
00:26:09.380 --> 00:26:12.300
So it's a great solid
tool to work with.
00:26:13.970 --> 00:26:19.134
For JavaScript, Visual Studio
Code is a great option.
00:26:19.134 --> 00:26:22.668
And for C#, we recommend
Visual Studio 2015 or
00:26:22.668 --> 00:26:25.250
2017 with our functions to link.
00:26:25.250 --> 00:26:30.313
And we can have
a look at what that
00:26:30.313 --> 00:26:37.449
can do when we're doing
local development.
00:26:37.449 --> 00:26:38.229
First of all,
00:26:38.229 --> 00:26:42.090
our new project structure is
based on class libraries.
00:26:42.090 --> 00:26:45.710
You have a great power of
IntelliSense, and unit testing,
00:26:45.710 --> 00:26:47.820
and everything that you're
used to with Visual Studio.
00:26:48.870 --> 00:26:52.829
And we're introducing
WebJobs attributes, so
00:26:52.829 --> 00:26:57.561
that it's easier to convert
from annotations to metadata
00:26:57.561 --> 00:27:00.468
that is required for
our platform.
00:27:04.405 --> 00:27:07.720
There's a lot of value in the
ability to do local development
00:27:07.720 --> 00:27:08.630
and debugging.
00:27:10.140 --> 00:27:12.938
Here we have components
of our demo,
00:27:12.938 --> 00:27:16.644
specifically the order
processing function app
00:27:16.644 --> 00:27:20.810
in the client that we can run
locally in Visual Studio.
00:27:22.315 --> 00:27:25.074
Here we have our order
processing function.
00:27:25.074 --> 00:27:30.064
And I have added a break
point that will allow us to
00:27:30.064 --> 00:27:35.915
interact with the processing
through local debugging.
00:27:35.915 --> 00:27:40.045
And we can get started
with this locally by
00:27:40.045 --> 00:27:43.121
using the Azure function CLI.
00:27:45.640 --> 00:27:49.450
When we launch
the local tooling,
00:27:49.450 --> 00:27:55.640
we have a custom MSL
task that is running.
00:27:55.640 --> 00:27:59.860
And then the binary is picked
up by our local run time and
00:27:59.860 --> 00:28:04.630
you can see me that our
local URL that we can use
00:28:04.630 --> 00:28:06.080
to access this function.
00:28:07.760 --> 00:28:10.980
So we can also run
our client locally.
00:28:13.350 --> 00:28:16.260
When we run our client locally,
we are using
00:28:16.260 --> 00:28:20.710
the same URL that is provided
by the function tooling.
00:28:22.683 --> 00:28:25.258
Here we can place an order and
00:28:25.258 --> 00:28:30.740
we can see we are hitting the
break point that we set earlier.
00:28:31.940 --> 00:28:34.047
Not only that, but
00:28:34.047 --> 00:28:39.060
we can override their
request information.
00:28:39.060 --> 00:28:43.053
Here, I might want to override
the email address that I was
00:28:43.053 --> 00:28:44.120
working with.
00:28:45.600 --> 00:28:49.580
And previously, I had just
a generic email address.
00:28:49.580 --> 00:28:53.335
So I can make a change,
00:28:57.033 --> 00:29:00.810
And show how that
change takes effect.
00:29:00.810 --> 00:29:05.218
Here first we can focus
on the current value,
00:29:05.218 --> 00:29:11.260
personA@example.com and
then we can override this value.
00:29:14.769 --> 00:29:17.566
And we can certainly see
the change is taking effect.
00:29:17.566 --> 00:29:20.948
It's now localdebuggingtest.com.
00:29:22.960 --> 00:29:26.666
So let's continue.
00:29:26.666 --> 00:29:30.730
And once the order is
complete we can go and
00:29:30.730 --> 00:29:34.460
validate by looking
at our database.
00:29:35.640 --> 00:29:38.870
And here we have our
order number, and
00:29:38.870 --> 00:29:42.730
we also have the value of the
email address that we managed to
00:29:42.730 --> 00:29:45.170
override during our
local debugging session.
00:29:49.430 --> 00:29:52.580
The value of the tooling
continues, also through
00:29:52.580 --> 00:29:56.556
familiarity, because you can do
all the things you're used to
00:29:56.556 --> 00:29:59.720
doing when you're running
with Visual Studios.
00:29:59.720 --> 00:30:04.279
Such as being able to do simple
publish directly to Azure by
00:30:04.279 --> 00:30:06.799
doing a right-click publish.
00:30:09.340 --> 00:30:11.332
All right, so
you might say okay,
00:30:11.332 --> 00:30:13.064
if I'm not writing C# code?
00:30:13.064 --> 00:30:16.154
Well, if you're running
Node.js for example,
00:30:16.154 --> 00:30:19.097
you have great features
that are similar to what
00:30:19.097 --> 00:30:21.686
you've just seen in
Visual Studio Code.
00:30:21.686 --> 00:30:25.294
We support Node 6.5.0 and
00:30:25.294 --> 00:30:31.680
VS Code by itself as support for
local debugging.
00:30:31.680 --> 00:30:36.480
But we also have the CLI for
functions so that you can get
00:30:36.480 --> 00:30:39.672
a similar experience to
what you've witnessed here.
00:30:42.520 --> 00:30:45.740
So now, we can also talk
about the deployment aspect.
00:30:48.190 --> 00:30:51.305
When we talk about deployment,
we're talking about a few
00:30:51.305 --> 00:30:53.730
different topics, so
let's explore them.
00:30:53.730 --> 00:30:56.510
The first one is
resource deployment.
00:30:58.270 --> 00:31:00.240
In Azure Function Apps,
Logic Apps,
00:31:00.240 --> 00:31:01.909
are represented as resources.
00:31:01.909 --> 00:31:05.936
So a great consistent and
automatable way to deploy
00:31:05.936 --> 00:31:10.440
resources is by using the
Azure Resource Manager or ARM.
00:31:11.830 --> 00:31:14.477
We use ARM at once to deploy.
00:31:14.477 --> 00:31:17.420
And then once you
deploy your resources,
00:31:17.420 --> 00:31:21.300
you can deploy content or
you can do it at the same time.
00:31:23.100 --> 00:31:25.780
We have great options for
that as well.
00:31:25.780 --> 00:31:28.370
So you can use Visual Studio.
00:31:28.370 --> 00:31:32.143
You can use the CLI Or
Azure Functions Code choice and
00:31:32.143 --> 00:31:35.833
you can also expect continuous
integration to work
00:31:35.833 --> 00:31:37.740
just like you are used to.
00:31:37.740 --> 00:31:42.472
In addition, there is a safe
deployment practice that we talk
00:31:42.472 --> 00:31:45.657
about in Azure and
that is separating your
00:31:45.657 --> 00:31:49.482
production from your
development environment.
00:31:49.482 --> 00:31:51.121
This is especially relevant for
00:31:51.121 --> 00:31:54.600
Silverlight because it is
attentive a programing model.
00:31:54.600 --> 00:31:57.790
So its really important
that you control who
00:31:57.790 --> 00:31:59.690
processes your events.
00:31:59.690 --> 00:32:01.130
And also that you
00:32:03.380 --> 00:32:07.220
control isolation for
productions, that you're not
00:32:07.220 --> 00:32:08.529
deploying over code that is
currently reacting to events.
00:32:09.710 --> 00:32:12.416
And what we advise for
that is using deployment slots.
00:32:12.416 --> 00:32:15.804
You are mentioned that it's
a feature of Azure App Service
00:32:15.804 --> 00:32:18.927
that we just opened up for
Azure Functions this week.
00:32:22.032 --> 00:32:27.086
>> [APPLAUSE]
>> So
00:32:27.086 --> 00:32:32.126
when we talk about Function Apps
as ARM resources, they are very,
00:32:32.126 --> 00:32:37.400
very similar to what you're used
to as app service resources.
00:32:37.400 --> 00:32:39.012
They only have a couple
of things that
00:32:39.012 --> 00:32:40.000
are specific to them.
00:32:40.000 --> 00:32:44.230
One of them is you have
to specify the kind.
00:32:44.230 --> 00:32:48.168
And the other one is that you
have a set of app settings that
00:32:48.168 --> 00:32:50.480
are very specific to functions.
00:32:50.480 --> 00:32:53.934
And what they do is they
describe the dependency to
00:32:53.934 --> 00:32:55.091
Azure Storage.
00:32:59.083 --> 00:33:02.160
So I'm gonna be brave and I'm
gonna try [LAUGH] another demo.
00:33:02.160 --> 00:33:06.274
In the context at
deployment we talked about
00:33:06.274 --> 00:33:09.840
Functions Apps being
ARM Resources.
00:33:09.840 --> 00:33:12.740
Logic Apps also have
an ARM representation.
00:33:14.050 --> 00:33:16.992
You have the ability to
work with Logic Apps
00:33:16.992 --> 00:33:18.961
in Visual Studio Tool link.
00:33:18.961 --> 00:33:23.447
You can see the same Logic App
Designer view here that we used
00:33:23.447 --> 00:33:24.979
to seeing in Azure.
00:33:24.979 --> 00:33:28.599
Not only that, but
you can edit that view.
00:33:28.599 --> 00:33:32.457
And the way changes
are persisted are through ARM
00:33:32.457 --> 00:33:34.350
template formatting.
00:33:35.940 --> 00:33:40.028
So here we can define our
entire set of resources and
00:33:40.028 --> 00:33:44.401
we can expect these resources
to be deployable to Azure
00:33:44.401 --> 00:33:48.124
through the ARM, or
Azure Resource Manager.
00:33:50.714 --> 00:33:52.001
With this tooling,
00:33:52.001 --> 00:33:55.820
it's very easy to do
that type of deployment.
00:33:55.820 --> 00:33:59.890
Let's say that we would like to
deploy our entire logic app.
00:34:01.000 --> 00:34:07.806
And all we have to do Is
do a right-click Deploy.
00:34:11.052 --> 00:34:14.710
Visual Studio is connecting
to the subscription in Azure,
00:34:14.710 --> 00:34:17.344
who is able to arrange
research groups, so
00:34:17.344 --> 00:34:20.580
that we can select a research
group for deployment.
00:34:22.210 --> 00:34:25.490
And once we select a research
group for deployment,
00:34:25.490 --> 00:34:29.650
we can go and watch
the resources being created.
00:34:33.710 --> 00:34:35.731
So I'm selecting
the research group and
00:34:35.731 --> 00:34:37.640
selecting the deployment
template.
00:34:37.640 --> 00:34:41.190
And I'm selecting a set
of parameters that should
00:34:41.190 --> 00:34:41.760
be applied.
00:34:42.800 --> 00:34:45.570
These parameters can be edited.
00:34:47.640 --> 00:34:50.270
So here I am editing the name
for my function app.
00:34:51.980 --> 00:34:53.725
And I will request, deployment.
00:34:56.520 --> 00:35:01.590
We have this resource group
that is currently empty.
00:35:01.590 --> 00:35:06.340
And we can watch for resources
to start being populated
00:35:06.340 --> 00:35:08.330
in this research group
that I selected.
00:35:11.700 --> 00:35:15.080
So, if we continue to rephrase
we will see this starting to be
00:35:15.080 --> 00:35:16.780
created in real time.
00:35:16.780 --> 00:35:19.930
And we might not want for
all of them to be created, but
00:35:19.930 --> 00:35:21.890
you can see how they're
starting to come in.
00:35:25.170 --> 00:35:30.242
So, the next thing that we
wanted to show you today was
00:35:30.242 --> 00:35:37.903
how you can publish
from Visual Studio And
00:35:37.903 --> 00:35:41.170
one way that you can do
that is by click publish.
00:35:41.170 --> 00:35:43.890
It's the same concept that
you might be used to already.
00:35:45.250 --> 00:35:49.470
We also wanted to talk about
how deployment looks like
00:35:49.470 --> 00:35:51.369
when you have deployment
slots in the picture.
00:35:53.050 --> 00:35:56.320
We talks about deployment slots
as a safe deployment practice.
00:35:58.860 --> 00:36:03.330
Here we have our coupon
processing function app,
00:36:03.330 --> 00:36:06.540
the same that we been exploring
throughout the session.
00:36:06.540 --> 00:36:09.230
We have a production
deployments app which is
00:36:09.230 --> 00:36:11.140
the one that you're used to.
00:36:11.140 --> 00:36:14.520
And also we have a staging
deployments that configured.
00:36:16.540 --> 00:36:20.738
The staging deployment side
is a standalone application
00:36:20.738 --> 00:36:25.555
that can be managed, configure,
and addressed individually.
00:36:29.043 --> 00:36:33.409
So we will look at how we can
do a swap deployment, and
00:36:33.409 --> 00:36:36.697
what it looks like
to configures that.
00:36:38.180 --> 00:36:41.372
First we will look at
the results that we
00:36:41.372 --> 00:36:45.730
are currently seeing
from our production side.
00:36:45.730 --> 00:36:50.550
When we asked to retrieve
a coupon, after we request
00:36:50.550 --> 00:36:54.880
a coupon, we are told no coupon
offer is available at this time.
00:36:57.480 --> 00:37:02.480
So here we can make a change and
request for
00:37:02.480 --> 00:37:06.250
the coupon value to be returned
as a free t-shirt coupon.
00:37:08.280 --> 00:37:10.800
This is integrated with GitHub,
so
00:37:10.800 --> 00:37:14.340
we're going to
commit our changes.
00:37:16.660 --> 00:37:21.857
And expect our stagings slide
to be updated with this change.
00:37:33.925 --> 00:37:35.625
So this is our gate commit.
00:37:39.662 --> 00:37:44.513
And if we go back to the portal
view of our staging slide,
00:37:44.513 --> 00:37:49.170
we can see here that we have
this connected to GitHub.
00:37:50.290 --> 00:37:53.958
Not only that, but we can see
our deployment history and
00:37:53.958 --> 00:37:57.560
we can see progress for
synching to our latest commit.
00:38:00.414 --> 00:38:04.940
For this we use our
engine in Azure.
00:38:04.940 --> 00:38:09.630
And we are listening to a web
hook configured to GitHub.
00:38:09.630 --> 00:38:10.830
We're pulling in new changes,
00:38:10.830 --> 00:38:14.600
and we're also doing a local
build on our Azure machines.
00:38:14.600 --> 00:38:18.710
And this is great, because you
have opportunities to build in
00:38:18.710 --> 00:38:23.260
the same environment that you're
planning to run your code in,
00:38:23.260 --> 00:38:24.760
which is always a good idea.
00:38:26.440 --> 00:38:30.850
So there we go, we are notified
that our changes have been
00:38:30.850 --> 00:38:32.730
deployed to this staging site.
00:38:34.530 --> 00:38:37.264
And we can validate
this by going and
00:38:37.264 --> 00:38:40.649
requesting a coupon
from the staging slot.
00:38:47.793 --> 00:38:51.195
And we expect the value return
to be you get a free t-shirt and
00:38:51.195 --> 00:38:52.339
that's what it is.
00:38:54.080 --> 00:38:56.960
So now that we
validated our changes,
00:38:56.960 --> 00:39:01.940
we're ready to go back and
request a swap.
00:39:01.940 --> 00:39:04.510
So that means that
we're swapping between
00:39:04.510 --> 00:39:06.470
our staging site and
our production site.
00:39:09.120 --> 00:39:12.489
And swap operation is
available over here,
00:39:12.489 --> 00:39:15.140
under the function app overview.
00:39:17.730 --> 00:39:23.414
And we can say that we want to
swap from staging to production.
00:39:27.042 --> 00:39:30.180
And then we will be notified
when this wrap is completed.
00:39:32.160 --> 00:39:38.720
One thing to point out here is
that you have to get ready for.
00:39:38.720 --> 00:39:42.740
Your staging starts or
starts in general
00:39:42.740 --> 00:39:45.250
to be configured differently
than production.
00:39:45.250 --> 00:39:46.630
So if we look, for example,
00:39:46.630 --> 00:39:50.190
at application settings
here what we see
00:39:50.190 --> 00:39:53.720
is that we've defined what
we call a sticky up setting.
00:39:55.110 --> 00:40:01.140
It's a storage connection in
this case and you can choose
00:40:01.140 --> 00:40:05.510
to define surge up settings that
will be very integral as well.
00:40:05.510 --> 00:40:09.804
They will stay with the slot
where they have been configured.
00:40:15.762 --> 00:40:19.140
You also have to go over
to diff these app settings.
00:40:19.140 --> 00:40:23.918
So there are a lot of features
that are already available to
00:40:23.918 --> 00:40:29.100
help you with running deployment
stats with Azure functions.
00:40:29.100 --> 00:40:31.733
We were notified that
our swap was completed.
00:40:31.733 --> 00:40:36.651
So now we can go back to our
production side this time, and
00:40:36.651 --> 00:40:39.530
we can request the coupon again.
00:40:42.010 --> 00:40:45.935
And there we go,
we have deployed our changes and
00:40:45.935 --> 00:40:50.452
now we get a response that
our coupon is a free t-shirt.
00:40:50.452 --> 00:40:52.634
>> Right, so the next thing
wanna talk about this
00:40:52.634 --> 00:40:53.305
is monitoring.
00:40:53.305 --> 00:40:58.350
And monitoring basically start
with the ability to monitor.
00:40:58.350 --> 00:41:00.380
So you need to be able to
monitor your serverless
00:41:00.380 --> 00:41:00.950
application.
00:41:00.950 --> 00:41:04.640
Once you're monitoring
you may want to go ahead
00:41:04.640 --> 00:41:10.280
and terminate alerts.
00:41:10.280 --> 00:41:12.990
I'm been worsening,
generates alerts.
00:41:12.990 --> 00:41:15.120
And so
you're monitoring your alerts.
00:41:15.120 --> 00:41:16.220
You basically learn.
00:41:16.220 --> 00:41:17.750
You learn from the telemetry
that comes in.
00:41:17.750 --> 00:41:18.480
You learn from the alert.
00:41:18.480 --> 00:41:21.400
You learn how to actually run
and manage your application.
00:41:21.400 --> 00:41:22.700
And then you go into optimize.
00:41:22.700 --> 00:41:24.610
And then it's a cycle
that goes through.
00:41:24.610 --> 00:41:27.220
And ideally with continuous
deployment integration,
00:41:27.220 --> 00:41:30.030
all of that makes things
a lot a lot easier.
00:41:30.030 --> 00:41:31.570
Cool thing is with
Azure functions,
00:41:31.570 --> 00:41:35.090
we have integrated app Insights
directly into the platform.
00:41:35.090 --> 00:41:36.960
So App Insights,
Application Insights.
00:41:36.960 --> 00:41:37.730
I don't know if you guys.
00:41:37.730 --> 00:41:40.330
How many of you guys
are using App Insights?
00:41:40.330 --> 00:41:42.470
All right, so
most of you are familiar and
00:41:42.470 --> 00:41:43.300
know what we can do.
00:41:43.300 --> 00:41:44.390
So great news,
00:41:44.390 --> 00:41:46.210
when you're create a new
function today on the portal,
00:41:46.210 --> 00:41:48.450
you can check a checkbox.
00:41:48.450 --> 00:41:50.760
And say that one application
insight enabled and
00:41:50.760 --> 00:41:51.800
deployed with it.
00:41:51.800 --> 00:41:54.650
And you have up insights deploy
with your Azure function
00:41:54.650 --> 00:41:55.650
which is awesome.
00:41:55.650 --> 00:41:58.612
If you reach telemetry and
data all of that.
00:41:58.612 --> 00:42:02.704
There is specific set up within
the functions of JSON for
00:42:02.704 --> 00:42:07.057
on Azure function to be able to
control some of the telemetry
00:42:07.057 --> 00:42:08.201
information.
00:42:08.201 --> 00:42:09.133
And error level and
00:42:09.133 --> 00:42:12.010
all debugging information
you want to reduce.
00:42:12.010 --> 00:42:16.910
Or telemetry want to
externalize to App Insights.
00:42:16.910 --> 00:42:18.280
And the App Insights portal and
00:42:18.280 --> 00:42:20.790
all the tooling will give
you great, great indication.
00:42:20.790 --> 00:42:24.210
So we'll brave
another portal demo.
00:42:24.210 --> 00:42:27.760
>> A demo app
00:42:27.760 --> 00:42:31.540
is integrated with Application
Insights for monitoring.
00:42:31.540 --> 00:42:35.153
We are creating custom events
when we process coupons and
00:42:35.153 --> 00:42:37.580
when we process orders.
00:42:37.580 --> 00:42:42.550
And here with app insights,
you have a great overview for
00:42:42.550 --> 00:42:47.900
platform metrics and
the custom events.
00:42:47.900 --> 00:42:51.373
We define this part of
developing that application.
00:42:51.373 --> 00:42:56.196
In this case, the customer
bands are processing orders and
00:42:56.196 --> 00:42:58.037
processing coupons.
00:42:58.037 --> 00:43:00.873
And I will zoom in to make
that a little easier to see.
00:43:00.873 --> 00:43:05.820
Not only that, but we
00:43:05.820 --> 00:43:10.650
have the ability to run queries
against the data that we create.
00:43:10.650 --> 00:43:15.740
So here you have a better
representation of the trends
00:43:15.740 --> 00:43:22.460
as far as coupons and
orders being processed.
00:43:22.460 --> 00:43:24.180
And not only that but
00:43:24.180 --> 00:43:27.870
in this case we have some
random failures that have
00:43:27.870 --> 00:43:30.840
been introduced
throughout the execution.
00:43:30.840 --> 00:43:34.538
And you can see here that
you have this opportunity to
00:43:34.538 --> 00:43:36.891
look even deeper
into the data and
00:43:36.891 --> 00:43:40.300
have integrated
diagnostics as well.
00:43:40.300 --> 00:43:42.733
Which is a very useful
feature to have.
00:43:48.182 --> 00:43:51.880
So this is a great view to
explore by integrating what
00:43:51.880 --> 00:43:53.226
happens inside and
00:43:53.226 --> 00:43:57.610
looking at a rich view of the
data metrics that are retrieved.
00:43:59.280 --> 00:44:01.923
>> Okay, and with that we
are going to go in and.
00:44:04.464 --> 00:44:08.023
Reports to Andrew, which I'm
gonna show you how basically,
00:44:08.023 --> 00:44:11.190
how you can run Azure
functions runtime, onpremise.
00:44:11.190 --> 00:44:14.256
And I assume that
might work better.
00:44:14.256 --> 00:44:19.110
[LAUGH]
>> I've just got up on stage and
00:44:19.110 --> 00:44:21.720
saw a battery warning,
and so let's hope so.
00:44:21.720 --> 00:44:24.580
Good afternoon,
00:44:24.580 --> 00:44:28.770
yesterday we announced the
Azure Functions Runtime Preview.
00:44:28.770 --> 00:44:31.457
And this is a way that
you can get the power of
00:44:31.457 --> 00:44:35.415
Azure Functions, but with inside
your on premises network and
00:44:35.415 --> 00:44:37.145
your own infrastructure.
00:44:39.852 --> 00:44:42.988
So from a developer experience,
we support the same consistent
00:44:42.988 --> 00:44:46.241
programming model which you're
used to when you're working with
00:44:46.241 --> 00:44:48.910
Azure Functions in Azure or
Azure Stack.
00:44:48.910 --> 00:44:52.400
The same functions portal that
you've come to know and love.
00:44:52.400 --> 00:44:55.790
And we have obviously because
of our great experience of
00:44:55.790 --> 00:44:56.600
Visual Studio and
00:44:56.600 --> 00:44:59.740
the experience that you have
today from a developmental.
00:44:59.740 --> 00:45:03.310
And we have the publishing
capability from there.
00:45:03.310 --> 00:45:07.760
We bought a new trigger for
Azure Functions runtime and
00:45:07.760 --> 00:45:10.680
that SQL Service broker trigger.
00:45:10.680 --> 00:45:13.997
You won't see HTTP triggers or
generic web hooks,
00:45:13.997 --> 00:45:16.940
because there's no
HTTP endpoint exposed.
00:45:18.070 --> 00:45:22.790
The Azure functions workers
run inside containers.
00:45:22.790 --> 00:45:25.680
And for that reason,
you will need to run on
00:45:25.680 --> 00:45:30.670
Windows 10 Creator Edition or
Windows Server 2016.
00:45:30.670 --> 00:45:33.440
But the benefit of this
model that we think
00:45:33.440 --> 00:45:35.970
we're excited to see
what you do with it.
00:45:35.970 --> 00:45:39.870
Is many many organizations
have thousands of PCs sitting,
00:45:39.870 --> 00:45:42.410
running overnight doing
absolutely nothing apart from
00:45:42.410 --> 00:45:44.100
consuming power.
00:45:44.100 --> 00:45:46.250
So why not turn those into
functions workers and
00:45:46.250 --> 00:45:49.070
have them doing some
high powered compute.
00:45:49.070 --> 00:45:51.690
And taking advantage
of your spare compute.
00:45:52.940 --> 00:45:57.210
The Management Role, hosts our
portal and publishing endpoint
00:45:57.210 --> 00:46:00.040
and then the Worker Roles
do all of the work for you.
00:46:00.040 --> 00:46:02.165
But that's enough talking
let's have a look at a demo.
00:46:14.186 --> 00:46:17.420
So here we have the Azure
functions runtime portal.
00:46:17.420 --> 00:46:20.860
The same portal that you are
used to seeing within Azure, but
00:46:20.860 --> 00:46:22.910
we've shipped it on
our management role.
00:46:23.930 --> 00:46:29.510
And we have language support in
the preview for C# and Node.js.
00:46:29.510 --> 00:46:34.286
And you'll see here that I have
a output key trigger that is
00:46:34.286 --> 00:46:37.128
looking at an Azure
storage cube.
00:46:37.128 --> 00:46:41.220
So what I've tried to do is
take the demo that Daria was
00:46:41.220 --> 00:46:42.660
working through.
00:46:42.660 --> 00:46:45.190
And I have the same
pizza application.
00:46:45.190 --> 00:46:48.000
And in this instance we're not
persisting the data to a data
00:46:48.000 --> 00:46:49.395
base within inside the cloud.
00:46:49.395 --> 00:46:51.260
We're just putting on
a queue for processing.
00:46:52.450 --> 00:46:57.531
So I'm gonna go off and
get me a coupon.
00:46:57.531 --> 00:46:59.092
Wait for that to go and call.
00:46:59.092 --> 00:47:00.942
This is a combination
of a hybrid.
00:47:00.942 --> 00:47:04.671
So we're talking to some Azure
functions and then we're talking
00:47:04.671 --> 00:47:07.800
we gonna close the demo with
Azure Functions Runtime.
00:47:09.120 --> 00:47:10.935
Is that gonna come
back anytime soon?
00:47:13.131 --> 00:47:14.863
No, okay let's just
create the order and
00:47:14.863 --> 00:47:15.910
hope that goes through.
00:47:19.915 --> 00:47:22.537
Please, no.
00:47:27.122 --> 00:47:31.010
Okay, let's try once more and
if this doesn't.
00:47:31.010 --> 00:47:32.080
There we go.
00:47:32.080 --> 00:47:34.530
Morning special get
Azure functions runtime.
00:47:34.530 --> 00:47:35.530
Let's place the order.
00:47:35.530 --> 00:47:37.550
We now have an order
placed on my queue.
00:47:37.550 --> 00:47:40.400
And we now have
a line of business
00:47:40.400 --> 00:47:43.520
application that simulates
what would happen say
00:47:43.520 --> 00:47:45.870
in the pizza shop where we need
to actually fulfil this order.
00:47:47.630 --> 00:47:50.330
So in the background our
function is pulling and
00:47:50.330 --> 00:47:54.090
making sure that we can
reach that storage queue.
00:47:55.140 --> 00:47:57.100
You see the logs coming
out at the bottom.
00:47:59.810 --> 00:48:06.743
See pick up the message.
00:48:11.012 --> 00:48:14.040
See the old faithful and
just check the messages there.
00:48:14.040 --> 00:48:16.494
So there's the message just
waiting for it to be picked up.
00:48:21.602 --> 00:48:24.279
Looks like the demo gods
are not shining on me either.
00:48:26.470 --> 00:48:28.490
Let's do refresh,
see if we pick up the order.
00:48:28.490 --> 00:48:30.460
Well here's an order
from earlier.
00:48:30.460 --> 00:48:32.920
So in true blue beta fashion,
here's one I made earlier.
00:48:33.950 --> 00:48:37.960
And there that order was
pulled in to my SQL database
00:48:37.960 --> 00:48:39.070
on premise.
00:48:39.070 --> 00:48:40.810
And I read it through my
line of business app.
00:48:40.810 --> 00:48:44.332
And now I can change the status
with inside my organization.
00:48:44.332 --> 00:48:48.886
So this kind of example shows
how you can produce a hybrid app
00:48:48.886 --> 00:48:51.902
to take advantage
of Azure functions.
00:48:51.902 --> 00:48:54.626
And working with multiple
services where you don't want
00:48:54.626 --> 00:48:55.312
data arrest.
00:48:55.312 --> 00:48:58.182
Whether you can use Azure
functions on premise to
00:48:58.182 --> 00:49:01.585
do some processing which
you need to take care of.
00:49:01.585 --> 00:49:04.285
So this way you can integrate
Azure functions with
00:49:04.285 --> 00:49:07.695
ERP systems etc., which you
can't expose externally.
00:49:07.695 --> 00:49:10.525
And you can use
the power on prem.
00:49:10.525 --> 00:49:13.205
We are really excited to see
what you do with it, and
00:49:13.205 --> 00:49:16.185
we've already started to
see some suggestions and
00:49:16.185 --> 00:49:19.172
some issues flowing on
the blog post on GitHub.
00:49:19.172 --> 00:49:22.530
So we're really excited
to see what you do.
00:49:22.530 --> 00:49:24.870
>> Andrew, one question, can you
switch to the portal real quick?
00:49:24.870 --> 00:49:25.710
>> Yep.
00:49:25.710 --> 00:49:26.940
>> Can you explain where
this is running from?
00:49:28.400 --> 00:49:32.540
>> Yeah, so this portal is
all running on-prem and
00:49:32.540 --> 00:49:37.058
this VM that I remoted on to
is a machine that we have
00:49:37.058 --> 00:49:41.170
running in.
00:49:41.170 --> 00:49:43.406
So if I open up IIS,
00:49:47.102 --> 00:49:55.002
>> The log just got updated.
00:49:59.131 --> 00:50:01.640
>> But I think the powerful
thing is to show the container.
00:50:03.700 --> 00:50:06.097
So there we see it's running.
00:50:06.097 --> 00:50:12.722
But if I scroll up we'll see
there in the docking server.
00:50:12.722 --> 00:50:15.048
I haven't got Signet
on this machine.
00:50:15.048 --> 00:50:18.037
But we can see in the trace that
we're starting up a container
00:50:18.037 --> 00:50:19.034
for the function and
00:50:19.034 --> 00:50:21.390
on this instance we have
2 workers available.
00:50:21.390 --> 00:50:23.890
And we'll spin at multiple
containers to run the functions
00:50:23.890 --> 00:50:24.498
workload in.
00:50:24.498 --> 00:50:26.910
Everything's running on-prem.
00:50:26.910 --> 00:50:29.370
Everything's local to
your organization.
00:50:29.370 --> 00:50:33.352
Nothing is reaching external
unless you ask it to.
00:50:33.352 --> 00:50:39.928
And now back to to wrap up.
00:50:39.928 --> 00:50:41.135
>> All right, so
terrible apologies
00:50:41.135 --> 00:50:43.200
about the networking and
the demos issues.
00:50:43.200 --> 00:50:46.120
But I hope you got at least
a somewhat of a sense
00:50:46.120 --> 00:50:50.710
of what Azure, what serverless
on Azure can offer you.
00:50:50.710 --> 00:50:54.190
There is a pretty rich set of
services that you can work with.
00:50:55.240 --> 00:51:00.340
Use binding, use local developer
tooling for the ability
00:51:00.340 --> 00:51:04.490
to optimize your time to market
and to just enjoy development.
00:51:04.490 --> 00:51:05.880
Logic apps are great.
00:51:05.880 --> 00:51:06.820
You can try logic app and
00:51:06.820 --> 00:51:09.680
Azure Functions on
aka.ms/tryfunctions.
00:51:09.680 --> 00:51:11.870
You can join the community.
00:51:11.870 --> 00:51:13.370
There is a session tomorrow.
00:51:13.370 --> 00:51:15.250
Chris and Donna will show
the developer experience.
00:51:15.250 --> 00:51:17.380
I truly hope they have
better luck than we are.
00:51:17.380 --> 00:51:19.799
And please come and
see us at the booth upstairs or
00:51:19.799 --> 00:51:21.530
not upstairs, downstairs.
00:51:21.530 --> 00:51:23.370
See us at the booth for
Azure functions.
00:51:23.370 --> 00:51:25.497
And again we'll show you some
cool demos there as well.
00:51:25.497 --> 00:51:26.295
Thank you very much.
00:51:26.295 --> 00:51:29.600
>> [APPLAUSE]