(soft instrumental music)
Hello and welcome.
Please enjoy this short readiness video on Azure Cosmos DB.
How you doing?
Hey, good!
(laughs)
Nice to be back here.
Great to have you with us, of course.
Andrew, can you please tell us more about
your role at Microsoft?
Sure, well, of course, I'm Andrew.
I'm a product manager on the Cosmos DB team.
I've been with product for about six years now,
and it's been a really awesome time.
It has been.
So can you please tell us
what are you gonna talk about today?
Well today I'm gonna give you an overview of Cosmos DB,
the capabilities, the unique features.
I'm also gonna go and show you
what are the common use cases
and scenarios that I keep seeing popping up.
Why Cosmos DB are in those solutions.
I'll give you a quick summary,
what are the top four things you should know
about Cosmos DB before building any solution.
And of course, I'm gonna leave you
with a bunch of go-to resources as well.
So that way I'm giving you some homework, Sanjay.
That's awesome (laughs).
Okay, I'll do that (laughs).
So, let's get started.
Where do you wanna start.
Let's do a demo.
Oh my god you're surprising me there.
This is awesome.
The best place to start it always is,
rather than PowerPoint let's show you the product itself.
Okay, cool.
So I'm gonna go here
and I'm jumping into the Azure portal.
Which is where of course everything Azure is.
And what I've done here
is I've provisioned several different resources.
I have a Cosmos DB account,
as well as a pair of virtual machines.
Now each of these different virtual machines
is deployed in a different region.
I have one running in West Europe,
as well I have another virtual machine
running in West U.S. too.
And what I'm gonna do with these virtual machines
is simulate this is where my application's gonna live.
Yes.
Now, I also have a Cosmos DB account.
And one of the neat things about Cosmos DB is,
in a nutshell it's a no SQL database.
It's distributed database.
How it's different from a relational database
is that it's built to scale out natively,
as opposed to scale up.
And as we know relational databases,
you can generally speaking when your data volume grows,
or your request volume grows,
you scale up by adding more cores.
You add up more disks, yes.
But then you hit that ceiling.
And that ceiling is,
"Uh-oh, what happens
"if I have the biggest machine available?"
Well the solution's quite simple,
you scale out to more machines.
Yes.
And there's many different dimensions of scale out.
Scale out's actually a pretty nuanced concept.
There's partitioning,
which is dividing the data set.
There's also replication,
which is copying the data set.
Yes.
And what you wanna do
is not just be able to have these capabilities,
but do that in a very, very robust manner.
So as you replicate,
traditionally there's been a lot of challenges,
which is how to deal with consistency,
how do you deal with trade-offs with consistency,
with latency.
And latency especially.
And relational databases used to push you
into these hard extremes of
strong and of ventral consistency,
which would be modeled as synchronous
or asynchronous replication.
Like maybe we can get some nice shades of gray in between.
And on the partitioning side,
a lot of the manageability aspects,
like just doing the things like schema updates,
index updates,
can we make that really, really a robust experience?
So that's what I'm gonna show you today.
Okay.
Is a highly partitioned,
highly replicated database,
and it's gonna be very easy to develop.
So here I've opened up my Cosmos DB account.
And one of the first things I wanted to show you
is on the replication perspective,
we've made this globally distributed.
We've deployed this across four different regions
around the world.
In fact, now that I have North America, Europe,
Asia, and Australia covered,
if I wanted to let's say have a truly global presence,
I wanna be in every continent.
I wanna be in Africa and Brazil, too.
Yeah.
Replications setting that up is literally
clicks of buttons and hitting save.
Wow!
Super easy.
By the way, it's my favorite screen,
I love this how you easy way to tell this.
(Andrew laughs)
We wanna make this as easy as possible,
and one of the beautiful things is
once you've replicated everything,
you can go into the consistency settings
and this is where I am showing you
like we have these nice shades of gray.
Now what I'm gonna do here is,
I have a container set up,
and I have a few applications on those VMs I mentioned.
So here I'm just having a fictitious scenario where,
it's actually one of our common use cases,
as IoT device telemetry,
and what you'll notice here is I've initially,
I'm gonna start out with a fairly small container.
I'm gonna start with 1000 RU/s,
and then what I'm going to do is
I'm gonna show you just how elastic this is
and traditionally in a let's say an old school RDBMS system
like this rebalancing and redistributing your cluster,
Yeah.
You would have availability loss.
Well, in this case what we're doing
is we're able to scale up, scale down dynamically,
and I'll do that online.
So if you have mission critical workloads
that always have to stay online,
this actually gives you a really easy way to do so.
So no need to configure
it just automatically does it?
Oh, and that's actually one of
the really cool things is one of the new features we have
is auto pilot.
You don't even have to know about these RU/s.
We'll talk a little bit about that later.
(laughs) Okay.
So let's go over into our first application.
I'm jumping into my virtual machine.
I have remote desktoped into it,
and in my first application what I'm gonna do is,
what it does is there's a bunch of code here,
but the main meat of it is going to be right here.
I'm gonna spin up a ton of asynchronous tasks,
and within those tasks I'm gonna
invoke this function insert document,
and what insert document does is it actually it just
writes to the database in a really really tight loop.
And so think of it as on my app,
I'm gonna spin up a bunch, a bunch of threads.
Each of those threads is pounding the database
constantly with requests.
Okay.
And what I wanted to show you is
just how elastic some of these are.
So you're basically simulating
a real-world scenario.
Yes, I'm trying to show you
if you have let's say an application that's running AdScale,
in this case lets say an iO2 device telemetry scenario.
Either one elevators or something?
Yeah, let's think of it as elevators.
You wanna do smart elevators,
and one of the things you wanna do is
a experience where if an elevator is unhealthy,
you wanna be able to get a technician
right there on the spot so that that way,
elevator never stops. Right?
Yes.
This is a mission critical work up for a you.
So, what I'm gonna do here is,
the thing with the IoT is devices tend to emit
telemetry really really fast, right?
They're going, "Here's my state,
"here's my state, here's my state, here's my state,"
and within let's say 10 seconds,
it's generated 10 data points.
That's more than I'm gonna tweet
or anything like that per day.
People like that think social media is big data,
no IoT is actually truly data.
I see.
And what we're gonna do here is,
if imagine that I'm starting off small,
I've built my minimal viable product,
I'm gonna go and have let's say a set of devices
writing to the database.
I've deployed it I have a bunch of writes per second,
and that's what I simulating here is
lots of writes per second.
Now now that I'm MVP successful,
I wanted to go and go big, right?
So what I'm gonna do is,
I noticed like hey with a thousand RU/s, you know what?
That's, that's cool and all,
but can I for example scale 10x higher?
And when I say scale does that happen instantaneously?
Does that happen traditionally you would wait
for like your shards to rebalance
and reconfigure and it takes a while.
but with Cosmos DB I just go and added an additional zero,
10x isn't like 10% more throughput.
This is 10x more throughput.
Go back to my application,
run it again and check it out.
Right away this thing is gonna spin up,
takes a little bit to warm up,
but as you noticed it's gonna settle
instead of a thousand RU/s roughly,
it's gonna settle at about 10000 RU/s consistently.
The key thing here is there's no loss in availability,
and it can happen instantaneously.
It does.
That is I think the key thing number one.
The second thing,
this is really all about spreading a workload,
in a partitioned cluster.
Let's also look at what we can do with replication.
So replication typically you do with two reasons.
Number one is high availability.
You want redundancy so that if,
you know a data center gets whacked by a hurricane,
or a natural disaster,
you can failover.
The other thing is you can do something really novel here,
which is bring CDM-like capabilities,
like really, really low latency,
to every one of your users,
no matter where they are around the globe.
I see.
And so what I'm gonna do here is
I'm gonna run my second application,
and I'm gonna show you the latency.
So in this application what I do is
I first connect to the database,
and you can steal my keys if you wanna play with it.
(laughs)
Once I connect to the database,
I just have a, this is a much simpler app.
I just have a while loop,
and I'm just gonna run a query on it.
And when I run the query against the database,
I'm also gonna start a stopwatch,
just to take a look at,
well how fast does this actually run, alright?
Well you'll see that first request
takes a second to initialize the client,
but from here you get consistent,
really, really low latency.
Tight latency, right?
Like you can get even single-digit millisecond latencies,
so if you're loading like really, really robust
real-time applications,
real-time machine learning for personalization,
or fraud-detection,
this is incredibly fast.
Absolutely.
Now the challenge here is I'm in my West U.S. VM.
Imagine if I had a West U.S. database.
It's talkin' to a local database.
It's pretty fast.
So you have a user in the West U.S.,
as well as Europe?
And now I'm gonna set it a second user, right.
User's in West U.S.,
it talks to an application in West U.S.,
talking to your database in West U.S.
Okay it's all ideal.
But then, real one.
That's Alice.
Bob comes in.
Bob is in Europe.
And Bob if I have to ship a packet from,
let's say Europe to West U.S.,
I'm sending packets across the ocean.
Yes.
Take a look at what happens here.
Same application.
I'm gonna run queries.
I'm gonna do a stopwatch.
And if I had a single region deployment,
what you'll notice is,
well if I just even were to ping a server across the ocean,
it takes a while, right?
What you've noticed is the latency jumped
from about 10 milliseconds to about 300 milliseconds.
How do I fix that?
Globally distribute a database.
Replicate bring that data close to where the user is.
I've actually intentionally connected my West Europe VM
to a U.S. endpoint,
and with a client you can actually set
custom failover policies,
so that way if one region goes down,
it knows to automatically
and seamlessly failover to additional region.
Now what I'm gonna do
is I'm gonna actually configure it properly,
so that my West Europe application
also talks to a West Europe replica.
Yes.
Rerun this again,
and boom all the sudden my latency has been floored by
order of magnitude.
Fantastic.
So here's the kicker.
Historically if I'm running many many shards,
and I'm also running many many replicas,
I have a project, right?
I'm developing an application.
The business is really pushing me to deliver
new functional requirements.
I need to do a schema update.
If I have to do alter tables,
create index across a dozen shards,
across three or four several replicas,
and then the business also tells me,
"By the way no loss in availability".
You cannot take your website off for maintenance.
There's no offline.
You have to do this online.
Ooh well.
I've been in those awkward statements before.
Yeah right?
What you're doing here is,
the application has changed it's data model,
it expects a different data model from the database,
and now you have to make sure that you have
a consistent view across all these shards and replicas,
doing alter tables create index
is just an operational nightmare.
It really slows down your application development.
So Cosmos DB,
not only does it act as a distributed database,
it does this as a core tenant of the system,
and one of the things that we wanna make is,
it's easy to develop.
So here I have the dataset
I've been jamming into the database.
It's a mock dataset for an iO2 scenario.
But what I'm gonna do here is
I'm gonna show you like let's say tomorrow
I wanna add an additional property to the schema, right?
Like I wanna add some tagging,
and on the tagging I can go
and add a new tag that this is tag blue.
And what I'm doing here is
I wanna just add a new property or column
without having to do any kind of alter tables create index.
I just wrote the record.
No schema update.
And I'm gonna go and query for that record back,
and using the automatic indexing,
let's say this is an array.
Array contains c.tag blue.
Automatic indexing that came back blazing fast.
I did not have to do any kind of crazy deployment.
That's magical actually. (laughs)
I'm gonna leave you with a few things
now that you've seen in the magic of Cosmos DB.
One is how are people using it?
If I were to go and codify this,
and you can always pause the video here.
I'm not gonna read all of this for you,
but typically people use us for,
you saw the latency for real-time workloads.
Real-time telemetry.
Real-time telemetry has another aspect,
is the write ingest.
And one of the hard challenges historically with databases
is many of them were read-optimized.
They would have locking mechanisms
to do concurrency control,
and they would do it in a pessimistic way.
But chances are like for telemetry,
you're actually doing,
like most of these writes aren't conflicting.
You could do an optimistic concurrency control
and using a log-structure underlying store,
to get very, very high write throughput,
as well as partitioning that out.
And so we see this a lot
and doing if it's IoT it's doing device telemetry,
if it's user-facing websites user telemetry,
to do things which is the second workload,
real-time personalization.
This is once again really using the latency.
Like if you need to generate,
if you have a website that needs to respond just like that,
you have a large stale eCommerce website,
you're gonna go and personalize a landing page
so that Alice sees products that Alice likes,
Bob sees products that Bob likes,
that way you actually can increase your sales conversions
a little bit on your eCommerce website.
But the thing is user's not gonna wait
two seconds for a page to load, right?
They're gonna go, "Oh okay this thing,
"screw it let's hit back button."
Well this thing's gonna respond in single-digit millisecond
giving you ample buffer to implement that business logic.
People also use us for the mission-critical workloads,
the resiliency you get across regions.
This is a multi-master database.
You don't even have to do server-side failovers anymore.
The client I showed you earlier,
you can configure different regions,
the client seamlessly just goes,
"Oh okay I can't talk to this endpoint,
"let me go and just basically fall back."
And then of course we see a lot of people
take advantage of the fact
that this is a fully managed service
and they migrate their no SQL databases,
existing ones over here.
Fantastic.
Four top four things you need to know.
Partitioning, Request Units, Time-to-Live, Change Feed.
I'm not gonna go into these in depth,
because we're gonna do follow-up videos,
or you've already seen some of the partitioning
and data modeling.
What we'll do is you can check out,
here's a quick summary of what you need to know,
but if you're gonna know anything in Cosmos DB
these are the things you should know about.
Fantastic.
And then I'm gonna give you some homework.
Yes.
If you wanna know more about Cosmos DB,
this was a really crash-course on what is the product.
We have a full day Pluralsight course
that I encourage any of our users to take a look
it'll go you from "hey I don't know anything about this"
to a hero in a single day.
We have a bunch of different labs and decks
and other workshop materials,
both for Cosmos DB specifically,
as well as full-blown solutions
that we've prebuilt out at these GitHub links.
Of course we really value our user feedback,
this is where you can send in your feedback,
and also encourage people to follow us on Twitter.
That's where you'll see the latest updates.
It's a Cloud service things are always moving very fast.
Fantastic. So awesome to talk to you every time.
Yeah.
Thank you.
Thank you so much.
Thanks for watching this short Azure readiness video.
