X

Best Practices from Oracle Development's A‑Team

Extending Oracle Fusion SaaS with OCI: Network Considerations

Bill Jacobs
A-Team Consulting Solutions Architect

NOTE:  This blog post is one in a series of blogs covering various sub-topics within the "Extending Oracle Fusion SaaS with OCI" topic area. For an introduction to this topic and a listing of other articles in the series, refer to "Extending Oracle Fusion SaaS with OCI - Introduction".

Overview

The pace of Oracle Cloud Infrastructure’s (OCI’s) evolution as a mature, full-featured, enterprise-ready cloud platform has been breathtaking.  OCI's variety and coverage of what the computing industry refers to as “cloud-native” tools and applications is perhaps where the evolution has been most apparent, but the foundational pieces -- the networking, security, and user management tooling -- have also progressed in step with the tools and applications.  On all levels the OCI platform is more than ready to be exercised at enterprise scale.

In addition to cloud infrastructure, of course, Oracle offers a complete, complementary selection of cloud-based software-as-a-service (SaaS) applications for the enterprise, along with cloud platform-as-a-service (PaaS) components.  The comprehensiveness of Oracle’s cloud stable makes it possible for organizations to take full advantage of built-in synergies across Oracle’s SaaS, PaaS, and IaaS (infrastructure as a service) platforms.  One prime area where these multiple cloud products converge is in extending SaaS applications, Extending SaaS can be effective when organizations need to address critical, “can’t-do-without” business requirements, those that are either not supported or only partially supported out of the box in SaaS.  When designing and developing these extensions to SaaS, Oracle cloud subscribers do not need to start from square one; there are established, recommended best practices in place that can be used to jumpstart SaaS extensibility projects.  In particular, this document provides an overview of how to set up OCI networking to support a variety of extensibility patterns that take advantage of OCI cloud-native components.  In other words, the focus is on what needs to be in place from a networking perspective to support an integration between OCI cloud-native component(s) “X” and Oracle SaaS product “Y”.

The focus here will be on Oracle Fusion SaaS products.  Although some of the strategies discussed will apply in general to all of Oracle's SaaS applications, the Fusion pillars – due to a common infrastructure framework used by HCM, ERP, SCM, Financials, and Sales/B2B Service – all share virtually identical networking strategies when it comes to setting up connections with OCI cloud native platforms upon which extensions can be deployed.  Additionally, neither Oracle's government SaaS infrastructure nor the older, legacy OCI classic infrastructure will be discussed specifically.  There are special considerations from a networking and security perspective that need to be taken into account with the government cloud.  Likewise, there are different networking models for SaaS deployed in Oracle's legacy cloud infrastructure, which slowly but surely, is being replaced by the newer, "Gen2" OCI.

SaaS Extensibility Then and Now

Of course, extending an Oracle SaaS application, especially Fusion Applications SaaS, was possible long before OCI came into its own.  Historically Oracle Public Cloud PaaS has provided several options, deployed on pre-OCI infrastructure, explicitly designed to be quick-start environments for SaaS extensions.  Java Cloud Service – SaaS Extension (JCS-SX), packaged with a dedicated database service, was an Oracle-managed Weblogic-based application deployment platform that came with networking and security built into the product offering.  While it is true that the platform lacked flexibility, for many subscribers having a pre-configured environment to host SaaS extensions was a real boon and exactly what they needed at the time.

Slowly but surely market demand driven by newer development paradigms and platforms has made it necessary to replace JCS-SX with other options.  The closest PaaS option to JCS-SX available in OCI is probably Visual Builder Studio.  Many FA instances, especially those deployed to OCI, are pre-wired to support tight network connectivity between FA and Visual Builder, so subscribers do not have to concern themselves with network configuration.  Another option with a footprint similar to JCS-SX could be a Weblogic server hosted on an OCI compute instance with a database service, but in this case the subscriber would be responsible for setting up network connections with FA.  Of course, cloud-native options for extending SaaS are now also available with OCI.  The OCI Serverless Functions offering is one example of a more modern framework that subscribers can harness to extend their SaaS applications.  But here too there is a need for “roll-your-own” networking.  With additional flexibility and more options comes the requirement for a bit more hands-on network setup and management.

