First and foremost, it’s important to keep in mind that there is no "one true way" of delivering a digital service, regardless of whether you’re doing it as a business with customers being outside of your own organization, or whether your own organization is the customer. Hence, the challenges and solutions we will be discussing in this article reflect our own preferences and experience - both from being a part of a "backup-as-a-service" business ourselves (from 2006-2016) and subsequently from being an independent software vendor (ISV) working with customers on our product, named "Cloutility", which we have been providing as a software solution for delivering backup-as-a-service to "managed service providers" (MSPs) and large enterprises since spring of 2016.

Providing services in general

Regardless of which type of service you want to provide, being able to scale without drowning in your own success, i.e. ensuring that the work required to provide your service doesn’t grow proportionately with each added customer, is of paramount importance. This means that you need to:

1. Choose your tools carefully: You want to use your time improving your service, not worrying about the fundamentals.
2. Automate whatever you can: You want to avoid performing repetitive tasks - frequently at least. Spending time setting up each new customer may be acceptable, but having to spend time on them daily is probably not.
3. Outsource tasks whenever possible: You want to enable your customers to perform as many tasks as possible on their own, so that you’re using your resources efficiently.
4. Minimize dependency on individuals: You want your service to run and be able to change features, billing and other settings, regardless of which of your colleagues are available.

Backup-as-a-service

When it comes to providing data backup-as-a-service (sometimes abbreviated as "BaaS"), the fundamental challenge revolves around choosing a data-protection infrastructure based on backup technology which is scalable, robust and secure. Whether there is one vendor or product that satisfies your needs, or whether you need to use multiple vendors and products, depends entirely on your situation, e.g. do your customers use physical client-machines or virtual environments/hypervisors and virtual machines, do they run specific application servers, do they need to back up cloud services, etc.?

The next challenge is choosing tools, which allows you to provide the chosen backup technology/technologies to your customers, not just in terms of actually getting their data backed up, but also in terms of providing with the information they need to know that their data is secure and possibly the capabilities to make changes to how their data is organized and handled. In our experience, some of the key features required to satisfy these needs are (in no particular order):

1. Multi-tenancy.
2. End-user self-service.
3. Scheduled reports and alerts.
4. Consumption measurement.
5. Subscription-based recurring billing.
6. Integration with other systems.

… each of which will be elaborated upon in the remainder of this article. 

Multi-tenancy

Secure multi-tenancy (or multitenancy) is the concept of having multiple tenants in a shared system, rather than having to set up dedicated systems for each tenant, while preventing them from accessing information which doesn't concern them. However, if you're providing backup-as-a-service, merely having multiple tenants in one system often isn't enough as there is a good chance that your service exists in a multi-level (or multi-layer) organizational hierarchy which can be almost flat in some parts, and many levels deep in others (unless your service has a strict one-to-one relationship with the end-users). Hence, in relation to backup-as-a-service, your multi-tenant environment needs to enable you to create a model that reflects your real-world organizational hierarchy, consisting of e.g.:

• Regions
• Departments
• Server groups
• Direct customers
• Resellers
  • Customers of resellers
• etc.

... and provide the users with the ability to manage their own part of this hierarchy (e.g. by providing them access to a shared data-protection infrastructure), without them gaining access to information which doesn’t concern them, i.e. have them securely separated from business units and other resources outside of their own part of the hierarchy.

Regardless of whether you deliver backup-as-a-service to hundreds of end-customers as an MSP, or to regions and departments as the internal IT services provider in a large enterprise, you will benefit from being able to segregate the data-sources you manage (even though they may reside in a shared data-protection infrastructure) in order to gain both a general overview as well as detailed insight into how your data-protection infrastructure is used. And if your business model changes at some point, say that you decide to enable other organizations to use or resell your service, multi-tenancy can provide you with the tools you need to easily add them to your existing hierarchy and provide them with the resources and privileges they need to get going, instead of necessarily having to set up a separate environment for them.

The predecessor to Cloutility was designed as a rigid multi-level structure that was tightly coupled with the business practices and distribution channel (dealer > partner > customer > subscription etc.) of the backup-as-a-service business which was intended to be its sole customer. However, even within our own organization, this approach sometimes led to redundancy in case a said customer didn’t quite fit into the rigid structure. Armed with this knowledge, the offset for Cloutility became:

• a flexible and secure multi-tenant hierarchy in which there were no fixed/required organizational levels
• where each business unit could be the root of a new hierarchy, while being completely separated from other hierarchical siblings or ancestral relationships (apart from intentionally shared resources), and e.g.:
  
  • use their own brand
  • have related users signing in and be able to administer their own business unit as well as its potential descendants
• and with each business unit being able to be related to one or more data-sources.

