EC News DeskKevin Bogusch
Senior Competitive Intelligence Analyst, Oracle
If you’re using only one public cloud vendor, times have changed.
Ten years ago, cloud was new and novel. You had to learn a new style of infrastructure, operations, and deployment. You optimized and simplified by choosing one cloud vendor: Amazon Web Services (AWS), Microsoft Azure, or Google Cloud. But you kept mission critical workloads on premises.
Five years ago, you built significant applications entirely in the cloud. You trusted production workloads to the cloud. You accepted cloud as part of corporate infrastructure. But your decision to stick to one cloud hadn’t kept up with the times. Because each cloud was initially designed to solve a different problem, they have matured with different strengths and capabilities.
As you tried to migrate more complex and demanding workloads, you found shortcomings in performance, incurred unexpected cost overruns, and experienced mismatches between the cloud’s architecture and your enterprise workloads.
You’re still moving to the cloud, but like any technology, supplier diversity is a necessity. Using multiple clouds gains you a competitive advantage, geographic resilience, and pricing leverage. When you look at other cloud vendors, look at the disruptor who has used the lessons learned early and already built a next-generation cloud—Oracle Cloud Infrastructure (OCI).
It’s not you; it’s your cloud
Many enterprise workloads remain on premises despite various pro-cloud strategies, such as cloud-first or cloud-only. Migrating them to the cloud hasn’t been as easy as anticipated, and that reasoning is subtle.
Broadly speaking, we can segment many enterprise workloads into the following categories:
• Web-scale or mobile-scale
• Productivity
• Systems of record or process control
• High-performance computing (HPC)
Web-scale (or mobile-scale) workloads respond to vast changes in demand, such as a holiday sale or a viral video. These workloads can be broken down into components that are independently added or subtracted. For example, adding more web servers for a sudden spike in sales traffic and then removing them when the sales taper off. AWS was designed exactly for this purpose: A global retailing website. Similarly, Google was also designed for this purpose, having been created to run their Search and Gmail applications across the world.
Productivity workloads support many users in a steady state of usage. Document sharing, identity verification, and group communications are typical examples. Microsoft has built its Azure cloud around these needs for their Office and Xbox communities.
Both these workload types share the design pattern to compartmentalize activities and add more resources (scale out) as needed for an increase in demand. A failure of any one component has little or no effect on the other components. To use an analogy, if one checkout lane is full at the supermarket, those impacted shoppers can simply move to another lane. The reference architectures for the cloud vendors explicitly state that you should anticipate any component to fail with the application designed to accommodate this failure.
Unfortunately, most enterprise workloads fall into the remaining two categories—systems of record or process control and HPC—where scale out isn’t applicable and component failure isn’t acceptable. Put another way, the design of most clouds doesn’t match the design of most enterprise workloads.
Systems of record and process control tend to be monolithic in nature and require scale up with larger servers instead of scale-out. Because they’re monolithic, a failing server impacts the entire application and causes expensive downtime.
HPC needs raw performance provided by bare metal servers, unencumbered by hypervisors, and connected with high-bandwidth, low-latency networks that join these servers into a distributed system. Not overcommitting the network is important. Surges in traffic in web-scale applications can swamp even high-bandwidth networks and seriously impact nearby workloads that share underlying infrastructure. This over-commitment is a common, resource-saving design practice for the cloud vendors.
OCI is a next-generation cloud designed to support these enterprise workloads. You can migrate systems of record and process control applications as-is with little or no change to high-reliability servers, either virtual or bare metal. OCI’s virtual servers run on enterprise-grade bare metal servers. HPC can take advantage of the bare metal servers connected over hyperconverged networking. The network is fully built-out to support maximum communication without suffering from noisy neighbor syndrome.
OCI is the cloud that allows you to complete your cloud strategy by moving existing, mission-critical workloads to the cloud.
Living in a multicloud world
Does this mean that OCI is the only cloud you should use? No.
The question is no longer which cloud to use, but which clouds to use to gain the most value. Four out of five companies surveyed by Gartner are already using at least two public clouds. The multicloud world is already here.
However, multicloud is much more than using services in each cloud independently. Multicloud is about connecting the best services and capabilities of each cloud. For example, AWS offers many machine learning services, such as Amazon SageMaker, Amazon Lex, and Amazon Transcribe. Azure supports foundational services, including Azure Active Directory, Microsoft 365, and the Xbox network. Google developed container management to support elastic, “cloudy” applications.
Oracle has engineered OCI to focus on enterprise-grade reliability, bare metal performance, and hyperconverged networking. This architecture supports mission critical applications at single-server sizes beyond what other clouds offer and large, bare metal clusters for HPC. We explicitly price these offerings at costs lower than the other cloud vendors. OCI also provides the expected cloud services, such as virtualized compute, storage, and containers.
To experience true multicloud, your data must move with as little friction between clouds, enabling you to use the services from each cloud as you see fit. For example, one cloud can collect data from various devices, move the data to OCI for high-performance processing, and finally move the data to another cloud for archiving.
Moving data across clouds is another area where OCI supports true multicloud by charging lower, per-byte fees on data exiting a cloud (egress fees). We expect OCI to interoperate with other clouds and have structured the egress fees to promote this usage—typically 10 times cheaper. Oracle is also a member of the Cloud Bandwidth Alliance that allows for free or reduced egress fees between members. The other cloud vendors have implemented a “walled garden” pricing policy that imposes noticeably higher egress fees to incentivize customers to keep their data within a particular cloud.
If you’re using Azure in a supported region (10 globally and counting), Oracle has uniquely partnered with Microsoft to offer Azure Interconnect that provides high-bandwidth, low-latency connectivity of less than 2 ms with no egress charges between the two clouds. This interconnection supports a common use case for mutual customers with investments in Microsoft and Oracle technologies that want to migrate to the cloud without impacting networking performance.
Best for Oracle Database
Naturally, Oracle also designed the next generation OCI to provide the best environment for Oracle Database service. Customers can easily migrate, using free expert guidance with the Oracle Cloud Lift service, from on premises to OCI with minimal or no changes.
Oracle Database can run on virtual machines for flexibility and engineered hardware for maximum performance and reliability. Because your Oracle licenses scale along with the hardware, many customers find their overall cost shrinks when migrating to OCI from on premises, even while experiencing better performance.
