1. Design the infrastructure for hosting SaaS applications
  2. Understand the Design Considerations

Understand the Design Considerations

The architecture described in this solution incorporates design choices that are intended to provide an enterprise-grade topology that you can scale easily, access securely, and operate efficiently.

  • Resource isolation
    The resources in the tenancy are isolated logically in compartments. Access to the resources in each compartment is controlled through policies that the tenancy's administrator defines.
    • The root compartment could be either the tenancy's root compartment or another compartment that's designated as the root. It contains all the other compartments in the topology. You also define all the access-management policies in this compartment.
    • The management compartment contains a VCN with subnets to which the bastion server and management server are attached.
    • The peering compartment contains the routing gateways and the peering VCNs.
    • The tenant compartments contain the application resources specific to each tenant.
    From a networking perspective, the architecture divides the topology into isolated networks, each a VCN with a unique private address space.
    • The bastion server, the management servers, and the routing gateways are attached to the ISV VCN, also called the management VCN.
    • The application resources specific to each tenant are deployed in a separate tenant VCN.
    • One or more peering VCNs serve as bridges between the management network and the tenant VCNs.
  • High availability

    For high availability of the routing gateways, you can deploy primary-standby gateway pairs in separate fault domains. The routing gateways can be configured to use floating private IP addresses. If the primary gateway fails, the floating addresses can be moved to the VNICs of the standby gateway.

  • Scaling
    • The application resources for each tenant are deployed in a tenant-specific VCN in a separate compartment. So the maximum number of tenants that you can scale up the architecture to depends on your tenancy's limits for compartments and VCNs. Note also that the maximum number of tenant VCNs that you can connect to a peering VCN is fixed at 10. Consider these limits when you plan your topology.
      For example, if you expect to provide services to 100 tenants, then your Oracle Cloud Infrastructure tenancy should have at least the following service limits:
      • 102 compartments (a management compartment + a peering compartment + 100 tenant compartments)
      • 111 VCNs (an ISV VCN + 10 peering VCNs + 100 tenant VCNs)
    • If any of your tenants require private connectivity, then consider the Oracle Cloud Infrastructure tenancy's service limits for DRGs, IPSec VPN connections, FastConnect circuits, and customer premises equipment (CPEs). For example, if 25 of your tenants require private connectivity, then you need to configure 25 DRGs, and possibly twice that number of IPSec VPN connections for the sake of redundancy. When you set up the topology (and at regular intervals thereafter), forecast the number of tenants that you expect to serve, and work with Oracle to increase the service limits as required.
    • Each connection from a routing gateway to a peering VCN uses a secondary VNIC of the gateway. So the number of secondary VNICs that the gateway instance can have determines the number of peering VCNs that the gateway can serve. Consider this factor when you select the shape of the gateway instance.

      For example, given the default limit of 10 tenants per peering VCN, if you use a routing gateway that has three secondary VNICs, then the routing gateway can serve up to 30 tenants.

  • Management network bandwidth

    The network bandwidth between each tenant VCN and the ISV VCN depends on the compute shape that you select for the routing gateway. The available network bandwidth is shared across all the VNICs of the gateway instance. For example, if you select the VM.Standard2.4 shape for the routing gateway instance, then the maximum available bandwidth is 4.1 Gbps, which is shared by the primary VNIC and up to three secondary VNICs. Consider this factor when you decide the shape of the gateway instance and the number of peering VCNs that you want each gateway to serve.