For the entrepreneur who wants to implement a significant digitally-based service or sell products to customers on-line, the need to get the application written and implemented quickly is a strong one. The thought of creating and maintaining an information technology infrastructure is daunting. Purchasing hardware, finding a space with appropriate power requirements, installing software, managing leases and licensing agreements, backup and recovery ... the list is long, and getting it all done will be time-consuming.
Luckily, there are several services available to the business that wants to get its new application up and running in minimal time. These include Software as a Service (SaaS), Database as a Service (DBaaS) and cloud storage. Each of these has its costs, advantages and disadvantages. In this article, we will concentrate on why you would consider having someone else host your database data, and what are the risks in doing so.
Hosting Your Data
The choice to have a service provider host your data rather than building that infrastructure yourself will affect more than just the location of your data. Some of the considerations are below.
Investment in Infrastructure
External data hosting will usually occur in the cloud, based upon how your DBaaS vendor defines its hardware locations or third-party storage providers. In either case, the investments made in hardware, software, disk and tape storage, and network bandwidth will be the vendor’s, not yours. This is sometimes seen as an advantage to using DBaaS since it relieves you of the need to purchase, locate, install, and maintain all of these things. However, there are some additional considerations.
Since the vendor owns the infrastructure (or at least the portion not located at other providers), the vendor gains financial advantages such as volume and size discounts on leases and license fees for equipment and software, as well as the ability to depreciate these assets. Information technology assets are also often classified as capital expenditures that enjoy favorable tax treatment.
Physical Data Characteristics
As your data is not physically stored at a location that you own or control, you lose visibility as to the specifics of the storage mechanisms. Is the data in a database and, if so, what is the vendor? Are the multiple databases from different vendors? Is the data stored on high-performance disk drives, or in memory, or a combination of both? What performance techniques are available and being used to speed data storage and retrieval? Is the data encrypted? Is the data compressed on storage and, if so, are you being charged for the compressed or uncompressed storage?
These and other questions may affect how you may retrieve the data. Must you use proprietary software? Can you use a standard database interface such as SQL? Will you receive regular copies of the data for your own purposes such as emergency backups? Will you be charged for data transfer as well as data storage?
Database as a service requires the provider to hire and train several different classes of support staff, including database administrators, systems programmers and storage analysts. Each of these jobs requires special skills and education related to the specific hardware and software environments that they support. As your application grows over time, the vendor’s staff gains valuable experience. What happens after the first year or so? Will these experienced professionals move on to other jobs taking their experience with your application with them? How will new employees be training to take over? When it comes time to perform hardware and software upgrades, which staff will be doing this?
Having the vendor worry about these things makes it easier for the entrepreneur to concentrate on developing and publishing their application. However, your business staff who defined the application and the application developers must interface at some point with the DBaaS staff. It is essential for your success that their staff have experience with your category of application and that they remain supporting it through initial implementation and beyond. When it comes time to grow your data and application due to an increase in customers you want experienced staff supporting everything.
Interoperability Versus Performance
Your DBaaS provider has already made hardware, software and network choices. They may have chosen to purchase ‘best of breed’ items from various vendors. These items, such as CPUs, disks, and database management software, will each be one of the best in their class. The DBaaS provider must then handle any interoperability issues that arise from connecting equipment from disparate sources. If your queries are running slowly is it because the network is slow, the database manager is slow, the CPUs are slow, the disks are slow, there isn’t enough memory, the database is configured incorrectly, or what? You must expect to encounter occasions when your provider is unable to ascertain quickly where problems are occurring.
The alternative approach is to acquire all hardware, software, etc. from the same vendor. This assures that all equipment will work together, and if problems do occur there is only one vendor to call. One potential downside of this choice is that the various pieces of the service may not be the best cost or best performing choices. When it comes time to scale up to support your growing customer base, performance enhancements may be limited.
Planning for Future Expansion
It is only natural that you expect your application to experience growth in many ways such as number of customers, number and complexity of offered products and services, database size, and so forth. The DBaaS provider must make allowances for an eventual scaling up that will probably involve larger databases and more frequent transactions. Another dimension is scaling out as the application adds new functions and new transaction types, and may also include serving a larger potential customer base or geographic area.
Another type of scaling that is pertinent to the database is the storage and support of complex data types. Many applications store pictures of parts or products for viewing by customers. Audio and video clips are also popular as either product samples (songs or musical performances) or how-to or troubleshooting tutorials. Beyond these common data types are more complex, unstructured data types such as extensible markup language (XML), a self-describing data type used by modern database applications.
As the DBaaS provider has already implemented a hardware and software platform, its available choices for these unstructured data types may be limited.
Security concerns are quite common. Despite their best efforts, many companies have had their data hacked by outside agencies. In the DBaaS arena it may not be enough to encrypt your data. A total security solution should include user account management for customers and for support staff. For the new application, this is particularly worrying as the various methods of accessing data are controlled by an outside vendor.
It may not be enough that security safeguards are in place. Does your provider have a method of determining if data has been stolen? If customer data is compromised who is responsible for informing customers? Are the DBaaS staff monitored and audited to ensure that only authorized staff have access to the database? Last, what about your own application staff? Since they must also have access to the production data for testing and verification, who is responsible for monitoring them?
A business must decide if a specific application is critical or will be used to gain an advantage over current and potential competitors. This is in contrast to many mundane applications such as billing, payroll, human resources and the like, which simply execute standard functions similar to those in other companies. Internal application such as these are rarely considered as giving the company a competitive advantage; frequently, however, customer-facing applications such as on-line ordering and payments may be seen as one-of-a-kind or specialized interfaces that are unique to your business.
In the case of these applications implementing DBaaS means exposing your application and its data to an outside provider and their staff. As part of your service agreement you will likely include a section on non-disclosure. Still, as the vendor experiences vendor staff turnover, where will the previous staff go? To your competitors? Even more interesting is the case when one or more of your competitors implements DBaaS, maybe with your provider!
Backup and Recovery
Disaster recovery planning is a standard database management task. No doubt your DBaaS provider already has plans for differing scenarios such as hardware failures or site power outages. Since DBaaS concentrates on databases and data, one common method of ensuring data recovery is to store multiple copies of the data in multiple locations. Should one location fail or not be available, other sites can be accessed.
The same isn’t true for the database management software. There are typically only a few instances of the DBMS installed by your service provider. This is due to the sometimes prohibitive cost of multiple software licenses. In addition, new applications such as yours are expected to start off small and to grow over time, so a single DBMS instance is enough. What if it fails? Software isn’t perfect, and database software failures can be spectacular at times. Your provider should have plans in place to handle this kind of failure.
Managing Your Data
Apart from the above concerns of data hosting, there are additional considerations for data management. This involves the data structure, or metadata, as well as the database design. Various aspects of your data and its definitions need to be managed. Who will manage these, and what happens when something changes?
The Data Model
The data model consists of an organized description of your data elements, the entities in which they occur, the relationships between data elements and any business rules for the data. Here are some examples:
· Data element: Customer number; stored in master customer table;
· Entity: Customer table, unique key is customer number; uniqueness enforced by the DBMS;
· Business rule: Order date must be valid date;
· Business rule: Every order must refer to a valid customer in the master customer table.
For a simple application, the data model will tend to be straightforward. However, suppose your application grows in the future and your application will now handle multiple customer types. Who determines how to implement this in the database? Do you have multiple customer tables, each for a different type? Do you add a data element to the existing master customer table that has a type code? What if different customer types may or may not have valid orders?
The point is that application or business rule changes may drive data model changes and, hence, database definition changes. Who determines what changes will be made at what point? This is also true for data integrity checking. Entity integrity requires that all entities (customer, order, product) be uniquely identified. Who or what enforces this uniqueness, the application or the database? Domain integrity means that data element values must conform to certain definitions. For example, salaries will typically be greater than zero, and delivery dates are usually in the future. Again, where is this enforced? Last is referential integrity, which defines the valid relationships between entities and how to handle changes. If a customer is deleted what happens to their orders, which now refer to an invalid customer? Should such deletions even be allowed?
It is tempting to take the quickest route possible when developing a new application. The speed with which you implement it may determine its success; and, if implemented too slowly or after your competition, its failure. One method of shortening this time-to-market is to take advantage of database as a service. By having a service provider responsible for database implementation, definition and maintenance you can concentrate on coding and testing your application. For a fee, the service provider will handle data storage and database management system infrastructure.
There are some risks involved. Delegating information technology support means that someone else will gain any experiential or staff training benefits, as well as experience in application support. Your options for application growth may be limited based on the provider’s hardware and software choices. Most importantly you must ensure that data management authorities and responsibilities are clearly agreed upon and in writing. When it comes time for your application to grow you need to be in control of data management in order to guide your provider in the direction best for your application and your data.
How the Internet Defines Database as a Service
IBM State of DBaaS
IBM Cloudant Database as a Service
See all articles by Lockwood Lyon