OCI Networking Concepts and Artifacts

Before an in-depth discussion of networking options for SaaS extensibility leveraging OCI components, it is important to understand OCI networking concepts.  Flexibility, security, and performance are the major considerations.  The main construct is the OCI Virtual Cloud Network (VCN), which, because it’s virtual, allows for the ultimate in flexible network configuration.  IP address ranges are completely under subscriber control, as well as flexible public and private subnet creation and configuration.  In OCI, subnets created within VCN's are the basic units of management.  Within a subnet, components share common route tables, security lists, and DHCP options.  Usually one of the first setup tasks for an OCI tenancy is configuring one or more VCN’s along with subnets.

Virtual Network Interface Cards (VNICs), attached to compute instances, are set up as needed to support connectivity of instances to components both within and outside the subnet.  Dynamic Routing Gateways (DRG’s), also virtual, create a network path for private network traffic within a VCN to flow to and from a subscriber’s on-premise network.  In this case either and OCI IPSec VPN or OCI FastConnect is configured to be the network tunnel between the DRG and on-premise network routing gateways.  DRG’s can also be set up to provide a route for private subnet traffic to be shared with other subnets, even across regions if necessary.

Internet Gateways, Network Address Translation (NAT) Gateways, Local Peering Gateways (LPG’s) and Service Gateways support other specialized routing requirements of private and public subnet network traffic.  Service Gateways get special attention for SaaS extensibility, as they are the component that provides network connectivity with the Oracle Services Network (OSN), where Fusion Applications, along with other shared OCI resources with public IP access such as Object Storage and Autonomous Database, are deployed.  (But note that the Oracle Services Network is more conceptual than a real virtual network; think of it as a loosely-defined network container for public services.)

Starting Points:  Oracle Cloud Infrastructure and Oracle Fusion SaaS Basic Network Models

Perhaps the most practical way of presenting the networking options to support OCI-Fusion SaaS integrations and extensions (the term "oci4saas" has been coined as a shorthand reference term for this area) is to start out with the basics, and then take a step-by-step building block approach to introduce the additional OCI networking components and setups which may be needed to support common Fusion SaaS extensibility patterns.

OCI Basic Networking

Diagram 1 (below) depicts a more-or-less default network topology.  Access to OCI if to/from the Internet, hence the use of an OCI Internet Gateway to act as the traffic consolidation point for access to resources that are deployed to a regional public subnet set up in a virtual cloud network (VCN) within the subscriber's tenancy.  In the topology represented in the diagram some HA redundancy has been set up by taking advantage of regional availability domains.

Diagram 1

Diagram 1:  Default OCI Network Topology / Accessing resources (set up with public IP addresses) over the Internet from a subscriber's on-premise network

Fusion SaaS Basic Networking Configuration

By default, when Fusion SaaS instances are deployed in OCI, they are set up to be accessed over the public Internet through (currently) the Akamai Content Delivery Network (CDN).  This arrangement usually works well for standard access use cases, but if there are any non-standard connectivity requirements, including but not necessarily limited to oci4saas extensions, additional network components will need to be set up and configured in the OCI tenancy.  The standard network setup will often need to be augmented to support optimal connectivity among the OCI, SaaS, and in many cases on-premise applications that will need to be included in integrations.

OCI Cloud-Native Components and SaaS Extensibility

For the most part, Oracle SaaS and OCI coexist in regional Oracle data centers, but network connections between the two realms are not set up automatically.  Configuring connectivity is the subscriber’s responsibility, as there are multiple options driven by functional business requirements, thus making a generic network configuration impractical.  A major decision point is how to connect with FA SaaS deployed inside the Oracle Services Network:  whether to configure a VPN-based private connection to SaaS services or whether it is acceptable to stick with the default connectivity that is configured with Akamai CDN over the public Internet.  The extensibility design, and which OCI components are going to be part of the extensibility footprint, will drive this decision to a large extent.

