Instance: 

A bare metal or virtual machine (VM) host running in the cloud. Oracle Cloud
Infrastructure Compute lets you provision and manage compute hosts, known as instances. You
can launch instances as needed to meet your compute and application requirements. After you
launch an instance, you can access it securely from your computer, restart it, attach and detach
volumes, and terminate it when you're done with it.

Instance Type:

 Standard shapes: Designed for general purpose workloads and suitable for a wide
range of applications and use cases. Standard shapes provide a balance of cores,
memory, and network resources. Standard shapes are available with Intel or AMD
processors.

 DenseIO shapes: Designed for large databases, big data workloads, and applications
that require high-performance local storage. DenseIO shapes include locally-attached
NVMe-based SSDs.

 GPU shapes: Designed for hardware-accelerated workloads. GPU shapes include Intel

CPUs and NVIDIA graphics processors.

 High performance computing (HPC) shapes: Designed for high-performance

computing workloads that require high frequency processor cores and cluster
networking for massively parallel HPC workloads. HPC shapes are available for bare
metal instances only.

Block Storage: Block storage is an approach to data storage in which each storage volume acts
as an individual hard drive that is configured by the storage administrator.  In the block storage
model, data is saved to the storage media in fixed-sized chunks called blocks. Each block is
associated with a unique address, and the address is the only metadata assigned to each block.  

Storage Type:

 Block Volume: Lets you dynamically provision and manage block volumes that you can
attach to one or more Compute instances. See Overview of Block Volume for more
information. For steps to attach block volumes to Compute instances, see Attaching a
Volume and Attaching a Volume to Multiple Instances.
 File Storage: A durable, scalable, secure, enterprise-grade network file system that you
can connect to from any Compute instance in your virtual cloud network (VCN).
See Overview of File Storage for more information.
 Object Storage: An internet-scale, high-performance storage platform that lets you
store an unlimited amount of unstructured data of any content type. This storage is
regional and not tied to any specific Compute instance. See Overview of Object
Storage for more information.
 Archive Storage: A storage platform that lets you store an unlimited amount of
unstructured data of any content type that doesn't require instantaneous data retrieval.
This storage is regional and not tied to any specific Compute instance. See Overview of
Archive Storage for more information.

Block volume: A detachable block storage device that allows you to dynamically expand the
storage capacity of an instance.

Bare Metal: A bare metal compute instance gives you dedicated physical server access for
highest performance and strong isolation.

Virtual Machine: A virtual machine (VM) is an independent computing environment that runs
on top of physical bare metal hardware. The virtualization makes it possible to run multiple VMs
that are isolated from each other. VMs are ideal for running applications that do not require the
performance and resources (CPU, memory, network bandwidth, storage) of an entire physical
machine.

An Oracle Cloud Infrastructure VM compute instance runs on the same hardware as a bare
metal instance, leveraging the same cloud-optimized hardware, firmware, software stack, and
networking infrastructure.

Overview of the Database Service

The Database service offers autonomous and user-managed Oracle Database cloud

solutions. Autonomous databases are preconfigured, fully-managed environments that
are suitable for either transaction processing or for data warehouse workloads. User-
managed solutions are bare metal, virtual machine, and Exadata DB systems that you
can customize with the resources and settings that meet your needs.

Overview of Autonomous Databases

Oracle Cloud Infrastructure's Autonomous Database is a fully managed, preconfigured

database environment with two workload types available, Autonomous Transaction
Processing and Autonomous Data Warehouse. You do not need to configure or manage
any hardware, or install any software. After provisioning, you can scale the number of
CPU cores or the storage capacity of the database at any time without impacting
availability or performance. Autonomous Database handles creating the database, as
well as the following maintenance tasks:

Exadata DB Systems

Exadata DB systems allow you to leverage the power of Exadata within the Oracle Cloud
Infrastructure. An Exadata DB system consists of a base system, quarter rack, half rack, or
full rack of compute nodes and storage servers, tied together by a high-speed, low-
latency InfiniBand network and intelligent Exadata software. You can configure
automatic backups, optimize for different workloads, and scale up the system to meet
increased demands.

Bare Metal and Virtual Machine DB Systems

Oracle Cloud Infrastructure offers 1-node DB systems on either bare metal or virtual

machines, and 2-node RAC DB systems on virtual machines. If you need to quickly spin
up a DB system for development or testing purposes, a special fast provisioning 1-node
VM system is available.

Overview of Load Balancing

The Oracle Cloud Infrastructure Load Balancing service provides automated traffic

distribution from one entry point to multiple servers reachable from your virtual cloud
network (VCN). The service offers a load balancer with your choice of a public or private
IP address, and provisioned bandwidth

Public Load Balancer

To accept traffic from the internet, you create a public load balancer. The service assigns
it a public IP address that serves as the entry point for incoming traffic. You can
associate the public IP address with a friendly DNS name through any DNS vendor.

A public load balancer is regional in scope. If your region includes multiple availability

domains, a public load balancer requires either a regional subnet (recommended) or
two availability domain-specific (AD-specific) subnets, each in a separate availability
domain. With a regional subnet, the Load Balancing service creates a primary load
balancer and a standby load balancer, each in a different availability domain, to ensure
accessibility even during an availability domain outage. If you create a load balancer in
two AD-specific subnets, one subnet hosts the primary load balancer and the other
hosts a standby load balancer. If the primary load balancer fails, the public IP address
switches to the secondary load balancer. The service treats the two load balancers as
equivalent and you cannot specify which one is "primary".

Whether you use regional or AD-specific subnets, each load balancer requires one
private IP address from its host subnet. The Load Balancing service supplies a floating
public IP address to the primary load balancer. The floating public IP address does not
come from your backend subnets.

If your region includes only one availability domain, the service requires just one subnet,
either regional or AD-specific, to host both the primary and standby load balancers. The
primary and standby load balancers each require a private IP address from the host
subnet, in addition to the assigned floating public IP address. If there is an availability
domain outage, the load balancer has no failover.

Private Load Balancer

To isolate your load balancer from the internet and simplify your security posture, you
can create a private load balancer. The Load Balancing service assigns it a private IP
address that serves as the entry point for incoming traffic.

When you create a private load balancer, the service requires only one subnet to host
both the primary and standby load balancers. The load balancer can be regional or AD-
specific, depending on the scope of the host subnet. The load balancer is accessible only
from within the VCN that contains the host subnet, or as further restricted by your
security rules.

The assigned floating private IP address is local to the host subnet. The primary and
standby load balancers each require an extra private IP address from the host subnet.

If there is an availability domain outage, a private load balancer created in a regional

subnet within a multi-AD region provides failover capability. A private load balancer
created in an AD-specific subnet, or in a regional subnet within a single availability
domain region, has no failover capability in response to an availability domain outage.

Overview of Object Storage

Oracle Cloud Infrastructure offers two distinct storage class tiers to address the need for
both performant, frequently accessed "hot" storage, and less frequently accessed "cold"
 storage. Storage tiers help you maximize performance where appropriate and minimize
costs where possible.

 Use Object Storage for data to which you need fast, immediate, and frequent access. Data
accessibility and performance justifies a higher price to store data in the Object Storage tier.

 Use Archive Storage for data to which you seldom or rarely access, but that must be retained
and preserved for long periods of time. The cost efficiency of the Archive Storage tier offsets the
long lead time required to access the data. For more information, see Overview of Archive
Storage.
 OBJECT
 Any type of data, regardless of content type, is stored as an object. The object is
composed of the object itself and metadata about the object. Each object is stored in a
bucket.
 BUCKET
 A logical container for storing objects. Users or systems create buckets as needed within
a region. A bucket is associated with a single compartment  that has policies  that
determine what actions a user can perform on a bucket and on all the objects in the
bucket.
 COMPARTMENT
 Primary building block used to organize your cloud resources. When your
tenancy is provisioned, a root compartment is created for you. You can then
create compartments under your root compartment to organize your resources.
You control access by creating policies that specify what actions groups of users
can take on the resources in those compartments. An Object Storage bucket can
only exist in one compartment.
Cloud Concepts:
Hi, everyone. Welcome to this course on Oracle Cloud Infrastructure fundamentals. This is the first l
ecture in the fundamentals series focused on core cloud concepts. My name is Rohit Rahi, and I'm p
art of the Oracle Cloud Infrastructure team.

So in this particular lecture, let's look at what it means to use cloud. Cloud is very different than on-
premises infrastructure and environment. So we'll look into that. What does it mean to have different 
service models in cloud? We'll look into that.

What are some of the common cloud terminology, like elasticity, fault tolerance. We'll go with those. 
And then what does it mean from a business sense to use cloud? So we'll talk about capital expendit
ure and operational expenditure. So let's get started.

First, the best place to find the definition of cloud computing is through the National Institute of Stand
ards and Technology. And even though I have given a link at the bottom, so you can find-- in 2011 th
ey came up with the standard definition of cloud computing. And even though it is a bit dated, going 
back to 2011, the definition they came up with is still very relevant.

And just to close on that, they have updated those standards in years since 2011. And you can alwa
ys find the latest out in the web. But let's go over their definition. And it actually closely resembles m
ost of the public cloud environment.

So the first thing a cloud needs to have is this concept of on-demand self service. You should be abl
e to provision computing capabilities as needed without requiring human interaction with a service pr
ovider. So you don't have to go to a service desk or a help desk and request a virtual machine, whic
h takes a couple of days for IT to provision for you. It should be all based on on-demand and self-
service.

That the cloud service should be available through broad network access using standard mechanism
s, the web standards. So this, again, says that you should be able to access these using self-service 
mechanism. And it should be as simple as using, let's say, a web console.

In a cloud provider environment, the resources need to be pooled. What it means that resources are 
pooled to serve multiple customers, using this model called multi-tenant. And we'll look into that as w
e get into subsequent lectures, with different resources dynamically assigned and reassigned accord
ing to demand.

Why do you do this resource pooling. Well, you pool these resources, you make them available to cu
stomers. So you can save money as a provider.

And then if
the customer needs more resources, you can give them. And some customers need less resources, 
so you can take away the resources. So this dynamic pooling is a core essence of cloud.

The fourth one is rapid elasticity which actually ties closely with the pooling concept. Capabilities can 
be elastically provisioned and released in cases that automatically to scale rapidly outward and inwa
rd, depending on your demand. So if your demand increases, you can get more resources.
[?
You'll ?] have elasticity. If the demand is not that much, you can release those resources. So this go
es, again, tied closely with resource pooling concept.

And then finally, the services can be monitored, controlled, and reported, providing transparency for 
both the provider and consumer. So this concept of pay-as-you-go, or consumption-based pricing, w
here what would you consume, you only pay for those resources. And you have complete visibility in
to what you're using and what you're paying for. So these five things, the five broad areas, this list co
vers is actually pretty true for a public cloud environment.

All right, so let's look at some of the service models which are prevalent. The one that you are familia
r with is the traditional IT. In this case, your IT organization manages everything end-to-end. So whet
her it's your core infrastructure, or whether it's some of the higher level things, like your middleware a
nd runtime, everything is managed by your IT organization.

So the first model, about which we talk a lot more detail subsequently, is infrastructure-as-a-service-- 
sometimes also referred to as IaaS. So in this particular model, the cloud provider manages the core 
infrastructure. So what that means is the cloud provider has data centers. The physical infrastructure
, the servers, the networks, the storage machines, even the virtualization layer, is all managed by the 
cloud provider and delivered as a service.

And you, as a customer, are responsible for things like your operating system, your middleware, you
r apps, and your data. Those are all your responsibility. So a good example, you'll get a virtual machi
ne in the cloud, you'll have complete control over it. You could install whatever operating system you 
want, whatever application you want. So that's a good example of an infrastructure as a service offer
ing.

The second model in the cloud is platform-as-a-service. So in this case, the provider is responsible f
or managing a little bit more than infrastructure-as-a-service. So the provider is also managing things 
like your runtime.

So let's say you have a Java runtime, or you have a Node.js runtime. And what do you do as a custo
mer is, you can write your applications. And you could run them on the platform without worrying abo
ut the underlying virtual machine. You don't get a VM. You just get a runtime environment.

A classic example here are serverless offerings. So we, at Oracle, have an offering called Oracle Fu
nctions. And that gives you various runtimes. And you can run your code on those runtimes. And we 
take care of things like scalability, high availability, etc.

Now, one of the big differences between this and the infrastructure model is it takes your pay-as-
you-go pricing to even the next level. You have this consumption-based pricing. So your functions ru
n only for a certain period, and you only pay for the invocation. It's not like your virtual machine is run
ning based on an hourly billing model, where even if you don't use it, you're still paying for it. So Ora
cle Functions serverless in general is a good example of platform as a service.

And then finally, we have software-as-a-service, where the vendor delivers everything as a service, a
nd all the components, all the layers, as a service. So a good example here would be ERP-- would b
e a supply chain manage it the cloud, or a human capital management SaaS offering in the cloud. Or
acle has a bunch of these SaaS offerings, as other providers do.
So this is again and area where there are lots of offerings where you, as a user, are just interacting 
with that particular SaaS offering. You're not getting the VMs. You're not writing your own code for yo
ur applications.

All right, so let's look at another key construct. Now we are getting to some of the cloud terminology, 
which is around high availability. This is a core concept you really need to understand.

Computing environments configured to provide nearly full-time availability are known as high-
availability systems. So that's basically what it means. What it means is these systems have redunda
nt hardware and software that makes the system available, despite any kind of failure.

Well-designed high-availability systems avoid having single points of failure. And we'll talk more abo
ut this in our next module. But the idea is, because you have redundancy built in the system, you do
n't have a single place of dependency where things can fail.

So a classic example is using a load balancer. So let's say you have two web servers here, and you 
put a load balancer in front of them. And so if the web traffic is coming in-- let's say you are running s
ome kind of website here. So if the web traffic is coming here, the fact you have a load balancer right 
in front of the web servers gives you some kind of redundancy.

Now, when a failure occurs in these higher availability systems, a failover process moves processing 
performed by the failed component to the backup component. The more transparent the failover is
to the end users, the higher the availability of the system. So in this case, what happens is, let's say t
his particular web server goes down.

This web server is still running. And your website, whatever you're running here, is still up and runnin
g. If let's say you had only one server running here, if this ever had gone down, that site would go do
wn. So this is a very common basic example of making a system and making it highly available.

The next concept, which you need to understand in cloud is disaster recovery. It involves a set of poli
cies, tools, and procedures to enable the recovery or continuation of your technology infrastructure a
nd systems. Now, the two key definitions which come up all the time are recovery point objective and 
recovery time objective. So what do these things mean?

At a very high level, recovery time objective basically means how much downtime your business can 
tolerate. Recovery point objective basically means how much data loss or transaction loss can your 
business tolerate. Let me give you an example.

Let's say your RTO is 24 hours, and so is your RPO same as RTO-- 24 hours. Now, they mean very 
different things just based on what they actually imply. So let's look at that.

Let's say your RTO is 24 hours. This means that if a disaster happens, you are OK for having a dow
ntime of 24 hours. So let's say your IT organization and your processes in place are there so that yo
u can recover within, let's say, eight hours. So your recovery happens within eight hours. You are O
K, because you can tolerate a 24-hour downtime.

Now, instead of eight hours, if the recovery takes 48 hours, that is not OK, because your RTO is less 
than that. You cannot tolerate a 48-hour downtime. Let's look at the
case of RPO. Most of the businesses would do some kind of backup.
So let's say you do a backup at 12:00 AM, in midnight, and then the disaster happens at 8:00 AM. S
o what happens in this case is your last good backup was done eight hours back. So this is the amo
unt of data which you have lost, because your last backup happened at midnight. So in this case, let'
s say your RPO is 24 hours. You are still OK because you have only lost eight hours worth of your b
ackup data.

Now imagine if your RPO is 24 hours-- let's say your RPO was, instead of 24 hours, lets say it
was four hours. Now, in that case, this eight-hour loss is not good, because in that case, you have lo
st more data than your business can tolerate. So again, understand these core concepts around [IN
AUDIBLE] and [INAUDIBLE] are relevant when you talk about cloud.

Let's look at some of the other cloud terminology. So the first one here is fault tolerance. Fault tolera
nce describes how a cloud vendor ensures minimal downtime for their own services. So for example, 
we looked at this previous example before, and we said avoid single points of failure. So the fact that 
you have a web server here ensures that you don't have a single point of failure.

But what about this load balancer? It is a single point of failure, because if the load balancer dies, ba
sically, the website dies. So what we do in Oracle, and other cloud providers, is we manage a standb
y copy of the load balancer. So if there is an issue with this load balancer, we can switch the traffic to 
this standby load balancer. And in subsequent lectures, we will look into how we do fault tolerance fo
r every service, whether it's storage services, it's database services, compute services, etc.

Now, another concept which is relevant in cloud is scalability. Now, there are two kinds of scalability 
which are there. One is called horizontal scaling. It is also called scaling out.

So what it means is, you have a server here. Let's say you want to add more servers. So this is your 
scaling out. And along with that, suppose if you don't need these [? few ?] servers, you
could remove them. And you have this concept of scaling in.

The other kind of scaling is called vertical scaling. And basically, it means that if you have a machine 
running here, you could always get a bigger machine and a bigger machine, and so on and so forth. 
And if you don't need a bigger machine, you can always go to a smaller size, smaller [?
shape. ?] So scaling up or scaling down.

