I really enjoy talking with customers about the technology strategy and platform that underpins our IFS Cloud enterprise software, and I must say it is nice to have some of these conversations face-to-face after two years of it being exclusively online.
One of the questions that I get now and then is whether IFS Cloud is a multi-tenant application?
I understand why the question is asked. If we back up to the early days of SaaS software, application developers built multi-tenant applications to share expensive resources (which in those days often were big servers) between multiple customers (the “tenants”). But that was a long time ago. Today that question is the wrong one to ask.
So let me explain why we should never talk about multi-tenant applications again.
Things are no longer what they were
When SaaS software started to take off after the millennium, most companies that provided SaaS applications were providing solutions to smaller businesses—the ones that did not have their own large or mature IT departments or data centers. Instead, the software vendors ran the software on behalf of their customers. And they did so from servers running in their own “server rooms” (remember this was before AWS got popular and before most of the other public clouds even existed).
Running separate physical servers and databases for every customer, especially since many of them were smaller companies, was too expensive and many of those servers would sit idle a lot of the time. Application developers had little choice but to solve these issues in the application itself. Typical patterns were the introduction of a “tenant id” to all tables in databases to share database servers, and the mapping of sub-domains to tenants in order to share things like web and application servers. This led to consequences like changes being applied to the application impacting all customers at the same time. Not necessarily something customers wanted, but something they had to accept. From a security point of view, customers depended on the application developers not to make mistakes that could lead to data bleeding between tenants. Again, not ideal, but something customers had to accept.
Since then, a lot has changed. With software moved to the big public clouds like AWS, Azure and GCP, organizations don’t worry about any physical servers or disks or things like that for applications. All applications share physical resources just by running in the cloud. Building on the virtualized infrastructure, we now have container and Kubernetes technology, platform-as-a-service, server-less computing and a host of techniques. These techniques allow applications to share resources and platform services with thousands of others efficiently and without the application developers having to architect or build this into the applications themselves. This avoids many drawbacks of application-level multi-tenancy and improves aspects such as data privacy since the segregation is built into the cloud platform, rather than relying on all the application developers.
Ask about service attributes
So, if “is the application multi-tenant” is the wrong question to ask, which question should we ask? In my opinion, it’s not a single question—we should ask multiple questions about the different attributes of the service that are important to your business. Some good examples include:
- Privacy. How well is my organization’s data shielded from that of other companies? To what extent is it accessible to the vendors’ service operations and support staff only on a need-to-know basis (e.g., to work on an open support ticket)?
- Automation and self-service. Are common operations such as adopting the latest update or refreshing my test environment with data from the production environment something our teams can do themselves using self-service and automation without waiting for a vendor to perform a manual operation?
- Customer in control. Do I have some flexibility (within reasonable boundaries) to determine when maintenance windows happen or when functional changes to the software are applied? So, I don’t end up with a big change in the middle of the most critical time for my business.
- Tailoring. Can I tailor the solution to fit the specific needs of my business? What methods of tailoring are available? Can I add/extend the functionality of the vendor’s solution using the vendor’s platform?
- Efficient resource usage. With a subscription fee that includes both the “service” and “license” aspects of the software, resource efficiency is primarily a concern for the vendor. That said, resource efficiency could affect the vendor’s ability to support its customer base or develop the service further. And computing resources impact the environment just like everything else.
- Elasticity. How easy is it to increase my usage if I need to? Can I decrease later if my usage changes?
There isn’t one single approach or architecture pattern ideal for all the above. Nor is there only one way to achieve privacy, automation, or any of the attributes. Consequently, modern software mixes techniques to deliver a software service with the attributes desirable for their customers. Perhaps the main application runs as a set of containers, using a platform-as-a-service for image storage, spinning up a dedicated database for each customer for data privacy reasons?
Is there no case to build multi-tenancy into the application code anymore? For larger enterprise applications, I would argue that the answer is generally no. However, it still makes sense in high volume consumer freemium services where you might have millions of free accounts which are used infrequently (or not at all) since even with today’s cloud services and pricing application implemented multi-tenancy is likely to come in at even lower costs (virtually zero) for a minimally used tenant. But give the cloud providers a couple more years and we might not need it for these applications either. Of course, purposely implemented multi-tenancy continues to make a lot of sense to platform services, as well as the cloud infrastructure itself, are multi-tenant.
Worth talking about
Of course, what you should expect from a SaaS software service depends on what kind of service it is. But since I am an enterprise software guy, I will forgo commenting on consumer or even small business software and stick to commentary for those of you looking at enterprise software for large or mid-size businesses.
- You should expect that the vendor makes every effort to keep your data private and that they can explain to you how they do this.
- Whether you prefer just automation and full service (things are just done for you by the vendor) or a higher degree of being in control supported by self-service depends on your business needs Discuss the options with your vendor and/or its partners.
- You will need some level of tailoring, as a minimum, for things like reports, workflows, and integrations to other software. If you need more extensive tailoring or the ability to add/extend functionality, check if this is possible—in many cases, it is not.
- Related to cost and elasticity, enterprise software usage tends to change over years rather than months or days, which is worth considering when talking about commercials.
Multi-tenancy shall continue to be applied across cloud infrastructure, platform services, serverless computing and so on. Know this and then talk to your software vendor(s), not about whether their application is multi-tenant, but about the attributes of their software service and how that fits the needs of your business.
Learn more about our IFS Cloud enterprise software here.