The use cases being considered here all have Fusion Applications SaaS, deployed in OCI, as integration targets or hubs.  (NOTE:  the network solution will be somewhat different for SaaS that is still resident in the legacy Oracle Classic OCI infrastructure; as most older FA SaaS deployments have already been migrated to Gen2 OCI, classic OCI is not covered in depth here.)  Obviously, business requirements for SaaS extension(s) will drive the selection of PaaS and perhaps other OCI components, and in turn, the OCI product(s) chosen will influence the networking requirements.  But, in many cases, there is also a need to consider two other factors that will shape networking choices:  (1) how the SaaS target(s) is/are configured (e.g. CDN enablement (Akamai), optional Location Based Access Control (LBAC)), and (2) whether or not private connectivity to FA SaaS is important and/or required.  To sum up there are multiple dimensions to consider in designing the network that will support SaaS extensions:

  • The need for private connectivity between on-premise endpoints, OCI, and Fusion SaaS
  • Which OCI components are going to be involved in SaaS extensions
  • Any non-standard SaaS setups (e.g. Akamai location based access control) that will need to be supported

Private SaaS Connectivity and Accessing the Oracle Services Network from OCI

Utilizing the OCI Service Gateway makes it possible for components deployed within a tenancy VCN to access resources deployed within the Oracle Services Network (OSN) (see Diagram 2).

Diagram 2: Routing in OCI and OSN with a Service Gateway Deployed

Most OCI components that would be deployed to support a variety of integration architectures would take advantage of the Service Gateway (SGW) to access Fusion Saas just like they would be able to connect with Autonomous DB and Object Storage. Components such as Functions and Kubernetes clusters need to be deployed to a private subnet.  With an existing Service Gateway set up in the VCN, create routing rules to direct appropriate traffic to the SGW from endpoints in the private subnet.

A NAT (network address translation) Gateway is shown in the diagram to support use cases where resources in the private instance may need to access resources over the public Internet.

By default, new Fusion Applications instances are deployed in the OSN with public IP addresses that are reachable over the Internet through Akamai's CDN.  It is possible, however, from within OCI VCN’s to access OSN-deployed services without relying upon the Internet.  The advantages are significant: 

  1. Network traffic remains private without any exposure to the public Internet, which is a significant security improvement
  2. Replacing somewhat unpredictable Internet network performance with predictable, private Oracle network infrastructure improves both performance and reliability.

There is a partial downside to setting up private network access to Fusion SaaS:  it is necessary to disable access from the Internet going through the Akamai CDN.  As of the time of this writing (August 2021), work is underway to support "traffic steering", which will allow support for both private and public connectivity to Fusion SaaS.

The key piece of the network configuration here is the Service Gateway, which makes it possible for VCN-deployed resources in an OCI tenancy to connect with services, including FA, that are deployed within OSN, without any dependency on the public Internet (see Diagram 3 below).  Additionally, if so desired, by adding an IPSec VPN or Oracle FastConnect, private access is also possible from a subscriber's on-premise network.

Diagram 3:  Service Gateway / Connecting to OSN-deployed Services

Creating and setting up a Service Gateway is covered well in the OCI networking documentation.  It is possible to configure both routing rules and optional security rules with setup of the SGW. 

There are a few constraints and other things to keep in mind with the OCI Service Gateway:

  • SGW’s are regional in scope and they can only enable access to services in the same region as the VCN.
  • In addition to routing private traffic to/from OCI resources to SaaS services, if it is necessary to support access to public services, there will be a need to set up a NAT gateway or similar access to the Internet.
  • Only one SGW per VCN is supported.