The next concept is elasticity. And similar to scalability, it's the ability to quickly increase or decrease 
resources. Not just limited to virtual machines, it can be your storage.

It can be your database. It can be any other load balancer, etc. So the idea is, if you throw a lot more 
traffic to my load balancer, my load balancer should be able to scale seamlessly and [INAUDIBLE].

Now the final topic in this lecture is around cloud economics. Now, I'm not getting deep into every as
pect of how the costs changes between on-prem devices and cloud. But the thing to note here is CA
PEX and OPEX, the most common cloud terminologies.

So capital expenditure, or CAPEX, is the money an organization or corporate entity spends to buy, m
aintain, or improve its fixed assets, such as buildings, vehicles, equipment, or land. So a good exam
ple of CAPEX would be your data center. [INAUDIBLE] you need to spend money to build a data cen
ter. You fill that data center with equipment. So there is no capital expense involved with that.
An example of operational expenditure, or OPEX, is the ongoing cost. So for example, you might be-
- [INAUDIBLE] data center you are getting a power bill, a utility bill. That's an example of OPEX. The 
labor cost is an example of an OPEX.

And what makes cloud so interesting is it lets you trade CAPEX for OPEX. So instead of having to in
vest heavily in data centers and infrastructure in the cloud, you can pay only when you consume res
ources. So you don't have to do a massive capital intensive buildout, and you only pay for how much 
you consume-- the pay-as-you-go consumption based pricing. So it's a game-changer. That's one of 
the reasons, on the business side, cloud is so attractive.

All right, so we covered a lot of ground in this lecture. Let's just recap some of the core concepts we l
earned. Cloud computing, we talked about the different characteristics-- self-service, available to net
work, ability to pool resources, provide rapid elasticity, and ability to measure what you are using. Se
rvice models, we looked into infrastructure-as-a-service, platform-as-a-service, software-as-a-
service. And we looked at specific examples.

We looked at some of the core cloud terminologies-- high availability, disaster recovery, fault toleran
ce, scalability, and elasticity. And of course, there are more terms. But these are some of the commo
n ones you really need to understand. And then finally, we really quickly touched on cloud economic
s, what CAPEX is, what is OPEX, and why the cloud model is so much attractive from a business pe
rspective, because it lets you create CAPEX or OPEX.

Thank you for joining this lecture. In the next lecture, we'll talk about on the core high-availability desi
gn architectures in OCA. Thank you.

Oracle Cloud Infrastructure Architecture:

Hi, everyone. Welcome to this lecture series on Oracle Cloud Infrastructure Fundamentals. My name 
is Rohit Rahi. And I'm part of the Oracle Cloud Infrastructure team.

In this module, we will look at the physical OCI architecture and look at how it enables you to create 
highly available applications. So for the agenda for this module is something like this. We will first loo
k at regions. What does a region imply?

What are availability domains, a construct specific
to OCI? What are fault domains? How can you design your own highly available applications? And th
en what is this concept of compartments which is, again, a unique OCI construct?

Today we have 21 regions live around the world. And we also have 15 announced regions and plann
ed to go operational later this year. So by the end of 2020, Oracle Cloud Infrastructure is going to ha
ve a global footprint of 36 regions, worldwide.

And you can see some of the regions which are live today, commercial regions here around the worl
d. You can see some of the planned ones. You can also see some of the government regions availa
ble to some of the government customers. And we also have a partnership with Microsoft, where we 
connect some of our regions to Microsoft Azure. And you can see some of those regions here on the 
map as well.
Now, let's zoom in
in some of the details on the physical architecture of OCI. So the first one concept is, what is a regio
n? A region is a localized geographic area comprised of one or more availability domains. So think of 
regions as a metropolitan location, metropolitan area.

Within a region, you have this concept of availability domains. These are one or more fault-tolerant c
ompletely isolated data centers located within a region, but connected to each other by a low-
latency, high-bandwidth network. So within a region, you have three availability domains. And as you 
can see, they are connected by a very low-latency, high-bandwidth network.

Now, within an availability domain, you have this construct called fault domains. Fault domain is a gr
ouping of hardware and infrastructure within an availability domain to provide anti-affinity. Sometime
s we also refer to these fault domains as logical data centers within an AD.

And we'll look into all these in subsequent slides. At a high level, this is what the physical OCI archite
cture looks like. OCI physical architecture comprises of regions. Regions are comprised of availabilit
y domains. And availability domains have fault domains.

Now, we also have this concept of one AD region, one Availability Domain region. OCI has chosen t
o launch regions in new geographies with only one AD to increase our global reach quickly and opti
mize for reaching as many customers worldwide as possible. We are launching regions which have 
only AD.

Now, for any region which has only AD, a second AD or region in the same country will be made ava
ilable. We have committed to making it available within a year to give you options for disaster recove
ry and data residency. So for example, you can see some of the regions we launched in the beginnin
g have three ADs, in the US and Europe.

Now the regions we are launching now have one AD. But still what we are doing is we are giving you 
this idea of region pair. So in every geopolitical area, you will have region pairs. Like
in US, you have two regions. In Australia, you have two regions, Japan, and so on and so forth, so th
at you can still comply with your local regulatory and data residency requirements, but you could still 
do things around disaster recovery. And we'll talk about that as we go and talk about [?
HA ?] designs later on.

So how do you choose a region? It's rather straightforward. You choose a region based on location. 
You want to be closest to your users. Why? You want to give them lowest latency and highest perfor
mance, makes sense. Many times you have data residency and compliance requirements. Many cou
ntries have strict requirements around data residency. Your data cannot leave the country. European 
Union is a good example, and so on and so forth, many places. So you will choose a region to compl
y with your residency and compliance requirements.

And sometimes your choice is also dependent on service availability. Now, we commit to making ne
w cloud services available in every region, worldwide. But sometimes we make these available base
d on regional demand, regulatory compliance, resource availability, and so many factors. So it is pos
sible that we launch a service first in a few regions and then we roll it out to other regions. So these a
re some of the key considerations you will have when you have to choose region.

Now let's really zoom in and talk about some of the constructs we looked at earlier, specifically avail
ability domains and fault domains, because we talked about regions, what regions are, one-AD regio
ns, how you choose a particular region. So now let's talk about availability domains. Availability dom
ains, as we talked about a few slides back, are data centers completely isolated from each other, fau
lt-tolerant, and very unlikely to fail simultaneously.

So what happens in ADs if they don't share physical infrastructure such as power and cooling, they d
on't share an internal network? So what happens if a failure in an AD is unlikely to impact the availab
ility of the other? So what do I mean by that? Well, if you look at the region here, this particular regio
n is a multi-AD region. And you have three ADs, as we talked about, so AD1, AD2, AD3.

If AD1 is unavailable for some reason, your AD2 and AD3 are still operational. This might happen be
cause, let's say there is a power failure in that whole AD, though we have several mechanisms to pr
event that from happening, but let's say, you know, there
is a power failure, there is flooding, there is natural disaster like an earthquake or something. So it ju
st impacts that particular AD. It might be unavailable, but your other availability domains are still up, 
and running, and available.

So that's all pretty much on availability domains. What are these things called fault domains? Well, e
ach availability domain has three fault domains. Fault domains act as a logical data center within an 
AD. Usage of multiple fault domains reduces correlation of failures within and AD. We'll look into wha
t that means.

Resources placed in different fault domains do not share single points of failure, single points of hard
ware failure, specifically. So things like physical servers, physical RAC, top-of-RAC switches, or pow
er distribution units, these fault domains do not share. Now, what does that mean?

Let's look at the previous example. We have a region here. We have three availability domains. Eac
h of these availability domains has three fault domains. So you can see fault domain one, fault doma
in two, fault domain three here, so on and so forth, for availability domain two and availability domain 
three.

If fault domain one is not available for some reason, you still will have fault domain two and fault
domain three running. So literally what we have done is, in the region, first we had these availability 
domains which were data centers, physical data centers. And we carve out logical data centers withi
n them. And we are giving you three logical data centers within each of these ADs.

And there is a whole complex set of things we do to make sure that services are always up and runni
ng. And this is a fundamental course, so we are not talking about those. But just to give you an idea, 
the control plane and the data plane, we have running in every fault
domain for every service. So even if a particular fault domain goes down, you still have your control 
planes and data planes running, and so on and so forth. There are lots of complex things we are sort 
of just avoid for this particular lecture.

Now, when we change resources, we make sure that resources in, at most, one fault domain are ch
anged at a point in time. So it will never happen that we do a configuration here and we do the softw
are configuration here. We always roll it out one fault domain at a time.

This means that any kind of availability problems caused by changed procedure, which is really up to 
us, on us, are isolated at the fault-domain level. So it will never happen that we are trying to patch th
e hypervisor and the whole hypervisor for the whole AD goes down. We will isolate all this at fault-
domain level. And we have this concept of service cells, and lots of complexity around how we actual
ly architect around those that we are not going through in this lecture. But we make sure that we isol
ate the faults, these kind of configurations, changed procedures, at the fault-domain level.
Now, US customers control the placement of your compute and database instances at
the fault domain. And you could choose that at launch. What happens to storage? We do that for you
. And I'll talk about that in the storage modules. But you have a choice of using these logical data ce
nters.

The whole idea of a region having three availability domains and each availability domain having thr
ee fault domain is to give you this high-availability construct and let you avoid single points of failure. 
So you should design your architecture to deploy instances. So what does that mean? You should d
esign your architecture to deploy instances that perform the same tasks in different fault domains or i
n
different availability domains if you can leverage that, if you can leverage the multiple AD regions. W
hat does that mean?

Well, let's look at an example. So you have a region. Let's say you have one AD in that region, which 
are most of these new regions. You have three fault domains, which is always the case, whether it's 
one AD in a region or multiple ADs in a region. And AD will always have three fault domains.

Now, we haven't talked about networks and such. So we'll skip that for now. But let's
see you create a virtual network here. And you have a virtual machine or an instance, an application 
talking to a database.

So you have this kind of a setup, very simple setup. It can be like a web app or something. You have 
an app instance talking to a database. Now, in this case, you have a single point of failure.

If this application, this virtual machine dies, your application dies.
Or if the database dies, your application dies. So this is a single point of failure. The fact that we hav
e ADs and fault domains in a region is to let you avoid these single points of failure.

So how can you do that? First thing is you should always have multiple instances of the same type. 
So you have an application here. These are all stateless.

You actually have a second copy running. Running where? Running in the second fault domain. Don
't put it in the same fault domain, because this fault domain can be unavailable as well.

So choose the second fault domain. And you could do that, as I said in the previous slide. When
you are launching a compute instance or a database instance, you can choose your fault domain.

And now, instead of having one database, I can use something called a real application cluster RAC. 
And we have a managed service for that. So now you
are running this RAC, basically two copies of the database in a clustered environment across two fau
lt domains. So now if any of these things go down, are unavailable, you still have your app available. 
So this is what I mean by saying avoid single points of failure.

Now let's say you are in a geopolitical area where you get multiple ADs in a region. And we have so
me we saw in European Union and not in the US. So let's say you have a region which has multiple 
ADs. So in this case, you could actually take it take your design to the next level.

So
the first thing you could do is AD2 has the same construct, three fault domains. You create your appl
ication in a highly available environment. So in this AD, your application is highly available. You have 
two copies here. You have two copies here. And you know, if this goes down,
you're still [INAUDIBLE].

Now what you could also do is you could do-- you could leverage this thing called Data Guard which 
is, again, a managed service we offer. And this one does
your replication of your database, for example. And you could have different modes, switch over, pla
nned replication, unplanned replication, and unplanned migration.

And in this case, let's say if your whole AD1 becomes unavailable, you still have your application up 
and running, because you're replicating your data. And your AD2, you're running the same applicatio
n in your AD2, another AD within the region. So this is what we mean by saying avoid single points o
f failure. And the fact we give you these constructs of fault domain, availability domain is to help you 
avoid single points of failure and manage, design, create highly available applications.

All
right, so we looked into this in the previous slide, same thing here. In this case, you have single AD. 
So again, make sure that you're leveraging fault domains, because these, in essence, are your logic
al data centers within your single ADs.

All right, so just to recap what we just went over, now let's go from the opposite direction when we lo
oked at the region, availability domains, and fault domains in a few slides back. So in this one, first st
art with fault domains. What are fault domains?

Recap, well, they protect against failures within an availability domain. So for some reason, if there is 
a failure in
set of RACs, you can still have-- or set of infrastructure, you can still have your applications up and r
unning, leverage them. You have a choice when you instantiate your compute and database instanc
es. You could actually leverage fault domains.

In essence, these fault domains give you a logical data center within your availability domain. Then y
ou have the concept of availability domain, which protects from entire AD failure,
entire data center failure, so there is an earthquake, there
is a natural disaster, something gone wrong here. So you can still, if your region has multiple ADs, y
our application can still be highly available.

And then we have this concept of a region pair available in some regions worldwide and coming soo
n in the other regions, where if a whole region is unavailable, you can still move your applications to 
another region, copy your data search. And you can still recover from that disaster. And you can still 
maintain your data residency and compliance requirements. And on top of that, we also have SLAs o
n availability, management, and performance, so you can also leverage SLAs around these construc
ts.

All right, so let's look at one last thing, your design considerations, which is not really a physical desi
gn construct within OCI, but it's rather a logical design construct called compartments. What do we 
mean by compartment? Well, compartment is a logical collection of related resources. It helps you is
olate and control access to your resources. Remember, it's logical. It's not physical. So what do I me
an by that?

Now, we are not talking about data centers, and grouping of hardwares, fault domains, et cetera. We
're talking logical constructs. So logically, you have an account. Your tenancy is nothing but an
account. Tenancy is also called a root compartment. And I will talk about what that means.
So you have lots of resources running in your cloud environments. Let's say you have a bunch of net
work components. And you have a bunch of storage resources.

You could logically compartmentalize them in different compartments for-- why would you do that? 
Well, you want to isolate your resources. Maybe you want to have different resources going different 
places.

You want to control access. So not everybody should have access to your network resources, very f
ew people should have, the same with storage. So you have different requirements around who you 
want to access these resources. So you could create compartments. And you could start putting the
se resources in these compartment.

You have compute systems, which actually might go
in a completely separate compartment. The great thing here is, look at this example. You can nest th
ese compartments up to six levels deep.

Now, you might look at all this and say, well, this seems more complex. Why couldn't I just put everyt
hing in my root compartment, my tenancy? Yeah, of course you could do that. It's not a best practice
.

Why? First, because you want to isolate your resources. You don't want to put everything in one plac
e. And the related reason is, you want to control access. You want to give access to only specific pe
ople, to specific resources. If you put everything in one place, literally, you are opening up all your re
sources to every user within your environment.

