>> Hi, this is Steve Michelotti
from the Azure Government
Engineering team.
I'm joined here today by
Rafat Sarosh from the
Cosmos DB Engineering team,
and we're going to be discussing
Cosmos DB on Azure
Government. Welcome.
>> Thank you.
>> So, I think the most logical
way for us to start is to
just start by describing
what is Cosmos DB.
>> So, Cosmos DB
is a multi model,
multi-master,
globally-distributed database.
>> So, that's a mouthful.
I think we'll
explain this as we go.
>> Sure. But, before we
talk about Cosmos DB,
I would to talk about
what problem we are
trying to solve here.
>> Okay.
>> Because technology
for technology's sake,
it'll not be fun.
So, if we see what are
the challenges
modern apps faces today.
Number one is, all these
apps today because
the world is flat,
they have to have a
global distribution.
Data is created in one region,
consumed in another region.
So, Azure Gov may not be
internationally-distributed,
but you have US East and US west.
So, data can easily be consumed
from different region.
>> So, Cosmos DB is
a globally-distributed
database on Azure.
>> On Azure.
>> In Azure Government,
of course it's
nationally-distributed.
>> Right.
>> Yeah, good point.
>> Secondly, is we see
that we have to have
very high responsiveness and
most of the modern apps
have personalization,
and because they have to
have personalisation.
By that, I mean the
app need to know you,
so they can tailor-made
their menu and options for you.
>> Everyone has user
preferences, that kind of thing.
>> Things like that.
>> Okay.
>> Right.
>> A lot of data.
>> Lot of data. Two, because if
you want to enable the
personalization feature
on your app,
you have to go
through the history
of your usage of your data.
So, a lot of data
you have to process.
This data can be
very complex and different
schema and things like that.
Because the apps are
globally-distributed,
your users are distributed.
So, it's very difficult
for you to figure it out
what is the requirement for
your storage and throughput
from the get-go.
>> We might want
our app, our data to
be as close as
possible to our users.
>> As to your users, too, right?
>> Okay.
>> Then, today, if
any app takes more than
200 or 300 millisecond,
we say that app is slow,
and you use a complaint.
So, we have this
requirement that we have
to have very low latency even
if the data is distributed.
We have to have a low latency
for our global users.
>> I think this is
an interesting point because
a lot of the crusty old SQL
people will think,
"I have Oracle Sequel Server.
Sometimes, these queries
take a long time."
So, do we really have
low latency on Cosmos?"
Sometimes seeing is believing.
>> True. As I'm showing here
that all these modernizing app
have to have personalization,
recommendation, social,
gamification, all these
are mean bar for the apps.
There's no more premium feature.
>>> Right.
>> So, we were in Microsoft.
We were seeing these problem
almost about 80 years back or so
when we were trying to
build database for our own need
for Xbox and Skype,
where we have this
hugely, globally-distributed
customer base.
So, we started building
this database called Cosmos DB,
and it's born in Cloud.
So, from the inception of
our design principles,
where that we have to
have global distribution,
elastic scale out, and
guaranteed low latency.
So, that's how we build
this core capability platform,
and then on top of this,
we built Multi-Model.
>> Okay.
>> So, by Multi-Model,
I mean any enterprise have
data in different forms,
and they would like to
consume this data
in different forms,
not only through UI but
the client libraries itself.
>> Okay.
>> So, on this core
capability platform,
we build this
Multi-Model database
where you can keep
different kind of data.
You can keep a document data,
you can keep graph data,
column family, or a key value.
>> So, I think this is
a really important point
because I think often
misunderstood with Cosmos.
Because a lot of times,
people think Cosmos DB,
that's a no SQL document
database and it is,
but you have these
other options, too,
if you want to use that column
great, key-value, great.
Even graph storage, it
can do all of that.
You get to be in control.
>> Exactly. If you will
see our competition,
you have to have
different database products
to keep a graph database,
keep a JSON document,
or column family.
Here in Cosmos DB,
everything is in one database,
so you don't have to learn
four different databases,
different technologies,
and languages,
and client libraries and all.
It's all into one.
>> Right.
>> On top of this,
we have different
client libraries to
interact with this
Multi-Model databases.
We have our own SQL
client libraries
to deal with documents,
and they are in
different languages:
CSharp, Java, Python, JavaScript.
For Cassandra and Mongo,
you can use their
libraries itself,
so you don't have to
learn anything new.
If you are a Mongo user and you
bought the Mongo data
in Cosmos DB,
you don't have to
learn anything new.
>> So, you're telling
me, if I'm a developer
that currently uses MongoDB,
I don't even have to use any of
these Azure client libraries,
I can use my existing Mongo API?
>> Exactly.
>> Point my connection on Cosmos.
>> Right.
>> And all of a
sudden now I have,
if I'm in Azure
Government, National
geo redundancy and
multiple regions.
>> Exactly.
>> I didn't have to change
any code as a developer?
>> No code change, you have
to just change
the connection string.
We have many demos on the web
where we showed this,
that you use Mongo tools,
Mongo export, Mongo import,
and move that Mongo data
into Cosmos DB,
change the connection string,
and your application
will keep working.
>> Okay. Cool. So, I've
heard you've talked
about Geo distribution
a little bit,
and GEO redundancy,
can you give us
a little bit more
information on that topic?
>> True. So, when I
say your data is
globally-distributed,
you know that Azure data
centers are almost,
I think in 50 or 52 places
we have Azure Data Center.
Cosmos DB is airing zero service.
By that, we mean
wherever Azure is,
Cosmos DB will be.
So, your data, you
can distribute to all
this 52 data centers,
and they are growing every day.
>> Or in Azure Government,
the six data centers we have,
Cosmos DB is there as well.
>> True. True. With that,
you have this option to
manually or automatically,
you can fail over from
one region to another region.
So, let me explain that through
a couple of slides which
will make you understand
it very simply.
>> Okay.
>> So, as you can see,
that when you write the data,
the data is written
in four copies in
a data center itself.
So, as you can see in the slide,
that you have a collection
and I have this three partitions,
and your data is written
four copies of it.
What we mean by always on,
that if there's a problem
on the partition,
there will be no hiccups
on your application.
Your application
will keep working.
Because I still
have three copies,
I can have the column,
and then your application will
keep working when the disk
will be repaired.
Behind the scene, the data will
be distributed. You
will know nothing.
>> So, if I look at
this diagram here,
I see US Gov Virginia,
that's my primary
writable region.
>> Right.
>> I've got Texas and Arizona.
Those are my secondary
read location.
>> Right.
>> You're saying even
if we have one of
the partitions on Virginia,
I'm still not because
we will get a blip.
>> Yes.
>> Because it'll be
repaired in the background.
>> It will be repaired
in the background,
and the applications
will keep working.
As we've shown here,
that you can write in one region
and read it from
all different regions.
>> Okay.
>> Now, if there's a problem
and whole of the partition
is gone, even then,
there will be
no effect to the user,
and that's why we call it
always on because now,
the call will flip
automatically to the Texas.
>> Okay.
>> Data Center.
This all you control.
I'll show you on the portal,
how you distribute this data
and how you control that,
what should be my preference,
which datacenter I should flip
to when there's a problem?
>> All right.
>> In the worst case,
if we say that whole
datacenter is gone away.
Even then your user may just feel
a 100 millisecond or
150 millisecond delay but
the application
will keep working.
So, that's the beauty of
this global distribution thing.
>> So in this case, then,
Texas for example
might switch to be
my primary datacenter
or reach us.
>> Yes, okay. No matter what
happens your applications will
keep working, data is saved.
>> I'm just trying to think as
an engineer of
the engineering feat that I
would have to do
if I wanted to do
something like this
on prem myself.
>> Oh my God.
>> I don't think I
want any part of it.
>> True.
>> Okay. So Microsoft is doing
this for me. Okay, great.
>> Yeah, exactly. Now let
me show you on the portal.
>> Okay, great.
>> So, as you can see
in this screen that we
are on the portal looking
at the Cosmos DB.
I already have two collection,
will go in detail how to create
this collection later on.
But I want to quickly show you,
how you can replicate
this data globally.
So, today here I'm just showing
you four datacenter because it's
Azure Gov but if you are
outside of the government
you will have options all
around the world
like 52 datacenters.
>> But this is a good picture
actually because it shows us.
Yes, you're in Azure Government.
Here are the Azure Government
regions where we have Cosmos DB.
>> Exactly, and as you can see,
when you take your mouse
it shows you the name,
and Texas, and here it is
USDoD Central, and Arizona.
Just to distribute this,
you just go ahead and click
on these datacenter
and that's it.
It's unbelievably simple that
you can distribute your data but
just by a click of a mouse.
>> Yes, I see at the bottom,
it says Texas as the right
region but you click Arizona,
and now all of the sudden Arizona
showing us a read region,
that's awesome.
>> As a read region, that's true.
Then, you can just go ahead
and save and that's it.
>> Okay.
>> Nothing, no more
configuration is needed.
Nothing you have to do.
>> Right.
>> If you see a file just
discarded quickly so I can see
this other menus lighter that
I have automatic failover.
By that we mean is
if your application is
running and there's
a problem in the datacenter,
automatically
the application will
move to the next
datacenter again.
Nothing is needed from
your end to enable this thing.
Then, we have
a manual failover where
you want to do a test
and you want to say,
"How this failover takes place?"
Then, you can use this option
to manually failover.
>> So, if I don't trust
the automatic failover
I can always
test it and gain myself
some peace of mind.
>> Right.
>> Okay, great.
>> Okay. So that's one thing.
The next thing I want to
show you, here again,
we differentiate ourselves from
the competition, the
consistency level.
If you see no sequel,
market and all the product
which we have in the market,
they generally have
two consistencies.
They have strong consistency
or eventual consistency,
and you have to
choose one of them.
In the beauty of this
what Cosmos DB has done,
comes more in focus when you
start developing an application,
and later on you realize, "Oh,
this consistency level is not
good enough, I want to change."
Here you have an option that
you can change this
consistency level too.
So, as you can see there's
just this five radio
buttons are there.
You can just click on them,
and you can choose one of
the consistency level.
So, let me quickly
explain what do I
mean by all these different
consistency level.
Strong consistency means when
you choose strong consistency
by that it means when you
get the act back from
your right you should
be rest assured that
your data is strongly
consistently written on
their data on the desk.
>> So, no stale reads,
that kind of thing?
>> No stale reads. You don't
have to worry about that
if you lose that data,
it's really written the data.
So, that's strong consistency.
Now, we do have a strong
consistency in multi-region.
Multi-region strong
consistency is also
there which is in
preview but very soon
we'll be enabling.
So, you can have a saying,
"If I write in US West,
I want it consistently
written in US East."
That's also an option.
>> Okay.
>> Second is Bounded Staleness
where you say that,
"I'm fine to have my data
stale by few minutes or seconds."
> >For some applications
that's perfectly appropriate.
>> Yes. Because
what happens if you
say I want a strong
and multi-region,
you have to pay the price
of the round trip.
So, it will cost you 200 or
150 milliseconds
for the round trip.
But you don't want to pay
that price but you still
want that data consistently
written in different region.
So, then you will use
Bounded Staleness.
Next one is the Session.
Session is very simple,
like whatever you write that's
all you're going to read.
So, it's bounded to your session.
Next one is Consistent Prefix.
By Consistent Prefix, we
mean that you will
see the data on
the other side in the same
sequence that data is written.
So, if I have written A, B,
and C, on the other side
also you will see A, B,
and C. This becomes
very important
if you are writing
a chat application where
people are chatting.
So, if you have Consistent
Prefix set by that you
guarantee that you will never
see an answer before
the question.
>> Okay.
>> Right. That's Consistent
Prefix and eventually,
the data will be consistent.
But if everything is okay,
like there's no a breakage in
the network pipe and all, again,
this eventual consistency also
walks with almost speed of
light in few milliseconds you
will have the data on that.
>> So, those are really clear
explanations and I
notice not only that,
but you can click on
any one of these and
the portal will
actually show you.
>> Exactly.
>> A brief description
of what each
of those are. So,
that's very cool.
>> Right. So let me show you,
how you can write code
to use Cosmos DB.
So, this is I'm showing
you a C# chord here.
First thing is obviously
you have to go
and get reference to
our client libraries.
Then, once you reference
the client library,
code is very simple, it's
just couple of line.
There's a lot of code here,
but I'm just zooming in to
the main code which is
creating the client library,
and then how we will use it,
how we will use the client
library to insert some data.
>> Okay.
>> So, if you see we just view up
a documentclient library and
for that we just
need three things.
What is the endpoint?
What is the authkey and
the connectionpolicy?
Right. Just three
things. Let's look
at each of them,
one after another.
So, if I show you my App config,
here I just define
my four things.
What is my endpoint?
This is you will get
from the portal.
>> We see the dot has
a documents.azure.us.
So, that's Azure government
as opposed to Azure commercial.
>> Exactly. Then,
this is your authkey.
Then, you just put your database
name and collection name.
If you see the code back here,
that's what I'm doing
using the endpoint, authkey,
and connectionspolicy.
>> So, if I look at this line
of code here, on line 160,
it's actually the exact
same line of code
that I would do on
Azure commercial,
I do an Azure government.
>> Yes.
>> No changes
sort of developer is just
that one connection
difference and that's it.
Only change for Azure Government.
>> True, exactly.
The same code is running between
Go and public cloud.
So, there's no change.
>> Yeah, cool.
>> So, now once the client is
created what you will do is,
here just one line of code
where you say,
CreateDocumentAsync.
Then, you give the collectionUri,
and I will show you what this
collectionUri and the data.
>> So, when we create
document we're
really basically saying
insert a record.
>> Inserted a record.
>> Okay.
>> Right, exactly.
So, this data is
defined as a IoTData class.
>> It could be anything we want.
>> It can be anything,
and it's plain vanilla,
just C-sharp class
where you're just
defining all these
properties on it.
Once you define that,
you can use the collectionUri.
What is collectionUri?
It's nothing
but a unit database
and the collection.
So, let me show you.
>> I can almost
conceptually think
of it like a table name, sort of?
>> Exactly.
>> Okay.
>> Exactly. This is how I
create my collectionUri right?
I am saying UriFactory given
database and collection.
>> Okay.
>> Right. It's exactly like
database name and then the table.
So, one line of code
to create that line,
one line of code to
insert the data.
>> Awesome.
>> These are the two line.
So, now let's see,
let's run this code again.
Here, this code it
just creating the database
if it's not there.
As you can see, once you have
the client library you just say
CreateDatabase, and it
creates the database.
>> So, I can create a database
from the portal if I want,
or I can create a database
from C# if I want?
>> C#.
>> Okay, great.
>> These client libraries
I'm showing you in C#
but you can use JavaScript,
Java, Python, or any
other kind of chair.
>> All right. Let's run it.
>> So, let's run it and see.
So, before I run it,
let's go to the portal
and see it's empty here.
>> Yeah.
>> This is my database
and this my collection.
Now, let me run this.
>> So it looks like this is
inserting multiple records.
>> This is inserting
multiple records.
Now, let's go to the portal and
see if I find this document.
>> Here it is. awesome.
>> They have inserted.
>> All right. So
pretty easy to do.
>> Very easy to do
that and as you
can see your documents
are showing up here.
>> I didn't have
to create schemas
or altered table statements,
or anything like that I just
had some C#, boom, insert.
>> As you know that it's
a no-sequel search
schema agnostic.
You can keep inserting
the document with
different schema.
>> Okay.
>> So, everything will work.
>> Very well. This has
been a great introduction
to Cosmos DB on Azure Government.
We've talked about
GO distribution,
talked about Multi-Model,
different Staleness Levels that
are supported with consistency,
and we've even seen the portal
as well C# example.
So, a great
introduction. Thank you.
>> Thank you.
>> This has been
Steve Michelotti of
Azure Government Engineering with
Refat Sharooz of
Cosmos DB Engineering talking
about Cosmos DB on Azure
Government. Thanks for watching.
