Oracle Cloud Impressions

After hearing the news that Zoom was moving part of its infrastructure to Oracle Cloud and reading a few articles on that matter, I was curious to see with my own eyes what Oracle’s offer looked like.

Please note that I’m familiar with (but not affiliated to) AWS, much less with Azure or GCP, so this article is in no way exhaustive nor a comprehensive benchmark of the cloud market. I may be a little biased, but I’ll try to keep it to a minimum.

First impressions

At first sight, the UI of the console feels a lot cleaner and less cluttered than the AWS console. The interfaces of all services (even those dedicated to Oracle RDBMS !) also follow the same UX principles, which is nice. On AWS, each service team is also responsible of the UI displayed on the console, which may help them deliver more rapidly, but comes at a cost in terms of homogeneity of the UX.

The geographic presence of Oracle Cloud is less dense than AWS, as it was foreseeable given how Oracle was late on the market. At the time of this writing, Oracle has 17 regions, but only 4 have 3 Availability Domains (equivalent of Availability Zones in AWS jargon), 2 in Europe, 2 in the US. This numbers should be compared with the 24 regions of AWS, almost all with 3 Availability Zones. This may not be perfect for every countries on earth, but at least in should allow US and european customers of Oracle to have a nominal/backup topology without leaving their home continent.

IAM

IAM and user management is usually the first step when building a cloud infrastructure. Oracle follows a slightly different approach than AWS by introducing a notion of compartment, which has the same objectives as Organizational Units and Accounts in an typical enterprise AWS setup with AWS Organizations.

Compartments are a logical object where you attach the objects you create in Oracle Cloud: Users, Groups and all compute/storage/whatever resources, but also IAM policies. Compartments can also have sub-compartments which inherit policies from their parents.

Once your account is created you end up with your first compartment, the root compartment and an admin account and group. You can then create child compartments for each perimeter of your organization.

I must say that this feels a lot simpler and more integrated than the tree of accounts and OU in AWS Organizations. Admittedly, this is probably due to the fact that the first IAM releases in AWS were not designed to segregate resources between different user populations. AWS chose afterwards not to break the backward compatibility by adding a layer on top of this notion of accounts. One clear benefit of the Oracle approach is that cross-account policies feel a lot more natural to write and you don’t end up with a dozen of administrative accounts to secure - that should not be used in day-to-day operations btw.

One interesting difference lies also in the way policies are defined: Oracle leveraged a simili-natural language approach for defining policies, which make them a lot more readable than their AWS counterpart.

As an example:

Allow group admins to manage database-family in compartment dev [where advanced conditions]

Some important notes:

• You can only allow something in policies. Everything that is not allowed is denied. This approach feels sound from a security perspective, but I fear it could lead in some edge cases to defining a lot of policies.
• You can only define policies on groups, not individual users. Again, this also feels like a good idea by forcing administrators to define clear responsabilities for their users.
• Verbes are limited to 4 values: inspect, read, use, manage. The verb defines the set of APIs in the referenced resource that the user can use, instead of explicitly listing which API are allowed.
• Resources can be individual resources or resources families (like database-family in the example)
• Some advanced conditions can be leveraged by relying on properties of the policy itself (by example, to restrict which API in the resource-family is authorized) or properties of the target of the policy (like the group name).

Networking

The concepts are very similar to AWS and any AWS user should quickly find their marks once the specific vocabulary is assimiled (VCN vs VPC, etc.).

The only major difference that struck me is how filtering is handled in Oracle Cloud. Security Lists are at first glance an equivalent of Network ACLs in the AWS world. They are attached to a subnet but the filtering occurs on the Virtual NIC attached to an instance. Security Lists doesn’t actually control the traffic entering or leaving the subnet like Network ACL, but rather the traffic entering or leaving a Virtual NIC: subtle but disturbing as those lists do filter the traffic between instances in the same subnet.