So let's look at some of the core tenets of compartment. First thing is, each resource belongs to a sin
gle compartment. Each resource can only go to one compartment. It cannot go to multiple compartm
ents. That's number one.

Number two, resources can interact with other resources in different compartments. So in the previo
us example, this load balancer can be put in front of this compute resource. And this compute sourc
e can use this block storage. It's completely possible. Even though they live in different compartment
s, they can interact with each other.

You can always add and delete resources and compartments anytime. There are some restrictions a
round [?
ability ?] compartments. They have to be empty, et cetera, but you could do that. Resources can be 
moved from one compartment to another.

So it's a very flexible design. If you decide that resources need to be moved, you did an acquisition o
f a company, you want to group resources together, you could do that. And then resources from mult
iple regions can be in the same compartment-- so very important concept.

Compartment is a global construct, so you can still have resources in multiple regions, worldwide. An
d they go into the same compartment. And you can have access policies so people in different regio
ns are only restricted to resources in their specific regions. You could do that.

Compartments can
be nested-- we looked at that in the previous slide-- six levels deep. You can give group of users acc
ess to compartments by writing these things called policies. That's one of the key reasons why you h
ave compartments in the first place.
And then you can analyze cost and assign budget for resources and compartment, very important. Y
ou could roll up a compartment. And you could see how much it costs to run the resources in that co
mpartment. You could actually give a budget and say it should not exceed that particular threshold fo
r a particular compartment.

So that's it, folks. This module on OCI physical architecture, we looked at regions. We looked at wha
t availability domains are, what fault domains are, availability domains isolated from each other, fault-
tolerant, unlikely to fail simultaneously. Fault domains are logical data centers within an AD. And of c
ourse, you should use these constructs to avoid single points of failure and design-- and create highl
y available applications.

Finally, compartments is a logical construct. It's a collection of related resources. Why do you
do that? Isolate your resources and control access to your resources.

So that's it on this module on OCI physical architecture. Thank you for your time and joining this mod
ule. In the next module, we'll start looking at various OCI services. Thank you.

OCI Compute Services:

Hi, everyone. Welcome to this lecture series on Oracle Cloud Infrastructure foundations. My name is 
Rohit Rahi, and I'm part of the Oracle Cloud Infrastructure team.

In this particular module, we are going to look at the various compute services offered by Oracle Infr
astructure. Specifically, we are going to look into bare metal offerings-- virtual machine offerings. We'
ll look at various options around scaling, whether it's horizontal scaling or vertical scaling.

We'll look at Oracle Container Engine which is
a managed Kubernetes service, and then we'll look at Oracle Functions. So first, let's look at the cont
inuum of offerings we have in compute. And this is similar if you have gone through the storage mod
ule or the database module, or even the networking module for that matter.

You will see that we offer a wide range of services to meet your workload and application requireme
nts. So as you can see here, we have bare model as a service-- we'll talk about what that is. We hav
e dedicated virtual hosts, we have virtual machines, we have container engine and functions.

And all these are, in a way, a continuum of compute, and these are all different flavors of compute of
ferings. So start with bare metal. In this case, you basically get a physical server without any virtualiz
ation. And we'll talk more about what that is, but as you can see here, you have to manage the virtua
lization layer, you have to manage all the things which are on top of that-- operating systems, your ru
ntimes, et cetera.

In case of a dedicated virtual host, we do give you a machine which is dedicated to you, but you can 
run VMs on top of that-- it has virtualization. So this thing is now offered as a service. In case of virtu
al machines, well, a virtual machine is a guest on a host server with hypervisor based virtualization. 
This should be very familiar because it's a public cloud multi-tenant model.

And here you are managing things like operating systems, you are patching them, you
are upgrading them-- your runtimes, your code, et cetera. But you're not managing the virtualization l
ayer because as a cloud provider, we actually take care of that. In case of container engine, you are 
managing your code, and then of course you are managing your app container.

And app container, if you think about this, that is a container runtime which executes containers and 
manages container images on a node. The most widely known app container or container runtime is 
docker, but there are other options available as well. And then finally, you have Oracle Functions wh
ere you just write the code. You write the code in different languages, and you don't worry about any 
of the underlying infrastructure, and we take care of all that.

And you write your own code. You deploy your code-- you can call it directly, trigger it in response to 
any kind of event. And then you only build for the resources consumed during the execution. So this i
s really consumption based pricing.

And all of these-- basically, we have a pay-as-you-go model. But Oracle Functions will takes it to the 
next level, where you only pay for the resources consumed during the execution of your code. So ho
pefully, it gives you a good idea of the different offerings we have as part of the Oracle Infrastructure 
compute services.

Now why do we have these many offerings? Well, it depends on your application requirements. You 
might actually just want to write code and run your application like that, or you might actually want to 
run it-- manage the whole thing in a bare metal machine.

Now we talked about bare metal. You basically get a physical server without any virtualization. Now
one thing to keep in mind, we also have this-- you will read with Oracle this thing called off-box virtua
lization. So you might say, well, bare metal has no virtualization, but what is this off-box virtualization
?

What we do in off-box is we off-load network and storage to a separate hardware card in the server. 
People also call
it as custom silicon. So a lot of these storage and network operations are done by this card-- custom 
silicon-- which sits outside the server. So that's why off-box. But the server itself, there is no virtualiz
ation-- that's bare metal.

Virtual machine guest on a whole server with hypervisor based virtualization. In case of Oracle Cloud 
Infrastructure, we take the bare metal machine and then we slap a hypervisor on top of that, and the
n you can run your VMs. This is typically the multi-tenant model.

And then there is a third model which is called dedicated VM host. Now in this case, we do the same 
thing as a VM based offering, but the offering is single-tenant, meaning you get access to the whole 
box. So you ensure that the whole box has VMs which are only owned by you, and you don't have a 
green and a red VM, meaning VMs from two different customers, on the same box.

Why would you do that? Well, this gives you the highest level of security, and you can manage the w
hole thing yourself. It's sort of-- it's best of both worlds. You get a whole dedicated machine, but then 
your VMs are only yours-- it's a single-tenant VM model.

One thing
to keep in mind, because all of them use the same underlying bare metal machine, so our APIs are v
ery consistent. These offerings are a first class citizen of the bare metal cloud service. So the bare m
etal service runs beneath. And then you are running-- whether VMs or you
are running dedicated virtual hosts, we call the same APIs.
Well, what are the use cases for bare metal? The first use case is workloads that are performance in
tensive. So the first thing, yes, you will run databases on bare
metal, but workloads that are not virtualized. Again, a lot of that databases were never virtualized, so 
you could run on bare metal.

Workloads that require a specific hypervisor. You might actually have heard this term called bring yo
ur own hypervisor. So you could run your own hypervisor, and depending on your use case, use a sp
ecific hypervisor.

And then workloads that require bring your own licensing. So if you are running SQL, or you
are running exchange, or something, you might actually want to bring those workloads and bring you
r own licensing. And in some cases, you actually require a bare metal machine in order for those lice
nses to work in compliance with the requirements.

Well, our virtual machine, this is the simplest model which public cloud really made widely available, 
and before that, VMware. You have a hypervisor running on
the machine. You want to use a virtual machine when you want to control all aspects of an environm
ent-- it gives you the maximum control.

You want to deploy a legacy app, whether you might be running something in Windows or Linux. As 
I said, before public clouds, VMware really came in and had this offering on virtualization, which reall
y led to better resource pooling. And that's why it became powerful and widely used.

So you might still be running VMs and legacy apps in those. So if you're doing that and you want to u
se public cloud, well, an option which is simplest is to move them, package them, and move in as a 
VM. You can also use VMs to move application from on-prem like I was talking about. If you're migra
ting something, VMs actually make a lot of sense.

VMs require work. That is one of the downsides to be a VM model. It
gives you the maximum control, flexibility, et cetera, but you have to manage things. You have to pat
ch the operating system. Same with us, same with any cloud provider.

You have to manage your security configuration, you have to manage your network security, your fir
ewalls. You have to take care of things like monitoring-- constantly seeing if something is going on wi
th a virtual machine. You have to take care of things like application configuration, because you're de
ploying your applications to the VM, so it's your responsibility to configure them properly. And then fi
nally, you also have to manage things like scaling. So if you throw more traffic to your VM, more load
, variable traffic, your VM has to scale accordingly, otherwise, your application might not work optima
lly.

So those are some of the use cases why you would use a virtual machine, and some of the consider
ations to keep in mind when using VMs. With that, let's look at some of the instance basics. And thes
e basics apply to the bare metal, apply to the virtual machines, and apply to the dedicated virtual hos
ts.

It doesn't matter, so that's why we have instance. I'm not calling virtual machine or a bare
metal. It's the same across all. Why? Well, we talked about all these offerings internally uses bare
metal-- that's where it's built as layers. So they have the same APIs.
Well, like any cloud, we have different sizes. You have CPU, RAM, your bandwidth, you have differe
nt sizes for your instances, whether it's virtual machines, whether it's bare metal. We support both Int
el and AMD.

And AMD processors are typically 50% cheaper-- around 50% cheaper than Intel, so that's the price 
performance thing. If you're looking for, you could go with AMD. Could go with Intel, which is the com
mon model in the cloud.

We have instances specific to GPU and High Performance Computing-- HPC. And things like RDMA
, and intercalate and lots of detail which comes with those instance types. And then the thing to keep 
in mind is, though we talk about compute as sort of in isolation, compute in fact depends a lot on net
working and storage-- other services.

So if you think about it, you have your instance-- the instance actually boots using something called 
a boot volume. So think about this as well your operating system disks are kept. Instance also has d
ata. Let's say you are running a database, or you're running VMware, or something.

Your data actually doesn't live on the local instance, though you could do the direct attach storage. T
ypically, you would have remote storage, and this storage is actually stored on a service using a serv
ice called Block Volume. Your data, think about them as [? SATA ?] disks.

Boot volume and block volume are the same offering, meaning the boot volume is a type of a block v
olume. So boot volume specific use case is keeping the operating system disks from where the insta
nce boots, but it's a kind of block volume. And then finally, you have virtual cloud network where you 
get lots of networking capabilities.

Now that's a very simplistic picture. Typically, what happens is-- to make it a little bit more complex-- 
you have regions. We talked about this in the physical OCI architecture. Within a region, you have a
vailability domains-- might have one, might have three. And then you create a virtual cloud network, 
which is a logical construct. It's software defined networking in OCI.

Now you spin up an instance. What happens is instance has a physical NIC here. So this is your Net
work Interface Card, this is physical. We virtualize this and we call this virtual NIC. And this virtual NI
C gets placed in the instance subnet.

So typically, sometimes, you will see that the instance is shown here. In reality, the instance doesn't l
ive within this logical construct, only the virtual NIC lives within that. Why do we do that? Well, in virtu
al NIC, we would assign things like your private IP, we would assign things like your public IP.

We could secure your instance using a firewall here, or on the NIC itself you could put a firewall here
. So those
are some of the advanced networking capabilities you get on the NIC itself, the NIC runs in a specific 
subnet. Now as we talked about, the compute instance also uses the block volume service, and ther
e are two kinds of flavors of block volume that it leverages. One is called boot disk where your operat
ing systems are
kept, and then the other one is the data disks, which are also called as block volumes, and this is wh
ere your data resides.

So this is sort of a more realistic picture of what an instance looks like in OCI and similarly in other cl
ouds. So you
have instance-- it leverages your virtual cloud network. Basically, you keep a virtual NIC in a subnet. 
You could do a bunch of things here on security, IP addresses.

And then the data lives on remote servers, and the instance boots from there. The boot disk and the 
data disk are all kept remote. Why do we do this? Well, if
the instance becomes unavailable, your data is still running-- it's not lost. And we talked about virtual 
NIC-- you get your IPs, you get your security lists, your network security groups, you could secure yo
ur instances.

So let's look at two kinds of scaling supported by Oracle Cloud Infrastructure. The first one is called v
ertical scaling, and vertical scaling basically mean you can scale up and scale down. So you could g
o from a 1 core machine to a 2 core machine, or a 4 core, or an 8
core, or so on and so forth. And you could go up or you could go down.

And new shapes have the same hardware architecture. In this case, I think most of the public cloud, 
there is a downtime which is required. So instance must be stopped before you can resize it. I believ
e there is a feature coming where it's automatic, but right now this is a limitation you have to keep in 
mind. When you change the shape, it's a very brief downtime which is required, stop it, and then you 
can resize it.

Well, there is also something called autoscaling, which is literally horizontal scaling. So what you cou
ld do in autoscaling is you enable large scale deployment of VMs from a single gold image with auto
matic configuration. So let's say you have one instance running, but you want four copies of that inst
ance.

You could scale-out-- this operation is called scale-out-- and you get four instances. You started with 
one, now you have four. So you added one to three. And you can also do the reverse. So if you have 
four instances running, you could [INAUDIBLE] and you reduce one, and you go to three instances.

This is called scale-in. So scale-out, you add more instances. Scale-in, your remove instances. Why 
would you do that? Well, the idea here is if one VM fails, your others will still keep working, so you ge
t high availability.

That's why you would use horizontal scaling. This is the predominant application architecture in the p
ublic cloud. And again, the idea is you can match your traffic demand by adding or removing VMs au
tomatically-- and we do this in OCI based on metrics-- but add CPU or memory. You could actually 
match the traffic demand by adding or removing VMs.

And going back, historically, this is one of the key reasons why cloud became so powerful. Because i
n on-prem in order to do this was super complex. In cloud, it's actually much easier, and you can aut
omate the whole process. And then the great thing is there is no extra cost for using autoscaling.

So how does it work? And again, this is a foundations course, so we are not going into a lot of details
, but I just want to at
least give you some idea. It's actually really straightforward. You have an instance running-- what yo
u do is create a configuration.

And configuration is nothing but, as you guessed it, an operating system image, your metadata, stor
age disks, all that stuff. It basically learns about what your instance looks like. You're creating this thi
ng called a gold image here.
Then what you do is you take this configuration and you create what is called an instance pool. And 
as you can see here, instead of one instance, now we have two. And you could do many more.

And the idea is you could put these instances in different availability domains. And then now you can 
manage all of them together. You could stop them, you could start them, you could terminate them, a
nd you can update them.

So now instead of managing one VM at the time, you're managing at scale. You could manage hund
reds of VMs together as one unit. So this really gives you the power.

And then what you do is you define your scaling rules. You could say that if CPU or memory goes be
yond 70%, add two instances, and if they go below 70%, remove two instances. And then what happ
ens here is you have an initial size-- you could add plus two to more instances, or if the metrics you 
define say that a particular threshold is met, you actually can remove two instances.

And this is basically what autoscaling is. You could automate the whole thing, and this really gives y
ou the power to match your traffic load, and scale your application sort of seamlessly. So we talked a
bout lots of things on virtual machines, on bare metal, and we looked at the basics of instances, and 
then we looked at how you would do scaling, whether it's vertical scaling or whether it's horizontal sc
aling.

Now let's look at containers. The next two three slides, we talk about containers, and the Oracle Con
tainer Engine offering, and then we'll finally come
to the module talking about Oracle Functions. Well, if you think about traditionally what happened-- t
here was the concept of virtual machines. We talked about a VM is a guest on a host server with hyp
ervisor based virtualization.

So you have hardware, you actually have a thin layer-- what is called a Virtual Machine Manager-- V
MM-- your hypervisor. And then on top of that, you have VMs. Now if you see in this picture, VMs inc
lude an operating system. So each VM has an operating system, the necessary binary libraries, et
cetera, et cetera.

Now VMs took shape because they led to better resource pooling. Before VMs were there, you had t
his whole thing as a monolithic. You could only run one application. With VMs coming in, you could s
lice this hardware into various virtual machines and connect to the better resource pooling.

But there were some downsides to VMs as well. The first being in case of a VM, you were repeating 
the operating system everywhere. And so these became bulky. You're packaging operating systems 
in all the VMs.

So let's say-- in the previous example, we talked about autoscaling. If you have 10 VMs, basically, y
ou're packaging the operating system 10 times. So it's a bulky model, becomes hard to manage, et c
etera, et cetera.

