Improve app resiliency by enhancing the data tier

 

The challenge is that applications cannot take advantage of modern databases without extensive re-coding. Applications are directly tied to the database, and the application has to know to send certain database requests to the read replicas or secondaries instead of to the primary database. For many organizations, recoding applications to talk to secondaries is, at best, very costly and, at worst, untenable. Perhaps the team that wrote the code is long gone, or an organization might not have access to the code, as with third-party software.

 

Organizations can take advantage of database load balancing software to front end modern databases and remove the burden from application developers. This software can automatically direct application traffic to the appropriate database, and it can complement database failover to make those processes invisible to the app - and, therefore, customers. 

 

We chatted with the CEO of ScaleArc, Justin Barney, to get his input on how your choice of a database design can make or break your app from the start.

 

ADM: How are database architectures changing?

Justin: Like a lot of other IT infrastructure, database architectures are undergoing a transition to multiple, scaled out instances vs. one big monolithic server. Data servers, web servers, storage infrastructure - they’ve all gone through a similar change. Why? Because a scaled out infrastructure leverages cost-effective hardware and enables a more incremental approach to adding capacity.

 

ADM: How are these changes affecting application design?

Justin: Applications are tied directly to database servers. When app developers write code, they’re writing to a particular database, and in deployment, the application is connected directly to the database. When the hardware design changes from one monolithic server to multiple, smaller servers, the application does not inherently know how to connect to those additional servers. Application coders must rewrite the application to know where to direct specific database requests.

 

ADM: What aspects of modern databases, like SQL Server 2012 and later, help make applications more resilient?

Justin: Modern databases use the architecture of multiple, scaled out instances acting together in a single cluster. The databases use replication technologies to create copies of the primary database server, called replicas or secondaries. These scaled out database architectures offer a number of advantages for application resiliency. First, they provide more capacity, since organizations are now able to tap multiple servers to respond to database requests, spreading out the load and no longer swamping a single server. Second, the database servers can work together for orchestrated failover to reduce application downtime.

 

ADM: What advantages of modern databases are hard for applications to leverage?

Justin: The primary advantages for applications talking to modern databases are to use the additional server capacity and to leverage the automated failover the database supports. Both of these advantages, however, present challenges at the application layer. For scale out, the application has to know it can send traffic to additional servers. In the SQL Server world, for example, that requires “read intent strings” to be added to every database request that’s a read vs. a write. That kind of application recoding is time-consuming, and many organizations have apps - particularly in-house apps - with at least sections of code that were written years ago, and everyone at the organization now is scared to touch that code. The second advantage, failover, also presents a challenge at the app tier. Even if the database is ready to complete a failover and have a secondary take over as the new primary, because applications are directly connected to the databases, the app feels that database outage - no matter how short. Many applications don’t handle the surge of error messages that result from the database dropping all the connections.

 

ADM: What’s the value of an abstraction layer, like database load balancing, between applications and databases?

Justin: Many other areas of IT infrastructure that have undergone scale out have simultaneously adopted a “buffer” layer between the client and the infrastructure getting scaled out. The web tier, for example, uses web load balancers to front end the web servers - clients don’t directly connect to web servers. Those web load balancers spread the load, assist in failover, and route around down servers. The database world is exactly the same. As databases scale out, it’s used to apply an abstraction layer, in the form of database load balancing software, between applications/web sites and the database servers. This software shields the applications from the outages at the database layer, distributes the read load across the secondaries or replicas, and routes around offline database servers. They provide one other advantage as well - when the primary database server, the one taking all the writes, goes down, the software can queue subsequent writes. Then, when a secondary has become the new primary  and is ready to take writes, it can drain the queue and service the database requests. In this way, the application avoids seeing errors - it just sees delays - so it doesn’t hang or have to be restarted. This queueing means users can be entirely unaffected by even a full database server failure.

 

ADM: What attributes should enterprises look for in database load balancing solutions?

Justin: The most critical feature of database load balancing software is that its deployment should be transparent - neither the applications nor the databases should need changes. Also, most organizations run databases from multiple suppliers. Most database load balancing solutions, however, are designed for only one database type - only MySQL, for example. Organizations adopting the architecture of database load balancing should look for solutions that can accommodate the range of their SQL database types. Also, with so many workloads moving to the cloud, organizations should ensure their suppliers are already running successfully on multiple cloud platforms. Finally, since this software typically front-ends really critical workloads, organizations should look for public testimony from well-known customers using that software to service their most business-critical apps.

 

ADM: What other capabilities can database load balancing provide to apps beyond increased resiliency?

Justin: Assisting in failover is one key capability of database load balancing software, but the solutions should also improve performance. Organizations can look for such software to support connection management and connection pooling. This functionality will increase the performance of database servers because the servers won’t be as interrupt-driven and as busy setting up and tearing down short-lived connections. Another way in which database load balancing software can increase performance is via app-transparent caching. The ability to add resource-intensive query responses to a cache - with no code changes or help from app developers - is a key feature for increasing performance 10x to 60x. Handling unplanned outages is an expected capability, but organizations should also look for the software to support planned outages, or maintenance, with no application downtime. The ability to mark a server offline, patch it or perform other maintenance, and bring it back online - with no interruption to the application - provides a significant benefit to the organization.

 

ADM: What advantages do database load balancing solutions provide to app developers?

Justin: Most of the advantages for app developers that get to tap database load balancing software fall into the “what I now can ignore” bucket. Programming database scale out, database failover, and other cluster logic into the application tier is tedious and can be error-prone. It’s also highly repetitive - when you’re done with one app, you have to do it all over again for the next app. There’s no economy of scale or code reuse. With database load balancing software in place, developers can instead turn their attention to more business-value functionality - focusing instead on improving their own customers’ experiences vs. mundane database logic. They’ll also deliver faster, more available apps - and developers always love that outcome!