Customers are organized in different business units, with varying degrees of autonomy and varying degrees of synergy and shared resources. The question how to make this split will at some point also touch on the WSO2 implementation. Under those circumstances, a customer may note that WSO2 offers the multi-tenancy feature. Subsequently, Yenlo is asked to assist in the implementation.
However, for us at Yenlo this is really just the starting point, not the conclusion. While WSO2 multi-tenancy offers interesting features, we do not consider it as the one and only solution.
The API Manager Devportal as a Department store
It depends on what you want to achieve, when implementing WSO2 across multiple business units. Let’s make a comparison with a department store, selling various fashion brands like Zara, Prada, Levi’s and more. The department store may want to separate the various brands on display, for example in the show window, while the accommodation (i.e. department store building) and business processes are essentially the same for all brands sold. They wouldn’t maintain a separate department store for each brand, would they?
WSO2 multi-tenancy is not much different. It offers functionality to completely separate WSO2 processing per business unit, but what exactly do you want to achieve? We’ve seen cases where it was just sufficient to separate tenants in different API stores (comparable to the display window), each with their own branding (i.e. layout and use of logo’s). Which is much easier and allows more flexibility to realize than using the WSO2 multi-tenancy capability. In doing so, you can stick to synergy in development and maintenance, much more when compared to different tenants being implemented.
WSO2 multi-tenancy
Let’s take a closer look. What defines WSO2 multi-tenancy? The WSO2 documentation mentions at various points:
“the goal of multi-tenancy is to maximize resource sharing by allowing multiple users (tenants) to log in and use a single server/cluster at the same time, in a tenant-isolated manner. That is, each user is given the experience of using his/her own server, rather than a shared environment. Multi-tenancy ensures optimal performance of the system’s resources such as memory and hardware and also secures each tenant’s personal data.”
Please visit the WSO2 website for more details:
https://wso2docs.atlassian.net/wiki/spaces
https://is.docs.wso2.com/en/5.10.0/learn/configuring-multi-tenancy/
The right mix of autonomy and synergy for your business units
The first thing to note is that this description focuses on synergy in the use of system resources, not so much on user experience. Secondly, optimal performance can be realized in many other ways as well. For example, the WSO2 Traffic Manager offers rich features for throttling and caching. In today’s environment, it does not take much to avoid server capacity from becoming a bottleneck. Especially when we are moving towards the Cloud, like Yenlo’s Connext solution, where scaling has been neatly and flexibly solved. Thirdly, a tenant’s personal data can be secured in many other ways, using standard database technology for user stores and for stateful data, be it personal or not.
To us, the given WSO2 multi-tenancy description raises the question: why would you want to use a single server/cluster at the same time, in a tenant-isolated manner? The case may be made, but not necessarily. That’s why we at Yenlo will start to ask what mix of autonomy and synergy is desired and offer the best solution fitting your requirements.
Conclusion
WSO2 multi-tenancy is not necessarily the best solution to separate business units within your organisation. Other options exist. Look up at the sky, as if you are in the famous Lafayette department store in Paris! Get your inspiration and please consult Yenlo first. We help you achieve what is best for you, in your specific situation.
