WSO2 API Manager Deployment in Azure
This is a guide on the core concepts associated when deploying a highly available architecture in Azure which can be applied to a WSO2 API Manager deployment. The various options suggested can be applied based on the SLAs that are required for your use-cases and deployments.
When building a highly available architecture in Azure, following core concepts can be taken into consideration.
- Use of Availability sets ( Protection from hardware failures within datacenters — 99.95% SLA) : Azure availability sets help to ensure better availability within a given data center. Availability sets consist of update domains and fault domains. Update domains ensure that a subset of your application’s servers always remain running when the virtual machine hosts in an Azure datacenter require downtime for maintenance which can be considred as a planned downtime. While update domains are logically sectioned fault domains align to the physical separation of shared hardware in the datacenter. Therefore if one server rack fails due to unexpected failure there will be other server racks available.
- Use of Availability zones (Protection from entire datacenter failure — 99.99% SLA) : Availability zones help to protect your server availability amidst data center outages within a region. Availability zones are independent physical datacenter locations within a region that include their own power, cooling, and networking. However availability zones don’t support all virtual machine sizes and aren’t available in all Azure regions. Check that they are supported in your region before you use them in your architecture. (https://docs.microsoft.com/en-us/azure/availability-zones/az-region )
- Use of subnets and network security groups(NSG): When you define resources within a virtual network, it is important to place them in relevant subnets with network security groups defined to filter inbound and outbound traffic for each subnet. There are default rules defined such as direct access to internet can be overriden by custom rules defined in NSGs. By default, all Azure resources within a virtual network have outbound connectivity to the internet. External inbound communication must come through a public-facing endpoint.For example in most scenarios , WSO2 API gateway is the component that needs external visibility which you would want to expose to the internet.
- Use of scale sets: Azure virtual machine scale sets let you create and manage a group of identical, load balanced VMs. Therefore you could place WSO2 API Manager components (that need to scale) in scale sets for automatic provisioning.
- Use of Application gateway and Azure Load balancers: For load balancing between multiple VMs you could use either ALBs or application gateways based on the scenarios. Application gateways are L7(application layer routing using request URL) while ALBs are L4 load balancers.
Above diagram depicts a reference deployment in a single region, however if you require a multi-regional deployment you could place Azure traffic manager to perform global traffic routing to each regional deployment based on various routing methods such as geographic routing, performance routing etc.
Above diagram depicts a typical hybrid deployment where you would need certain runtime components such as WSO2 API Gateway residing on-premise to support certain services that should reside onsite while the control plane and a public data plane is deployed in Azure. In such a scenario you could use a virtual network gateway which can be a VPN gateway or Expressroute gateway to build the connectivity between Azure and on-premise data center.
A VPN gateway can send encrypted traffic between the two networks by using an existing internet connection.ExpressRoute creates a direct connection (private connection) between your on-premises network and the Azure virtual network that doesn’t use the internet. Therefore use of VPN gateway might not be suitable for all scenarios where bandwidth constraints can cause latency issues that result from reuse of the existing infrastructure. Therefore , for mission critical workloads/environments it is recommended to use Expressroute where there is a need for a resilient high-bandwidth connection,high level of availability and higher security from the on-premises network to Azure.In addition, as depicted in the diagram , you could refer to a pattern where aVPN gateway can be configured as a failover route if there’s a loss of connectivity to an ExpressRoute circuit.
