Hey, friends.
Azure Cache for Redis Enterprise is
a low latency, high
throughput data storage solution
for modern applications.
There's some exciting new features
now in preview
that not only improve
developer efficiency
but also enhance security and scale.
Our special guest, Sean
Noyes from Redis, is here to show me
what's new - today on Azure Friday.
Hey, friends.
I'm Scott Hanselman and it's Azure Friday.
I'm here with Sean Noyes from Redis.
How's it going, sir?
It's going very well.
Hi, Scott.
Thank you for having me.
And hello, everybody.
Yeah, this is cool.
So you work for Redis
and you're here to talk about Redis.
So this is going to work out nicely.
I am. Yeah.
So we have, you know, this
this first-party product.
It's available in Azure.
It's part of a co-engineering effort
between Azure and Redis.
So we provide this
this joint engineering
as well as joint support for the Azure
Cache for Redis Enterprise
or ECR products.
Interesting. So what does that mean?
Joint engineering?
Like, I don't mean to minimize things,
but someone who's watching
might say, well, aren't
they just running Redis inside Azure?
Yeah.
Well, so,
you know,
in order to access the APIs
that do governance
for a fully managed service,
you know,
we have to coordinate very closely
with the Azure engineering teams
as well as coordinate with the teams.
We're actually implementing
the open source
versions of Azure Cache
for Redis on on Azure.
So in order to have this service
that offers these enterprise tier
features,
then we have have a very close connection
with those folks
and they actually do
a lot of engineering side
by side on the product.
That's cool.
So then that means that it's
the very best Redis
doing, the very best high
throughput, low latency on Azure
because you
talk to the Azure engineers
and you know how to make that as
work as absolutely.
So we have product engineers
on, on the Azure side
who are working
very closely
with the same product managers
and engineers on Redis.
And those folks are in in near
constant contact.
Very cool. All right.
Do you have a demo
I do have a demo,
so we do have these new features.
A lot of things have changed since we,
you know, launched this product.
It launched a few years ago
and we've done several things.
Some of the things I won't get into.
But, you know,
there are
these extended data types
in Redis enterprise, for instance, JSON,
which allows you
to granularly pull JSON documents
and also to update JSON documents
without having to serialize
and serialize the entire payload
up and down the wire.
So it's very convenient
and I would recommend
that users look into these modules
because they're,
they're extremely powerful.
So I'm just going to kind
of walk through here a set up.
I already kind of started this one.
We've added in some
some information here.
You can see
I selected read a search
because I want to have this
in my cluster.
We have one redundancy.
Of course,
we can enable or disable TLC access,
but some of the new things
that we have right in preview,
we have data, persistence.
So you can do a snapshot of already be a
60 minute
six hour or 12 hour
snapshots which get
put into a storage account.
We can also do append only files
which are more accurate
but take longer
for a restoration, obviously
because they are more accurate.
And you can do those always. Right?
Right. Every second.
Of course, we have
active geo replication,
which launched
at the beginning of last year
and this is for multi regional set ups.
So we do an eventual consistency
last write wins
approach toward the reddest clusters.
And it's very simple to set this up.
You just go in,
you click configure
and then you can just add it to a group
or you can create a new group
and you just click configure
and it joins that group automatically.
So that becomes a very attractive
thing for customers
when they're doing
multiple deployments and regions
because of course
you can get local latency for your Redis,
but still have the added comfort
of knowing
that your data is available
in another region
in the event of regional outage.
speaking about
just so
the R&B format, the database format is,
you know, the binary format for Redis,
but then off is the append
only file format.
What are the differences
between those two?
The differences between the
files themselves are really
not that great.
You know, effectively
the RTP is just a snapshot
of what is in RAM for Redis.
And whereas the AOF is
is all the commands
that have come in to write to Redis.
I see.
So I'd like an audit log
and that gets saved to Azure storage.
Then if there's a catastrophic failure,
you can reconstruct
all those things with those stored
rights, Absolutely. Absolutely.
And that's something
that's done through,
you know, through support at Microsoft.
Kind of related to this is this customer
managed key encryption,
which is something
we didn't have previously.
A lot of customers ask for it.
There's a lot of security concerns
in order to get approved
to use Redis Enterprise,
we needed to have this ability
to manage your own keys.
Previously, those were Microsoft's
Microsoft. Microsoft provided keys.
So you
effectively have to
you create an assigned
entity identity.
Excuse me,
you have a keyboard
key vault that you would have stood up.
You select the key
that you have in your key vault,
and then you can just
assign the version to it and apply that.
So any data at risk
then will be encrypted with your own key.
So that's very important
to a lot of especially,
you know, extremely security
minded customers.
And we are talking
about the data at risk.
So that would be the RTP in the
AOS files.
we have a couple of other
other features here.
We're just going to go ahead and do this.
I have I've stood up this cluster.
This is just a persistence cluster.
We have something very cool.
So for active geo
replication, we've
just allowed the ability
to send a flush command into the right
US enterprise clusters
that are participating in active active.
That's something
I think not a lot of customers
we didn't expect
customers to use in production,
but when customers are testing
or they're doing internal benchmarking,
it's very convenient for them to say,
you know what,
we want to flush all the keys,
not just from this cluster,
but from everything that's participating
in the active, active group.
So another thing
that we have that's
currently in preview is scaling.
Now in this case we're scaling up, right?
So you can see across the top
it says the best practice
is to scale up before scaling out.
And the reason for this
is because customers
think in terms
of like the open source radius
where scaling out
is really your solution,
where you are
expecting to get more shards
and you expect better performance.
But of course, open source
Redis is all single
threaded in enterprise.
Has that kind of extra tier
where we're doing
pipeline and multiplexing
to take advantage
of all the cores on any node
within the enterprise cluster.
So one of the things we have
we see with customers
is that they're if they're having, you
know, connection
slowdown or they're having connection
pool exhaustion
or they're experiencing really high CPU,
that scaling up is really
a good solution for them.
And you can scale up in this case,
this is an enterprise Z10,
which is a 12 gigabyte cache,
and you can scale up
into any of these other tiers
and that's just a click of a button.
You save it
and it happens behind the scenes.
It stands up another Redis cluster
and then
migrates the keys over
to it, updates
DNS and your clients resume
connecting as normal.
can you pull that down again.
What's the starting
and where's the ending?
Like, how big can this get
So right now in this case,
these are Enterprise Eaton's.
This one is an E ten.
Now we have enterprise on flash too,
but I don't necessarily
want to get into that right now.
But right now
we have these four SKUs available.
You can get two.
So the base with two nodes,
that's a primary secondary node
is going to be 100 gigabytes.
You can expand that to ten,
which is actually going
to be five primaries.
So that's 500 gigabytes.
However, we are about to launch
probably next quarter and E5,
which will be half of that E, ten
and an E 200, which will be double
the E 100 in size.
And of course we're talking
about a lot of RAM there,
especially if you start doing
multiple node clusters,
you know,
ten node clusters with five primaries,
we're looking at about a terabyte.
They're enterprise on flash
can go up to
right now
it's 13 terabytes
as configured in the portal,
although from what I understand,
they've been testing configurations
up to 29 terabytes.
well,
but it's definitely to be able to handle
anything I can throw at it.
That's absolutely true.
You know,
the extra cores
that you get on those enterprise
VMs really,
really makes a difference
in terms of ops per second
and the amount of connections
you have available.
You know,
open source has a problem
where there's
there can be network back pressure
and there could be pressure
because those single threaded shards
can only support so many writes and reads
on any given shard.
So you do experience
sometimes network back
pressure with the open source shards,
which we get around with our
our proxy tier
available at that enterprise level.
And even if I'm doing 100
gigs,
the latency is still going to be
near zero.
That's what that's what
Redis is so well-known for.
Yeah, absolutely.
So you know, in the event
that we're looking at,
you know,
100,000 ops per second or something,
you know, is extremely high,
you know,
scaling out
and making more shards
available for writing,
as well as taking advantage
of the ability to multiplex
and pipeline against those shards
greatly increases throughput.
know, if I'm doing
local testing on this,
if I'm using the open source registry,
I spin operators
locally here
and I'm writing
using the libraries
that I'm used to be using as a developer,
I'm just talking to Redis.
And if I go and pointed
to us, the Enterprise, it's
going to continue to just work, right?
Because registered as Redis,
it's just more tuned to the cloud.
is 100% backward compatible.
The only difference in terms of coding
would be
if you are experimenting
with using the red modules.
Okay.
And then a module would be an API
that is going to be specific
to that module
and then that would need
to be also local on my machine
if I were going to try to do that.
Yeah. So.
So in Azure we have red bloom,
we have red it's time series
red, a surge in red JSON,
which I mentioned before,
something interesting
a lot of customers are doing right now
with Red a search
is that we do
vector similarity search
natively from within Redis.
So if you have
I models and you have files,
you can process those through
your models,
you can capture those vectors,
store them in Redis,
and then query against them
using Redis search
at that very, very low latency.
very cool.
And then read as
JSON is literally emailed
me, processed my objects
and is
making it
like a document store
instead of a name value pair store.
Absolutely.
You can store
large JSON documents and again,
you can access these on a granular level
so you don't have to pull down
the entire document.
If you need one
particular facet
of a large JSON document,
you can just pull that single value
or you can pull an array of values
off of multiple keys, multiple documents
just to see how
a bunch of different documents
might compare.
And conversely,
you can do those updates in place.
So if you just need to update
one facet of a JSON document,
you can run a command.
It's a JSON path like,
you know, very, very familiar
type of query query language for that.
So, you know,
customers are,
you know,
use JSON
or using JSON in their client apps
are going to be very familiar
with how
they would access the data
from within their JSON documents.
If I'm implementing Redis
for enterprise in my enterprise,
I probably already
have an existing database.
Do you think about Redis as a cache
or it is an in-memory database?
Is it
something that you expect
is going to augment
my existing data stores
or should I consider it as a database
on its own, in its own right?
customers look at it
initially as a cache.
You know, that's
where a lot of developers come to.
That's where I came to it.
It's probably
where you came to it initially.
Like let's
just cache sessions for instance.
But then really with these extended
data types
and all of the other native data types
available for Metis like streams,
you can implement this
as an in-memory database.
We do have something on our roadmap,
which I'll kind of tease out right now,
which is that
we're going to provide the ability
to monitor streams and key spaces
within the Redis
so that you can do triggers
for Azure functions.
So this will allow us to
to get some isolation against the code
which we're doing right behind
and read through those in our code.
And you could actually
just kick off functions in order to,
you know,
have a R2 beams
or a source of truth database
while utilizing Redis
as an in-memory database
for all of your other needs.
Yeah.
And what's interesting
is this rise of the multi-modal
database, right?
You're storing all this indexed
and indexing all this information
not just in one model,
but it's a relational database, it's
a document
database, it's a graph database,
like it's
with with the plug ins and the add ons.
Redis is really
whatever you need it to be.
Yeah, absolutely.
You know, again,
there are so many different
native data structures
that, you know, even,
you know,
augmenting for time series data.
Like that's a really big deal
because the time series module
does aggregation on the fly.
So in the event that you have like
an edge
use case or an IoT use case
where you do have lagging data,
you don't have to rerun
these batch processes
which which, you know,
development teams
have had to write over and over again
every time new data comes in in order
to make it more human readable
in, you know, to make it analyze able,
all you have to do is tell Redis,
hey, watch this key
and make aggregations off of it
and downsample to whatever time frame you
Yeah, it's a great point.
And then you mentioned Reddish
Bloom Bello,
and that adds a whole other
series of data structures
that one can use.
So like it's
kind of infinitely extensible.
And the data structures
that are included
with red
bloom on red list for enterprise
are pretty sophisticated.
Yeah, they are.
They are the probabilistic data types.
You know,
they tell you whether it's something
that's probably in the cache
or definitely not in the cache,
depending on how you,
how you set that up.
But, you know, it's it's great.
We have a lot of customers
who use it for,
you know, for things like like checking
IP's like has
this IP ever been used before.
They can very, very quickly
sub millisecond latency
find out from Redis
whether or not
we have seen this IP address before.
Right.
And so then you can easily apply
that to any secondary processes.
If you say no, we haven't seen it,
well then there could be
a secondary process that would be
that is kind of made unnecessary
if you get Yes,
it's it's probably here in this cache.
And this is a
this is software as a service.
So I'm assuming
I don't need to upgrade it.
I don't have to think about maintenance.
You know, is there are there downtimes,
are there maintenance
windows Maintenance
and patching are all
done by the Azure team
there.
There may be were some initial,
you know hiccups
when the service first launched
but we've we've gone through those
and we've gotten over those humps.
We haven't had any significant issues
in terms of outages
related to those things.
So at this point,
it is it is,
you know, 100% managed service.
We will be offering maintenance windows.
Some customers have said, hey,
we just want to be sure
that you're not doing patching
because there can be
some slowdown on those nodes
when they're
when they're patching course,
they do them round robin.
But customers have asked for that,
and that's that's on our roadmap for,
I believe, sometime this year.
very cool.
So some of these features in preview,
but folks can access them right now.
Right. They can go up and sign up today.
Yeah absolutely
none of this is in private preview.
It's all in public preview
so if customers want to go in
and kick the tires, it's as simple
as going out to your Azure portal.
So I already have this.
Yeah,
this is the thing I love talking about
Azure Fridays
that I find out
that I already have access
to something cool
and then I can finish the show up
and then think about
how I'm going to go and implement
this on one of my projects today.
Yeah, that's a great idea.
I mean, that's
that's what we talk to our customers
about all the time.
You know, it's so simple to stand up.
You know, in 15 minutes
you can have a Redis Enterprise
cluster and start using it.
Very cool Azure Cache for Redis
Enterprise, Low Latency, High Throughput.
Thanks so much,
Sean, for hanging out with us today.
Thank you very much.
I really appreciate it.
I am learning all about Azure Cache
for Redis Enterprise, today on Azure Friday.
Hey, thanks for watching this episode of
Azure Friday.
Now I need you to like it.
Comment on it,
tell your friends, retweet it.
Watch more Azure Friday.