Mastering the Art and Science of WSO2 IAM Capacity Planning
WSO2 IAM is an Open Source IAM platform that offers three main offerings in 2022. Depending on your budget, user base, and the complexity of the solution you can choose one of the following CIAM solutions:
- On-Prem WSO2 Identity Server
- WSO2 Identity Server Private cloud on Azure managed by WSO2
- WSO2 CIAM public cloud on Azure — Asgardeo
When you use the WSO2 Identity Server to build your solution, the first question that comes to your mind is what are the standard system requirements to deploy the WSO2 Identity Server on an on-prem or cloud infrastructure.
The performance of the WSO2 Identity Server is not dependent on the total number of users in the system, it always depends on the parallel login requests that hit the server at an average time or a peak time. If this peak time happens regularly or more frequently, then better to get this peak concurrency value to decide on the number of virtual CPUs or the instances you need to install the WSO2 Identity Server.
Based on the performance benchmarks that were done from the lab tests do not clearly show horizontal or vertical scalability of performance, but we can roughly estimate that 2 cores of the WSO2 Identity Server instance can handle 150 to 200 concurrent login requests at a time. Similarly, 4 cores can handle up to 250 to 400 concurrent login requests with less than 1 second response time. But this response time also varies depending on the login flow which you select. If it’s redirection based then it's obvious for the high response time as user interaction is involved.
When deciding the number of cores you as a multiple of 2 cores or 4 cores and horizontally scale up depending on the performance tests that you have done on your deployment.
After deciding on the number of cores, there are a few other important things that you need to further consider before you work on a CIAM deployment.
1. The High availability of the Identity Server instances
When you work on a CIAM cluster, it is a must to create it in a way that achieves high availability.
- Active / Active — is the most recommended HA deployment for critical and sensitive systems. A minimum of two instances of WSO2 IS is recommended.
- Active/Passive — is recommended for less critical deployments where data is not critical or sensitive and less than 5 mins of downtime is bearable.
2. Auto-Scalability of the deployment
If you use Kubernetes or AWS ECS, then you can able to get the auto-scalability option from the infrastructure itself. Hence if you go with Active/Passive, it is recommended to go for an auto-scalable infrastructure where your high availability of the deployment can be secured up to an extent.
3. Database scalability
The disadvantage of the WSO2 Identity Server cluster is, that all the nodes are pointed to one central database. Hence always there is a risk of a single point of failure at the DB level.
Although you scale up WSO2 Identity Server nodes, if you don’t scale your databases or maintain high availability at the DB level, then there will be a bottleneck at your database level during a high concurrency period. Worst case, this can cause service unavailable issues.
** If you have large concurrencies like 1000, 10 000 definitely then you should work on the high availability of your databases as well. You can use the RDBMS databases that support high availability like Oracle-Golden-Gate, and Amazon RDS.
** Do not use LDAPs or Active Directories to store millions of users. They themselves are not designed for CIAM use-cases. They are more suitable for workforce IAM solutions
When it comes to Asgardeo (Public cloud), you really do not need to think about the capacity of the deployment. All of these above factors will be handled by the WSO2 team. Moreover, Asgardeo has a pay-as-you-go system, up to 10,000 MAU you can use it for free as well if needed. After talking to WSO2, you can get a flexible pricing proposal too.
Hope this blog would help you to get an idea of how capacity planning happening in the WSO2 IAM platform.