In addition, as organizations changed over time, being able to easily move business units including their potential hierarchies (and data-sources) around in the multi-tenant hierarchy became an integral part of Cloutility’s backbone, in order to prevent inevitable changes inside and outside of our organization resulting in potentially huge workloads for our own organization.

To accommodate for various sign-in and security requirements, Cloutility also supports both single sign-on (SSO) via SAML 2.0, e.g. for Microsoft Active Directory Federation Services (AD FS), Google Workspace etc. and multi-factor authentication (a.k.a. 2FA/2SV/MFA/MSV) using "time-based one-time passwords" (TOTPs) which can be configured throughout the multi-tenant hierarchy.

End-user self-service

End-user self-service basically means that you enable your users to perform the tasks which you want them to perform, thus eliminating the time they otherwise need to wait for the task to be completed (often leading to greater user satisfaction), and enabling your highly skilled technical staff to spend time maintaining and improving your data-protection infrastructure. A "real world" analogy of this could be that you fill up/charge your car yourself, instead of having a mechanic do it, as you’re perfectly capable of doing it yourself, and because you would probably rather have the mechanic spending time fixing and fine tuning your car. By providing end-users with self-service features, you simply outsource various tasks to the people to whom they matter the most.

The downside of outsourcing tasks to end-users is of course a loss of control which needs to be mitigated. In Cloutility every action is controlled by role-based privileges, which means that in order for a user to carry out a specific task, the role that their user account is associated with needs to have the said privilege. An example of this could be a finance employee who needs to have access to finance information and billing data, but shouldn’t be able to create or delete data-sources in their part of the business unit hierarchy. In addition, Cloutility employs many definable rules, e.g. in terms of how backup nodes are named when they’re created in the infrastructure, date settings related to when data can be deleted etc., which means that the self-service features provided to the end-users actually follow strict rules which have been defined by our customers’ technical staff, and thus ensure that data remains nice and neat in the data-protection infrastructure.

For us, being able to provide our end-users with the self-service features they need (which is an ever-expanding list), meant that:

1. Our product needed to be able to run on-premise (i.e. in each customer’s local data center), as some of our customers run Cloutility-instances on internal networks which are sealed off from the Internet. This setup also fitted our shared philosophy of the importance of being able to control where your data is stored, and (depending on your license-agreement) having either a minimal amount of high-level data or no data at all exchanged with us.
   
   1. We also wanted our product to be relatively easy to install to lower one of the initial barriers of entry, and once you have the prerequisites in order, the installation only takes a few minutes (which includes the automated creation of Cloutity’s database).
2. We needed our customers to be able to keep up-to-date with the latest available functionality with relative ease, in order to reduce the time between our publication of a new feature (or fixed defect) and having the functionality available to our customers and their users. (We’re proud to say that you’re still able to install the first version of Cloutility and update it to the latest version with a single software-update - although there are a lot of automated database-updates to complete in the process, meaning that it could take a couple of hours for very large instances.)
   
   1. For our own satisfaction, we needed to be able to publish updated functionality easily, as we wanted to publish new functionality as soon as we felt confident about it instead of having to postpone great features to e.g. fixed yearly launch dates. To accommodate this, we built a delivery apparatus that is highly automated and (at time of writing) has a time from code is committed until a software-installer containing the changes is published at around 30 minutes, which potentially enables us to publish software-updates multiple times per day (if necessary).
3. It made sense for Cloutility’s user-interface to be a web-application, as this would provide the users with a "single point of entry" (for each Cloutility-instance) which users could access using their Internet-browser of choice (although some are more favorable than others), and provide our customers with a "single point of update", i.e. that our customers only have to update their Cloutility-instance in order to make new functionality available to their users.

Scheduled reports and alerts

One thing is having your users perform tasks themselves, another thing is to let them know whether everything is running smoothly or if they need to take corrective action. In a backup-as-service setup, scheduled reports and alerts are often central components of what determines if users feel confident about using the service. Scheduled reports, for instance, limit the need for your technical staff to merely collect and present data and allow them to spend more time improving the infrastructure or fixing potential problems.

In Cloutility, reports and alerts are built into the multi-tenant hierarchy in the sense that e.g. (customizable) status reports are generated automatically each day for each business unit and are available through the user-interface, and can be scheduled to be delivered via email to subscribers either:

• At fixed intervals, i.e.:
  • Daily.
  • One or more specific weekdays.
  • One or more specific days of the month.
• When errors are observed.

By default, the report settings are inherited through the hierarchy and can thus be centrally controlled, but as different users may very well have different requirements or different opinions regarding what constitutes an error, e.g. some users may consider a file being in use during backup as an error while others may not, each user and report subscriber can be configured to contain and emphasize different information. The integration with the multi-tenant hierarchy means that everyone from system administrators to end customers can get exactly the report that they need when they need it.

