Reference Architecture — Deploying WSO2 API Manager on Microsoft Azure

Introduction

WSO2 is a 15+ years old software engineering organization that provides a set of Open Source products/ platforms for API Management, Enterprise Integration, and Identity and Access Management.

  • Infrastructure-as-a-Service (IaaS) providers — AWS, Azure, GCP, etc.
  • Container platforms — Docker, K8s on On-premise or Cloud

WSO2 API Manager Deployment Architecture

In this article, I will be discussing how to deploy the WSO API Manager on the Azure cloud, and what are different Azure workloads can be used in the solution. This deployment is suited for small to medium enterprises and it can be used as the basis to further expand and design a fully distributed deployment. The concepts and workloads we discussed here can be used to deploy any other WSO2 products on the Azure cloud as well.

API Manager — minimum viable deployment
API Manager — minimum viable deployment
  • API Manager Analytics will be deployed to provide API-related analytics
  • API Manager Analytics Dashboard will be deployed on a dedicated VM instance to balance the performance impacts in the solution

Reference Architecture

The below sections will describe key technology concepts required to deploy the above WSO2 API Manager deployment on Azure.

Provisioning an Azure account

I am not going to go into details on provisioning an Azure account as it might be already provisioned when you get started with the WSO2 API Manager deployment or maybe it is beyond your role/ responsibilities. However, below are a few key concepts related to provisioning an Azure account, and knowing them high-level will be advantages.

Groping Azure Workloads

Grouping all the Azure workloads such as VMs, Storage Accounts, VNets, LBs, etc. into a Resource Group (RG) is the key to deploying, managing, and maintaining them as a single entity. All the resources we create in Azure will be part of a Resource Group.

Choosing the right Azure Workload

Choosing the right Azure workload is a critical factor and it has a direct impact on various features of the overall solution/ deployment. Choosing the correct workload is becoming very challenging as all the cloud providers keep increasing their offerings and we have a wide variety of workload options to choose from. Let’s look at some of the key workload options we can choose from.

1 — Azure Virtual Machines (VM)

We have options to choose between Windows or Linux VMs and they are served under different categories based on what they are meant for. Compute-optimized, Memory-optimized, and Storage-optimized are some examples and for deploying WSO2 API Manager, either Compute-optimized or Memory-optimized VM can be selected.

2 — Azure Storage Services

Azure supports structured, semi-structured, and unstructured data storage. WSO2 API Manager requires structured data storage and they are often referred to as RDBMS. Below are some of the popular choices we have to choose from:

  • Azure SQL Managed Instances
  • SQL Server on VMs
  • Third-party Azure Managed Databases— MySQL, PostgreSQL, and MariaDB

3 — Azure Files

Azure File Storage is a shared storage service that lets you access files via the Server Message Block (SMB) protocol, and mount file shares on Windows, Linux, or Mac machines in the Azure cloud. WSO2 API Manager can leverage Azure Files to synchronize files between nodes when there are multiple nodes deployed.

Reference Architecture — Deploying WSO2 API Manager on Azure
Reference Architecture — Deploying WSO2 API Manager on Azure

Key highlights:

  • The above deployment is designed to be deployed within a single Region. When we move to multi-region deployments, it will add a few more workloads into the picture and increases the complexity.
  • The entire deployment is within a single VNet and private Subnets with NSGs created for each component — Compute, Storage, etc.
  • Azure Load Balancer — is used to expose APIs to consumers
  • Azure Application Gateway — is used to expose product management portals such as Publisher, Dev Portal, Admin Portal, and Carbon Console
  • Azure DNS — is used to resolve domain names within the virtual network without needing to add a custom DNS solution
  • Azure VMs on Availability Sets — used to deploy WSO2 product binaries and availability set is used to group them logically so that Azure understands how your application is built to provide for redundancy and availability
  • Azure File Storage — is used to share files across API Manager nodes
  • Azure SQL — is used to provision underlying API Manager databases and Analytics databases
  • VPN — is used to connect Azure cloud with the on-premise corporate datacenter(s)
  • Azure Function Apps/ Logic Apps — used to depict the possibility of integrating with Services hosted on Cloud

Conclusion

The above deployment depicts only the WSO2 API Manager and WSO2 API Manager Analytics products. We can expand the same to deploy other WSO2 products such as Enterprise Integrator by using the same set of concepts and workloads. We can keep adding more Compute (VM) instances and scale-out the deployment horizontally to deploy more products depending on the use cases.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Joy Rathnayake

Solutions Architect | Public Speaker | MVP | MCT | Trainer | Author | Mentor | Community Leader | Blogger