Oracle Cloud also have the notion of Network Security Groups. This feature was apparently added afterwards and doesn’t seem to be pushed that much as the gold standard for traffic filtering. A lot of content (documentation, videos, etc.) still references Security Lists as the way to go to filter traffic. This is bad and the documentation should be fixed to rely instead on Network Security Groups for most of the filtering effort.

The most important problem with Security Lists (which are also true for Network ACLs in AWS) is that the filtering rules create a coupling between the applications and the network topology: changing an IP on an instance, adding a new instance, removing an instance, etc. all have potentially an impact on one or more Security Lists. This also leads, as in traditional firewall architectures, to a decay in the quality of filtering and it doesn’t scale well: instances are destroyed, but not the rules, or the rules are too wide…

For large deployments, the lack of an equivalent service to the AWS Transit Gateway may make the maintainance of the different Route Tables in each subnet very complex.

Compute and Storage

Oracle claims that the entire compute architecture is built on the same Bare Metal stack. VM instances are launched on a Bare Metal instance equipped with an hypervisor. Even if it’s intellectually satisfying, I see the benefit here for Oracle (less hardware types to manage), but not really for the customer. VMs are enough for the vast majority of use cases, unless you have very I/O-intensive applications (let’s say… a highly sollicitated database). Most people really don’t care that Bare Metal is a first-class citizen.

Oracle uses Xen as the hypervisor for their VM infrastructure and thus is very similar to the previous generation of EC2 instances on AWS.

Since then, AWS moved to an architecture called Nitro (more info on it in this video), which introduced a lightweight hypervisor with strong security guarantees (no human operator intervention possible for example) and a lot of things offloaded in hardware to ad-hoc chips (notably all encryption on block storage). On the technology side of things, AWS seems to have a clear lead.

Still, this doesn’t necessarily mean that AWS have a better compute/price ratio in practice, but at least this indicates they could.

On the storage side, Oracle leverages exclusively SSD disks and provides an SLA on I/Os. Again, I think most companies don’t really need this kind of SLA and quite frankly I’m not sure I would be willing entering a dispute with the legal department of Oracle if those SLAs were not met :-)

Pricing

Pricing seems relatively similar between AWS and Oracle, except for one point: outbound data pricing.

AWS is notorious for its convoluted and expensive pricing for data transfer. It is for almost any client one of the more costly spot in their bill. The problem is summarized in this figure:

Oracle outbound data transfer pricing is simple:

• Outbound traffic costs $0.0085/GB/month (at the time of this writing) after the first 10TB (billing starts at 1GB in AWS…)
• Everything else is free, including FastConnect data transfers (equivalent of DirectConnect in AWS)

It’s basically at least 10 times cheaper than AWS and a lot more predictable. It’s probably the main reason why Zoom signed with Oracle.

This is a very smart move from Oracle, for at least 2 major reasons:

• If you want to compete with AWS, you have to attack where they are weak or too complex. This very interesting article by Corey Quinn elaborates on this subject if you’re curious.
• It makes a lot of sense for a company who also specializes in data management

To elaborate on this second point, if you’re thinking about building an hybrid cloud setup and host your datawarehouse or your entire data platform in a public cloud to benefit from the higher level of automation than the one you probably have (or not) on premises, this is one major pain-point that goes away instantly. Once your data are in Oracle Cloud, the natural next step is also to host some applications on it. This is clever.

Databases

This makes a good transition with this section.

The RDBMS database offering is a bit complex. For hosting Oracle databases, you have 3 solutions:

• Host a database on a VM or Bare Metal instance. This is more or less identical to a classic private cloud Oracle service offer: the installation, patching, backup and maintenance tooling is plugged to the console and most operations can be not done through it. But… you still have a shell access to the server, you can modify, fine-tune or break the default configuration. I’m not a big fan of this unless you have really valid reasons to do so (and you often really don’t).
• Buy a partition on an Exadata system: More or less the same, but with a higher level of automation.
• Use the new Autonomous Database, which is basically a fully managed Oracle Database on an Exadata (which is abstracted away from the user).

