Welcome to this lesson on OCI Architecture.

In this lesson, we will cover the core

constructs of OCI's physical architecture, starting with regions.

High-Level Architecture:
===================
1. Region - is a localized geographic area comprising of one or more availability
domains.
2. Availability Domains - are one or more fault tolerant data centers located
within a region, but connected to each other by a low latency, high bandwidth
network.
3. Fault Domains - is a grouping of hardware and infrastructure within an
availability domain to provide anti-affinity. So think about these as logical data
centers.

We looked at it in the previous lesson. Today OCI has a massive geographic

footprint around the world with multiple regions across the world.
And we also have a multi-cloud partnership with Microsoft Azure. And we have a
differentiated hybrid cloud offering called Dedicated Region Cloud@Customer.

But before we dive into the physical architecture, let us look at how do you choose
a region?
===========================================================================
1. Lowest latency and highest performance.
-------------------------------------------------------------
First thing is choosing a region, you choose a region closest to your users for
lowest latency and highest performance. So that's a key criteria.

2. Data residency and compliance requirements.

---------------------------------------------------------------------
The second key criteria is data residency and compliance requirements.
Many countries have strict data residency requirements, and you have to comply
to them.
And so you choose a region based on these compliance requirements.

3. Service Availability.
---------------------------
The third key criteria is service availability.
New cloud services are made available based on regional demand at times,
regulatory compliance reasons, and resource availability, and several other
factors.
Keep these three criteria in mind when choosing a region.

So let's look at each of these in a little bit more detail.

Availability Domains
================
Availability domains are isolated from each other, fault tolerant, and very
unlikely to fail simultaneously.

Because availability domains do not share physical infrastructure, such as power or

cooling or the internal network, a failure that impacts one availability domain is
unlikely to impact the availability of others.

So as you can see in this graphic here, a particular region has three availability
domains.
One availability domain has some kind of an outage, is not available. But the other
two availability domains are still up and running.
Fault Domains
===========
We talked about fault domains a little bit earlier. What are fault domains?
Think about each availability domain has three fault domains. So think about fault
domains as logical data centers within availability domain.

So as you can see in the picture here, we have three availability domains, and each
of them has three fault domains.
So the idea is you put the resources in different fault domains, and they don't
share a single point of hardware failure, like physical servers, physical rack,
type of rack switches, a power distribution unit. You can get high availability by
leveraging fault domains.

We also leverage fault domains for our own services. So in any region, resources in
that most one fault domain are being actively changed at any point in time. This
means that availability problems caused by change procedures are isolated at the
fault domain level. And moreover, you can control the placement of your computer
database instances to fault domain at instance launch time. So you can specify
which fault domain you want to use.

So what is the general guidance? The general guidance is we have these constructs,
like fault domains and availability domains to help you avoid single points of
failure. We do that on our own.

So we make sure that the servers, the top of rack switch, all are redundant. So you
don't have hardware failures or we try to minimize those hardware failures as much
as possible. You need to do the same when you are designing your own architecture.

So let's look at an example. You have a region. You have an ability domain. And as
we said, one AD has three fault domains, so you see those fault domains here.

So first thing you do is when you create an application you create this software-
defined virtual network. And then let's say it's a very simple application. You
have an application tier. You have a database tier.

So first thing you could do is you could run multiple copies of your application.
So you have an application tier which is replicated across fault domains. And then
you have a database, which is also replicated across fault domains.

Why do you do that? Well, it gives you that extra layer of redundancy. So something
happens to a fault domain, your application is still up and running.

Now, to take it to the next step, you could replicate the same design in another
availability domain. So you could have two copies of your application running. And
you can have two copies of your database running.

Now, one thing which will come up is how do you make sure your data is synchronized
between these copies? And so you could use various technologies like Oracle Data
Guard to make sure that your primary and standby-- the data is kept in sync here.
And so that-- you can design your application-- your architectures like these to
avoid single points of failure. Even for regions where we have a single
availability domain, you could still leverage fault domain construct to achieve
high availability and avoid single points of failure.

Let's summarize what we learned in this lesson. So we looked at region. Region

comprises of availability domains. Availability domains comprise of fault domains.

So let's look at the inside out view. So first, let's start with fault domain.
Fault domain provide protection against failure within an availability domain.
Availability domain themselves provide protection from entire availability domain
failures, particularly in a multi-AD region. And then you have this concept of
region pair, where in every country we operate or most of the countries we operate,
we have at least two data centers. So you could use the second data center for
disaster recovery or backup or it also helps you with-- to comply with data
residency and compliance requirements. And then not only this, we also have SLAs on
availability, management, and performance.

To recap, we looked at the physical architecture of OCI with regions which are
geolocations. We looked at availability domains. Every region has three
availability domains.

And then every availability domain has three fault domains. So use these
architectural constructs to design your applications which are highly available,
and avoid single points of failure. Thanks for watching.