With API Management becoming a crucial requirement in modern-day organizations, the next challenge that the project teams face is to select the most appropriate software and match that into technical and budgetary requirements and restrictions of the organization. Being completely an open source and free API management product, WSO2 API Manager also brings so many possibilities into the picture that leave the project teams with many choices. This article intends to educate the readers about the available deployment options of WSO2 API manager and discuss the advantages that different options could deliver. The same knowledge can be used in order to choose the most cost-effective deployment that fits your exact requirements while keeping the complexity at minimum possible level.
WSO2 API Manager certainly is a well-known and proven product in the industry of API business. During the past few years, it has gone through many improvements and architectural revamps that has ultimately left you with the choice of using a much more fine-tuned version of a completely free and open source API Management product with the optional Enterprise Support provided under WSO2 Subscription.
Due to the architectural changes happened throughout the past few years and the technical level improvements made such as performance optimization and based on commonly identified industrial utilization patterns, WSO2 has recently published a set of recommended deployment patterns which are depicted and listed under the official documentation.
If you are already familiar with WSO2 API Manager product and have had hands-on experience in the past—knowing all the possibilities of distributing components and using them in different combinations that are also technically accurate—you may wonder why or whether WSO2 now has put limitations or restrictions.
Even if this sounds somewhat awkward from a theoretical perspective, you will not really have the same doubt when you practically design your API management solution using WSO2 API Manager product in order to meet the actual set of technical and non-technical requirements. Because these few patterns have been identified and finalized as the most applicable patterns based on the real use-cases in the industry and the existing WSO2 API Manager installations. In simple words, whatever your current requirements and future plans for expansion are, the required WSO2 API Manager deployment will follow one of these given deployment topologies in general. Therefore, it is important that you evaluate the nature of your requirements and expectations carefully and choose the best deployment pattern that would neatly fit in your use-case as it helps you keep the deployment complexity at the lowest possible level while making it more financially feasible.
When evaluating WSO2 API manager, the first thing that you have to do is verifying that it consists of the required capabilities/features and how easy it would be to understand and use it. For this, you can simply create a Trial Account on WSO2 public API Cloud and follow the instruction presented on the UI itself during the first run. When/if you are satisfied with the features evaluation, you can think of the other requirements and technical matters such as the deployment possibilities, topologies, and infrastructure.
WSO2 API Manager supports cloud, on-premise and hybrid style deployment of the components. WSO2 Public API Cloud comes with the default capabilities of WSO2 API Manager and would be a cost-effective version of the same product as it follows a subscription-based pricing model and as there wouldn’t be any implementation effort/cost involved in getting it up and running. However, depending on each organization’s requirements of unique capabilities, organizational security policies or customization (rebranding) many customers look for other deployment options such as on-premise, (private) managed-cloud and hybrid deployments. Only when you decide not to go for the WSO2 Public API cloud due to such requirements, you will have to consider of learning more about the component architecture of the WSO2 API manager and the recommended deployment patterns.
When thinking of your own deployment, there will be a few main factors which you have to consider in the initial design.
- Currently expected capacity
- Organisational security practices
- Future expansion possibilities
The deployment pattern 1 targets those scenarios where lower capacities are expected to be handled which however is the most common. Technically, this will handle a throughput of or less than 500 HTTP API requests per second with normal REST/SOAP inbound/outbound payloads even with a moderate amount of mediation. Therefore, it would be wise to at least start with this pattern keeping the deployment complexity and the implementation time/cost at the minimum until an actual requirement emerges for further scaling.
However, based on organizational security compliance requirements also, there can be requirements to separate API-M gateway from the rest of the components and maybe to install in different clusters in different network domains. This is also a valid reason for thinking beyond the deployment pattern 1.
Also, your API Management project may have different phases based on future expansion possibilities and expectations. For example,
- At the initial stage, your solution maybe used by internal customers (departments etc) and partners of your organisation.
- At some point in future, you expect to expose the APIs to the internet (public access)
- You wish to have a distributed deployment with physically separated gateway clusters (differently scaled) for internal and external API traffics
In such cases, if you are concerned about the migration effort/cost the existing API subscription records (of API users) from a simple API deployment (that follows deployment pattern 1) to a fully distributed API Manager deployment (such as the deployment pattern 3) you may have a valid reason to start with a complex/distributed deployment pattern from the beginning itself.
However, alternatively, you can start with pattern 1 and continue with the business for a foreseeable future and improve the solution following an iterative approach that would introduce new components with time, only when required. The choice between these 2 possible decisions may mainly depend on the Migration cost vs the WSO2 subscription for the number of years that the expansion is not required.
While it still is possible to deploy the WSO2 API Manager components distributed in different combinations that are not listed under the WSO2 recommended deployment patterns, it would be advisable to stick to these patterns or to go for a deployment that is nearly similar to these as these are most commonly used, hence are well tested and proven in the industry.
Also, as an additional advantage of complying to these patterns, you can easily onboard WSO2 API Manager based solutions with the resources such as the WSO2 Official Docker/Kubernetes repository that WSO2 has provided and keeps improving.
If you believe that the above mentioned capabilities would address some requirements you have, or WSO2 middleware platform has the potential of helping you build your future solutions providing the capability of expansion and extension; you can go to the next level by exploring WSO2 official documentation, articles and other resources such as videos and webinars to gather more knowledge on specifics.
Comments
Post a Comment