So now we have this concept of containers where we raised the abstraction one more level, and now 
we virtualize the operating system. So if
you see these two pictures-- let me just remove this here. If you see this picture now, we are raising t
he abstraction one more level, and we are virtualizing the operating system.
So operating system is here, and now we have containers which are running on top of that. So comp
uters include the app and all of its dependencies. But as you guessed it, it shares the kernel or the o
perating system with other containers.

Now in this way, containers are not tied to the guest operating system like the VMs here. They are n
ot tied to any specific infrastructure. They can run on-prem, they can run in a public cloud, they can r
un in any public cloud.

So the question then becomes how do you deploy these containers? Because literally, you're not goi
ng to just run one container-- you're going to run a massive number of containers like you do with virt
ual machines. Now there
are various ways to do it. You could manually SSH into machines, run containers. Well, Docker is th
e most popular container runtime, and there are other container runtimes as well.

So there is one option to do that. You could do scripting or config management. But typically, what b
ecame really powerful and popular in the last two or
three years are these orchestration systems. So what are these orchestration systems? Well, the on
e which is the most popular is this thing called Kubernetes. And sometimes you would hear people w
riting it as K8S, and there's a story on why that name came, and why they named it like that.

But it is an open source orchestration system for automating deployment, scaling, and management 
of containerized applications and containers. So the thing to keep in mind is-- anyway, this is all bey
ond foundations, and there is a course on Kubernetes we have, and Oracle Container Engine, et
cetera, et
cetera. But just to give you an overview, the way Kubernetes works is Kubernetes doesn't run contai
ners directly.

What it does instead is it wraps containers into a higher level structure called a Pod. You can see the
se two Pods running here. Think of Pod as the smallest deployable unit that is created and managed 
by Kubernetes. What really is Pod-- what does it represent?

It represents a group of one or more containers you can see here. And these containers, like we talk
ed about, you could use Docker as the container runtime, you could use something else. They have 
shared storage we're not showing here. This gets a little bit more complex.

They also share network namespace as a unique cluster IP address. And they also have things like i
nformation about how to run each container, image versions, specific ports, et cetera, et
cetera, et cetera. Lots of detail-- not getting into in this foundations course.

Now each Pod is tied to the node where it
is scheduled. You see these two nodes here, and these nodes are actually your instances. So these 
can be bare metal, these can be virtual machines, whichever model you want to use.

The Pod is tied to the node-- so you can see here where it lives, where it
is scheduled, and remains there until termination. Or you could have a restart policy or you delete it. 
So this is basically how it works at a very high level. And there's lots of details on Kubernetes, lots of 
training content available.

Now Oracle Container Engine is a fully managed, scalable and highly available service based on Ku
bernetes, as you guessed, that you can use to deploy your container applications in OCI. We also ha
ve this service called Container Registry-- Oracle Cloud Infrastructure Registry. It's a managed Dock
er Container Registry service, and it can be used to pull images for Kubernetes deployment.

These containers are based on images, and OCIR services running here, you could actually store yo
ur images in that. You could pull those images for your Kubernetes deployment. Well, the final thing 
we want to talk about is functions. Functions is a serverless offering.

This is the smallest-- I would say really the smallest unit of compute, where you write code, but gene
rally does one simple thing and then it dies. That's basically what functions do. And this is, again, thi
s whole category of several less offerings. That's basically what functions are.

With Oracle Functions, you can write code in Java, Python, Node, Go, and Ruby. And in fact, for oth
er use cases, you could actually bring your own Docker file. And then you deploy your code like we t
alked about earlier, you call it directly, or you could trigger it in response to events. And then you get 
billed only for the resources consumed during the execution.

So this really sort of takes the pricing to the next level. It's consumption based pricing rather than pa
y-as-you-go pricing. And you can see here how it
works. You push the container to a registry-- it actually uses containers beneath the layers. Then you 
configure the function trigger, and the code runs only when triggered, and you only pay for that exec
ution time.

One thing to keep in mind is Oracle Function is based on FN project. And FN project is an open sour
ce container native serverless platform that can run anywhere-- any cloud or on-premises. So that's 
one unique differentiation functions has compared to some of the other serverless offerings out there
.

Well, folks, that's it. In this particular module, we looked at bare metal machines, physical servers wit
hout virtualization. We looked at VMs, the different scaling options available with VMs, whether its ve
rtical scaling, horizontal scaling. We very briefly looked at what Kubernetes is.

Oracle Container Engine is a managed Kubernetes offering in the cloud. And then we looked at funct
ions based on the FN project, serverless offering, and sort of the smallest unit of compute available i
n Oracle Cloud Infrastructure. Well, thank you for your time. I hope you found this information useful.

OCI Storage Services:

Hi, everyone. Welcome to this lecture series on Oracle Cloud Infrastructure foundations. My name is 
Rohit Rahi, and I'm part of the Oracle Cloud Infrastructure team. In this particular module, we will loo
k at the various OCI storage services. We'll look at the various storage services within OCI, starting 
with block volume, local NVMe, file storage, object storage, and archive storage, and look at its vario
us characteristics and use cases, so let's get started.

Well, before we dive deep into the various storage services available, it's important to remember why 
do we have so many services available in the first place, and that-- the reason is you have different s
torage requirements, and depending on your requirement, you might choose a particular storage ser
vice over another. So what are these requirements? At a very high level, these are some of the requi
rements you have.

Storage is persistent versus non-persistent. What kind of storage are you looking at? Is it database? 
Is it videos? Is it audio? Is it photos? Is it text? What kind of performance are you looking at? And wh
en we talk about performance, there are different characteristics. How much is the max capacity avai
lable to you? What is your input output per second, IOPS? How much is the throughput? And so on 
and so forth.

What is the durability of the data you are looking at? And when we say durability, typically, what we 
mean is how durable is the data, meaning how many copies of data do you make or you keep? What 
is the connectivity? What does the connectivity look like? Are you trying to connect to a local storage
, direct data storage, or you're trying to connect to a remote storage? How does your application acc
ess the data?

And then finally, related to connectivity is the kind of protocol you are planning to use. Is it block stor
age? Is it file storage versus another kind of storage? So these are some the requirements, and dep
ending on your requirements, you might choose one storage service versus another.

So the various offerings we have, we have block volume. We have local NVMe. Local NVMe is also 
called sometimes local NVMe disks, file storage, object storage and then archive storage. So let's ge
t started, and look into each of them in a little bit more detail.

But
before we go and talk about OCI block volume service, first let's talk about what is block storage. We
ll, think about block storage as a hard drive in your server, except that the hard drive happens to be i
nstalled in a remote chassis. So the emphasis here is remote. So it's a remote storage, network stor
age.

In a block storage, data is typically stored on a device in fixed-size blocks. So fixed size of blocks. An
d that's the reason, if you look at even our icons for block storage, you have these kind of blocks, rig
ht? And what they imply is your data coming in, data going out. It comes and goes out in these chun
ks of data called fixed-sized chunks called blocks.

Your operating system accesses block storage as mounted or drive volume. And your application file 
systems decide how blocks are combined and accessed. Like I said, the blocks come out like-- go in 
or come out, and then your file systems, your apps, decide how they combine, get combined and ac
cessed. Because they are broken down and stored in chunks.

Data is stored without any higher level metadata for data format type or ownership. So keep that in 
mind. There's no metadata which is stored. And then this is the underlying offering on which you coul
d install any kind of file system. So this is sort of the basics of your storage.

So you could install different file systems on block storage. So things like Windows, users, NTFS, V
Mware servers, you use VMFS. But underneath both of those, they are using block storage. And the
n commonly block storage is deployed in storage area networks, if you're coming from on-premises 
environment.

So let's at in an OCI environment, what is the block-volume service? The first thing to note here is it's 
storage for compute instances. So you have a compute instance running here, and then you have re
mote servers. So keep in mind, like
I said, these are your remote storage, not local storage. It's network storage.

So you have server storage that we're running here, and then basically the compute instances is con
necting to those storage servers and accessing your data. Now there are two flavors of block volume
. One is called boot volume. The second one is called block volume.

Boot volume is the operating system disk. And you can see here, with a different color, this is where 
your operating system is stored at your instance, boot using this boot volume, that is also remote. It's 
a flavor of block volume.

And block volume, when we say, even though it also encompasses boot volume, we typically mean 
data disks. So I have only shown one disk here,
but you can have multiple disks attached to the same compute that you do
that. So remember? What is block volume? Storage for compute instances. Two flavors, boot volum
e, block volume.

Why do we use block volume? Well, the most important reason you use block volume, you want to st
ore data independently and beyond the lifespan of compute instance. What do I mean by that? This i
nstance dies. Your boot volume and your data volumes are all still available to you. So that is one of 
the main reasons, data durability, why you would use a block volume.

What are the use cases for databases? So databases can run here. They're individual data is actuall
y stored as blocks, or chunks of data. Exchange doesn't support-- supports only block-level storage. 
Remember we talked about VMFS, when you use VMWare virtualized servers, they use this kind of 
storage on block storage. And then like we talked about boot volumes, instances that configured to b
oot from block-level storage in most of the public clouds.

Well, so we talked about block-
volume being highly durable. So what do we mean by that? Well, what we mean by that is storage-- 
block volume service actually stores replica of data in three separate fault domains. Let's say this is t
he storage, which is getting connected here. Accessed here.

So block-volume service would actually make two more copies here in another-- two other fault dom
ains. The idea being, if let's say this fault domain becomes unavailable for some reason, your boot v
olume and your block volumes are still available to your computer instance.

Now with this, you don't have to configure any software-based protections. You don't have to do like 
[INAUDIBLE], et
cetera. Now, if we do this, is your job done? Do you also need to do anything? Actually, your job is n
ot done.

Because this is what our service is doing to make it fault tolerant. But what if you have instance wher
e you accidentally delete data or data gets corrupted? Those cases, you should do this thing called p
eriodic backups block volume. You should do backups.

Because if you don't have backups, then literally you know,
your data is at risk. Now also allows automated scheduled backups. How do these work?
Well, what happens is you have a block volume here. You can take a backup. To do a backup, it act
ually goes to our object storage. And from that backup, you will create a new volume, and then you c
an attach it to a compute instance.

And you could do that in a different ADL, so you could, of course, do it same AD. But if your region h
as multiple ADs, you could actually do that back and just store to another volume in another AD. So l
et say this AD goes down for some reason, because you have a backup stored here, very quickly. Or 
you automate it, your instance could be up and running, your application could be up and running in 
another AD in the same region.

Not only that, there is also a feature called block volume. There is also a cross-region copy feature th
at you can copy block volume backups from one region to another. So you could take the backup fro
m here, and you could do this.

Why would you do that? That's [INAUDIBLE]. Because you want to do the same thing across region
s, because you don't know if one region becomes unavailable, you can still have your application run
ning in another regions. And not only this, you can also schedule these backups.

What I just talked about is a manual backup. You don't have to do manual backups. You could actual
ly schedule this based on a policy, et cetera, you could write. And you could schedule your backup. 
So that's one of the most important characteristics of a block-volume service.

The last thing you need to know on a block volume are the different tiers of block volume. Well, we h
ave three tiers of block volume, starting with basic. Now the idea with basic is it's for large, sequentia
l I/O. So you can see that the number of IOPS is pretty small here, but the throughput is pretty decen
t.

So this is for data warehouse, big data, streaming. A lot processing kind of scenarios, where you wa
nt to read a lot of data, a big chunk of data. You don't want to read very quickly, or not as quickly as, 
let's say, a database. But you want to read a bigger chunk. So that's basic.

The second one is balanced, sort of the middle tier. Right here it's a balanced mix of IOPS and throu
ghput. You get a fairly decent IOPS, 60 IOPS per gig, and you get a fairly decent throughput. But the
se are good for things like random I/O, boot disks. You want to boot very quickly, right? Databases, e
t cetera, transactional databases, you could use this.

And then the last one is higher performance. In this one, you get actually really high IOPS per data,
the highest. And you actually get pretty good throughput. So this is optimal if you're running mission-
critical databases. Now, the thing to keep in mind, each of these tiers, you can create a 50 gig volum
e. That's the minimum.

And the maximum is 22 terabyte. And you could attach 32 volumes per instance. So the total volume 
of storage you can do is 32 volumes, into each of the volume can be 32 terabytes. So this is close to 
1 terabyte. That's mind boggling. This is how much storage your VMs can actually leverage.

And of course, there are lots of limits on how much they can use. But you could go as high as this. A
nother thing to keep in mind is data is encrypted at rest and in transit. And there
are two ways to do that. You can let Oracle manage the keys, encryption keys. Or you could control 
your own keys.
And there
is a service called key management. You could leverage that to create your own keys and manage t
hem, manage your encryption. So that's all about block volume. Let's move quickly to the other flavor 
of storage we have called local NVMe.

Now this is similar to block volume, but the idea here is it's temporary storage, locally attached to the 
computer
instance. So see there is not normal going to the remote storage here, like block. But just directly att
aching the story. But it uses the same construct. It's still block based, et cetera, et
cetera, and very high performance, but it's directly attached.

Now this is designed for applications that require high performance, so NoSQL, in memory, scale-out 
transactional databases could use it. The thing to keep in mind is storage is non-persistent. But it sur
vives reboot. So if this instance dies, your storage dies here.

So still a block-based storage service. But it's local attached. So it's not durable at all, unlike block vo
lume service.

Local NVMe, like block, uses NVMe, so it gets very good performance. We don't provide any vague 
snapshots, backups, none of
that, like you saw in the previous slides for block volume. Like block volume, it does use block-based 
protocol.

And then we have SLA around performance, because again, these are locally attached. We feel goo
d about these numbers. So we have an SLA around these numbers. If you're using this dense IO sh
ape, you would get something like a 3 million IOPS, if you use local NVMe.

Well, so, until now we looked at a block storage. We looked at local NVMe. Let's look at the third flav
or of storage, which is file storage. So before we get into the OCI file storage service, let's talk about 
what is a file storage. Well, file storage is a hierarchical collection of documents organized into name 
directories, which themselves are structured files.

So all of you are familiar with it. This is your local hard disk that you create folders. You keep your do
cuments, your pictures inside those folders. The difference is distributed file systems make distribute
d look exactly like local file system.

So this is an example of a file system. You have folders, starting with root, will decide to form a Unix, 
you know, documentation. And you have folders within the root. And then you have subfolders, and 
you keep files in them, right?

The idea is you take this concept, and now you use it on a distributed level. The two most common fil
e standards are NFS and SMB, server message block, network file storage. They are supported by b
oth Unix and Windows. So it's not like NFS is only here, supported by Windows.

You could create, delete, lead, write, share, lock. Files is files using these protocols or standards. It's 
supported by all major operating systems and hypervisors. So it's not like NFS
is only Linux and SMB is only Windows.

And typically you don't need extra client software for file storage. And then, like we said, the file stora
ge is basically a distributed storage, accessed or networked, at least in the cloud construct. And typi
cally, where do you see them? You see them in network-attached storage.
So file is typically seen at network
attached storage. And block is seen in increment as well, [INAUDIBLE] these are the [INAUDIBLE] c
ommonly in on premises environment.

So let's talk about OCI file storage service. As you can see here, the whole idea behind a file storage 
service is it's giving you a shared place where you could write your files. And here you could create y
our folders. You can have subfolders.

Shared, this instance can write, this instance [INAUDIBLE], both
of them, right? So like I was saying, it's a shared file system storage for compute instances, as you s
ee in the picture. Today we only support NSF, and we support NSF v.3. We do allow, like, block volu
me.

You have features for making backups, called snapshots. And light block volume. We do encryption f
or data addressed and in transit. We allow both, not just for the data but also for the metadata.

What are the use cases for file storage? Well, some Oracle applications require file storage, like EBS
, they require a clustered file system where multiple instances can write. The application is built like t
hat. Lots of high-performance computing scenarios use shared file storage. Big data analytics. And t
hen there are a general-purpose file systems.

