Now that I have had a couple of go-rounds with the OCI Dedicated Region Cloud at Customer (DRCC), I would like to think I have a pretty good understanding of how to effectively plan for an implementation. A DRCC is mostly like any other OCI region. The thing that makes it different is that it is OCI hardware inside a in a clients data center. The available resources are tailored to the clients need. Dedicated Region Cloud at Customer regions will always require customers to perform on-going capacity planning. Taking a more detailed approach when planning out the initial deployment will make the migration process to DRCC much smoother.

So what are the differences between a “traditional” OCI region and a DRCC? There are two main differences that stick out to me.

• Networking can be different due to co-location. I will handle the networking in my next post.
• Resource availability

Customers will work with Oracle to finalize the physical resources deployed in the DRCC. That will drive the type of OCPU (AMD, Intel, Ampere), amount of memory and storage available. This impacts services available as well as marketplace options. Unlike other commercial or government regions, if a shape is not available, the customer can’t just submit a service request to have a service limit increased.

As an example, if a customer chooses to only have E4 (or now E5) AMD OCPU shapes available and they attempt to deploy a Palo Alto image from the market place that depends on E3 AMD OCPU, that can become a blocker. This can be avoided with proper planning.

If a customer is running VMWare on-premise on Intel based compute, if they do not want to convert to AMD in DRCC, Intel based compute should be included in the bill of material. This requires planning not just for the first wave of applications to be migrated but also the future waves (potential applications) to be migrated in the future.

As part of the planning process, service limits should be considered (how much of each service will be consumed). This small but crucial step will allow customers to ensure the service limits are adjusted as the DRCC is deployed. Otherwise, one of my first steps is to review the service limits and submit an SR to adjust a list of service limits (i.e. number of virtual vaults, number of fast connects, number of ExaCS, etc).

In a traditional OCI region, customers have the luxury of looking at the primary application/s driving the on-boarding of OCI. Over time, as other workloads are identified, it is a simple process to add services or change service limits within a tenancy. My previous statement does not account for the architecture review board process required to on-board a CSP or to adopt new features. I am simply referring to the process of adding the required service or capacity. DRCC is a matter of identifying capacity based on identified or potential future workloads. The capacity requirement drives required floor space within the data center. It will also drive the services that are available for consumption on day 1.

Where I have seen delays in implementing DRCC has been related to insufficient initial capacity planning. This could be missed OCI services, not accounting for change in architectural design (network firewall to next gen fw marketplace image) or adding scope during implementation (adding in AI services not initially required by application workload). These are considerations that need to be front-of-mind when initially planning a DRCC region. Missed capacity is a sure fire way to delay migration to a DRCC.