Many vendors with data centers and cloud storage now offer database as a service (DBaaS) as part of a set of solutions to customers. The typical business will benefit because the vendor handles the installation and upgrade of database management software, backup and recovery of databases, query performance tuning, capacity planning and database administration staff. Of course, this comes with a cost. Still, the ability to create and roll out applications quickly means that software development is not hampered by the need to acquire database resources, hire and train personnel and manage software upgrades.
Is DBaaS a possible strategic direction for your company’s IT infrastructure? In order to determine this, there are several issues you must address. In this article I list the most common risks that require mitigation before embarking upon delegating all or most of your database storage and management to an outside firm.
Risks and Mitigations
There are several reasons why companies prefer to keep all portions of systems development in-house. This includes hardware, software and staff. No cloud services, no outside services, no contractors or temp staff. In order for DBaaS to be a viable strategic IT direction we must address these issues. Following are the most important issues accompanied by possible mitigations.
With corporate data stored in a controlled data center, an enterprise can directly manage who can access what data. A single, centralized control system for corporate data permits easy auditing, faster security threat detection and simple implementation of new security regimes and rules. Since all data is stored locally and IT controls all access to hardware, files and applications, the (perceived) chance of a security breach is minimal.
Contrast this with the DBaaS environment, where a large part of your data is stored and controlled by an outside entity at a remote location, or in the cloud. The DBaaS provider controls the form in which the data is stored (disk storage, flash memory, RAID disk arrays, etc.), how database backups are taken and stored (disk or tape, on-site or off-site or cloud, etc.), and which vendor employees or contractors can access the data. Several different media accessed by a large number of people through several (some unknown to you) applications would appear to multiply security risks.
IT can mitigate security concerns in a DBaaS environment by being selective about what data is stored by the DBaaS provider and limiting its access. Specifically, ensure in your DBaaS contract that no provider employees have direct access to the data. While this may seem unworkable for database administrators, in reality the DBA does not require data access. The provider can assign DBAs and other support staff to security roles that give permissions against the database object definitions but not to the data itself. This allows the DBA to create and change database table structures, create indexes, execute database backups and reorgs and other support tasks without seeing the raw data.
There is one case where direct data access may be needed, and that is when diagnosing and debugging possible application or database errors. For example, a customer complains that their computed account balance does not match what is on file, or a product was assigned an invalid price. In such cases you have two alternatives: give the DBaaS provider staff temporary data access authority (revoked after the problem is fixed), or diagnose problems yourself, remotely.
Technical Staff Management
Human resources and managers can directly measure and judge employee performance. In addition, management can plan for future staffing needs based on known skills and abilities. In the DBaaS environment, you have little or no knowledge or control over the provider’s staff. Indeed, turnover may be anywhere from zero to one hundred percent without your knowledge.
The DBaaS service provider’s reputation depends upon them hiring and retaining highly competent staff. On the other hand, there are many basic database management operations that do not require much expertise. These include creating objects (tables, indexes), implementing regular database backups and reorganizations, basic performance monitoring and tuning as well as several other operations. Newly-hired DBAs will already have several working examples available, from which they can copy or clone new ones.
The service provider should be able to provide a list of DBA-related tasks that will be performed by beginners or generalists; in addition, any procedures that require advanced DBA expertise should be spelled out in the service contract, including whether such services come at an extra cost. The provider expects that services will expand in the future. Your database size will grow, you will add new application functions and features, and may even wish to purchase advanced services such as business analytics. With that in mind, DBaaS services will expand and so will their need for expert IT staff to support that growth. Hence, expert DBA staff will always be available.
The one caveat is that other clients are growing as well. Your DBaaS provider may well need to prioritize how staff are assigned to tasks associated with their universe of client databases. Ensure that such staff will always be available for your database and application by including how, when and at what cost specific support staff will be retained by your provider.
The classic “buy versus build” argument is that you buy or lease an application (or product or service) if you wish to maintain parity with your peers, while you build an application if you wish to use it as a competitive advantage. Consider an employee payroll. Would you be more inclined to do business with a company that advertised that they have a “state-of-the-art” payroll system? This is an example of a process that should be purchased or leased. On the other hand, consider an on-line service ordering app. If you wish to attract and retain customers for your service business, creating your own custom application to interface with customers may be the best way.
The same logic could be applied to maintaining database administration completely within the enterprise. It is rare for a company to create its own database management system for use by all applications (unless, of course, you are IBM or Oracle or another DBMS vendor). However, there are some combined data models, database designs and applications that companies consider proprietary. You may not feel comfortable allowing a vendor to see exactly how you defined your databases and associated applications in order to get a special performance or operability advantage. Such things may not be completely covered by the idea of trade secrets or patents.
One way to mitigate this risk while still implementing DBaaS is to split off the non-proprietary data and definitions into a separate database and have that managed by a provider. Or, if this process would be too difficult, you may consider a non-disclosure agreement as sufficient. However, despite these concerns it is rare that applications with proprietary database configurations would be good DBaaS candidates. The purpose of DBaaS is to off-load database management tasks to the provider in order for you to develop applications more quickly. If your database configuration is highly-specialized, you already have the appropriate hardware, software and IT support staff in-place, and have already implemented your critical applications. DBaaS in this case is unnecessary.
Even with the advent of big data applications, many companies try to keep their data as close as possible (in the network sense) to the hardware that uses it the most. For analytics, this means keeping the data warehouse and even some operational data storage physically close to the business analytics software. This is especially relevant when analytical queries return large result sets. For example, many warehouse and big data extract files originate as queries. This, along with data federation (configuring your analytics operation to behave as if all of the data were in one location), usually leads to a large, centralized area for storing analytical data.
Implementing DBaaS in this environment means physically moving some portion of your operational systems data off-site or to the cloud. Daily extract processes that take that operational data and load it to the warehouse (and perhaps to your big data application) now execute longer, as the data must traverse a network to arrive at its destination. Finally, typical analytical queries will execute joins between transactional data and data warehouse dimension tables, in order to do groupings and aggregations. Table joins perform best when the tables involved are in the same database. Moving some tables to a DBaaS provider reduces performance of table joins.
One way to mitigate this issue is to consider migrating your data warehouse (or a subset of it) to DBaaS. Dimension tables tend not to be the largest tables in the warehouse; those are the fact tables, which contain the accumulated regular extracts of operational data. Therefore, migrating or copying the dimension tables to the DBaaS provider creates a secondary analytics platform. Business analytics queries may now execute entirely within the off-site database.
The next logical step is to federate both your on-site and DBaaS databases in your analytics system. While this requires special software, the advantage is that your analytics users can now build and execute queries without regard to data location, and the system determines where to execute the query. This requires some work on your part, especially ensuring that some tables (like the DW dimension tables) are at multiple locations and are kept in sync.
There are other issues with utilizing DBaaS, including concerns about application performance, data capacity planning, and handling change control of application code that is embedded within the database itself (for example, stored procedures). These issues usually involve delegating processes other than pure database administration to your DBaaS provider, and agreements or mitigations can be negotiated as part of the service contract.
The items highlighted in this article (security, staff management, proprietary technology and centralized analytics) are the ones that can make or break an IT strategy of moving to DBaaS as a standard IT model. Analyze and understand the risks and develop possible mitigation plans with costs and benefits. The result will be the perceived risks and rewards of this strategy, followed by your first pilot project with a DBaaS vendor. Expect several years of interaction with multiple vendors before you have a firm grasp of the real costs of delegating database storage and management; however, the time and effort spent in addressing the issues mentioned above will start you in the right direction.
See all articles by Lockwood Lyon