Over a million developers have joined DZone.

Cloud Challenges for Databases Series: Multi-tenancy – Shared Everything versus Shared Nothing

DZone's Guide to

Cloud Challenges for Databases Series: Multi-tenancy – Shared Everything versus Shared Nothing

· Cloud Zone ·
Free Resource

Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

Cloud computing is all about being able to consume shared resources in a linear and elastic manner. If you read my previous post on how Xeround got to the cloud then you understand the sharing aspect.

Multi-tenancy and its implications have been the primary concerns of companies that have avoided using the cloud. The underlying reasons mostly involve potential security vulnerabilities but also include the effect of one user’s utilization on other users who share the same physical, or worse, the same virtual resources.

Another layer of complexity is added when considering Database-as-a-Service and multiple tenants – not only do different users share the same physical host but even the database instance itself is shared between them.

There are no databases where a single virtual instance can be “sliced” and offered to several distinct users. When one signs on an Amazon RDS instance, which is a pre-configured EC2 instance with preinstalled MySQL on top, the relation is always 1:1 – one virtual DB instance per customer. This implies a managerial overhead for the service provider on top of inefficient and ineffective use of resources. This is because the end customer often gets a database that is significantly larger than what they need, not only to allow for scaling but also because customers are often unsure of their data’s size, growth rate or what processing power they require.

Xeround designed the core underlying database engine from the bottom up to be a virtual, scalable, distributed solution aimed at making optimal use of resources.

That’s why Xeround can take a single database virtual instance and slice it to be consumed by several users simultaneously. Each customer runs as if they are the only ones using this instance. Since our technology enables transferring a live working database from one instance to another without affecting service or performance, if one becomes overly “noisy” and starts consuming lots of resources, it’ll be moved to another, less burdened instance. Service providers are then able to utilize their resources in a more cost-effective and efficient operations manner.

The same considerations also apply in a private cloud, often associated with a single large enterprise. In this case, operational expenses like the number of required database admins plays an even more critical role in driving a cost-effective yet operationally efficient IT service.

Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}