In practice, setting up a Services Gateway for a VCN makes it possible for any OCI component deployed in the VCN to connect with services deployed in the Oracle Services Network. 

Private Connections to OSN-based services from Private Networks (e.g. on-premise)

Adding an IPSec VPN or Oracle FastConnect to the Service Gateway-enabled configuration above makes it possible for endpoints sourced to/from a private network to access Oracle SaaS services utilizing a totally non-Internet, private set of connections (refer to Diagram 4 below).

Diagram 4:  Adding Private and/or Public Access to SaaS from On-Premises Networks

While it is possible to set up Oracle FastConnect with public and/or private peering, normally network traffic from on-premise endpoints to Fusion Saas instances deployed in OSN will utilize private peering.  This traffic will traverse over several routers/gateways.  First is the Customer Premises Equipment (CPE) which has been configured to act as the FastConnect termination point on the customer side.  Second is a required Dynamic Routing Gateway (DRG), acting as a termination point on the other side of the FastConnect tunnel, and which is configured to route traffic to an attached VCN.  Third is the Service Gateway which is set up to route traffic out to Fusion SaaS deployed in OSN.  Note that this traffic only supports one direction:  customer-to-service (C2S).

Private peering is the preferred means of network routing with FastConnect, but it is still possible to set up public peering to access public resources in OCI.  The key difference between this setup and the default public SaaS access is that there is no public Internet dependency.  (See documentation for list of OCI regions where public peering access is supported over FastConnect.)  Fusion SaaS could be reached over FastConnect utilizing its default public IP addresses.  Moreover, both private and public peering can be active at the same time.

Oracle Integration Cloud (OIC) is a special case when it is needed to support certain integrations, many of which may require connecting in both directions to and from on-premise data sources and applications.  The main challenge is that most on-premise integration targets will not be reachable with public IP addresses.  There are two possible solutions with OIC:

  • FastConnect Public Peering:  On-premise applications can call OIC over FastConnect, but to go in the other direction, the OIC Connectivity Agent needs to be deployed in the on-premise network.
  • FastConnect Private Peering:  Private peering is more flexible in that the Connectivity Agent can be deployed in either the on-premise network or in an OCI VCN.  With private IP address routing set up correctly, the OCI VCN acts as an extension of the on-premise network, so from a network topology standpoint, there is not much difference in where the connectivity agent is deployed.  However, a Service Gateway does need to be in place to route the private network traffic to OIC, which is hosted in the Oracle Services Network.  (There are other options requiring transit routing which are not covered here.)

Summary

OCI networking is flexible by design; what makes this possible is virtual network component creation and configuration instead of depending on hard-wired physical network components.  When there is a need to extend Oracle SaaS products with Oracle PaaS or with custom applications and/or integrations deployed to OCI cloud-native platforms, network flexibility in OCI is a huge advantage.  Virtual service gateway components configured in OCI virtual cloud networks make it possible to support private network connectivity to Oracle FA SaaS from OCI tenancy endpoints, whether these endpoints are bespoke applications running on compute instances or cloud-native containers such as serverless functions or Kubernetes instances.  This private connectivity can even be extended to organizations’ private networks by setting up either an IPSec-based VPN or Oracle FastConnect, along with Dynamic Routing Gateways configured in applicable VCN's.  With OCI, SaaS extensibility options are no longer limited to Java/ADF/Weblogic running on JCS or JCS-SX.  OCI networking provides for access to SaaS from most if not all conceivable OCI components that may be included in SaaS extensions as needed while still providing for a high degree of security, which after all is what networking needs to support.

Other Documentation Resources

OCI Networking Documentation:  https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/landing.htm

FastConnect Design Options (Javier Ramirez):  https://www.ateam-oracle.com/fastconnect-design

Oracle Integration Cloud (OIC) and OCI Networking Design (Jack Desai):  https://blogs.oracle.com/fmw/fastconnect-and-vpn-with-oracle-integration-cloud-oic

 

 

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha