>> Azure Integration Services
provides an enterprise ready, event-based,
serverless compute experience that drives efficiency and
consistency when connecting applications
across the Cloud and on-premises.
Matt Farmer's here to show us how we're bringing
together API Management, Event Grid,
Logic Apps and Service Bus in a more consistent way,
today on Azure Friday.
Today, on Azure Friday,
we're talking about Azure Integration Services.
With me, I've got Matt Farmer who is
the Program Manager for Integration Services.
Matt, what are you going to show us today that's going
to make life a lot easier for the developer?
>> So, I'm going to talk about
what we're planning to do and what
we're doing with Azure Integration Services.
I want to start by talking about the term iPads
because it's how we talk
about this, what we're planning to do.
A lot of people within
the enterprise application space
are talking about this term iPads,
which is Integration Platform as a Service.
We have customers coming to us asking us,
"Well, what have you got for iPads?"
How are you putting this together?"
So, Azure Integration Services
is based on some key components that we see
customers needing to deploy when
they want a solid platform for enterprise integration.
So, this is less, I just want to build one application,
this is more, I have many applications
that I want to build that connect me to my partners,
to things like apps and to within the business itself,
how do I put those things together
into a solid reusable platform that
gives me benefits from not having
to design an application every time.
>> Okay. So, today,
we've got a number of components
that are available on Azure?
>> Correct. Absolutely. So, we see
some key components as being part of this.
So, we have APIs, Workflows,
Workflows and Orchestration really,
Enterprise Messaging and Event.
So, being able to build
applications with event-driven architecture.
So, we have services that embody each of those.
So, API management for publishing securing APIs,
Logic Apps allows you to
create Workflows and Orchestration.
Azure Service Bus as
an enterprise messaging queue
for messages and Azure Event Grid,
which is our new platform
for building event-driven applications.
So, those four things come
together as our Integration Services.
So, we see them as being,
by deploying those four pieces,
customers can build reliable,
reusable platform on Azure that allows them to build
all the integrations they want to build as
part of their enterprise architecture.
>> Okay.
>> There are some key things that are part of that.
So, for example, being API driven.
So, a lot of customers are
talking about the API economy and
how they can enable parts of their business,
parts of their applications into
APIs that allow them to connect to people.
The Azure Integration Services
embodies that allows people
to use APIs all the way through their Integration.
Serverless. So, Logic Apps for example,
is a serverless platforms so they don't have to
completely deploy a huge infrastructure to get started,
they can do it based on whatever the amount
of stuff they're using.
>> Okay. So, we've had all of
these four services up to now?
>> Yes.
>> How does Azure Integration Services make them better?
>> Well, I think the first thing to say is
that a lot of customers don't
want to take on a lot of risk.
So, we have these four things in Azure,
so yes somebody could go and deploy them today
but the question they often ask us is,
"Well, how many other customers have done this?
Have you put your name to any ways of doing
this Microsoft so that I
don't have to take all the risk when I do this myself?"
So, the first part of doing this is
making sure that we provide guidance,
that we provide the commitment
that we're going to think about these services together,
going to give you guidance on how to deploy and run them,
so that you don't have to take on that risk yourself.
>> That's good.
>> The second thing is thinking about ways we
can make the services work together more seamlessly.
So, making sure that we
file off any rough edges and integrating them together,
and also make sure that we're
thinking through those ways in which
customers are using them together to
make sure those scenarios work.
>> Okay.
>> Again, it provides a reassurance.
If I'm either a Developer
thinking about how I build my application,
or CEO of a company I can go to Microsoft and say, "Well,
what have you got on is it tried and trusted
and is the thing I want to build going to work.".
>> Right. So, what are you going to show us?
Can you walk us through
some an example of
how you quickly use Intergration Services.
>> Exactly, yeah. So far I flipped it.
I've got a slide here.
I'm just going to jump ahead.
So, just to make absolutely clear before we do that,
just making it clear that you don't
have to use the things on their own.
Could people quite often say,
"Well, I've got those four things.
What if I want to use
functions to write some custom code?"
Well of course, all the other Azure Services
come with this and absolutely you will connect
to Azure Integration Services through
Logic Apps or Service Bus or API management.
We've also got this whole connect a library,
that we have in Logic Apps
that connect to all sorts of services that aren't
even in Azure that Sand Services or Enterprise Systems.
But, let's move on to
a quick demo that walks us through how it works.
>> Okay.
>> So, I'm just going to use this slide to explain
this just to give you an example.
If you imagine a system that processes orders,
that a customer may have to deploy.
So, generally if you're big enterprises
all sorts of systems you'll
connect to to process an order.
There's probably three or four of them.
Now, you can imagine a Logic App
being the thing that does that.
But it probably is something maybe takes a little while.
Isn't something that you want to delay
any customer process is based upon,
and one you want to run all day and
all night based on when those systems run efficiently.
So, we could trigger that Logic App with Event Grid.
Event Grid can tell the Logic App when to run,
when there's stuff to do and not have
that Logic App running when there's no stuff to do.
So, it saves you money. If we
imagine Service Bus being
the place where we store all these messages.
So, we can play some messages on this queue,
have it doing things like deduplication,
have reliable disaster recovery in that message queue,
so that you know that the place where
all the things that have come in is in that queue.
Another Logic App that then places the message on there.
So, we've got two Logic Apps.
Why we separating them up?
Well, because we have one business action
that is make this order happen,
and we have another business action that is take
this order in and create an order ID for it.
So, that's what that Logic App would do.
Then fronting all that, I've talked about
this being API driven.
The first Logic App that we have there
is a request response HTTP API.
So, we confront that in API management and
provide it out to
either our apps or
to partners to be able to create an order.
>> Okay.
>> So, that was a lot of words. Let's have
a look what actually is.
I will move across to my domain.
So, Fabrikam we're all familiar with them,
that the great things that they do.
We've got those components here in Azure.
So, we have our connectors.
So, Logic Apps has this concept of connectors being able
to connect it to things that you didn't have
to write that code yourself,
and then we have our Logic App.
So, the first one was Received_Orders.
So, let's just have a quick look at that.
So, Receive_Orders takes in an order object,
let's go up to the top, from Event Grid.
Serving Grids says, "I've got an older to process".
We go into Service Bus and we get those messages,
and then we loop around them because it's
a collection that comes back and do
all the things we need to do to actually make
that order received and processed and shipped.
Am doing silly things like posting to teams
and sending an email here you can imagine
connecting to SAP or Dynamics
or any other systems you have customers.
>> It could be in Azure, could be elsewhere, [inaudible].
>> Exactly. It could be any Data Center.
Could be in your Data Center or
in another Cloud if you really want.
But that Logic App is concerned with that process.
So, from documenting what
your business does point of view,
that Logic App is documenting
that Received Order Process.
We have Service Bus topic,
actually set up rob in the queue.
Because actually you may have parts of
the system that need to go and get messages from
the queue and they also want to know about those orders.
So, the topic allows us to do that.
The other Logic App we have
is the Purchase Orders Logic App,
which is popping messages onto the Service Bus queue.
So, effectively this Logic App is
just concerned with someone wants an order,
put it into the system and forget.
>> Right.
>> So, then you return to the customer as
quickly as possible in Order ID and say,
"We've got your order, we'll worry about it."
So, this one is doing,
it's actually an HTTP request response.
So, this is an API operation.
It's creating a record in dynamics.
We do some JSON handling to compose it into
our order object and then we
send the message to Service Bus
respond saying, "We got you".
Then finally, API management,
if we go in here we can see that this,
I actually created this API
by importing it with the "Logic App" button here.
So again, just emphasizing that we make it as easy
as possible to build out the solutions
without having to write a lot of code,
you can add code if you want to be you don't have to.
Then, we have our v1 Orders here,
which is the ProcessOrder API configured ready to go.
Now, the people at the back,
the people consuming this API I
have no ideally using
Logic Apps and Service Bus and whatever else,
is just an API that you've provisioned
out to your users, your apps whatever.
We can see it in the Developer portal.
So, if your developers
or partners wanted to come
in and develop an API based upon it,
they could see things like
the sample that they need to pass into the API.
They can see the responses,
they're going to get back and they can even test it.
>> Great. Great. So, with
Integration Services you've made a commitment that all of
these services are going to work together and an
easy flawless way and
as you've said smooth out the rough edges.
>> Absolutely.
>> What's to come with Integration Services?
>> So, the first thing we want to do is make sure we got
as much guidance and
documentation out there for people to use.
We're looking at other features that we can add,
so that removing rough edges,
so that we can for example,
make it really easy to
deploy from one service to another with
the click of a button or through automation templates.
>> Right. For a lot of those common scenarios.
>> Exactly, and provide guidance for those.
So, if we can provide templates to say, "Build me" well,
I just showed here",
with one arm template and
then configure from there you can do that.
So, that's what's on the short-term roadmap.
Then later, we've got some ideas for features,
we haven't quite tied down yet but there's a bunch
of features we'd like to add to this that will
be looking to produce as well.
>> That's great. Well, thank you so much
for showing up today and walking-.
>> My pleasure.
>> -through Azure Integration Services.
I think it's going to be a great help to simplify
the life when we're
building out these common applications.
>> Right, thank you.
>> So, today we've been learning all about
Azure Integration Services on Azure Friday.