Attended Oracle Cloud Infrastructure seminar – part 1

I had the opportunity to attend half a day seminar about Oracle Cloud Infrastructure (OCI) what Oracle offers. Here are some notes about it and some comparison to Amazon Web Services which I have been using a lot lately as well.

Content

The seminar was divided in to few different topics which were:

1. Introduction to Infrastructure services
2. Identity and Access Management (IAM)
3. Virtual Cloud Network (VCN)
4. Compute Services
5. Storage – Block volume & Object Storage
6. Load Balancer
7. Database Services (DBCS)
8. A Lab

I’ll describe what I learned from each area and in the first post I’ll go through everything up to VCN.

1. Introduction to Infrastructure services

This was just a general walk through on the services and how they are build up. As with AWS Oracle has divided OCI to different regions and each region has multiple Availability Domains (AD) same as AWS has Availability Zones.

Services which are available on high level can be seen from below picture. This is only the infrastructure services and Oracle’s other cloud services were not discussed in this seminar.

2. Identity and Access Management (IAM)

Similar to AWS when you sign up to OCI your account is the root account. After that you are free to create new user accounts with least privilege policy. So by default you don’t have access to anything.

OCI has IAM groups and you can then assign user to one or many groups and groups then dictate what access you have. You could for example have a group for network admins who can then modify network configurations.

OCI has a resource called tenancy which contains all of your OCI resources. However under tenancy there are compartments which is a logical container to isolate and organize your cloud resources. For example you can have specific compartment for your Finance department. You can still share resources across compartments if needed.

Policies to access resources are written in a SQL-a-like format. This seemed like a nice way to get people understand how to write them. Only thing I was wondering would it have been easier to go with already existing language?

Example on policy:

Allow group HR to read all-resources in tenancy Subcompany; (or compartment level)

Unfortunately for cost management there is no fully matured consolidated billing yet available but that is on the roadmap.

More info on IAM and tenancies and compartments from here.

3. Virtual Cloud Network (VCN)

Again a concept which was easy to absorb after working with AWS. After you have selected your region and want to start building your infrastructure you need to create your network. In OCI you have VCN and in AWS you have same concept with VCPs.

A VCN can cross multiple Availability Domains in a region. Usually when you create a VCN you reserve specific private CIDR block for your use and under it you will create subnets.

For example create VCN with 10.0.0.0/16 and then two subnets with 10.0.1.0/24 & 10.0.2.0/24.

Subnets are then specific for an Availability Domain and are either public or private. With OCI and subnets Oracle reserves first two IP addresses and the last for their use where as in AWS they reserve 4+1.

Access to your subnet is controlled by Security Lists. You define what ports can be used in & out. With OCI they had possibility to set your Security List rule as stateful or stateless. In AWS you either use security groups (stateful) or network ACLs (stateless). Was nice to simplify this!

To learn what stateless vs stateful is check it from here.

If you want to access internet from your subnet you need to create Internet Gateway and add it to your subnets route table.

You need Dynamic Routing Gateway (DRG) compared to AWS Virtual Private Gateway if you have requirement to access your onpremise datacenter with VPN. Again if you know AWS then these concepts are really easy to pick up!

When you have higher bandwith requirements between your onpremise datacenter and OCI you can use Oracle Fast Connect to achieve higher throughput. This matches to AWS Direct Connect on high level.

If there is requirement to access internet but you don’t want to make your server visible to public you can use Private IP on your route table. This acts as a NAT gateway for the servers.

You can connect multiple VNC’s with VNC Peering however at this point this is limited to tenant and the same region. Improving this was also on the roadmap.

More info on VCN from here.

Summary

Starting concepts were almost 1:1 with Amazon Web Services. Some things which I mentioned are still behind compared what AWS offers today but it was good to hear they had so many things under roadmap which should make things easier for customers in the future.

On part 2 I will go through rest of the services on the seminar and also review the lab we did.