The NAS systems I was talking about earlier. You can use cloud to replace your general-purpose file 
system. These are very common in enterprises, where you have, I'm sure all of you have seen remot
e storage where you can-- remote drives where everybody can keep, like, their backups and like co
mmon storage for projects, et cetera, right? Pretty common general-purpose file systems.

Well, like block volume, file storage is also highly durable. So if this instance dies, this instance dies, 
your file storage is actually-- is quite, is durable. So the service itself replicates the data in three sepa
rate fault domains.

Now like block volume, your job is not just done with it. What you could do is you could take snapsho
ts of file systems that provide a read-only, space-efficient point-in-time backup. And so you could tak
e a snapshot of this file.

Why would you do that? Well, the data can get corrupted. You can accidentally delete a file. So you 
should always do, like block volume, you should always do backups. If a file storage, those are
called snapshots. You can restore a file within the snapshot, or you can in any task snapshot using c
ommands like copy or rsync.

Well, so that's all about file storage. Let's look at the last storage offering we have and the two flavor
s we have in that called object storage. So in case of an object storage, all data, regardless of conte
nt type, is managed as objects. An object is stored in a bucket.

Think of a bucket as a logical container for storing objects. So you have a
bucket here. And these are your objects that you are storing within the bucket. As simple as that.

These are stored in single flat structure, without a folder hierarchy. Unlike file storage. This means th
at accessing individual objects is fast and easy. Massive at the speed set that you can compute thes
e objects, because it's very flat hierarchy.
You don't have to go in a hierarchical fashion looking for, like a B tree, and you know, like all comple
x kind of algorithms. You don't have to do any of that.

Each object is composed of the object itself and the metadata of
the object. This is, again, unlike if you recall, block volume doesn't store any metadata. So this make
s it very easy to index and access data. Unlike block volume, right? where there is no metadata store
d.

Object storage is quite common in cloud-based scenarios. You could guess why. Well, it's highly sca
lable. It's very easy to index access. Massive scale. That's because of that. And it's highly reliable, b
ecause you don't maintain this folder structure. So you could keep multiple copies.

While files and blocks are generally available to an operating system, you could use by using mount 
operation, object storage relies on standard HTTP verbs. So you put an object, you get an object, rig
ht? You use a completely different mechanism by which you access object storage.

So in OCI, we have an object storage service, like, we talked about earlier. It's an internet-scale, hig
h-performance storage platform. You could store unlimited amount of unstructured data, whether it's 
images, media, files, logs, backups, et cetera.

Its a
regional service, not tied to any specific compute instance, right? You don't do remote operation. Yo
u won't get objects. And we have two different classes-- hot storage and cold storage. And we'll talk 
about each of these in the next slide.

What are the use cases? Well, it should be pretty obvious. It's a content repository for data, images, l
ogs. You could do archive backup for long periods of times. You can store data for analysis. Things li
ke, in a log data, et cetera. You could store large data sets, like genome data
or IOT data. And then you have-- this can be used as a storage for big data, Hadoop, et cetera.

Now object storage, like file and block storage, is also highly durable. So if
you see here, we make-- the service makes copies. Increase separate file domains in an AD, like file 
and block. But if we are running in a multi-AD region, because its an original service, we
store replica of data in more than one AD. So here, you can see three copies made, and
here you can see three
copies made. In total, making six copies, of course, This is the case when you have, when you have 
a multi-AD region.

Data integrity is actively monitored and corrupted data detected in auto repair. That's one of the key 
characteristics of an object storage. It's massively reliable and highly, highly durable. And you can al
ways leverage across region copy for disaster recovery scenarios. We have a feature where you can 
copy object storage between two different regions, if you have the [INAUDIBLE].

Well, so what are the tiers of object storage? So first tier is called standard storage tier. It's also refer
red to sometimes as hard storage. And what it means is the storage retrieval is fast, immediate and i
nstantaneous. You put an object in object storage, and you get it instantaneously. There is no like so
rt of a time lag.

If we always serve the most recent copy of data when retrieved. And there are some restrictions. If y
ou do this, your object always is in this particular tier, right? So when you create the tier in OCI objec
t storage, you actually choose whether it's a standard tier or whether it's going to be an archive tier.
So that brings me to the next tier, which is the archive tier. Now as the name suggests, this is for dat
a archival. For seldom or rarely accessed data, which must be regained and preserved for long perio
ds of time.

Why would you use it? Well, obviously you are retaining data for a longer period. But it's 10 times ch
eaper than the standard storage. So that makes it very attractive to keep as much data for, dependin
g on your requirement, for longer periods of time.

There are some restrictions which come with that. There is a 90-day minimum retention period for ar
chive storage. And then there is, when you retrieve the data, unlike the standard tier, the first-- the ti
me to first byte is four hours before you can start getting your data.

So some restrictions around the trade-off, being it's 10 times cheaper. The trade-off being there cert
ain restrictions, whether it's the duration you have to keep defined for, or whether the time it takes to 
download the file. You have to sort of feed off between those things.

All right, so let's look at all these side by side. So we look at local NVMe. The main thing here it's tem
porary storage. Keep that in mind. Block. It's persistent storage, unlike local NVMe.

File we have NFS v3 compatible system. Object, highly durable. Archive use gives being long-term a
rchival and backup.

Access, the first two are block-level services. File, of course, operates at the file level. And then obje
ct is different characteristics operated object level.

The structure is, its block-level structure. This is block-
level structure, very structured. You give these chunks of blocks numbers and you keep them. File is 
hierarchical. Object is all about unstructured, right? You could put anything in here, and they
are treated as objects.

Durability. Most important thing to keep in mind, non-persistent, though it survives reboot. But if the i
nstance dies, storage dies. Block, most important reason why you would use block? Durability. We 
maintain three copies within an AD three separate file domains.

Same thing with file, highly durable. Same thing with object storage. It's actually highly durable within 
multiple ADs. And same thing with archive storage. It's highly doable within across ADs.

Capacity, you can see some of the numbers. We didn't go through those numbers. And then the use 
case is right here. You
can see for local, it's OLTP, NoSQL. Block, databases, VMWare, Windows, workloads, any kind of w
orkloads which require [INAUDIBLE] performance.

File, general purpose file systems set in Oracle apps. HPC, et
cetera. Object is unstructured data, logs, images, videos, and archive storage is, of course, you kno
w, backup and long term archival. Things like your database backups.

Well, folks, that's it. That's the module on OCI storage services. Hopefully give you a good understan
ding of the various storage services we offer. The use cases, the different characteristics, and why y
ou would choose them. Thank you for joining this module. In the next module, we'll talk about some 
other OCI services. Thank you.
OCI Networking Services:
Hi, everyone. Welcome to this lecture series on Oracle Cloud Infrastructure foundations. My name is 
Rohit Rahi, and I'm part of the Oracle Cloud Infrastructure team.

In this particular module, we will look at some of the OCI networking services. Specifically, we will lo
ok at what a virtual cloud network is, what kind of gateways are available in Oracle Cloud Infrastructu
re, what peering options do we get, what do we mean by security controls within VCN, and we'll brief
ly talk about load balancer service within Oracle Cloud.

So first, let's look at what is a virtual cloud network. A virtual cloud network is a software defined priv
ate network that you set up in OCI. What do we mean by software defined? What we mean here is y
ou get access to the VCN but not the underlying hardware because it's all in software.

What is the need? Why do we need a VCN? Well, it enables your resources such as compute instan
ces to securely communicate with the internet with other instances running in Oracle Cloud Infrastru
cture or your on-premises data centers. So those are the three key scenarios where your instances n
eed to communicate.

And in order to do that communication you need to have them running inside a virtual cloud network. 
So what does the virtual cloud network look like? As you can see here, I have a couple of instances. 
One instance is talking to the internet-- and these are talking to each other as well-- another instance 
is talking to your on-premises environment.

So in order for us to enable that communication, we take a region-- a region has ADs-- one or many, 
one or three, multiple. So in this case, we are showing just one AD. And in this particular example, w
e create this VCN. And as you can see, the reason we have this as a dotted line is to show this is sor
t of a logical thing-- it's not a physical thing. It's a software defined construct, the VCN here. And then 
we have these compute instances running inside the VCN.

So like we said, a VCN lives within an OCI region, and it's highly available, secure, scalable. All done 
in software, so it gets-- inherits all those constructs. Now let's dive a little deeper. When you create a 
VCN, first thing you do is you give it an address space. So address space is nothing but a range of I
P addresses that you assign.

Like in this case, you have this IP address of 10.0.0.0/16. Now what do we mean by an IP address? 
Well, think of about IP address as like your postal address. So this is a unique identifier for all the eq
uipment, all the assets by which you can identify an asset.

So typically, what happens in an on-premises environment, or at least in a traditional environment, is 
you have this concept called a DMZ-- Demilitarized Zone-- but then you have your local area networ
k here. And as you know, IP resources addresses are precious resources.

So many years back, the standards for RFC came up with this concept of RFC
1918 addresses. And basically, these addresses are called private address space. And the idea her
e was to preserve the public IPv4 addresses-- the number of IPv4 addresses we could have, and als
o prevent overlapping of IP addresses.
So these addresses, the reason they are called private is they are not routable on the internet. So yo
ur LAN could use these resources-- so if you have a computer here, you have a computer here, com
puter here-- they could all have private IP addresses. But your DMZ can have a load balancer which 
will have a public IP address.

If you just go and get the public IP address of your local machine with which you
are watching this video right now, you will get an IP address, which is publicly available. So it can be 
discovered on the internet. So that is a public IP. And
then organizations have used the private IP addresses.

There are three ranges here-- and we don't have to go in detail on these ranges. There is 10.0/8, the
re is 172.16/12, and there is a 192.168/16. Now again, we don't have to go into all these details-- get 
into a lot of complex CIDR notations, et
cetera. But the idea here is using these private IP addresses, your resources can still be identified on 
your local LAN network, but they cannot be routed on the internet.

So when we talk about VCNs, what we are talking about are these private IP address spaces. So yo
u look at that 10.0.0.0/16, that's a private IP address. So first thing you do in a
VCN is you assign that private IP address. Now it's a range as we talked about.

So this particular CIDR means these are the IP values which you can assign to your resources. Now 
every resource that is connected to this VCN, like a compute resource, will get its own unique private 
IP address. Remember, it's private IP.

So server 1 has this IP, and this particular server has this particular IP address. Now how did those s
ervers get those IP addresses? Well, the idea here is you take this big network and then you divide i
nto these things called subnetworks-- smaller networks.

Now why do you do that? Well, first, these are the examples here. You could pick a bigger network, 
you could divide it into smaller networks. Well, why would you do that? The idea is your compute inst
ances are placed in subnets.

You cannot put a compute instance just here without a subnet-- in just a VCN. You have to create a 
subnet-- at least one. And then subnets can be isolated and secured. And this is one of the big reaso
ns why you would have subnets, because you could secure it here on a subnet.

Now let's look at the communication pattern we talked about. Why did you create a VCN in the first p
lace? Well, we want instances to communicate. So the first scenario is communication to the internet
. So the simpler scenario is you are running a web server here-- let's say this is your web server-- an
d you want the traffic to go out. It's a web server-- a load balancer.

So in OCI, there is a gateway which is called internet gateway. It provides a path for network traffic b
etween your VCN and the internet-- it's bidirectional. So you can go from here, it can come from the i
nternet. People on the internet could actually discover it.

It's a web server-- you want
it to be discovered-- folks can ping it and access it. So you guessed it, this you would put in a public 
subnet. Also sometimes, people call them as DMZs-- not every public subnet. But there is this conce
pt where you put all your public facing assets in a subnet which is public, or a demilitarized zone.
Now on the other side, you might still want to reach the internet, but you want to reach it in a secure f
ashion. So what that means is-- let's say you are running a database here, and your database needs 
patching, of course. So for it to get the patches, it still needs to go to the internet and get the patches 
back.

But what happens is nobody-- a bad actor should not be able to ping a database from the internet. A
nd so you would use a gateway called a NAT gateway which enables this outbound connection to th
e internet, but locks inbound connections initiated from the internet. So this bad actor cannot reach y
our database. Use case is update patches.

Both these gateways are highly available, secure, and scalable. So this is the whole idea of software 
defined networks-- you don't care about the throughput, whether they are highly available. We mana
ge all that, and we make these fault tolerant for customers.

The second scenario is you want your communication to on-premises, whether you
are running in a hybrid mode. Let's say you have a DNS server which is running right here in your on
-premises, and your databases need to sync up with the DNS server. So what you need to do here is 
this-- let's say you are running a database. You need to go to on-prem.

So in this case, you have another kind of router called a dynamic routing gateway, and it's a virtual r
outer that provides a path for private traffic between your network and destinations other than the int
ernet. So you're not going to the internet right now, you're going to your on-prem environment, and y
ou use a router called a DRG. Now there are two kinds of mechanisms, or two kinds of designs you 
have with a DRG.

One is what is called a simple IPsec VPN, also sometimes referred to as site-to-site VPN because y
ou're connecting sort of to sites. And there is another-- and this actually goes through the internet. T
here's traffic, but we said that it's a private traffic.

So what it means is we encrypt the traffic, and that's the IPsec encryption in the name. So we encryp
t the traffic there. Now the second design is around using a private dedicated connectivity. So think a
bout this as having your own high occupancy vehicle lane if internet is this massive you set of highw
ays.

And you get your own [INAUDIBLE] lane, and it's only for you. It's private and it's dedicated connecti
vity. And again, this is a foundations course, so we're not getting into
a lot of details, but you can get into a lot of details on how each of these work and the components. 
Now there is a third scenario where you want to communicate this time to public OCI services, like a
n Object Storage.

As you know, Object Storage has a public endpoint-- it's public URL through which
you can access it. It's for the storage for the web. So let's say
you have a scenario where you want to access Object Storage. Why would you do that?

Well, again, as in the previous examples, let's see our database running here. You want to make bac
kups of those databases. The best place to keep the backups is an Object Storage. It's built for this 
massive scalability and reliability of data.

So you want to do the backups. Now to do the backups, you want to access a public endpoint. Now 
with virtual, it means that this subnet has to be public, and this instance needs to have a public IP ad
dress, and so on and so forth. So it becomes a security issue if you go that way.
So we have another gateway in OCI called a service gateway which lets resources in networks-- VC
N-- access public services such as Object Storage, but without using an internet or NAT gateway. So 
your traffic is not going over the internet. It's still going through the Oracle Private Network fabric.

So as you can see here, we use the instance private IP address for routing, and it travels over the O
CI network fabric. It never traverses the internet. The use case-- you have to back up your database-
- that's the most common use case. And there are several other use cases, but this is a way for your 
services to access public OCI-- your resources to access public OCI services, but not go through pu
blic internet.

So we looked at the four different kinds of gateway. Going to internet, internet gateway, NAT gatewa
y-- different use cases. We looked at dynamic routing gateway, going to on-premises, going to public 
OCI services, such as Object Storage. We looked at service gateway.

So four very common gateways. You should know the use cases for each of them. Now briefly, let's l
ook at security. So in this case, we have a similar example as before. We want to secure these insta
nces, because remember in the previous slides, we talked about the fact that you have subnets-- yo
u want to secure these subnets, and of course the compute instances running within the subnet.

So what you could do is you could design a set of firewall rules. You could put a firewall which would 
say what kind of traffic is allowed in and out of the subnet-- you could do that. Now security lists also 
apply if this instance wants to talk
to this particular instance. You need to put a security list here in order to enable the traffic.

So one thing you need to keep in mind is you create a network, you have subnets, and these are all 
secure by default. So it
doesn't mean that this instance can talk to this other instance. Just because they are in the same net
work, you have to enable that traffic.

And then you could do stateful, stateless. And again, we're not getting into lots of details here. So let'
s look at a couple of examples. This first one applies to the web server. It's saying port 80, traffic co
ming from anywhere, allow that port. Ingress meaning it's incoming.

The second one is applying to this guy here on the private subnet. It's saying it's egress-- going out-- 
only allow traffic to this particular subnet, and only allow traffic on port 1521. So this is how you woul
d secure your networks. Just think about these as your firewalls sitting on the subnet, and controlling 
access for all the resources-- for all the resources, like compute instances, within that subnet.

