- Use Cases
- Dev Center
- Download CE
- Watch the Demo ❯
You are here
The Shortcomings of Traditional Database Architecture
Apr 20 2016
Today’s SaaS market realities have revealed a number of fundamental flaws in the traditional, monolithic, relational database management systems (DBMSs) of the past.
Traditional database architectures were conceived in an era in which software and systems were deployed in a relatively centralized and static environment, often in a single data center. The traditional database vendor viewed service as a reactive support function rather than a proactive delivery method.
In today’s world, software users are both increasingly mobile and international and expect to access applications from anywhere at any time. They also expect continuous enhancements to the software to improve its usability on a regular basis. And, they expect the SaaS vendor to help them successfully utilize their applications to achieve their business objectives.
Traditional database vendors that have historically released updates and upgrades on a periodic basis are not accustomed to delivering new features and functionality at today’s pace. Their database architectures also fall short in today’s cloud delivery environment for a number of reasons, including:
- Lack of continuous availability which forces SaaS vendors to schedule downtime for routine updates and other maintenance requirements.
- Slow fail-over capabilities in any single-region that can make the SaaS solution vulnerable to total-region failures – a particularly big issue as demand grows globally.
- Mobile and multi-device access is setting user expectations that SaaS applications will be available anywhere at any time, but causing “local everywhere” latency issues.
- Bursty SaaS demand can lead vendors to over-provision their systems for peak periods and incur unnecessary costs that fail to take advantage of cloud elasticity.
- Simple virtualization requires each customer be given their own database, archives and security credentials, creating additional capital and operating costs for the SaaS vendor.
Although many SaaS vendors have relied for years on traditional SQL databases to manage their data, these relational databases are typically unable to scale to meet today’s global market realities. The monolithic architectures were not designed to accommodate rapidly growing and geographically distributed workloads across a heterogeneous environment with multiple Infrastructure-as-a-Service (IaaS), datacenter and geographic configurations.
This demands a scale-out architecture to respond to organic growth without step-change upgrades that can become costly. The architecture must also be highly elastic to accommodate workload fluctuations. As described above, existing on-premise applications typically have a rich heritage steeped in a transaction-oriented database and must take that heritage into account when migrating to the cloud.
By contrast, many applications “born in the cloud” have experimented with forgoing a lot of the traditional transaction logic. Such an approach has the advantage of simplifying the API and application requirements, but introduces complexity and cost to adequately manage consistency, handle failure, or otherwise ensure the operational flexibility a SaaS application needs to adjust to changing requirements. In incorporating necessary logic into the application instead of the database, upgrades, new features, dynamics of scale, and general operational activities become increasingly difficult to implement because of the many assumptions built into the application.
In addition, SaaS companies increasingly require a database that can not only handle more transaction-oriented SQL applications, but also complex data structures beyond relational – such as table-style, key-value document stores, or graph models. Where today organizations deploy single-data-model databases for each of their needs (and the accompanying complexity of data movement tools), SaaS companies ideally seek a single, multi-model database that can support two or more data models in a single platform.
Stay tuned next week where I'll explore "Maximizing the Value of SaaS Data in the Cloud" and why a new database architecture is necessary to support today's SaaS requirements.
This is the fourth in a multi-part series on "Executing a SaaS Strategy: The Role of the Database." You'll see a new post from me every week for the next several weeks on the topic, but if you'd like to access the entire series now, you can download it here.
Jeff Kaplan is the managing director of THINKstrategies, the only strategic consulting firm focused entirely on the business implications of the transition of the technology industry from product-centric to services-driven solutions, including software as a service (SaaS), cloud computing and managed services. Follow Jeff on Twitter @thinkstrategies.