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.
Meeting current industry demands, all the WSO2 product can be deployed on any of the below infrastructure choices:
- On-premise — using bare-metal servers or VMs
- Infrastructure-as-a-Service (IaaS) providers — AWS, Azure, GCP, etc.
- Container platforms — Docker, K8s on On-premise or Cloud
Due to a number of advantages compared to on-premise, most of the enterprises are either starting to move to the cloud or already started/ moved to the cloud. WSO2 products also come with first-class support for deploying on cloud platforms such as AWS, Azure & GCP.
Microsoft Azure is one of the leading cloud platforms available today. It brings a lot of new capabilities every month/ quarter into the platform. They have a very aggressive approach to acquiring a larger portion of the cloud market and they already have a large presence in the market.
While we see a lot of customers have already deployed WSO2 products on AWS already, Azure also becoming a preferred deployment option for most customers today.
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.
Below is the high-level WSO2 API Manager deployment architecture which we are going to deploy on Azure:
In summary:
- WSO2 API Manager all-in-one deployment pattern will be used and 2 nodes will be deployed to provide minimum high-availability (HA)
- 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.
Choosing the right location is the very first exercise of deploying any Azure solutions. For that, we need to select the right Region and Availability Zone (AZ).
Region — is a set of datacenters deployed within a latency-defined perimeter and connected through a dedicated regional low-latency network. Azure gives you the flexibility to deploy applications where you need to, including across multiple regions to deliver cross-region resiliency. We can choose the best Region based on technical and regulatory considerations: service capabilities, data residency, compliance requirements, and latency.
Availability Zone (AZ) — is a high-availability offering that protects your applications and data from datacenter failures. Availability Zones are unique physical locations within an Azure region. Each zone is made up of one or more datacenters equipped with independent power, cooling, and networking.
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.
Resource Groups (RG) — is a container that you use to group related resources in a subscription. Each resource can exist in only one resource group. Resource groups allow for more granular grouping within a subscription and are commonly used to represent a collection of assets required to support a workload, application, or specific function within a subscription.
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.
When provisioning VMs, it is recommended that two or more VMs are created within an Availability Set to provide for high availability. An availability set is a logical grouping of VMs that allows Azure to understand how your application is built to provide for redundancy and availability. Using availability sets we can achieve high availability and meet the 99.95% SLA provided by Azure.
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
- Azure SQL Managed Instances
- SQL Server on VMs
- Third-party Azure Managed Databases— MySQL, PostgreSQL, and MariaDB
Using Azure SQL or Azure SQL Managed Instances can be an advantage over the others as they are fully-managed storage services and provide all the production-grade Microsoft SQL Server capabilities in the cloud.
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.
Azure Files will be part of an Azure Storage Account and we need to pay extra attention when creating the Storage Account to make sure we select the right combination of Type — GPV2 mostly, Access tier — Hot, Replication — LRS, ZRS, GRS — ZRS for better availability.
Further, we can use Azure File Sync if we are planning to synchronize files between the on-premise file servers and Azure Files in the cloud.
Below is the high-level Reference Architecture diagram I have created for deploying WSO2 API Manager for a minimum viable deployment on Azure. While this caters to small to medium deployments, this can be further expanded to suit your complex/ distributed deployments. The concepts and workloads we discussed here can be used to deploy any other WSO2 products on the Azure cloud as well.
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.
Also, choosing the correct pricing tiers/ plans is another key concept when using cloud platforms and it also has a direct impact on the availability of certain features/ capabilities. We need to pay extra attention when selecting the required pricing tier/ plan especially for workloads such as Compute (VMs), Storage (SQL), etc. as it will affect the health, performance of the overall solution.
Happy WSO2 + Azure together…