This third option aims to compete with Relational Database Service (RDS) from AWS. It’s interesting if you’re an Oracle shop and develops mainly in Java or rely on Oracle middleware, less so if you’re developing in brand new languages like PHP, JS on Node, Go, Ruby, Python, etc. Despite those languages being able to connect to an Oracle database, the drivers are a lot less supported, the community support is reduced and the APIs are generally… meh.

Autonomous Database are also surprisingly lacking some important features found in RDS, for example the ability to create replicas in another regions, which are useful in Disaster Recovery scenarios. You’re basically stuck to restore a backup on another instances in another region, with a guaranteed data loss.

Oracle also proposes a MySQL service similar to the first bullet point before. Common procedures are automated, but you’ll have to manage or break the database yourself.

On the NoSQL front, Oracle doesn’t provide the same breadth of choices than AWS (DocumentDB, Neptune, Redis, DynamoDB, Elasticsearch, etc.), only Oracle NoSQL which is not that well known nor covers some of those use cases.

Free Tier

This may seem like a trivial matter, but Oracle is the only major cloud provider to offer a permanent and usable free tier:

• 2 VMs with 1/8 CPU and 1GB RAM
• 2 autonomous databases instances with 1 CPU and 20GB of storage
• 2 block volumes for a total of 100GB, 10GB or Object Storage and 10GB of Archive Storage
• 10TB/month of outbound data transfer and a load balancer with 10Mbps of bandwith

This is in my opinion usable for light hacking and a lot better than what AWS offers (mainly Lambda and DynamoDB which strangely are also services that have a propensity to lock you in with AWS).

Other services

Oracle offering is probably competitive on the main services you expect from a cloud vendor, but lacks a lot of the bells and whistles you’ll find on AWS.

I tried to list the important services in AWS I feel are lacking in Oracle Cloud:

• Config: very important to prevent mistakes or detect bad practices when deploying cloud resources. It would not be that problematic if popular alternatives like Cloud Custodian supported Oracle Cloud.
• Lambda: even if you don’t develop serverless applications, it’s also an effective way to host scripts to automate whatever you want on your infrastructure.
• Systems Manager: great to manage your instances without enabling SSH everywhere and benefiting from strong authentication mechanisms (MFA)
• CloudFront and Shield: to distribute content and protect hosted resources
• GuardDuty: to detect abnormal behaviours in your infrastructure
• Secrets Manager and Certificate Manager: great for managing and automating the management of secrets in applications. Hashicorp Vault is a great alternative, but you’ll need to operate it yourself on Oracle Cloud.
• Organizations: despite being complex, it also automates a lot of things when provisioning users in your accounts and allows fine grained control of rights through Service Control Policies (SCP)

Conclusion: Who is it for ?

If you’re Zoom and generates petabytes a month of outbound data, Oracle Cloud is almost a no-brainer given the huge difference in pricing compared to their competitors. Does it mean you host all your infrastructure on it ? Not so sure.

For existing customers of Oracle products (especially the RDBMS and products from the middleware offering), it can make a lot of sense to host them on Oracle Cloud in an hybrid cloud approach. The offering is clearly not ridiculous compared to AWS on the basic services that you can expect from a public cloud provider and those companies can level up the automation level on these apps (which are often hard to maintain on premises).

It can also appeal to companies which follow a strict “cloud-agnostic” or “multi-cloud” approach to public cloud (despite being in my opinion a not so good idea in practice… but that’s a topic for another day), where only basic compute and storage services are leveraged.

If you’re a small structure and want the provider to manage almost everything while having few constraints on your technology stack, Oracle will probably not be your first choice, unless you largely underestimate the effort and costs needed to operate your own infrastructure :-)

Finally, I must say that I was pleasantly surprised by Oracle Cloud. I had low expectations but they did deliver almost all the basics and the offering seems solid (with a few gotchas, especially on the database space). Keep in mind though that I only scratched the surface and that the little features of each services that are not marketed can make the difference between an easy setup and a nightmare. It takes time and a lot of customer usage to get there.