>> Hey folks, I'm Scott Hanselman and it's Azure Friday,
and I'm here with Azure Barry.
You can follow him at Twitter.com/AzureBarry.
And Barry is going to talk to me about
picking your Azure services.
There's a lot of services out
there and it's a little bit complicated.
And what I think is great
about you is you are an Azure MVP,
you don't actually work for Microsoft,
you're not trying to sell anything,
you just want to help me pick the
right service for the job.
>> Yeah. So, Azure is huge as you've said,
now like over 125 services or something,
and it's very difficult to choose the right ones,
at least I found with my customers.
>> True.
>> So, I have been through this a couple of times,
and I've made a couple of slides to
actually show how I choose those services.
Maybe it can help you and the audience as well.
So, I'm going to talk about how to choose
services for running your application in Azure,
and for storing your data in Azure.
There are obviously a lot more categories like securing
your application and all those things,
but we're just going to stick to this for this episode.
So, let's talk about running your application in Azure.
The first thing what I do to pick
a service is to ask a couple of big picture questions.
The first one is how much control do I need?
Do we need control over
the load balancers or do I not care?
Second one is where do I need my App to run?
Is that only in Azure public cloud
or also on-premises or maybe in other clouds?
And then the third one is what usage model do I need?
So, do I need to run
my application all the time like a website?
Or maybe only when it's needed like every hour or so?
And then when I've answered these big picture questions,
I've narrowed down the amount
of services that I can pick from,
and then from those services
I pick the services that actually
fits my requirements with
the functionality of those services.
So, let's go to these big picture questions.
The first one is how much control do I need?
And that question is all about control and
responsibility versus the ability
to work on business value.
So, work on things that actually matter.
So, if you look at the categories of cloud computing,
those are infrastructure as a service,
platform as a service, logic
as a service that's just my term,
but it's also called serverless,
and software as a service.
These vary from control and responsibility,
for instance infrastructure as a service.
You have control over the network and over
the antivirus in a VM for instance,
but you're also responsible for those things.
And also responsible to actually update the antivirus,
and that's the operating system.
Maybe I need that maybe I don't.
And the higher up the stick I get,
so for instance severless,
I don't have to worry about scaling anymore,
but I don't have control over it anymore.
It does allow me to work more on the business value,
to work on the app itself instead
of worrying about the network and the plumbing around it.
>> Definitely, one of the ways I like to
look at it is that I might
enjoy owning my own car or
even building my own car from scratch from a kit.
Right? Or I might just want to go from
point A to point B and rent a car or a lift,
and all of the different other ways
from public transportation,
each one giving me less control or possibly more focus.
I can work on business value
like write a book while I'm on the bus.
>> Exactly. Yes, that's a very good analogy,
and that's exactly what I'm trying to do here.
So the next big picture question
is where do I need to run my app?
So, obviously, we say it's Azure, the public cloud,
but it can mean Azure public
cloud but it can also mean in
Azure Stack or hybrids or
the premises a variant of Azure.
>> Or the government cloud in the US
or the German cloud, or the China cloud.
>> There're lots more types of Azure clouds out there.
Or instead of an Azure,
you can also have to run your app anywhere else,
like on-premises, like locally instance
for development or maybe in other clouds as well.
And then, the next big picture question is
what's the usage model do I need?
And this question is all about how will my app be used?
So if the answer is all the time,
like in a website or a web application, it's always on,
it has users all over the world 24/7,
then I need to look into services in the Classic model.
So those are services that are always on,
like a web app for instance,
and you pay for them all month.
If I don't use it all the time but occasionally,
lets say when a new message
comes in a queue or every hour,
then I need to look into services
into serverless or logic as a service category.
And those services only run when I need them to,
every hour or when and you message is in the queue.
And I only pay for the execution.
So, once I've answered all of
these questions, I ask myself, well,
the requirements of my app,
which Azure service fits those requirements.
So, which functionality fits those requirements?
All right. So, let's just try this out.
>> Okay.
>> I have an app, and I trust Azure to scale for me.
I don't want to do that myself. My app needs
to run in Azure and on-premises as well.
As my app only needs to run
once every hour, so not all the time.
So let's see. These are
all the options currently, they will change.
They're out there in Azure to run your application. So.
>> So, for example, I'm thinking,
well, I could just put it into VM,
it could be fine, but then I'm paying 24/7 all the time.
>> It doesn't have to be always on.
>> I have to remote it to desktop,
I have to acetates or Shosh into it and upgrade it.
I have to maintain the security.
And you said you wanted Azure to scale.
>> Exactly.
>> So, probably not a VM.
>> No. So, services in
that category into infrastructure as a service category,
those are not the services that I want in this case.
And those are all the services that the
fall in this box basically.
>> Okay.
>> Also services in the platform as a service category
those also need scaling instructions, let's say.
Azure doesn't do that automatically for me.
Yes I can obviously have automatic scaling in a web app,
but still I need to think about that
and I need to configure it myself.
>> Sure.
>> And I don't want that for this app.
>> And you could do Kubernetes and
have that scale, but it will be running all the time.
>> Exactly. So, I end up in
the last category and that is I call it
logic Azure service or serverless,
and that could be functions or logic apps for instance.
So that's one category that we've drilled down to.
So, that ends up in me
being able to work a lot on the business value,
and not so much having to
worry about the plumbing
and infrastructure of a VM for instance.
>> Right. And that's where the word serverless is
such a fun and funny word,
is that you're really trying to say, "I don't really
want to think about servers, I don't worry it.
I just want to get in
the car and I want to be delivered to my location".
>> Yes, exactly. So, the next thing is,
I want to Stay Vendor Agnostic.
That's what I said because it needs
to run in Azure but also on premises.
So, I don't want to opt in for Azure completely,
it needs to run anywhere.
In that case, I can choose from these services,
including Azure functions because
Azure functions run on the Azure functions run-time.
I can run that anywhere basically.
>> Right. I can take
Azure functions as a docker container that I can build
from and I could put that
on anywhere, on a container locally.
>> On-premises.
>> Or on my own laptop.
>> Wherever. So, that's still an options in this case.
>> Okay.
>> Then the next one is I only want
to run it occasionally. So not all the time.
That's the serverless what we've just talked about.
And those are Azure Batch,
Logic apps and Azure functions.
So, I'm kind of drilling
down to Azure functions in this case.
>> For this particular app?
>> Yes, exactly.
And then I will compare
all the features of
the Azure services to the requirements that I have.
I'm not going to drill down into that right now,
but I just wanted to show you
that I do that in different tables like these.
And I don't just build a big table,
where I just put in all of the Azure services,
but just tables that compare one category to another.
For instance, these are all the services
for container options and VMs,
and these are all the services for
background tasks, will be the one that I need.
And these are all the services
for running your application in Azure.
So, that's my process
for choosing how to run an application in Azure.
And now the next part is,
how do I store my data in Azure?
How do I do that? Again the same thing.
I have a couple of big picture questions
that asks to narrow down to services.
First one is, what will I use the data for?
kind of obvious but we'll get to that.
And what type of data am I going to store?
And then again, I'm going to look at my requirements
and see if the services fit with the functionality.
So, what will I use the data for?
Is it for your application?
So actually for your application,
where you have a data stored on your website for
instance that stores customer records or something,
that's also called Online Transactional Processing.
The other usage that you can
imagine is for data analytics, we do reporting.
And that's called Online Analytical Processing.
So that's the first divide that we do.
And then the second question
is what type of data am I going to store?
There are lots of data types.
One is Relational Data,
another one is Unstructured Data.
There are semi-structure data and all that stuff but
we're just going to stick to
these for clarity and simplicity.
In unstructured Data you have
different types: Document Data,
key Value Data, and Graph Data as well.
And then we're going to try it out.
So, my app is an online reservation system, in this case.
My app needs to store and retrieve document data.
So that last sentence actually says it all.
>> Couldn't you lead yourself in
a different direction if you were doing
an online reservation system that had
a great deal of need for reports,
or your team understood sequel more than another?
Would that lead you in different directions?
>> That could be the case
and could even be the case that I
might need two different types
of data storage for the same application.
>> And that would be okay?
>> That will be okay.
>> Okay.
>> For this example, we're going
to focus on the store and
retrieve document data in the application.
So, this is again an example of all of
the services that are out there
right now in Azure for storing data.
These are things like Azure Sequel Database,
Azure storage but also Azure sequel data warehouse.
So the first thing that we're going to do,
is divide this into two categories of data usage.
So Online Transactional Processing,
so the data storage that I actually
use for my application,
and Online Analytical Processing
data storage that I use for reporting.
So, in our case, it falls into the first category,
because I want to store and retrieve data
for my online reservation system
that is online constantly.
And then the second one is, what type of data?
So again, these services are relational data,
and these services I can store unstructured or
document data and all the other sub types of that,
and then these services as
a Sequel data warehouse and data lakes store.
I can do data analytics,
so I can store big chunks of data and use things like
Power BI or Hadoop Clusters actually crunched that data.
And then after that, I would go into these tables,
just like I did for the running the applications,
and to see if the requirements
match the functionality of the services.
And again, I compare services in
different categories like for OLAP and OLTP in this case.
So that's my process basically.
So, these were just a couple
of services in the Azure space,
just for running your application and for storing data.
Obviously, there are loads
more services out there for securing
your application and for doing IoT and all that stuff.
You can find all those service
on this url azure/services.
>> All right. I appreciate
the formality of your process and
the explicitness because I think a lot of us just pick
services because it's the thing we're familiar
with or the thing that we're comfortable with.
And what you've done is you've mapped
clearly the business need,
the technical needs to
the the myriad of services that you can choose from.
>> Yes. And this works for me,
it doesn't per se work for everybody of course.
It's just my process and
maybe it helps other people as well.
>> I hope it does. You can follow
Azure Barry at Twitter.com/azureBarry.
I'm learning all about how to choose
services here on Azure Friday.