Hi lakng,
I think you are trying to ask about multi-tenant if it is please go through below text:
In a multi-tenant cloud application, essentially all of the customers share the same copy of the application code. They also have their data stored in a single, shared (and often encrypted) database. When the vendor makes a new release available, there’s only one copy of the code to update and all customers get migrated to the new release simultaneously. Think of how Google changes its search screen imagery on Father’s Day and many other holidays. Every Google customer sees the new version of the screen the next time they access that website. No upgrade CDs/downloads are required. The new version just appears for all users.
There are a lot of advantages to the multi-tenant customer and to the vendor that licenses these applications. For the customer, fewer IT resources are needed to patch, maintain and upgrade the application (reduced TCO). End users get upgraded functionality regardless of what the IT backlog looks like (no delays in receiving new functionality). And, there are no additional hardware and systems software components that must be ordered, installed and maintained (lower TCO, lower capital consumption). For the vendors, there are markedly fewer versions of the software to support (often just the current version and maybe one prior) and far fewer technical architectures to support (often just one). Bottom line: vendors don’t need to charge as much to provide equal or better service to customers and customers can re-deploy a number of IT resources (people, capital, hardware) to more strategic initiatives.
In the private cloud and on-premises worlds, users can have their own copy of the application and their data is stored locally. When a new application version/release is available, the user (not the vendor) is on the hook to upgrade the software, do any database manipulations, convert files, etc. This environment is great for those companies that want to: heavily customize a packaged application; maintain control over when (or if) the application is upgraded; or, keep their data and software under their total control.
This world is populated with on-premises users, private cloud implementations of cloud software and single-instance cloud solutions. Regardless of the exact deployment, the customers have a unique instance of the software and their data is physically (not just logically) separated from other customers’ data.
This world is expensive for all parties. Whenever a customer has an issue with the software, the vendor may need to recreate the environment that a given customer has. That could mean running an older version of the code on a non-standard relational database, on an operating system that may or may not have recent patches, with a unique combination of systems and security software all on an older piece of computing hardware. Of course, this assumes a vendor can actually create this configuration, has subject matter/technical experts in all of these disciplines, and, can emulate the data that is getting borked. This support environment creates long resolution times and frustrated customers.
Vendors are not too fond of this world anymore. All of those added costs slow their innovation efforts and suck away scarce capital. Just last week, one software executive shared with me that his last employer has to maintain 54 different financial accounting application suites that this company acquired (via mergers/acquisitions) over the years. Worse, this vendor is supporting multiple versions and technical architectures for each of these. This support cost is a major drain on their profitability. It also is siphoning away capital from their innovation/R&D budgets. That last point makes it hard for them to compete with pure-cloud competitors. This sharp executive now works for a pure-play cloud application vendor – he’s loving his job again.
NOTE: Mark correct or helpful if it helps you.
Warm Regards,
Raj patel
Hi lakng,
Please mark correct or helpful based on the impact of my answer.
Regards,
Raj Patel