1. Set up the infrastructure to host multiple single-tenant SaaS applications
  2. Learn About the Infrastructure for Hosting Single-Tenant SaaS Applications

Learn About the Infrastructure for Hosting Single-Tenant SaaS Applications

As an independent software vendor (ISV) providing software as a service (SaaS), you need secure, scalable, enterprise-grade infrastructure to host your services and manage your tenants. This solution provides sample Terraform modules for a validated network topology to host multiple single-tenant SaaS applications on Oracle Cloud.

Before You Begin

Review the deployment patterns for SaaS applications, learn about a generic network architecture, and understand the design considerations. See Design the infrastructure for hosting SaaS applications.

Architecture

This architecture shows the sample network topology for which the solution provides Terraform code. The sample topology supports four tenants. All the components in the topology are in a single region in an Oracle Cloud Infrastructure tenancy.


Architecture for an ISV tenancy that hosts multiple SaaS tenants

The SaaS vendor's management infrastructure and the application resources of each tenant are isolated in separate compartments and virtual cloud networks (VCNs). Network isolation ensures that the applications and data are segregated from the other deployments in the tenancy. Compartments ensure logical isolation of the resources and enable granular access control.

This topology contains the following components:

  • Management compartment

    The management compartment is a logical container for all the ISV-specific resources necessary for the common infrastructure used to manage the individual tenant application deployments. It contains the following resources:

    • ISV VCN

      The resources required for the SaaS ISV to access and manage its tenants are attached to the ISV VCN.

    • Bastion

      The bastion server is a compute instance in a public subnet in the ISV VCN. The traffic between the internet and the bastion server is routed through an internet gateway.

      The ISV's administrative users can access all the resources in the tenancy, including the private addresses of the resources in the tenant compartments, through the bastion host. The administrative users of the ISV can also access the private resources in the tenancy by using an IPSec VPN tunnel or an Oracle Cloud Infrastructure FastConnect circuit.

    • Management server

      The management server is a compute instance in a private subnet. It is attached to a private subnet in the ISV VCN. The management server can communicate with the servers in the tenant compartments through the routing gateways.

      You can use the management server to install and run an infrastructure monitoring application, such as Nagios Core.

  • Peering compartment

    For private communication between the resources in the ISV VCN and the tenant resources, a local peering relationship is necessary between the ISV VCN and each tenant VCN. But a VCN can have up to only 10 local peering relationships. To overcome this scaling limitation, the architecture uses routing gateways that can connect to multiple peering VCNs. Each peering VCN can have a local peering relationship with up to 10 tenant VCNs. So you can scale up the topology by adding routing gateways and peering VCNs in the peering compartment.

    • Peering subnet

      The peering subnet is a part of the ISV VCN. All the routing gateways are attached to this subnet.

    • Routing gateways and peering VCNs

      Each routing gateway is an Oracle Linux compute instance that routes traffic from the management server to the tenant VCNs, through a peering VCN.

      To demonstrate high availability (HA) of the routing gateway, an active-passive pair of compute instances with a floating IP address is used for one of the routing gateways. Pacemaker and Corosync are installed to ensure automatic failover. The second routing gateway is a single (non-HA) instance.

      The primary VNIC of each routing gateway instance is attached to the peering subnet in the ISV VCN.

      The routing gateway instances use the VM.Standard.2.2 shape, which supports one secondary VNIC. The secondary VNIC of each routing gateway instance is attached to a subnet of a peering VCN. Each peering VCN can be connected to a maximum of 10 tenant VCNs. In the sample topology, each peering VCN is connected to two tenant VCNs.

      • By using larger shapes for the routing gateway instances, you can extend the topology to support more peering VCNs. For example, if you use the VM.Standard.2.4 shape for a routing gateway instance, then you can attach up to three secondary VNICs to the instance and connect the routing gateway to a maximum of three peering VCNs. So the routing gateway can support a maximum of 30 tenant VCNs. Remember that the available network bandwidth of the routing gateway instance is shared by all its VNICs.

      • 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.

  • Tenant compartments

    The resources for each of the four tenants in this topology are in a separate compartment. Each tenant compartment contains a VCN to which all the resources for that tenant are attached. So the resources for each tenant use a unique address space in a network that's isolated from all the other tenants in the topology.

    In each tenant compartment, a compute instance is created. You can use this instance to install and run an infrastructure monitoring agent. For example, if you install Nagios Core in the management server in the ISV VCN, then you can install the Nagios agent in the compute instance in each tenant compartment. The agent can monitor the servers in the compartment and send metrics to the Nagios monitoring server.

    When you add new application tenants, the necessary resources for the new tenant are provisioned in a new compartment.

    Tenants can access their application over the public internet or through a private connection (IPSec VPN or FastConnect). For access from the public internet, each tenant VCN requires an internet gateway. For access using VPN or FastConnect, a DRG is necessary. The architecture diagram doesn't show the internet gateways and the DRGs for the tenant VCNs.

About Required Services and Policies

This solution requires the following services and access-management policies:

Service Policies Required To...
Oracle Cloud Infrastructure Identity and Access Management Create and manage compartments.
Oracle Cloud Infrastructure Networking Create and manage VCNs, subnets, internet gateways, route tables, security lists, LPGs, and DRGs
Oracle Cloud Infrastructure Compute Create and manage compute instances.

See Learn how to get Oracle Cloud services for Oracle Solutions to get the cloud services you need.