>> Hey, welcome to another episode of On .NET Show.
Today, we've got Bahram and he's going to be
telling us about Azure Event Grid.
So quickly, tell us a little bit about yourself.
>> Yes. So I'm the PM for Azure Event Grid.
I've been with Microsoft for about a year and a half now.
>> Okay and how's everything working out?
>> It's been pretty awesome, so far.
>> Okay, awesome. Well, you ended up on the show.
So you know, this is pretty good.
>> I made it to the promised land.
>> Yes, totally. So, how
about you tell us about Event Grid
and what kind of cloud domain does that fit into?
>> Yes. So, Event Grid is
a messaging product and it's meant to be,
basically, a connective tissue for all of Azure.
So, what we're doing is building
first class integrations with
pretty much every Azure service.
And when there is a state change,
those services will emit an event,
and these can be pointed to pretty much any endpoint
or built-in event handlers within Azure.
>> Okay. So pretty much all the Azure teams I
talked to told me that
they're the connective tissue of Azure.
So, why are you really the connective tissue of Azure?
>> Yes. So, the goal is here.
We're building a pub/sub system
but within the ecosystem of Azure.
We don't want customers to have to go build one
off connections or you know
even write a lot of code to get up and running.
So, it's really a browse and select sort of operation.
You say, I want to listen to
my storage account anytime a blob is created,
send an event to this event, to
this Azure function to handle it.
It's supposed to be very quick and
easy to get set up, subsecond and to end latency.
>> Right. So, what I hear you saying is, you know,
if I'm a function or I have deployed
a docker container or app service,
it doesn't really matter.
I can either participate
in sending events or receiving them.
>> Exactly.
>> Yes. And, does this
relate to just if my code is running in Azure?
Or are there some not in Azure or
scenarios like desktop that are relevant or even IoT?
>> Absolutely.
So we do have first class integrations with
Azure but we're also a general purpose pub/sub system.
So, you can omit events from your desktop application,
you can receive them at pretty
much any public HTTP endpoint.
So you are not restricted to
native Azure event types or Azure as a system at all.
You can connect any services
or anything that can run code, really.
>> Right. So if I had the consoled app that
cared about blobs in a particular blob storage account,
could I get events every time one of those was updated
and then just write those to the console?
>> Yes. Absolutely.
>> Wow.
>>You would. Yes.
>> And you're saying
subsecond latency, so pretty much, as those blobs
were being updated, be up like almost instantaneous.
>> Yes. It enables
real-time reactive programming with your Azure resources.
>> Wow. Now, clearly with
Event Grid, I imagine people are using it within Azure,
with functions or whatever.
Have you seen people using it in
this other way that we kind of talked about,
either with desktop applications,
IoT applications or
even web applications that are running on-prem?
>> Yes, totally. We have a number of customers that
have various files that they're generating,
they're dumping them into a store and then they
want to go process them on-prem so,
they're firing events, picking them up
and going and taking these files
and processing them elsewhere.
>> I see. So,
clearly there's customers that are all on-prem
and there's another set of
customers that are all on the cloud.
And so I guess, these scenario we're talking
about is really interesting for these customers
that kind of have the sliding window for how
much of their work is being done on-prem
and how much is being done in Azure.
>> Yes.
>> Yes, interesting.
So, back to Event Grids.
Would you say maybe the three most popular
ways that people are using Event Grid today that you see?
>> Yes. So, the first one is certainly serverless.
So this is,
I have changes happening,
the state changes happening to
my various services in Azure
and I want to react to them in a way that requires
writing code but I don't want to
host my own infrastructure.
I just spent up in Azure Function
and point my Event Grid
subscriptions to those Functions or those logic apps
and I can get up and running incredibly quickly.
The second big scenario we see is OPS automation.
>> Right.
>> So, we've integrated with Azure resource manager
so that anytime a control plan event
happens within Azure,
Azure resource manager emits events as well.
So, we can basically
subscribe to events on a resource group
on Azure subscription when a VM
is created or sequel database is deleted,
and we can point those events to
any endpoint where we're running a script or a function,
and do things like check for proper protocols,
tag the VM, whatever needs to be done there.
And then finally, the third big scenario we
see is general purpose pub/sub.
So, we fully support--
As we've talked about it a little bit,
you can have an on-prem system that is using
Event Grid to publish its own events
and consume them on-prem
or those hybrid scenarios we talked about as well.
>> Right. So, if you're
more familiar with one of the other clouds,
what would be the analogous service
that is in that cloud
and does it have the same feature set as Event Grid?
>> Yes.
So, if you're more familiar with Google,
the analogous service there would be Google's Pub/Sub.
Google Pub/Sub is just a general purpose pub/sub engine.
It doesn't have filtering on
the wire like Event Grid and it
certainly doesn't have
those first party integrations that Event Grid does.
If you're more familiar with AWS,
their service over there would
be SNS, Simple Notification Service.
They have recently introduced filtering on the wire.
And this is actually a pretty cool feature
that both Event Grid and SNS have
is basically, you're
publishing events and you're sending them
to multiple different event handlers
that are subscribed to these events.
If a certain endpoint doesn't want to consume
all the events before on the wire filtering,
it would have to filter at its own end point,
you're wasting cycles and compute.
Now, we filter on
the wire so you
only listen to specific event types, if you want.
>> Great. And I presume that there might be
a latency in there as well?
>> Not, not really. It's in a milliseconds,
not something that customers will notice.
>> Okay. It's more of the comp cost.
>> Yes.
>> CPU costs. Okay.
>> Yes.
Well, there would be latency if you were
filtering on your endpoint and you
had really high throughput,
we scale out incredibly well
horizontally so we don't see latency issues.
>> Sorry, I mean on the other side.
>> Sorry, yes. There, if
you, in high throughput scenarios
you do start to see latency.
>> Yes.
>> You get clogged up.
>> Yes. Definitely.
>> Yes. And the other part of Event Grid is
those first class integrations that we
have that doesn't exist in SNS.
If you wanted to do something like that,
you would have to first use a Lambda trigger and
then pipe it to an SNS endpoint and then go from there.
Event Grid instead, we are trying to be
kind of a uniform ubiquitous eventing substrate.
>> Connective tissue.
>> Connective tissue.
>> Definitely.
>> Have I convinced you?
>> Yes, I am definitely convinced.
So, I want to go back to
this VM scenario that you mentioned,
like I said, I think the Functions
one is pretty straight forward.
So I haven't done this
particular scenario so I'm going to
kind of make something up and
you can tell me if this is true.
I kind of imagine that there's these applications that
people have built that do need to create VMs
who haven't found the one true way yet
with Event Grid.
And they get to
this point where they have to create a VM,
they actually have to have another VM
running that actually kind of manages this.
It creates the VM through arm
and then kind of like
connects that VM and has a script that runs,
that makes sure that VM is created correctly.
It feels very procedural
and very kind of like,
both has to create the VM and
then configure it and potentially
has to have this other VM running all the time.
With the thing you mentioned,
it seems like it's much more reactive that
maybe there's VMs created of one type that may be
configured one way and then VMs
of another type that need to be created in another way.
And then you just have these
listeners that do the right thing
in the right situations. Is it kind of like that?
>> Yes, pretty much.
Even before Event Grid, we did have
Azure Automation in Azure.
So you could run your scripts there
but you still have the problem of your
need to know that a VM has been created.
You have to actually send something to
that script and trigger it.
So with Event Grid,
now, you don't have to have prior knowledge,
you don't have to make sure
you're hitting the right script.
It will just listen to all control plane events coming
in to whatever resource group
or Azure subscription you pointed at.
And anytime a VM is created, you don't
really have to do anything, it'll just
trigger that automation script,
it'll run the script and tag the VM,
send the message to a slack channel,
whatever you really need.
>> Yes. Teams.
>> Teams.
>> Can you tell me,
some of this feels a little similar to
Queues which is
obviously thiis existing feature in Azure.
Can you compare and contrast?
>> Totally, yes. At a high-level,
the big difference is that a Queue is
push-pull semantics and
Event Grid is push-push semantics.
The other big difference is that Queues,
we put them out there as
a general tool and you write
your own code to push things to it,
you write your own code to pull from it,
while you can't do that with Event Grid.
You can get up and running and use
our first class integrations without needing to do that.
In fact, one thing we're actually working on is
a Queue integration for Event Grid so you could
push your native events to a Queue.
So, if you have a scenario where you're not up
all the time to receive these events,
you could wake up, look at your Queue, say, Oh,
Event Grid has pushed some events to my Queue,
I'll pull them now and consume them.
>> It's a little bit like when you land in
the plane and turn your phone on and then all
of a sudden like all these text messages, so yes.
>> Totally, yes. It also
works for buffering scenarios if you can only
handle certain throughputs for
spiky workloads and anything else.
>> Makes sense.
>> Yes.
>> So, I'm guessing that there's
a Visual Studio story for this.
>> Yes, absolutely.
>> And maybe even for.NET.
So, how about we take a look?
I think you've got a sample here.
>> Yes.
>> Just before we dig deep into it,
can you show me is there a NuGet package
that people can look for?
>> So our NuGet package is available on nuget.org.
We have both a run-time and a management NuGet packages.
>> Right. So this one is called Microsoft.Azure.
EventGrid. And, can you click that
"Dependencies" now so we can see?
Okay, so it looks like it's supported
to all the way back to .NETFramework
4.5.2 and there's also a.NETStandard Library.
So, that will work on
also.NETFramework but.NETCore and Xamarin.
So, that seems to be covering a lot of bases.
>> Nice.
>> Okay. Let's look at Visual Studio.
>> Yes. So, what we have here is a pretty simple sample,
it's just using our published SDK.
It's connecting to an Event Grid topic and a topic is
just your entry point to Event Grid if you are
publishing your own custom events to Event Grid.
And we're just publishing
a very simple new employee event
that I have here created.
We can go over to the Azure Portal and
create event subscriptions on
this topic we're publishing to,
point them at a function.
I can tell you how quickly this happens in real time.
>> Yes, please do.
>> And we can actually go consume those events.
So, this is the function that we're interested
in sending our events to and handling them from.
So we just need to endpoint URL for this,
I'll copy that and I have in
this tab are Event Grid topics.
So this is just a DNS endpoint that we have the keys to,
to send to our events.
I create a new event subscription.
I can say it's "netevents".
I give it the endpoint that I want to
aim it at and I hit "Create".
And as soon as that is done deploying,
we will see a new event,
a validation event of pop up here.
So, the validation event is our kind of security measure.
What the validation event does
is it's-- So Event Grid, in a way,
because we have a massive fan out
capabilities and very high throughput,
is kind of the world's largest [inaudible].
So, the first thing that our code is going to do here is
actually handle validation event
that we send every new endpoint that we register.
So, we're just going to look for
that validation event and when we receive,
it we're just going to echo back the validation code.
And that just means that I own this endpoint.
>> Is it a kind of 2FA for Event Grid?
>> Yes, in a way.
>> Okay.
>> Definitely. So.
>> It seems like we have to use 2FA for
basically everything these days.
>> Yes. So, our script
here is set up to actually
handle a number of different event types.
I'm just using a-- If check
to see if we're having a validation event,
a blob created event or this new employee event.
So is just a really simple function
that could handle a bunch of different
event types being thrown at it.
So, if I open my log and then
I go back to my Visual Studio projects,
I can just hit this endpoint with an event that
we're spinning out and we'll see it
appear pretty much instantaneously on the other end.
>> Okay, so this is the side
that's sending the event. Is that correct?
>> Yes. We're sending the event from visual studio.
>> Is it because
you might have the console locked by that block?
Yes, I've just started it down.
Sometimes when you select--
>> Yes, there we go.
>> That's totally what happened.
>> So, we should see an event.
We have our own subscription here.
>> Everything is configured correctly?
>> Yes, just checking out
if everything's configured correctly.
These are the events that I had published earlier.
Interestingly enough,
there is some reason we're not getting an event through.
>> Hopefully we're connected to the internet here.
>> Yes. I mean,
just create a second event subscription.
>> Right. So, we're demonstrating
the diagnostic kind of
patterns that you would use for this.
>> Yes. So, we have our endpoint here.
Let me just make sure,
yes, I'll just overwrite
that old endpoint to
make sure that we have the right one.
Save the changes.
It has succeeded so we
should be getting a validation event
right now and we're not. Just interesting.
>> Yes, let's run the client side code.
>> Yes. Let's see if I got it running.
Okay, there we go. So, we just got that event through.
>> So maybe, you just somehow,
you ran the client side wrong the first time?
>> Yes. Either I had run the client side wrong the first
time or I just didn't properly connect it.
So, we should now see,
I think I might just not copy the full URL or something.
If we click on "Metrics" here,
we would see the way we diagnose this is,
this has a little bit of latency,
we're working on improving that but soon,
if we wait a minute or two,
we would see our successful and failed delivery count.
It will show up on this graph.
But all we did was we matched
our event type as
our new employee event and we wrote to the line,
to the console, their name,
who they're reporting to and their email here.
Obviously, we could do
much more interesting actions on receiving an event.
>> Totally, but this kind
of demonstrates the fundamental.
>> The fundamentals, yes.
>> Yes. Awesome. Right. So, this
is obviously live in Azure.
People can go and use this today.
>> Yes.
>> So, they obviously
would download the NuGet package
but from an Azure standpoint,
do they create a new Event Grid subscription?
Is that kind of what happens?
>> Yes. So, there's a couple of ways to use it.
So if you want to send your own custom events,
first you would create a new topic
and this pretty much just gives
you your entry point into a Event Grid.
You just give it a name, a research group
you want it to live in and
what location you want it to be in.
And now, you can send all of your events from
different sources or a whole bunch
from a single application to this endpoint.
And then, once you have that topic,
you can go create event subscriptions on it.
The other option is in,
if you go to a storage account,
for example, you'll actually
see Event Grid as an option in your "Resource" menu here.
>> So that would be that blob
scenario you talked about earlier.
>> Yes. Exactly. And here
you just create new events subscriptions.
You again point them to whatever endpoint you
want and you click "Create".
And now, anytime someone creates
new blobs or deletes them in this storage account,
you get an event fired
to this endpoint every single time.
>> Awesome.
>> Yes.
>> Okay, I think we've learned
on quite a bit about Event Grid today.
I certainly think I've picked up enough knowledge
that I could use that amazingly enough.
Any closing thoughts or
resources that people can
look at that you'd like to share?
>> Yes. So, azure.com/eventgrid takes
you to our product page
where you can view our documentation,
learn more about it, and we're
very excited for where
we're going in the next year or so.
We're working quite closely with a number of
people's favorite product teams in
Azure to have more and more integrations.
So, it's only going to
become a more powerful tool as we go.
>> Right. Awesome. Okay, thanks for coming
by Bahram and telling us about Event Grid.
It has been another episode of
the On.NET Show. Thanks for watching.
For more infomation >> Timeless 2x04 Promo "The Salem Witch Hunt" (SUB ITA) - Duration: 0:16. 
For more infomation >> Laeticia, "premier soldat" de Johnny - Duration: 2:44. 
For more infomation >> The Royals 4x04 Promo "Black as His Purpose Did the Night Resemble" (SUB ITA) - Duration: 0:30. 
For more infomation >> Derniers jours de Johnny Hallyday : Et si David et Laura avaient tort d'en vouloir à Laeticia - Duration: 2:48. 
For more infomation >> حظك اليوم الثلاثاء 27-03-2018 فى التوقعات اليومية للابراج بقلم عالمة الفلك د. نيفين ابو شالة - Duration: 7:04. 
Không có nhận xét nào:
Đăng nhận xét