Today’s software users are a demanding bunch. They’re mobile and international, so they demand immediate access to applications from anywhere at any time. They want to see continuous enhancements – whether it’s new features, improved usability, or greater sophistication. And they don’t want to pay for things they either aren’t using or aren’t using yet.
So it makes sense that many companies selling software have started to offer software as a service (SaaS) to meet those needs. But in doing so, they’re finding that the traditional SQL databases their customers have used for years to manage application data on-premises are not necessarily well suited for today’s cloud delivery environment.
Database Choice Can Affect Your Financial Health
When software providers consider transitioning to (or at the very least adding) a SaaS offering, they think about the impact to their business of moving from a perpetual license model to a recurring revenue stream. And while it’s easy to remember and consider such migration costs as application-level rearchitecture, other upfront and ongoing costs – such as infrastructure and service-related costs – are often severely underestimated.
In addition to fundamentally changing the revenue and financial model of software licensing, a SaaS model shifts the balance of power and expectations between customer and provider. Suddenly, the software company is responsible not only for acquiring, building, and operating the entire application stack, but also for the service-level agreements (SLAs) associated with the provided service.
Let’s take a look at some of the potential cost considerations:
1. Continuous availability. Consumers don’t react well to SaaS vendors that need to schedule downtime for routine updates and other maintenance requirements.
2. Seasonal or time-dependent volume peaks. Bursty user demand can lead vendors to over-provision both hardware and software licensing for peak periods and incur unnecessary costs that fail to take advantage of cloud elasticity.
3. Disaster recovery. Slow fail-over capabilities can make a SaaS solution vulnerable to region failures – a particularly big issue as demand grows.
4. Mobile and multi-device access. Users expect that SaaS applications will be available anywhere at any time, but that can cause “local everywhere” latency issues.
5. Lack of multi-tenancy. Simple virtualization requires each customer be given their own database, archives and security credentials, creating additional capital and operating costs for the SaaS vendor.
Lower services cost allows ISVs to dramatically increase addressable markets, fuel faster services adoption, and pull-in the timeline for break-even on the initial investments. Therefore, the cost of providing software as a service becomes the most strategic consideration for an ISV in planning and executing its transition from a product to a service delivery model.
On the surface, it may seem that selecting a database is purely a technical decision driven by the engineering team based on best-fit feature set. But in fact, the database is interwoven into each of the considerations outlined above, and database choice can significantly lower total cost of ownership required to support a SaaS application.
For many application providers, the first step to providing a service offering is often to simply take the entire application stack and begin hosting it – isolated stacks for each customer. This has the advantage of minimizing application-level changes, as well as speeding time to market, but significantly compounds the cost burden on the ISV with each additional customer.
To move beyond an expensive hosting model to a more cost-effective true SaaS model, development teams need to consider how to optimize the software to support many customers simultaneously on the same resources (“multi-tenancy”), while meeting or exceeding service level agreements and maintaining separation of their data and instances for security purposes.
For example, finding a database that can support the concept of multi-tenancy means fewer licenses to support, less hardware to manage, and simpler administration of the system as a whole. Take the following example: In its original hosted environment, one mid-sized application vendor kept active use of system capacity to 30 percent to give more active customers headroom from growth. Relying on a cloud-based database management system, this company has been able to amortize the use of software and hardware across multiple customers through multi-tenancy. Now, the operations team no longer needs to think about projecting a customer’s future demands or playing musical chairs with fluctuating capacity.
Ultimately, the operational database is arguably the most expensive component of your application service, as well as the most difficult to manage at scale and often the most common source of customer problems and grievances.
In addition to the multi-tenancy issue outlined above, consider how the other items listed above can drive cost overruns:
- Continuous availability and disaster recovery: To address this with a traditional relational database typically requires highly complex architectures involving clusters, replication, and duplicate infrastructure
- Mobile device access and volume: To meet performance requirements due to increased demands around the world and/or higher access volumes, old school databases either rely on complicated sharding schemes or alternatively NoSQL databases that might sacrifice SQL familiarity and necessary ACID compliance
- Underutilization of resources: Seasonal peaks are usually addressed through year-round and forward-thinking over-provisioning, and without multi-tenancy, your resources are severely underutilized
All of these add up to the high cost of not just the initial migration to a cloud delivery environment but also to exorbitant ongoing costs. So how then to begin bringing those costs down?
Ultimately it comes down to architecture and priorities. There are effectively four core database options:
- Traditional relational databases
- NoSQL databases
- Cloud-based relational databases or database as a services
- “NewSQL” databases
Let’s take a look at each of those individually.
Traditional Relational Databases
This category is dominated by mega-vendors such as Oracle, Microsoft (SQL Server), and IBM, as well as open source options such as MySQL and Postgres. The advantage is that most traditionally on-premises applications are already architected to support two or more of these databases, so application layer changes are minimal and the time to market is reduced. Unfortunately, while these systems have the weight and support of decades of development, they struggle to capitalize on cloud advantages such as on-demand capacity, commodity hardware structures, and distributed computing. The result is that this strategy can limit your ability to scale out to address growing customer demand, and easily result in the highest total cost of ownership.
NoSQL
The rise and popularity of NoSQL databases can be attributed in large part to the inability of traditional RDBMSs to meet modern application requirements. Such systems are well suited for cloud delivery and can typically scale out elastically and support continuous. But the abandonment of (or at the very least, minimal support for) SQL and ACID semantics not only requires significant portions of an application to be rewritten, it also requires the application to take on significant complexity that would otherwise be absorbed by the database. As a result, a NoSQL strategy lengthens the time to market and can increase the difficulty in updating and maintaining the application code itself due to the absorbed data management complexity. For some applications, this may be acceptable. For many others, this isn’t a viable option.
Cloud Databases or Database as a Service
As more organizations become comfortable with public cloud deployments, cloud databases such as Amazon Aurora for RDS, Google Cloud SQL and Microsoft Azure SQL become prime candidates as well. Typically based on familiar products such as MySQL or SQL Server, these products have the advantage of a familiar database in a cloud environment, but often suffer the same single node disadvantages of their on-premises implementations as it relates to provisioning, elasticity, and even distribution. As a result, you need to rely once again on clustering, replication, and sharding to meet your availability and performance needs, not to mention the added difficulty of switching databases if you ever decide to change your cloud provider.
NewSQL
That leads us to a relatively new category of databases coined “NewSQL” by The 451 Group’s Matt Aslett. In a recent academic paper, Aslett and Andy Pavlo of Carnegie Mellon University define NewSQL as “a class of modern relational DBMSs that seek to provide the same scalable performance of NoSQL for OLTP read-write workloads while still maintaining ACID guarantees for transactions. In other words, these systems want to achieve the same scalability of NoSQL DBMSs from the 2000s, but still keep the relational model (with SQL) and transaction support of the legacy DBMSs from the 1970–80s.”
That’s not to say that NewSQL isn’t without its detractions. Unlike using legacy or cloud databases based on legacy systems, NewSQL requires some minor code review to eliminate database-specific idiosyncrasies – though infinitely less work than it would take to port an application to a NoSQL system.
Ultimately, identifying the right cost and architecture structure for an application can help determine both customer satisfaction and financial viability of a SaaS offering.
For example, by enabling an organization to pay for the capacity needed today and add as needed, one multi-billion dollar product design software provider estimates that it saves approximately five million dollars in license costs for a traditional relational database, as well as avoids about 1.5 million dollars in Amazon Web Services costs for the accompanying infrastructure.
Providing software as a service in addition to (or instead of) an on-premises model is a strategic business decision. What isn’t immediately apparent is that the database provides a critical role in ensuring the success and relevance of every factor that influenced that decision.
From a financial perspective, the right database choice can:
- Reduce infrastructure costs (by using commodity hardware and eliminating pre-provisioning)
- Speed time to market (by minimizing application rearchitecture)
- Maintain SLAs (by remaining up through outages and upgrades)
- Maximize existing resources (through multi-tenancy, capitalizing on existing skills, and increasing utilization)
One global financial software vendor with a hosting budget of $100M a year estimates that the use of next generation database management system resulted in savings of three million dollars in the first year alone and will increase significantly as more applications are ported over.
Given the pace of innovation and demands of today’s economy, companies are becoming more interested in leveraging on-demand services rather than continuing to invest in on-premise software and systems. Next-generation cloud based database management systems provide a financially responsible and efficient alternative to traditional databases to serve an increasingly growing, global, and mobile customer base.