Now you don't have to always put these at the subnet level. We have another feature called network 
security group. Basically, you could do the same thing, but now you could do it at the virtual NIC leve
l. So what that means is you could apply NSG just to this particular instance, and so on and so forth.

So it gives you more granular control of how you handle your security. Remember, you could apply s
ecurity either at the virtual network interface layer, or you could do it at the subnet layer. And there
are different use cases of when you would use one over another.

So that was-- we talked about the gateways, and we talked about security. Those are sort of the basi
c scenarios. The one other scenario for communication we actually missed in the previous slides, an
d that's around peering.
So what I mean by that is let's say you have a region here. All the previous scenarios were like focus
ed on one region-- you have different gateways. Now let's think about it in
this way. In a region, let's say you have multiple VCNs.

Now you still might have a scenario where these VCNs have resources you want to communicate-- 
who want to communicate with each other. Why? Well, a good example might be that DMZ has its o
wn VCN, and your other assets or other projects or other units have their own VCN. It's a very valid s
cenario. So your VCNs might want to communicate with each other. And the process to connect thes
e multiple VCNs is called peering.

Now in a peering, there are two kinds of flavors which are possible. One is called local VCN peering. 
In this process, you connect two VCNs in the same region-- so you are in the same region-- so their r
esources can communicate using private IP addresses. So this guy can
talk this guy to create something called a local peering gateway, and the communication happens.

Now what if you have VCNs in other regions? And we talked about the fact that many regions have r
egion peers. So two regions existing in the same geopolitical area. Or even if they are in different are
as. You might do things like global rollouts, you might do things like disaster recovery. You might still 
be talking between two different regions.

So in that case, you have this concept or this construct of remote VCN peering-- similar to local VCN 
peering-- but now you're connecting two VCNs in different regions so their resources can communic
ate using private IP addresses. Now the thing to keep in mind is you have peering here and you hav
e peering here.

This doesn't mean that the peering is transitive, so it doesn't mean that this compute instance can tal
k to this compute instance. This kind of communication is not allowed. If you want this instance to tal
k to this, you have to make an explicit peering connection, meaning the peering is not transitive.

So we looked at different scenarios around gateways, and security, and peering. Let's look at the las
t topic in this lecture around load balancer. Well, why would you use a load balancer in the first place
?

Well, load balancer is this construct which sits between your clients and your backend. The first thing 
you would use a load balancer is-- so in a load balancer, what you do is requests are coming in from 
the client. You do things like service discovery-- you say what backends are available, and when sho
uld we talk to them.

You also do health checks. So if this one has gone down and these are healthy, you stop sending tra
ffic to them. Why do we use a load balancer? Well, we use a load balancer-- the first reason is high a
vailability. We looked at it in the previous module. If these three web
servers, you still have your application running because one of the web servers is running.

Second is scale. One VM can only handle this much traffic or a bare
metal machine. If you put four of those, of course, you get a bigger scale. So those are the two com
mon reasons why you would use a load balancer.

Now in OCI, we have different kinds of load balancer. We have a public, we have a private. It operat
es at layer 4, operates at layer 7. You can do things like session persistence, affinity based routing, c
omplex kind of routing. You can do SSL.
There are lots of features. So in
this lecture, we are not going through this. I'm just going to show you common, simple example. So l
et's say you're running a publicl load balancer. The traffic is coming in here like this.

First thing we talked about is the services. OCI services are fault tolerant. What does that mean? Thi
s can become a single point of failure. To avoid that, we always maintain two copies of the public loa
d balancer or the private load balancer.

So if this one goes down, this load balancer
is still running. You don't have a single point of failure. And then as we looked at the previous slide, t
his load balancer is basically sending traffic to the various backends. In case this one goes down, th
e traffic will switch over-- the IP will switch over to this load balancer. And then the load balancer will 
still be sending traffic to the various backends.

Well, that's all we wanted to cover on the virtual cloud network. In this particular module, we looked a
t what a virtual cloud network is-- software defined network, highly available, secure, scalable. We lo
oked at different kinds of gateways-- internet gateways, NAT gateways-- for sending traffic to the inte
rnet. Different use cases.

We looked at DRG-- Dynamic Routing Gateway-- for sending traffic to on-premises. We looked at se
rvice gateway for sending traffic to public OCI services, such as Object Storage. We looked at peerin
g-- both local peering as well as remote peering, and different use cases why you would do one vers
us another.

And then we looked briefly at a public load balancer. Well, that's it, folks. Thank you for your time an
d joining this module. In the next module, we'll talk about some other OCI services. Thank you.

OCI IAM:

Hi, everyone. Welcome to this course on OCI foundations. My name is Rohit Rahi. And I'm part of th
e Oracle Cloud Infrastructure team. In this particular module, we are going to look into OCI Identity a
nd Access Management service. Specifically, we are going to look into what the service is.

Sometimes the service is also referred to as IAM service. We are going to look into authentication an
d authorization, and how those are done in Oracle Cloud Infrastructure. And finally, we are briefly goi
ng to look into policies and what those policies are. Well, I'm sure you would have seen this particula
r diagram in some other modules.

At a very high level, OCI Identity and Access Management service deals with a couple of things. The 
first one is identity-- who is requesting access. And then the second one is permissions-- what kind o
f actions does the authenticated principal want to perform? And let's talk about this in the next few sli
des. We'll talk about each of the individual pieces in here.

Well, the first thing you need to understand is, who is a principal? Think about principal as an entity t
hat is allowed to interact with OCI resources. Now, there are two kinds of principals which are possib
le in OCI and, in general, any kind of system you're designing. The first one are the actual people. S
o
let's call them users. And then the second one is something called Instance Principals. We'll talk abo
ut what those are, so just hang on for a minute.
First, let's talk about IAM users and groups. Well, we talked about users are individual people. These 
can be applications also. But typically, let's just keep them to individual people. So like a storage ad
min wants to use your resources in OCI, so that is a user. You have a network admin who is
a user and so on and so forth. You can have other users as well

The first user in case of OCI is always the default administrator. And the default admin sets up other 
IAM users and groups, which seems pretty straightforward. Now, in OCI, users enforced security pri
nciple of least privilege. What that means is a couple of things. Users have to belong to groups. And 
then groups need to have this thing called a policy, which has some kind of a permission to either a 
whole account-- so "tenancy" means your account-- or a compartment within that account.

If these two conditions are not met, users have no access, meaning if you create a user, and you do
n't put this user in a group and don't write a policy for this group, this user cannot use any of the OCI 
resources, has no access to any of the
OCI resources. And we'll talk about this in more details in the next few slides.

There is also this concept of Instance Principal. And in this case, think about a normal principal being 
a user. You are making an instance a principal. That's a good way to think about it. Instance Principa
l lets instances and applications, of course, running on top of those instances to make API calls agai
nst other OCI services, removing the need to configure user credentials or a configuration file.

In typical situations, what you will do is you would keep this user credential and a config file running 
on top of your instance. And let's say the instance wants to talk to an object storage bucket here. It w
ould use that config file to authenticate this particular instance against the object storage. Now, this i
s a clunky way to do security because of lots of issues-- so things like you're taking your keys, et cet
era.

So the better way to do it is designate this particular instance as a principal, as an Instance Principal. 
In that way, this instance can make calls to object storage without needing any of these credentials o
r configurations. It's a much cleaner, much better solution.

Well, we talked about compartment in the OCI architecture module. Let me just quickly revisit it. A co
mpartment is nothing but a collection of related resources. So you have your network resources. You 
put them in a compartment called "Network." You
have some storage resources. You could put them in a compartment called "Storage."

And of course, you don't have to call it Network and Storage. You could have any kind of compartme
nts either by your resource types. You can have compartments by your geographic location, so you 
can have a North America, you can have an EMEA. You can have compartments based on your proj
ects. You can have compartments based on your organizational hierarchy.

There
are multiple ways you could create compartments. And there is a whole best practices on what to do
, how to do, how to create these compartments, et cetera. And you can check out that advanced cou
rse.

What compartments basically help you do, it helps you isolate and control access to your resources. 
So the whole idea of doing compartments is to isolate your resources. Your networking resources go 
here. Your storage resources go here.
So you could put all of them in one like a kitchen sink, everything in one place but that's not a good d
esign principle. It's not a good way to isolate your resources. Now, each resource belongs to a single 
department. So resources don't belong. One resource cannot be part of multiple compartments.

Resources can interact with other resources in different compartments. So this block storage, there i
s the compute instance here. It can use this virtual cloud network. It doesn't have to be in the same c
ompartment. It can live in some other compartment.

You can give a group of users access to compartments by writing policies. And this is what we are g
oing to talk a lot more in
detail in the subsequent slides. But I want to give you an idea that, once you create a compartment, 
you put your resources in there, even if you have users, you have groups, if you don't write a policy, 
basically those users in those groups cannot access the resources.

And like we talked about, your root compartment, your tenancy-- also called as
root compartment-- can hold all cloud resources. Best practice is to create dedicated compartments l
ike you have here. And why? Again, the idea being you want to isolate your resources.

Well, so let's look at the picture we just saw in the beginning of this module. You have your account. 
We have two compartments, Network and Storage. Network resources are in
Network compartment. Storage resources are in Storage compartment.

Now, you have a set of users. Let's say these users are network admins. So you create a group calle
d a Network Admin Group. So that's your step number 1. You put these users, add these users as p
art of this group. Of course, you will first create the users, then create this group, add the users to th
e group.

And then the second step is you write a policy for this particular compartment. Let's say if you want t
hese guys to access these resources, and then they will be able to access these resources. And the 
same thing goes for, let's say, you have a separate set of people, let's say they are storage admins i
n a different compartment. And you could give them access like that.

And, of course, this is a very simplified diagram and picture. But in reality, it will be more complex. A
nd you will have heterogeneous kind of resources, and different kind of policies where you attach the 
policies, et cetera, et cetera.

So let's quickly talk about two of the most common things you have to encounter when you design a
ny kind of identity solution. And that is authentication and authorization. So this absolutely is a must. 
And every system handles it in a different way. Let's talk about how OCI does
this, Oracle Cloud Infrastructure does it.

So authentication basically deals with user identity, very simply. So basically, it is about who is this p
erson who is trying to come to your system, authenticate herself to the system. Is this who she says 
she is? That's literally what you are trying to do with authentication. In case of OCI, authentication is 
done in three different ways.

The first one is very simple-- username, password. This is common you
do this many times a day accessing many systems. You have usernames, your passwords. You aut
henticate yourself saying I'm the principal, this is my identity, let me
in. And the system lets you or not let you in.
The second one is API signing keys. This is used when you use the OCI API in conjunction with the 
SDK and CLI. Because think about you're using SDK or CLI. They need to authenticate-- your applic
ations need to authenticate themselves against the services, saying, this is an authenticated principa
l, let me in. Otherwise, it's a security issue.

So when you do that, there's something called an API signing key. And this whole documentation is t
here on the site, on the doc site. But a basic idea being, you provide the public key, and then you hol
d the private, keep it to yourself. And when you make the request, you sign the request with your priv
ate keys. This is the public-private key encryption, which is, again, very common model for the cloud 
space.

And then the third one is called auth tokens. So think about this as another model where the third pa
rties, any kind of third party APIs, that
do not support this particular approach can use somebody call an auth token. The very obvious one 
here is ADW, Autonomous Data Warehouse, which uses auth token to authenticate against OCI serv
ices.

All right. So let's talk about authorization. Authorization basically specifies various actions an authent
icated principal can perform. So once you authenticate somebody, what is she supposed to do in the 
system? What actions can she perform in the system? That is basically authorization. Authorization i
n OCI is done by writing these things called policies. We talked about them earlier.

Policies are written in human readable format. So you say, "allow group." You never say "deny group
." So everything is denied by default. That is a security principle of least privilege-- everything denied
, zero trust model. So you say "allow group." You're allowing somebody like a group of user, your gro
up name, to do something-- that is your verb here-- on some resources, either in your tenancy or in
your compartment, specific compartments. And you can also make these conditional.

But the idea is that these are very human readable lexical statements. Now, important to keep in min
d, policies attachment can be attached to a compartment or can be attached to an account. The sim
plest way is you just attach it
to the account. Where you attach it controls who can modify or who can delete it. And we talked abo
ut not in this module but earlier that compartments can be nested. So they can be six levels deep.

So then it becomes complex where you attach your policy, who has access to that particular level of 
your subcompartment, and so on and so forth. Simplest, attach it to the tendency. But keep in mind. 
Where you attach controls who can modify it or who can delete it.

All right. So let's look at a little bit more detail into the policy. And again, these things are just, I'm goi
ng a little deeper. In the foundational course, you don't need to write policies or anything. But just, it's 
good to know a little bit more on what these policies look like.

So we said earlier, allow group, that there's a group here. And there's some special conditions where 
there's also something called any-user, where you can specify that. But that's really boundary case. 
So most of the times, it's allow group, group name, to do something on some resources in a location-
- location can be your tenancy or compartment. And you can do a conditional statement. You could 
write a condition, well, make it more complex.

So what the two most important things here-- what kind of verbs are there? Verbs are nothing but yo
ur actions. What can I do in my account? So there
are four kinds of actions you can perform. You can inspect resources. You can read resources.
You can inspect resources. You can read resources. You can use resources. Or you can manage re
sources. Manage gives you all permissions. These permissions are cumulative.

So as you come down, read includes inspect plus. Use has read plus-- so everything here, everythin
g here, and then it comes here. And so the main thing to keep in mind is, most of the times you will b
e using use or manage. The difference is, manage gives you all the permissions. Use gives you read 
and update. But you cannot create or delete.

And this is true for most of the resources. But then specific actions vary by specific resources. So yo
u should always check out the documentation if you're writing a policy to see what kind of policies yo
u're writing and what they will do.

Now, resource type. So this is kind of the verb, the actions. I can create something. I can delete som
ething. I can update something.

What are the resource types? Well, resource types are the resources in the cloud in OCI. So if you w
ant to deal with just everything, just hit all-
resources, meaning everything you create. Everything you create in OCI is a resource. Or you would 
say, I want to limit somebody only to database. Or I want to limit something to just instance. And so o
n and so forth.

So you could do all-resources, meaning everything. These are aggregate resource types. Or you co
uld do database-family, instance-family, object-family, et cetera. Or you could actually go very granul
ar, to individual resource types. So for instances, you could just say instances, for example. Or
you could say images or volume-attachments, and so on and so forth.

And again, the list is very exhaustive. So I'm showing here some dotted lines, meaning you should g
o in the documentation, check it out. Idea being, you can control what kind of actions an authenticate
d principal can perform.

And then you can also control the actions can be performed on which resources. Is it at the aggregat
e level, the all up, all-resources? Or is it just databases? Or is it just compute? Or even be below that
? Is it something below compute, just on instances, or images, or so on and so forth. So it gets you
very granular controls.

Now, let's make it real by using an example we have seen earlier in the compute module. So you ha
ve a compute instance running. This is running in compartment-- sorry, the compute instance is runn
ing in compartment ABC. Your block volume is also running in compartment ABC. The virtual cloud n
etwork can be running in tenancy, or it can be running in like some other compartment, which is perf
ectly fine.

We talked about resources in one compartment can talk
to resources in other compartments. They don't need to belong to the same compartment. We talked 
about that.

So this is your setup. So for this setup to work, what kind of basic identity policies you'll have to write 
for, let's say, a group of users who want to create this instance to work? So the first thing you have t
o do, there's sort of two different groups of users here.

The first group of users are network admin. You don't want people in your environment to manage a
nd create virtual networks, because it's
a security issue. But these guys actually manage a cloud network. So they create, delete, update, ev
erything.

So you write a policy like this-- NetworkAdmins, allow group NetworkAdmins to manage virtual-
network-family, meaning everything. They can do VCNs. They can do subnets. They can do route ta
bles, security list, et cetera, in tenancy. So these guys have access to the whole account.