For administrators of the data-protection infrastructure, Cloutility provides server reports, which can also be delivered via email at fixed intervals or when errors are observed (i.e. if the Cloutility-instance encounters errors while synchronizing data), meaning that your technical staff can react quickly if something isn’t working as intended.

Consumption measurement

As an MSP or enterprise you have a license model with your data-protection infrastructure provider(s), and the cost of said license is often associated with the amount of data you back up and perhaps even the number of clients you back up. Based on this, it’s important to have access to various (and updated) data consumption values. In addition, it can be necessary to know these values for various parts of your hierarchy (e.g. specific departments, resellers or customers), and not just for your entire organization as a whole. And sometimes, the license can even be affected by the amount of data transferred as part of the performed backup operations.

In Cloutility, all of the aforementioned values are built in to the multi-tenant hierarchy, meaning that each value is summarized for each business unit and its descendant hierarchy as part of each status report (for items in the data-protection infrastructure which have been assigned to the hierarchy), so that you can easily get the level of granularity which you need or desire, e.g. viewing the top-level business unit for a summary of the entire hierarchy, or picking an arbitrary business unit to get a summary of its part of the hierarchy. Values for items which are not assigned in the hierarchy are available as part of the comprehensive server reports available to the administrators of the data-protection infrastructure, so whether or not you assign all of your data-sources to the hierarchy (manually or automatically), Cloutility helps you to determine if you’re compliant with the license model for your data-protection infrastructure.

Subscription-based recurring billing

Whether you’re running a multi-channel MSP business with e.g. internal systems, direct customers, resellers, etc, or a large enterprise with e.g. continents, regions, countries, cities, departments etc. having the ability to settle and invoice business units throughout your organization is often a fundamental requirement for delivering backup-as-a-service. If you’re an MSP this is most likely a core component of your business’s monetary foundation, and if you’re an enterprise this functionality could provide you with the ability to fairly distribute the license cost for your data-protection infrastructure based on how much your individual business units consume.

The process of settling (charging/invoicing) accounts in an "as-a-service" setup is often more complex than the e.g. one-time invoices associated with the delivery of computer hardware or consultancy hours. Customers of services often expect to get settled monthly, quarterly or yearly based on how much they actually consume of a said service at the time of settlement, along with various ways of choosing the actual value used for settlement: You may want to use the latest known storage values or perhaps an average of the said values since last time an account was settled. And in some cases, you probably have to be able to settle business units based on a mix of metrics and settlement values.

Our approach to this has been to enable each business unit in Cloutility’s multi-tenant hierarchy to own (or inherit) subscriptions, which can be configured with one or more products, which in turn is each configured with various settings that determine how they’re settled, e.g. which values are used when settling, whether they’re settled as units or packages etc. With subscriptions available, the hierarchy can then be used to assign one or more of these to the desired business units as part of contracts, which also defines the rate at which (i.e. the number of times per year) the specific business unit is settled. After being set up, Cloutility will automatically generate a set of billing data (on a configurable date) each month, which can then be imported into whatever system you use to generate your invoices to your customers. Hence, instead of relying on complicated scripts or (superhero) individuals in your organization to manually settle your individual customers, you can use a "set it and forget it" approach and retrieve your billing data effortlessly once a month.

Besides the core data-protection services, Cloutility even allows you to add custom consumption based products to your subscriptions which are settled according to "manual" registrations, i.e. various types of on-demand services. This functionality is handy for e.g. registering (and settling) time spent supporting a customer or a specific data-source.

Integration with other systems

Most organizations rely on multiple/many systems to function, and as a backup-as-a-service provider you’re probably in a similar situation. An obvious candidate is using a system to create invoices for your customers, or having this functionality built into an ERP (enterprise resource planning) system. Having multiple systems means choosing the best tools for your business, and being able to integrate them with each other is vital in order to spend your time most productively. It could be that you benefit from having daily alerts from your clients appear in a central support system, or automatically have your billing system fetch the latest billing data when it becomes available and generate invoices to your customers.

In Cloutility, integration with other systems is made possible through an extensive REST API which provides all of the data and actions available through the user-interface. Access to the API is also tightly coupled with the multi-tenant hierarchy, meaning that you can limit access from other applications to certain parts of the hierarchy as well as having them employ a role which is limited to the data and/or functionality they need. 

Summary

In this article we have highlighted some of the core challenges that our experience tells us are central to delivering backup-as-a-service, as well as provided you with some insight into how we have chosen to address these challenges in Cloutility, which is the solution we provide to enable our customers to deliver backup-as-a-service. We hope that you found it helpful and inspirational, and if you want to learn more, you’re welcome to get in touch with us.

Thank you for reading.

Book an online demonstration