We recently worked with a customer who needed a multicloud and multiregion infrastructure solution to host their third-party applications. Apart from the multicloud and multiregion setup, another requirement stood out. They wanted to replicate their on-premises architecture and infrastructure. They wanted to maintain the existing on-premises infrastructure setup, mainly networking, to keep managing the new cloud infrastructure while they managed the old on-premises environment, including the complex firewall configuration. Luckily, Oracle Cloud Infrastructure (OCI) supports these scenarios.
Their on-premises architecture was based on a classic hub-and-spoke layout, sometimes called star network, with a central component connected to multiple networks around it. The overall topology resembles a wheel, with a central hub connected to the edge of the wheel through multiple spokes. In this case, the customer had a central firewall handling all the network traffic and security.
Read on to see how we duplicated this entire on-premises application setup in the cloud, where we deployed different workloads on different OCI regions and made them available to Microsoft Azure in a real multicloud infrastructure. This blog post assumes some familiarity with cloud, networking, and security.
Solution overview
Part of the customer’s IT services ran in the on-premises data center, and the existing architecture looked like the following graphic:
The whole infrastructure was protected by a set of Palo Alto firewalls, which also took care of the whole network security for both the data center’s north-south traffic (Inbound and outbound traffic) and east-west traffic (Internal traffic).
The customer wanted to keep using a dedicated set of Palo Alto firewalls instead of a fully managed OCI network firewall because of some specific custom features required by the existing setup, including multiple custom IPSEC tunnels to connect with customers and partners. Apart from the on-premises data center, the customer was also running other IT services on Microsoft Azure.
We designed the following high-level abstracted diagram of the solution. In describing the solution, we make references to the numbered items in the diagram:
Azure-OCI Interconnect
Points 1 and 2 designate a connection between Azure and OCI. The customer was already running some workloads on Azure in the Amsterdam region and wanted to make them available to the new OCI tenancy based in Frankfurt. This section is the multicloud part of the solution. As previously outlined, Azure was also part of the on-premises solution, and OCI has great support for implementing OCI-Azure connections.
This connection uses Azure Express Route and creates an interconnection between Azure and OCI. This preferred, well-defined solution can be set up with a few clicks. However, use of the Oracle Interconnect for Azure isn’t available in all Azure and OCI regions. In this case, we set it up in Amsterdam, and the connected Amsterdam-based virtual cloud network (VCN) side is only used as a transit network, passing traffic between Azure and OCI.
All the traffic coming in from the Amsterdam region and all other regions and VCNs is by default routed to the central dynamic routing gateway (DRG) and then routed to the Palo Alto firewalls trusted interfaces to be inspected.
Central traffic management and security
In the part of the architecture diagram numbered 3 is the hub-and-spoke network implementation. The core of the solution is based on Palo Alto Next Generation Firewall and gives the customer all the classic features available on a dedicated firewall: Multiple IPSEC tunnels, custom configurations, and more. In this case, we have two Palo Alto appliances deployed in active/passive setup to provide failover capabilities, together the untrusted subnet and the trusted subnet. These two appliances are used to set up IPSEC VPN tunnels between the on-premises network (4) and OCI. The management interface is used for the firewall internal communications.
This setup gives the opportunity to handle all the traffic, east-west and north-south, and applying security rules in a centralized way.
The diagram shows a few VCN deployments in various regions, connected to each other (7). The magic to make them all be connected and able to communicate is called a remote peering gateway (RPG). You can easily deploy these RPGs and connect them to DRGs, which makes it easy to add another region and network.
Connection to the internet is then provided through the internet gateway, which is directly bound to the Palo Alto untrusted interfaces.
Although not depicted in the diagram, the customer required almost 64 public IPs on a single network interface card (NIC) in the untrusted subnet. This feature, available on-premises, was in place to handle their existing public internet services. This setup is the result of choosing this hub-and-spoke architecture and letting a centralized firewall handle all the traffic.
Third-party application hosting environment
Next, let’s focus on the application hosting part (5): A dedicated VCN with various subnets for front and backend applications, a database subnet, and a subnet for a Kubernetes cluster. The subnet division is for administrative and security reasons. This VCN is in the same region as the previously discussed hub network, so we can use simple DRG connections to connect them with other VCNs. In this deployment, VMs are based on Windows or Linux OS, the central database based on Microsoft SQL server and Kubernetes based on Kubernetes standards. This example shows how OCI can deal with a wide variety of technologies and industry standards.
All the traffic coming from each subnet and VCN is routed to the central DRG and the routed to the Firewalls in order apply the proper rule.
OCI Cloud Native services
Finally, we have reached the OCI Cloud Native services (6). These services are a perfect addition to an otherwise traditional setup. The biggest advantage is that they’re managed services instead of do-it-yourself solutions on-premises.
OCI offers many different services depending on your needs. In this solution, we used the following services:
-
Cloud Guard: Continuously scans the OCI environment for threats
-
Logging: A simple but powerful centralized logging service for all kinds of services and components
-
Monitoring: An extensive solution to monitor all kinds of services and components
-
Object Storage: An internet-scale, high-performance storage platform to store unlimited amount of unstructured data of any content type
-
Oracle Container Engine for Kubernetes (OKE): A fully managed, scalable, and highly available service used to deploy and orchestrate containerized applications to the cloud
Native OCI services are a big help for customers moving workloads from an on-premises data center. These services are fully managed, reducing all the administrative tasks typical when managing a data center.
Migrating third-party applications to OCI
So far, we have mainly addressed infrastructure. In the real world, customers want to understand if and how they can integrate their applications. Many approaches address the migration. In this case and many others, we use Rackware to clone VMs from other cloud vendors and on-premises infrastructure. Much documentation exists on this topic, but we recommend the article, Migrate AWS EC2 to OCI. Another advantage is that Rackware is available on the Oracle Cloud Marketplace, which provides pay-per-use and instructions on how to deploy and migrate VMs.
Conclusion
This blog post gave you an introduction to migrating third-party applications to OCI, specifically with hub-and-spoke architecture. The architecture is flexible, so you can easily remove or add components and environments. We can replace Palo Alto with other solutions or we can connect to Amazon or Google to implement this architecture in different multicloud setups
If this information interests you and you want to experiment, you can request a trial of Oracle Cloud Free Tier. If you want to discuss this scenario or other migration and deployment types, feel free to contact the authors, Alberto Veratelli and Arno Schots.