[MUSIC]
>> Hello, my name is Klaas Langhout and
I'm a Principal Program Manager in Azure.
Today I'm really excited to talk to you about Azure Blob Storage.
When we're talking about Blob Storage,
I want to first describe a little bit about what it is.
It's Azure's PaaS product that provides
unstructured data storage all the way up to exabyte scale at very,
very low cost points.
Blob Storage is used for different types of workloads.
Here is some of them that we look at.
The first is Cloud-native applications.
Applications that are designed, that require
that exabyte scale and
that low cost you can get with an unstructured data store.
We also focus on Analytics.
Analytics being Spark or Hadoop,
using the ADLS Gen2 capabilities that we have in Blob Storage.
The third category is high-performance computing,
whether that be autonomous driving,
genomics, oil and gas, or other,
and that also includes machine learning and AI workloads.
Last, which often is assumed to be the primary workload,
but really isn't of unstructured data storage,
is cold data storage,
be it backups, logs, media files, photographs,
etc, that is the fourth use case that
we see often with object storage.
Now, thinking about cost drivers,
I can break it up into four different categories.
The first is GB costs.
How much are you spending to store the data in Azure?
The second one is transactions.
As you're writing data to Azure, reading it,
or also processing against that data,
those are all transactions and how
to optimize your transaction cost.
The third is picking the right redundancy level for
your workload because that can have a major impact on your cost.
The final one is how to reduce your network cost by making
a choice of how you want to do
the network egress and ingress into Azure.
Now, for the first one, capacity,
there's two specific features I want to talk about.
The first one is reserved instance,
which I'll give a demo for.
The second one is life cycle management,
which allows you to automate your movement between
different tiers of Azure
storage such that you can control the cost.
Here, I have my storage account,
this is my personal account.
In here, I'm going to go ahead and
do a search because I don't remember where
these reserved instances that I mentioned are.
I see this thing came up called reservations.
I'm going to click on "Purchase" now.
I'm looking at blob storage,
so I'll select that as well.
Then it gives me up all of the options defined for
the region I'm in and the access tier.
Note that there's a whole bunch of different choices so I
can choose the access tier, the redundancy.
I notice that the purchase size is
either 100 terabytes or one petabyte.
I can choose in those two different sizes.
I can also choose a term of either one-year or three-year.
By doing this, I can save over 30 percent in
my storage costs by choosing to purchase
in that one to three year pattern.
Next, I want to talk about
the four different tiers we have in Azure Blob Storage.
Now, this is a stack where the higher-up is the hotter tiers.
Starting at the top, we have premium which is SSD based,
which is really ideal for
high throughput workloads with a
lot of different transactions coming in through time.
Then all the way at the bottom,
we have an offline tier.
The premium tier, if you have a workload that say,
has over 45 transactions per second per terabyte,
the overall cost of that workload,
including the capacity and the transactions,
will actually be less than the hot tier.
Now, the hot and the cool tier are both hard drive based.
They have a nice balance of capacity and transaction costs,
especially on the hot side for
the majority of workloads out there.
Now, once we get to cool,
that's really designed for workloads where you probably will
access the data maybe once or twice every month or two.
So not that often,
but you will access it periodically.
Then last, we have our offline tier which is archive.
I will mention that the archive tier,
I mentioned offline for a reason.
Any workload that requires
online access to be able to read that within a few seconds,
the archive tier is not the one to use.
But for cold data storage such as backups,
where you probably will not utilize
that data for months, if at all,
across the year, the archive tier will give you
the clear lowest cost for your storage.
Now, I want to do a quick demonstration of life cycle.
I'm going to pick this Canada East storage account I've created.
On the left-hand side,
there's table of contents.
I want to go down to Blob Storage.
At the top, I have settings,
then I get down to where it says blob service,
and then underneath there, I'll see life cycle management.
I have two policies already created,
but I want to create a new policy.
I also want to note that I've turned on access tracking,
which means that I can use the last
day that the blobs were accessed as part of my policy.
Now, to create a new policy,
I'd say add rule,
and it gives me a wizard.
I can name it so I can know what I'm doing in the future,
and I'll just call it Demo.
I can specify the scope.
All blobs or just some of them, I'll say all.
What kind of blob.
Then in this case, I'm going to pick Base blobs and versions.
Then when I go to the next screen,
I'm given these if-then blocks.
I'll say last accessed more than,
say, 30 days ago,
I want to move to cool storage from hot.
Then I'll add a new block, which basically says,
if this is last accessed say 180 days,
in that case, go ahead and move it to archive.
Then lastly, I'm going to add a third block,
which will basically say,
if I don't access the blob in the last 365 days,
so it's pretty cold, go ahead and delete it.
It's not something I want for this workload.
Then I said versions are also in scope,
so I'm going to set a separate policy for versions.
I'll set that to just seven days because those are intermediate.
I'm going to save that and it's successfully updated.
Now if I look at the Code View,
if I wanted to have a little bit more granular control
and I'll go down to the third policy I just created.
I can tell it's the third one by the name there.
It says Demo. I have those different statements there.
The versions after seven days,
the hot to cool in 30 days,
archive in 180 and then delete in 365 for block blobs.
That's basically a demonstration for how easy it is to create
a life cycle management policy to automatically
move your blob to the right tier to save cost.
Now I want to talk about transactions.
Transactions, as I showed in that previous slide,
increases as you get cooler.
In the premium tier,
it's the lowest cost of transaction.
Again on hot, the transaction costs is higher than premium,
but still relatively low.
So that's probably the more common tier
for most workloads where you know you're
going to use the data every day,
but you're not sure how much.
Now the next element of cost
is choosing the right redundancy level.
So when you create a storage account,
you basically have to pick how we
protect and copy the data on the back end in our environment.
We have these different modes that you can choose from.
We have Locally redundant storage, LRS,
which ensures that we commit the right to
three different hard drives in
three different locations within a zone,
such that if we even lose a hard drive or two hard drives,
we haven't lost any data and we can still
provide the access to that data.
With Zone-redundant storage, we do the same thing as LRS,
but we ensure that
those three different drives are in different zones.
In this case, even if we lose
an entire zone for a short period of time offline,
there is no impact to the application.
The application reads and writes can still happen as if
the system were fully functional because for
all intents and purposes, it is.
Now for data where you want to protect it from a natural disaster,
you want to ensure that even if there were
a fire or an earthquake in one of our regions,
that removed availability for some period of time,
that you still had that data securely accessible elsewhere,
and that's where the dual region options of GRS comes in.
Where we make sure that we commit the right on the primary,
and then at a later point in time,
usually within a few minutes,
we start to replicate that data to a secondary site.
It's like an LRS account on
the primary and an LRS account on the secondary,
and in most cases,
those two regions are at least 300 miles apart.
Lastly, the fourth option,
which is GEO zone redundant storage GZRS.
We combine the zone availability
on the primary for the ZRS account
with the geo-replication to protect against
regional loss on an LRS account in the secondary.
The last thing I'll mention is that for both dual region options,
we have an RA or Read Access Mode where on that secondary site,
you can also read the data that was copied there.
Then across the bottom,
I show that the cost structure is the least for
LRS and the most expensive for RA-GZRS.
Choosing the right redundancy
is important as you're thinking through your cost structure.
Here I just want to walk through that.
I want to create a storage account.
In the storage account creation,
there's a couple of things I have to answer
such as which resource group,
what's the name of my storage account,
the region it's in.
Is it a standard or premium storage account?
Then under replication, I have those options.
At this point in time, I can pick LRS, ZRS, GRS, etc.
After the fact if I already have a storage account,
I can also convert easily from LRS to GRS.
Moving to or from ZRS requires a separate step
because we actually are copying
the data to a different hardware resource.
So that was an example for how easy it is when you're
creating storage account to pick the right redundancy level.
Lastly, I wanted to talk about how to optimize your network costs.
For that I have a brief image I want to walk through.
So when you create a storage account
and you're going to use that storage account from
VMs or containers or other types of workloads, by default,
say I'm the client on
my on-premise network and the top right corner of the slide,
when I'm doing a read or write,
It'll go to the local point of presence within the region I'm in.
it'll go to a point of presence,
which is that edge router.
Then from there it will route on
the Azure backbone all
the way to say the West Coast if that's where
my storage account is to give me
a very low latency and high-performance network link.
Now, the routing preference that we
brought out allows the customer,
you, to choose a different model,
to choose Internet routing,
which is identified by the orange line.
Instead of using the Microsoft network,
you can instead use the Internet,
which then routes you to a point of presence
closer to the storage account in the region that it's in.
By doing so, you can bring down
your network costs for
both egress and ingress quite substantially.
Now hopefully, I've actually covered some of
the key ways that you can save costs,
including how to think about capacity,
how to move between storage tiers,
how to think about the transaction costs,
as well as how to think about redundancy and network costs.
Below, I have some specific links for more information.
I thank you very much for your time.
[MUSIC]