You could have said that network belonged to a particular compartment and written a policy just for t
hat compartment. But these guys have a policy which actually is at the tenancy level. So they
have access to the whole tenancy.

And then you have another set of people. These are your second set of people. And so that's why yo
u see this group is different. It's called InstanceLauncher. So these people are just launching instanc
es. And so what kind of policies would you write for them to be able to launch instance? Of course, y
ou're launching an instance, so you will give them the full manage capabilities for that instance.

So you say manage, which gives you all permissions, instance-family, meaning everything with insta
nces. So you are giving this access. And then you're saying in compartment ABC. So these guys ha
ve access only to this particular compartment. If there is another compartment here, and if you don't 
write a policy, these guys will have no access to that compartment.

So first thing is you do that. You give them manage all permissions instance-
family, meaning everything in instances. And then what are these two additional policies here? Well, 
let me talk
about this one first. Instances depend on the virtual cloud network. We talked about this. There's a p
hysical link, there'
a virtual link. And this is where you put your IP addresses, you put your security list, you put
your security group-- well,
security list actually goes on subnet. But you put network security groups, et cetera.

So instances cannot be launched outside the network, because they need to communicate, et cetera
, to other instances through the internet. So they launch within a virtual cloud network. And they laun
ch specifically within a subnet. So for these guys, for this policy to work, it
you just write this policy, you don't have these policies, you cannot launch an instance. Why? Becau
se it needs to use the virtual-network-family.

But in this case, you don't need to create a virtual-network-family. You're just saying use, because I c
an just read. Or I might update something, but I can just read it. So I don't need to do-- I don't need t
o manage action there, work there.

Similarly, these disks are already created. Somebody created these disks. So that's why you're sayin
g use volume-family, because I can read this boot disk and block volumes. If you didn't want to do th
at, you wanted to create it from scratch, you would have just changed the use to
say manage, meaning they can create, update, delete, et cetera.

So this is a common example, very common example, of how you would write policies. Just rememb
er, if you don't have these policies written, even if you create users, put them in groups, they cannot 
actually use any of the resources.

Well, that's it, folks. This was a short module. We quickly talked about Identity and Access Managem
ent service, the two main things it deals with-- identities, principals, and permissions, policies-- identit
ies meaning people saying who they are. And then you authenticated them using the various authent
ication mechanisms we saw.

Permissions basically means authorization. Once somebody is authenticated, what kind of specific a
ctions they can perform. And the authorization is done through policies. We looked at the very basic 
syntax of policies. And we looked at a common example where you would be using policies, of how y
ou would be using policies.

Well, I hope you found this information useful. Thank you for your time.

OCI Databases Servicec:

Hello, everyone. Welcome to this course on Oracle Cloud Infrastructure foundations. My name is Ro
hit Rahi, and I'm part of the Oracle Cloud Infrastructure team.

In this particular module, we are going to look at the various database services offered by Oracle Clo
ud Infrastructure. Specifically, we are going to look at the different options, and then talk about what 
we have-- DBs systems-- what we call them as managed database offerings, called DB systems. We
'll look at the two unique characteristics for backup, and high availability, and disaster recovery, two 
of the most important things for any of the database. And then finally, we'll look at autonomous datab
ases.

This is a foundation lecture, so I'm not going to dive deep into lots of details here. But hopefully, this 
should give you a quick overview of the different options we have available with Oracle Cloud Infrastr
ucture. The first option we have is what we call as VM DB System, or Virtual Machine DB Systems.

With this option, basically you get a virtual machine where you have a managed Oracle Database in
stance running. And you have different shapes-- these use block storage. And there is also somethin
g called fast provisioning available here. So you can provision your databases really quickly.

And in that case, we use something called logical volume manager instead of ASM-- the standard A
SM option you get with Oracle databases. And again, you can read about all of the details here. But t
his particular offering is about running your managed Oracle Database in a virtual machine along wit
h leveraging the block storage, which OCI provides.

The second option is called bare metal DB systems. In this case, as the name suggests, you are run
ning the Oracle database in a bare metal machine. And these are 52 core bare metal machines. You 
get 51.2 terabyte local storage. So here, you are leveraging the local storage, and the idea here is th
at you get really fast performance.

The third option is what we call as Oracle RAC. And Oracle RAC enables you to cluster Oracle datab
ases. In case of Oracle RAC, servers share a disk and have the same Oracle Database, but with diff
erent instances running on each node here.

If one node fails, a connection failover to the other nodes. The instances themselves don't failover be
cause they are just the processes on each server that acts
as the same data. Oracle Database is available from any of the nodes in the cluster.

So we have RAC available and the shape we have here is a two node VM RAC. but this is a manag
ed offering, and it's available out of the box for you to leverage. Idea here is you get managed high a
vailability.
Third option-- or the fourth option is Exadata DB systems. And basically, this is a managed accelerat
or infrastructure, including servers, storage, networking, firmware, hypervisor, et cetera, all managed 
by us, and you can leverage Exadata as a service. And finally, we have autonomous, and the three k
ey characteristics of autonomous which we talk about are self-driving, self-securing, and self-
repairing.

What it means-- self-driving, we automatically patch, upgrade, tune without requiring any human inte
rvention or downtime. We also support things like online scaling of CPU and storage. Self-securing b
asically means that we have encryption by default, and we also have features like Oracle Database 
Vaults and Oracle Data Safe, which helps you identify sensitive data and mask it.

And then finally, what we mean by self-repairing is we automatically protect from all types of downtim
e, including things like system failures, maintenance, et cetera. So really, it's a continuum like you sa
w with compute, storage, et cetera-- same concept here. And you have different options with some d
ifferent characteristics. And depending on what you are looking for, you could use one service or ano
ther.

Now let's look at some of the DB system capabilities first, and then we'll talk about autonomous. So y
ou can see a bunch of options we talked about-- the VM DB systems, the bare
metal DB systems, Oracle RAC that you cluster your DBs, Oracle Database, and then Exadata. Well
, that's the first thing-- you get different kind of options. Depending on your use case, you could use 
one or another.

We have complete lifecycle automation, whether it's provisioning, backup, patching. All that is suppo
rted. We support things like RAC-- we talked about that briefly. Also Data Guard, we'll talk about wha
t that is. We also support dynamic CPU and storage scaling, and we'll look at which option supports 
what.

Your bare metal supports CPU scaling, your virtual machines support storage scaling. Why? Becaus
e it makes sense. These use block storage, block bare
metal uses local storage, so you can change the CPU but not the storage. Virtual machine, you coul
d change the storage, not the CPU.

And then there are lots of security options available. Encryption, using OCI like Identity, et cetera, et 
cetera. And then finally, we also support bring-your-own-licenses. So if you have on-prem licenses, 
we talked about that in the pricing module. You could actually use those licenses in the cloud.

Well, we talked about that. You could start, stop, reboot DB systems. For bare
metal DB systems, the
billing continues in stop state because, again, you're using a bare metal machine-- has local storage, 
so you're paying for that. Virtual machine DB systems, you don't.

Scale we talked about. You can scale the number of CPU cores for bare
metal. For virtual machine, you can scale the amount of block storage [INAUDIBLE]. Patching we su
pport-- it's a 2-step process. First, you patch the server where the DB system itself, and then you pat
ch the database which is on top of that.

Now the important things to keep in mind when you're talking about databases are things like backup 
restore, high availability, disaster recovery, and performance. But this is a foundations course, so we 
are going to skip performance. But let's talk about backup and restore because that's a key design c
onsideration.
So we talked about some of these constructs earlier. You have
a region, you have availability domain, you can have one or three-- in this case, I'm just showing one
. You have a virtual cloud network running here, and then you are running a DB system within that n
etwork. This is running in a private subnet, so it's not accessible by entities outside on the internet, fo
r example.

Now we also talked about in the networking module a gateway called service gateway, which lets yo
u take backups from the database to Object Storage. And Object Storage, if you remember, is a publ
ic service, so
it has a public endpoint. But the fact you are using service gateway, what it does is it lets private end
points, like
the DB systems which doesn't have a public IP address, talk to Object Storage which has a public IP 
address and a public endpoint.

And the traffic is still secure-- it stays on Oracle network backbone-- it doesn't go to the internet. So t
hat's basically what service gateway does. Now using that, you could do manual backups, you could 
do automatic backups.

Automatic backups, as you see here, are written to Object Storage. There is
a particular window in which it runs. You could keep the backups for 7 days, 15, 30, 45, or 60 days. 
And you can always archive it in Object Storage for long-term archival, but these are the preset reten
tion periods we support.

And you could recover the database. So let's say the private database has a problem-- you could al
ways recover from your backups. And there
are different options for recovery. Well, let's look at disaster recovery because, again, this is one of t
he key considerations.

We looked at backup and restore. Let's look at disaster recovery. So a similar example as before, we
have a region. Now I'm showing three ADs, and we'll talk about a region with one AD as well. So let'
s say you're running a primary DB here, and of course, this is sensitive-- it has all your data. You wa
nt to protect that data.

So we have a capability in Oracle called Oracle Data Guard which provides a set of services that cre
ate, maintain, manage, and monitor one or more standby databases to enable Oracle Database to s
urvive disasters and data corruptions. So the way it works is a Data Guard configuration consists of 
one primary database and one or more standby databases. Now in case of OCI, we support only on
e standby, but in on-prem, you could actually have one or more.

Once you create a Data Guard configuration, as you see here, Oracle Data Guard automatically mai
ntains each standby database by transmitting redo data from the primary database and then applyin
g the redo to the standby database. So if the primary database becomes unavailable because of a pl
anned outage or an unplanned outage, Oracle Data Guard can switch any standby database to the p
rimary role, minimizing the downtime associated with the outage.

So this becomes primary in case of an outage, and then you could work on your primary database. A
nd you could do the-- so vise versa, you could move it back to primary again. There is also this thing 
called Active Data Guard. Active Data Guard extends Data Guard by providing advanced features fo
r data prediction and availability.
For specific Oracle versions, like Extreme Performance Edition and Exadata, it is included by default. 
Otherwise, you have to pay for that. And as we talked about, there are two modes for data. One is c
alled switchover, which is planned migration.

So suppose you want to test your data, there is no data loss. You could switchover. Like we just talk
ed about, the primary becomes unavailable, you could switch over to standby, the standby goes to th
e primary role. You minimize the downtime.

There is also a mode called failover which is unplanned migration. So let's say this availability domai
n has a problem, has an outage, something goes wrong, you could always do a failover. In this case, 
there is a minimal data loss. And then there are ways to mitigate that, but this is one option you have 
for disaster recovery with Oracle Cloud Infrastructure databases.

Now Oracle has this best practices called Maximum Availability Architecture-- MAA. And
I would highly recommend that you actually read about that. And as part of that, one of the best pract
ices guidance is to do both higher availability and disaster recovery together, because you have opti
ons to do that.

Now we talked about in the previous examples, we looked at the primary and standby as a single ins
tance Oracle Database-- we add just one single instance. But there is nothing which stops you from 
making a primary and secondary RAC database. Now we talked about RAC in the previous slides. L
ets you cluster your Oracle databases, and if there is a problem with one of the nodes, the connectio
n failover to the other nodes.

So this way, Oracle Database is available from any of the nodes in the cluster. And basically, what y
ou get is high availability. So let's look at the previous example, which we saw in the previous slide. 
Now in this case, you have again three ADs within a region, you have a virtual cloud network running 
here.

You have within an AD-- we talked about this in the OCI physical architecture module-- you have thr
ee fault domains of this. There it's a single AD region or multi-AD region. And AD always has three f
ault domains.

Now what you can do is you could create a RAC database in this AD. And one thing which I want to 
also bring up is when you create a RAC-- this is a managed RAC offering-- when you do that, autom
atically, the system is intelligent enough
to put the primary in fault domain 1 and the second node in fault domain 2.

Why? Because of fault domain 1 can become unavailable for some reason. And the whole idea of a 
RAC is to provide you high availability. So if this is unavailable, the connections actually switch over t
o the second one.

So we have to make the services fault tolerant ourselves, and this is something which we do transpa
rently for you. You don't have to choose because of our excellence around making things fault talent 
to the maximum extent possible. So this is how you create a RAC.

Now for AD 2, you could do the same thing. You could have another RAC here, and then what you c
ould do is you could establish Data
Guard between them. So literally then this becomes your primary database, and these becomes you
r secondary databases.
So if there is an issue within, let's say, fault domain 1, you still have your database running. Same
thing with your AD 2-- if there is an issue, you still have your database running. Let's say if the whole 
AD has an issue-- is unavailable for some reason-- you can always switchover to your AD 2, and you 
still have your database up and running.

So this way, by using HA-- High Availability-- and disaster recovery together, or using RAC plus Data
Guard, you are guaranteeing the maximum availability for your database. And again, I highly recom
mend to read
a little bit more on maximum availability architecture. There are lots of other capabilities, lots of other 
features.

It gets very complex. This is a foundations course, so hopefully this gives you a good idea. Now what 
happens in case of a single AD region? Everything we talked about is great if you have a multi-AD re
gion, fine, I understand that. What happens in a single AD region?

Now the same thing-- now you have a region. Now we have one AD here-- I think I'm not showing th
e AD boundary here, but let's say this is one AD. Within the AD, you have three fault domains.

Now what you do is like the previous example, you create a RAC, and system automatically puts the 
first node in fault domain 1. It puts the second domain in fault domain 2-- the system does that autom
atically. Now what you will do is you create your secondary databases, but since you don't have four 
fault domains, one of the domains will have both the primary and the secondary database.

And this can be in a separate fault domain. And the system again takes care of that. And then of cou
rse, you know you can establish Data
Guard between them. Now this is what it says-- primary and standby are two node RAC. Both are in 
the same AD.

Only one of the two nodes of the standby database can be in a fault domain that does not include an
y other nodes from either the primary or standby database, meaning this is-- only one of the two wou
ld not share its space with either the primary or the secondary rewrite. So now let's say fault domain
1 becomes available. You still have your database running.

If fault domain 3 becomes available, you still have your database running. If fault
domain 2 becomes unavailable, you still have your database running. So still sort of
you get this high availability, but just it's a different kind of a design paradigm compared to a multi-
AD region, so just keep that in mind. But it's sort of a best practice-- if you have one AD, you could st
ill go ahead and use RAC along with Data Guard.

And this is where optimal architecture-- we recommend that you read more
on this and use it. So this brings us to the final part of the module, which is autonomous databases. 
We talked about autonomous databases, self-repairing, self-securing, and self-tuning.

There are three-- there are two different modes called shared and dedicated. Let's talk about them in 
a little bit more detail. So first, before we get into that, there are two kinds of workloads which are su
pported with autonomous.

One is Autonomous Transaction Processing, also called ATP. The other one is called Autonomous D
ata Warehouse, sometimes called ADW. But this is for OLTP transaction processing uploads. This is 
for OLAP Analytical Processing workloads. Makes sense.
There are two kinds of deployment options. You have dedicated, where you have exclusive use of th
e Exadata hardware. Now all this autonomous is running on Exadata, so you get full access to the E
xadata hardware. In this case of shared, you provision and manage the autonomous DB while Oracl
e handles Exadata the infrastructure deployment and management.

And both these options support both ATP and ADW. So why use autonomous? And we talked about 
the three key characteristics of self-repairing, self-tuning, self-securing, self-driving.

The idea here is there are lots of tasks which get automated with autonomous. Backing up the datab
ase-- you don't have to initiate the backup. We do that automatically for you. Patching the database, 
including maintenance without any downtime.

Remember, we talked about self-repairing. We do automatically protect from all types of downtime, i
ncluding those that happen with patching and maintenance-- we do that. Then upgrading the databa
se-- we again take care of that, so it's sort of seamless to you.

And then finally, we talked about self-driving. We tune the database, automatically patch, upgrade to 
the database without human intervention or downtime. So that brings us to the conclusion of this mo
dule. These are the DB services we talked about at a very high level-- at a
glance, very high level management.

