Connect multicloud microservices using Oracle API Gateway

The Oracle API Gateway service enables you to publish APIs with private endpoints that are accessible from within your network, and which you can expose with public IP addresses if you want them to accept internet traffic.

When creating enterprise solutions, you may find that different parts of the solution have been deployed in different clouds (or even on-premises), as a result of specific needs or as a result of team preferences on cloud vendors. For example, services that extend Office 365 may have been deployed on Azure, but the core services such as ERP may reside on OCI.

If you then wish to expose some of these services as APIs to partners, you would not want to try operating multiple gateways in different clouds. Splitting APIs across different clouds is likely to be confusing to the API consumer - not to mention risks exposing the user to a greater chance of needing to change. Also if there are some sort of restrictions or controls involved in the use of the APIs, managing such controls becomes very challenging. In such situations, Oracle API gateway enables you to link multiple backend services into a single consolidated API endpoint.

The Oracle API Gateway service is integrated with Oracle Cloud Infrastructure Identity and Access Management (OCI IAM), which provides easy authentication with native Oracle Cloud Infrastructure (OCI) identity functionality. When you have services running on different clouds (such as OCI, Oracle SaaS, any 3rd party cloud: such as an Amazon Web Services (AWS), Microsoft Azure, Google Cloud Computing, and so on, you can use Oracle API Gateway to expose all these services to your service clients.

Using Oracle API Gateway provides the following benefits:
  • Supports multicloud architecture: avoid vendor lock-in, meet compliance requirements, improved resilience, flexibility and risk management. Enables users to run service backends on any cloud to meet the compliance requirements (without getting locked to a single cloud vendor), but still expose a unified endpoint to clients regardless of where the backend service is running.
  • Enables running different services on different clouds; provides an unified endpoint regardless of where the backend is implemented.
  • Enables a unified endpoint to be presented to API clients regardless of where the backend is implemented. Sometimes legislation may dictate where the backend can and cannot be deployed, but Oracle API Gateway ensures that clients are not impacted.

Using Oracle API Gateway helps to address the following challenges:

Customer challenge Oracle API Gateway solution
Implementing a multicloud architecture and running different microservices on different clouds using an unified endpoint
  • Enables a mix and match approach: different microservices can be implemented on different clouds.
  • Provides a monitored and controlled point of ingress. Having a common gateway allows network traffic to be directed in a more controlled manner. i.e. traffic to other clouds is enabled via the gateway and monitored effectively. If the traffic starts and ends wherever services are deployed, then the network has to allow everything being able to connect with everything.
Microservices can undergo internal changes and they can also be moved from one cloud to another Microservices already running on other clouds can continue to do so (for example, Microsoft based applications can continue to run on Microsoft Azure)
Client applications, that leverage these microservices need uniform uninterrupted access to all these microservices running on different clouds All microservices running on different clouds can be exposed together to clients using OracleAPI Gateway.

Architecture

This reference architecture shows how to connect services running on OCI and other clouds (or data centers, such as OCI, Oracle SaaS, any 3rd party cloud, or an on-premises network) using Oracle API Gateway, and expose the services to your service clients.

The following diagram illustrates the data flow for this reference architecture.



oci-multicloud-api-gateway-flow-oracle.zip

There can be different service providers. For example:
  • Containerized services and services running on virtual machines, on 3rd party cloud.
  • Oracle SaaS applications, like Oracle Fusion Cloud Applications or Oracle Fusion Cloud Enterprise Performance Management, (which can be integrated using services such as Oracle integration).
  • Oracle Autonomous Database services
  • Cloud native services such as OCI functions and Container Engine for Kubernetes (OKE).
The services can be consumed by:
  • on-premises applications (connected using OCI VPN or FastConnect). For example, applications running in the data center.
  • internet based clients. For example, web pages and mobile apps accessing the services over the internet.

Once proper network connectivity is established, the OCI API Gateway can connect to different backend service providers, abstract the complexities of these services (as required), and expose the service APIs that can be easily consumed by the service clients.

The following diagram illustrates this reference architecture.



oci-multicloud-api-gateway-arch-oracle.zip

The architecture has the following components:

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Availability domains

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • Virtual cloud network (VCN) and subnets

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • Oracle Cloud Applications

    Our complete cloud suite of SaaS applications brings consistent processes and a single source of truth across the most important business functions—from enterprise resource planning, supply chain management, and human capital management to advertising and customer experience. The applications help you improve your customer engagements, increase your business’s agility, and react to change faster than ever before.

  • Integration

    Oracle Integration is a fully managed service that allows you to integrate your applications, automate processes, gain insight into your business processes, and create visual applications.

  • Autonomous Database

    Oracle Cloud Infrastructure Autonomous Database is a fully managed, preconfigured database environments that you can use for transaction processing and data warehousing workloads. You do not need to configure or manage any hardware, or install any software. Oracle Cloud Infrastructure handles creating the database, as well as backing up, patching, upgrading, and tuning the database.

  • API Gateway

    Oracle API Gateway enables you to publish APIs with private endpoints that are accessible from within your network, and which you can expose to the public internet if required. The endpoints support API validation, request and response transformation, CORS, authentication and authorization, and request limiting.

  • Site-to-Site VPN

    Site-to-Site VPN provides IPSec VPN connectivity between your on-premises network and VCNs in Oracle Cloud Infrastructure. The IPSec protocol suite encrypts IP traffic before the packets are transferred from the source to the destination and decrypts the traffic when it arrives.

  • Oracle Cloud Infrastructure FastConnect provides an easy way to create a dedicated, private connection between your data center and Oracle Cloud Infrastructure. FastConnect provides higher-bandwidth options and a more reliable networking experience when compared with internet-based connections.

  • Functions

    Oracle Functions is a fully managed, multitenant, highly scalable, on-demand, Functions-as-a-Service (FaaS) platform. It is powered by the Fn Project open source engine. Functions enable you to deploy your code, and either call it directly or trigger it in response to events. Oracle Functions uses Docker containers hosted in Oracle Cloud Infrastructure Registry.

Recommendations

Use the following recommendations as a starting point. Your requirements might differ from the architecture described here.
  • Virtual cloud network (VCN)

    When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

    When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

    Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

    After you create a VCN, you can change, add, and remove its CIDR blocks.

    When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

    Use regional subnets.

  • Security

    Use Oracle Cloud Guard to monitor and maintain the security of your resources in Oracle Cloud Infrastructure proactively. Cloud Guard uses detector recipes that you can define to examine your resources for security weaknesses and to monitor operators and users for risky activities. When any misconfiguration or insecure activity is detected, Cloud Guard recommends corrective actions and assists with taking those actions, based on responder recipes that you can define.

    For resources that require maximum security, Oracle recommends that you use security zones. A security zone is a compartment associated with an Oracle-defined recipe of security policies that are based on best practices. For example, the resources in a security zone must not be accessible from the public internet and they must be encrypted using customer-managed keys. When you create and update resources in a security zone, Oracle Cloud Infrastructure validates the operations against the policies in the security-zone recipe, and denies operations that violate any of the policies.

Considerations

When deploying an Oracle API Gateway, consider the following options.

  • Performance

    OCI API Gateway supports response caching by integrating with an external cache server (such as a Redis or KeyDB server), that helps in avoiding unnecessary load on back-end services. When responses are cached, if similar requests are received they can be completed by retrieving data from a response cache rather than sending the request to the backend service. This reduces the load on backend services and thereby helps in improving performance and reducing costs.

    OCI API Gateway also caches Auth Tokens (based on their time to leave TTL), reducing the load on the Identity Provider and improving performance.

  • Security

    OCI cloud services use IAM policies such as allowing API Gateway to invoke functions. API Gateway can also control access using OAuth authentication and authorization. IAM allows authentication and authorization that can be federated via IAM - as a result the API Gateway has the power to authenticate against a wide array of services and authentication setups.

  • High Availability

    Consider using a high availability option based on your deployment requirements and region. The options include distributing resources across multiple availability domains in a region and distributing resources across the fault domains within an availability domain. Fault domains provide the best resilience for workloads deployed within a single availability domain. For high availability in the application tier, deploy the application servers in different fault domains, and use a load balancer to distribute client traffic across the application servers.

Explore More

Review these additional resources to learn more about the features of this reference architecture.

Acknowledgments

  • Author: Kaushik Kundu
  • Contributors: Wei Han, Phil Wilkins