Developers are continually upping the ante by creating better, smarter and more valuable apps. However, these apps also have increasingly sophisticated data requirements, and the ability to take them to the next level may be stymied by an archaic approach to databases in which developers are required to either make serious compromises about how they store and query their data, or learn to manage their own data infrastructure.
Increasingly sophisticated data requirements
Mobile apps, for instance, typically require a great deal of user-provided and contextual data to function, as compared to what a stationary computer would have collected 10 years ago. The data that's being collected is frequently well suited for a particular type of database, but a bad fit for another. While MongoDB, for example, handles most of what a mobile app requires, such as the geodata that a mobile device collects, other databases are well suited for tracking relationships between users (graphs) or time series data.
The difficulties of integrating multiple data streams
Not only do apps work better when they use a database that’s appropriate for their specific requirement, but they get built faster. However, there are hundreds of different database engines available to developers, and going to production with the wrong one can be a costly mistake. For example, if they’re creating a social app, they must consider the need to store user records, relationships between users, time series data, and connections between people. Games typically need to store some amount of social data, in addition to game state data, and many apps also need to store large binary files. Which database do you choose to work with? All of this can lead the developer to decision paralysis, which slows the development cycle.
Furthermore, going to production with a new database can be extremely difficult due to operational constraints. Most databases are difficult to "try out" and don't provide a one-click-to-production service that developers trust behind their apps. As developers are often constrained to the few databases supported by their organization, they may be tied to a specific type of database simply by virtue of the fact that they don’t have the time to invest in managing another, even if it is more specific to their challenge.
Developers are hamstrung by the inability to use the latest and most effective tool to solve a problem, and too frequently "compromise" by using the wrong tool for the job. Problems associated with having the wrong database for a given problem don’t always surface immediately, but when they do, the developer’s hands are often tied. This can be particularly troublesome when it comes to app requirement changes. When a new feature has new data requirements, it introduces new problems, and often re-introduces old ones too.
Database-as-a-Service offers developers freedom
As Database-as-a-service gains steam – its market is predicted by MarketsandMarkets to reach $14B by 2019 – it offers to free developers’ hands, allowing them to pick and choose databases for apps with the ease that one pulls a hammer or wrench from a toolbox.
Developers face some fairly common obstacles to adopting database-as-a-service, such as distrust of cloud and confidence in operational abilities, which is changing over time as everyone learns more about what to ask of a provider. Additionally, if DBaaS platforms can be tried out without an enormous commitment, this often gives the proponents a chance to show what they can accomplish without a huge cost or time commitment. When DBaaS becomes widely adopted, we’ll begin to see tremendous advances in the functionality of apps.