For the VM DB, and the bare
metal, and Exadata, it's customer's responsibility. In case of autonomous, it's Oracle's. Makes sense. 
Updates-- you can see customer initiated. In case
of shared, it's automatic. In case of autonomous dedicated, it's something called customer policy con
trol. So you control how you apply your updates.

Scaling storage is the scaling supported by VM DB. Why? Because it uses block storage, so you cou
ld change that. In case of bare
metal DB systems, it's CPU. Exadata, you could actually change the CPU within an Exa configuratio
n.

And across Exa racks, you could always change storage. You could go from a quarter rack, to a half 
rack, to a
full rack. Autonomous, you could scale both CPU and storage. But this is again a reason why you wo
uld use autonomous-- because you could online scale both CPU and storage.

And you could see some of the things around backups-- customer initiated still automatic. But custo
mer initiated, in this case, it's automatic. You don't even have to say-- we do that for you. And you co
uld see storage, rack some of the Data Guard options.

So this is a foundation course. Hopefully, this gives you a quick overview of the different services we 
offer, and the different use cases for those services. So that's it, folks. In this module, we looked at th
e various DB options.

We dived a little deep into DB systems-- what are
the different operations you could perform. We looked at the two important considerations with any d
atabase offering-- managed database offering, how you do backup and restore, and then how do yo
u do high availability disaster recovery. And then finally, we concluded the module by talking about a
nonymous databases. Thank you so much for your time. I hope you found this information useful.
Notes

This section contains the notes for the certification topics for quick
reference and its the biggest section in this article :) If you want,
you can skip it and jump to the next section.

OCI Architecture

 OCI Regions — 21 Available + 15 Planned; Commercial, Govt,

Microsoft Azure Interconnect

 Region — Localized Geographical area comprised of 1 or more

AD

 Availability Domains — One or more fault-tolerent, isolated DC

located within a region, but connected to each other by low
latency, high bandwidth network; Do not share physical infra

 Fault Domains — Grouping of hardware and infrastructure

with in an AD to provide anti-affinity(logical data center); 3 FD
per AD; Do not share SPOHF; change procedures are isolated
at FD

 One AD Regions — within one year second AD or region will be

made available
 Choosing Region — Location, Data Residency & Compliance,
Service Availability

 Avoid SPOF — Design architecture to deploy instances that

perform same tasks in different FD or different AD for multiple
AD regions

 Data Guard — Data replication across AD

 HA Design — FD, AD, Region Pair

 Compartments — collection of related resources; helps to

isolate and control access to resources; Tenancy/Root
compartment; Compartment Network, Compartment Storage
etc;

 Each resource belong to a single compartment; Resource can

interact with other resource in diff compartment; Resources
and compartments can be added/deleted anytime;

 Resources can be moved from one to another; Resources from

multiple regions can be in the same compartment;
Compartments can be nested (6 levels deep); can give group of
users access to compartments by writing policies; Analyze cost
and assign budget for resources in compartments

OCI Compute Services

 Bare Metal — Code, App Container, Language Runtime, OS,
Virtualization; No virtualization

 Dedicated Virtual Hosts — Code, App Container, Language

Runtime, OS;

 Virtual Machines — Code, App Container, Language Runtime,

OS; Guset on a host server with hypervisor based
virtualization;

 Container Engine — Code, App Container (Docker);

 Functions — Code; Consumption based pricing

 BM — Direct Hardware access; Single Tenant server; Use Case:

Performance intensive workloads (DB), workloads not
virtualized; workload that require specific Hypervisor,
workload requires BYO licensing (SQL, Exchange etc)

 VM — Multi-tenant VMs; Use cases: to control all aspects of

env, to deploy legacy app running on windows/linux, to move
apps from on-premise to OCI

 Dedicated Virtual Host — Single-tenant VMs

 Instance Basics — various instance sizes(CPU, RAM,

Bandwidth); Support both Intel and AMD processors; Provide
GPU and HPC instance options(RDMA); instance placed on
virtual network with powerful connectivity options; Depends
 on other OCI services such as Block volume (Boot(OS)/Data)
and VCN(Virtual Nic)

 Vertical Scaling — Scale up/Down; Downtime required;

 Autoscaling — Enable large scale deployment of VM from a

single gold image with automatic configuration; Scale
out/Scale in; If one VM fails, others will keep working; based
on metrics; Running Instance -> Config (Gold Image — OS
image, metadata, shape, vNICs, Storage, subnets) -> Instance
Pool (put in diff ADs, Manage all together) -> Scaling Rule

 How to Deploy containers?

1. Manually SSH into machines and run Docker
2. Scripting or Config mgmt tools
3. Orchestration Systems

 Oracle Kubernetes Engine — K8S; Containers in Pods, Pods in

Node (Instances); OKE and OCIR

 Functions — small but powerful blocks of code that generally

do one simple thing; stores as Docker image; invoked in
response to a CLI command or signed HTTP request Push
container to Registry -> Configure Function Trigger -> Code
runs only when triggered -> Pay for code execution time only;
based on FN project

OCI Storage Services

 Block Volume, Local NVMe, File Storage, Object Storage,
Archive Storage

 Storage Requirements — Persistent vs Non-persistent, What

type of data?(Database, videos, audio, photos, text),
Performance (max capacity, IOPS, throughput), Durability
(Copies of data), Connectivity (Local vs network, How does
apps access the data), Protocol (Block vs File vs HTTPs)

 Block Storage — Hard drive in a server(on a remote chassis);

stored on device in fixed sized blocks (512 bytes); Access by OS
as mounted drive volume; Storage for compute services; 2
types (Boot Volume/OS Disk, Block Volume/Data Disks) Use
cases — Databases, Exchange, VMWare, Server Boot. Block
volume stores replica of data in 3 separate FDs; No need to
configure s/w based protection(RAID-10 etc); Periodic backups
(automated schedule backups);

 Block volume backup — Complete point-in-time snapshot copy

of block volumes; Encrypted and stored in Object Storage and
can be restored as new volumes to any AD within same region;
Can copy block volume backups from one-region to another(X-
Region Backup); Backups can be scheduled

 Block Volume Tiers — (50 GB — 32 TB, up to 32

volumes/instance (32x32=1PB); Data encrypted at rest and in-
transit(oracle managed/customer managed key)
* Basic(2 IOPS/GB, 240 KB/s/GB Throughput); throughput
 intensive workloads with large sequential I/O such as big data
& streaming, log processing and data warehouses.
* Balanced (60 IOPS/GB, 480 KB/s/GB); most workloads that
perform random I/O such as boot disks
* High Performance (75 IOPS/GB, 600 KB/s/GB); workload
require best possible performance including large DB’s

 Local NVMe — temp storage, locally attached to compute

instance; app require high performance local storage; Use case
— NoSQL DB, In-memory DB, Scale-out txn DB, Data
warehousing. Storage non-persistent but survives reboot. OCI
uses NVMe(Non-Volatile Memory Express) interface for very
high performance. OCI provides no RAID, snapshots, backup
capabilities

 File Storage — Hierarchical collection of docs organized into

named directories which are themselves structured files.
Distributed file systems make distributed look exactly like local
file systems. Distributed file standards — NFS and SMB
(provide access over networks). FSS — supports NFS v.3; Data
protection: Snapshots(10000 per file system); Security (Data at
rest, in-transit encryption). Use cases: Oracle Apps, HPC, Big
Data and Analytics, General purpose file systems. FS —
replicates data in 3 FDs; can take snapshot and restore
snapshot

 Object Storage — All data, managed as objects; Each object

stored in a bucket, relies on standard HTTP verbs; flat
 structure; OSS — An internet-scale, high performance storage
platform; ideal for unstructured data;
regional service; storage classes (hot/cold); Use cases: content
repo for data, images, logs & video etc; Archive/Backup,
Storing log data for analysis; Storing large datasets; Big
Data/Hadoop storage
OS replicates in 3 FDs; stores replica of data in more than AD

 OS Tiers — Standard Storage Tier(Hot) Fast, immediate, and

frequent access; Data retrieval in instances; Always serves the
most recent copy of the data when retrieved; Standard buckets
can’t be downgraded to archive storage. Archive Storage Tier
(Cold) Seldom or rarely accessed data but must be retained and
preserved for long periods of time; 10x cheaper than standard
tier ($0.0026 vs $0.0255 Gb/month);
90 days min retention period; objects needs to be restored
before download; TTFB after restore request is made: 4 hours;
Archive bucket can’t be upgraded to Standard

OCI Network Services

 Virtual Cloud Network — software defined private network that

you setup in OCI; Enable OCI resources to communicate

 VCN address space — Address space 10.0.0.0/16; Every

resource will get its own unique private IP address; subnet —
divide VCN into one or more sub networks;
 Gateways — IGW; Public Subnet(DMZ);

 NAT Gateway (Blocks inbound connection)

 DRG — virtual router that provides a path for private traffic

between your VCN and destinations other than the internet;
DRG to establish a connection with on-premises network via
IPsec VPN, FastConnect(private, dedicated connectivity)

 Service Gateway — Communication to public OCI services —

access without using internet

 Peering — process of connecting multiple VCN; Local VCN

peering (same region); Remote VCN peering (Different Region)
No transitive peering
VCN Security — Firewall rules (Subnet layer); Network
Security Group (VNIC layer)

 Load Balancer — sits between client and backends; performs

tasks such as: Service Discovery, Health Check, Algorithm. LB
Benefits — Fault tolerance and HA; Scale; Naming abstraction.
LB Types — Public LB, LB pair for HA

OCI IAM

 IAM — Identities, Permissions

 Principals — IAM entity that is allowed to interact with OCI

resources; IAM users and Instance Principals
 IAM Users and Groups — 1st IAM user is default admin; Users
-> Groups -> at least one policy

 Instance Principals — let instances make API calls against

other OCI services

 Network Admin, Storage Admin etc — Policies

 Authentication — deals with user identity;

Username/Password, API Signing key, Auth Tokens

 Authorization — actions performed by principals; Policies;

Allow group <> to <> resource-type in tenancy/compartment
where conditions <>
Policies — Allow <subject> to <verb> <resource-type> in
<location> where <conditions>
Verb — inspect(list resources), read(inspect_user-specified
metadata), use (Read+Update), manage(all permissions)
Resource type — all-resources, database-family, instance-
family, object-family etc

 Common Policies — Network admin(manage virtual-network-

family), Instance Launchers(manage instance-family, use
volume-family, use virtual-network-family)

OCI Database Services

 OCI DB Options — VM (Fast Provisioning), Bare metal(Fast

performance), RAC (Managed HA), Exadata DB
 systems(Managed Exadata Infra), Autonomous —
Shared/Dedicated(Self-driving, Self-Securing, Self-Repairing)

 DB Systems — Managed DB systems, Complete Lifecycle

automation (Provisioning, Patching, Backup & Restore), HA
and DR (RAC & Data Guard), Scalability (Dynamic CPU and
Storage Scaling), Security (Infra(IAM, VCN, Audit),
Database(TDE, Encrypted RMAN backup/Block volume
encryption)), BYOL

 DB Systems Operations — Launch, start, stop or reboot DB

systems(Billing continues in stop state for BM DB systems),
Scale (CPU cores (BM DB), Storage(VM DB)), Patching (2 step
process, For Exadata and RAC patches are rolling)

 DB Systems Backup — Manual/Automatic Backups, Auto

backups written to Oracle owned Object storage buckets, Runs
between midnight — 6 AM in DB system time zone, Preset
retention periods: 7, 15, 30, 45 and 60 Days; Recover DB from
backup stored in Object storage(Last known good state,
Timestamp specified, Using SCN)

 DB Systems HA and DR — Oracle Data Guard — survive

disasters and data corruptions (maintain sync between primary
and standby DB); Active Data Guard (adv features for data
protection and availability, included in Extreme Performance
edition and Exadata service); 2 modes — switchover(planned
migration, no data loss), Failover (unplanned, min data loss)
 MAA — Primary and standby DB can be either a single-
instance oracle db or RAC db

 Autonomous Databases — Fully managed DB with 2 workload

types; TP, DWH; Deployment options — Dedicated/Shared;
Automates backing up DB, patching w/o downtime, Upgrade
DB, Tune DB

OCI Security

 Shared Security Model — OCI upto virtualization; Customer

(Patching app and OS, OS config, IAM, Network security,
Endpoint protection, Data Classification and Compliance)

 Security Services — OCI IAM, MFA, Federation, Storage and

DB services, Data Safe, Key Management, OS Management
Service, Bare Metal, Dedicated VM hosts, VCN, NSG, SL, WAF

 IAM — RBAC; Authentication -> OCI IAM -> Authorization ->

Compartments -> Resources; MFA; SSO using IDP

 Data Protection — Block volume (Data enc at-rest/in-transit,

BYOK) File Storage (Data enc at-rest/in-transit, BYOK) Object
Storage (Data enc at-rest, BYOK, Private Buckets, Pre
authenticated requests) Database(TDE, Data safe, Data Vault)
Key Management (BYOK, use HSM)

 OS & Workload isolation — OS Mgmt service configured by

default for Oracle Linux; Network protection — Tiered subnet
 strategy for VCN, Gateways, Security Lists, NSG, OCI WAF
(XSS, SQL Injection), Protection against layer 7

OCI Pricing and Billing

 Pricing Models — Pay as you go; Monthly Flex (Universal

Credits) $1000 monthly charge/12 months -> 33% — 60%
savings vs PAYG; BYOL (apply on-premise Oracle license); All
OCI region have same pricing;

 Block volume (Storage cost $0.0255 per GB/month,

Performance Cost (VPU/GB) — NA for Basic, 10 VPU at
$0.0017 for balanced, 20 VPU at $0.0034 for higher
performance); Data Transfer costs — Ingress/Egress free b/w
data transfers, Egress charge for different regions; To and from
internet (Egress charged), DRG/FastConnect both
Ingress/Egress free

 Pricing Example — Outbound Data Transfer 10 TB free

 Billing — Cost Tracking Tags, Cost Analysis, Budgets, Alert

every 15 mins, Usage reports (automatically generated CSV file,
24 hrs data, retained for 1 year)

 Free Tier — $300 free credit for 30 days; upto 8 instances, 5TB
storage
 Always Free — 2 Oracle Autonomous DB, 2 OCI Compute VMS,
Block, Object and Archive Storage, LB and Data egress,
Monitoring and Notifications

Certification Appointment Booking

Please follow below steps to book appointment for the certification

exam:

 Go to http://www.pearsonvue.com/oracle.

 Select Sign In under Oracle on top right.

 Use your existing Pearson VUE account to log in or create a

new account and log in.

 Select Proctored Exam.

 Type 1Z0–1085–20: Oracle Cloud Infrastructure Foundations

2020 Associate and select Go.

 Select how you want to take the exam and follow the prompts.

System Test (Prior to Exam Day)

I highly recommend you to perform system test from the same

computer and location you will be testing from on exam day.
Please follow below link for further steps:

http://www.pearsonvue.com/oracle/op/
Ensure you have administrative rights on your computer to be able
to download the software and proceed further with the prompts.

On Certification Day

The certification will be open 30 minutes before the booked time

and please be ready at least before 15 minutes so that you will be
ready for the booked time after completing the admission process.

 Login: http://www.pearsonvue.com/oracle/op/

 Click on your exam under ‘Purchased Online Exams’

 Click “Begin” and proceed through the self check-in process

and wait for a Proctor to connect with you

Some tips…

There are totally 60 questions and you have 105 minutes — so you
have approximately 2 minutes for each question. So take your time
to read the question carefully before choosing the answer and also
review the each question once you completed all questions.

 Pass percentage is 68% — so even though you give wrong

answers to 19 questions, you still can pass the exam :) Hence
don’t panic if you don’t know answers for few questions.
 Read questions properly, sometimes they are tricky and you
can often miss some minute details which will be a key point to
find the correct answer.

 Few topics to concentrate more are OCI support, Databases,

Storage and Network. You might comparatively get more
questions on these topics.

 If you take the exam from home, then you are video proctored.
So strictly follow the PearsonVue guide for taking the exam.

Good that you read the whole article; hopefully it will be useful for
you.