Network Proximity Is King on the Oracle Cloud VMware Solution

Adopting a vSphere-on-cloud platform will often be driven by integrating existing applications with newer cloud-native applications. One of the surprising realities is that the network integration between vSphere on Cloud and the cloud platform is not always as seamless as you might expect. After Cloud Field Day 7, I wrote about my desire for better network integration from VMware’s own vSphere on Cloud service. Our latest Build Day Live project with the CTO Advisor team was to integrate the Oracle Cloud VMware Solution (OCVS) with the CTO Advisor Data Centre (CTOADC). We were able to incorporate the CTOADC network with the Oracle Virtual Network (OVN) and the OCVS network without needing VPNs or different routing for the vSphere infrastructure layer and the workload VM layer.

Proximity Matters

Cloud-native services are driving the adoption of public cloud platforms for building digital interaction applications. Digital interaction means allowing customers to use a web or mobile application to interact with the business. Customers buy products or get the information they require without contacting a company employee. These web and mobile applications are replacing phone calls to call centers or visits to physical stores and make the Internet a core business location. There is a big challenge that the application server used by on-premises staff is not designed for cloud-native integration, often using heavy-weight network protocols that assume fast networks and low latency. The cloud-native application must use these same heavy protocols and so to get good performance; the legacy application needs to be close to the cloud-native component. By close, I mean having a fast and low latency network connection just like we have on-premises. These older protocols do not behave well over high latency connections. Do you remember using your work laptop from home with a VPN and how slow some applications ran? Your customers do not want your new applications slowed down by the network between the cloud-native part and the older vSphere application. Low latency first needs a short distance (the speed of light isn’t just a good idea), which is why we put vSphere in the Cloud. Then it needs a simple network path without the complexity of VPNs and separate routing configurations.

vSphere on Cloud

Existing enterprise applications expect enterprise infrastructure, not cloud-native infrastructure. VMware leads the hypervisor market, which is based on delivering enterprise infrastructure for VMs. vSphere on cloud platforms offer enterprise infrastructure inside public cloud datacentres, allowing enterprise applications to remain unchanged while running inside a public cloud. The core value proposition is around unmodified enterprise applications right beside newer cloud-native applications.

Oracle Cloud Proximity

You will be able to see this in upcoming Build Day TV episodes; we connected the CTOADC to the Oracle cloud and deployed a vSphere cluster in OCVS. The Chicago side had a single network path for our entire Oracle network, containing the vSphere hosts, the vSphere VMs, and any Oracle Cloud Infrastructure (OCI) based resources we deployed. On the Oracle network side, the network is divided into two pieces: the OCI manged part and the VMware NSX managed part for vSphere VMs. Within the Oracle network configuration, we could define routes into the NSX network using the NSX VTEPs, precisely the same as on-premises. The same OCI dynamic router handles traffic for on-premises, Oracle cloud, vSphere management, and OCVS VMs using NSX. There was no requirement for a VPN to link the vSphere VMs to anything else, and no separate network for vSphere management is required. The Oracle networking for OCVS felt just like another datacentre with vSphere and NSX.

With the OCVS vSphere network so close to the OCI cloud-native network, newer web and mobile applications have excellent access to older applications deployed in vSphere VMs. The hands-on process of joining the CTOA datacentre in Chicago to the Oracle cloud in Ashburn was simple, once we had our on-premises network team setup BGP for dynamic routing. A central design idea for the Oracle Cloud Infrastructure seems to be that it should feel like home to enterprise IT. In the upcoming videos and blog posts about using the Oracle Cloud VMware Solution (OCVS), you will see that theme a lot. Almost all of the way we operated the Oracle environment was the same as our on-premises environment. The Oracle Cloud Infrastructure is an extension of our enterprise infrastructure.

Disclosure: This blog post forms part of a project commissioned and paid for by Oracle. Oracle has had no editorial oversight and has not seen this article before it was published.