Cloud Applications Done Right - Part 3: Scalability, Availability, and Performance

This is the third post in my series on cloud applications done right. In previous posts [Part 1 and Part 2], I talked about how multi-tenant cloud solutions are less expensive, more secure, and allow for more powerful customization than their on-premises alternatives. These outcomes often surprise buyers who may think they are compromising on these factors in order to get a cloud solution with the convenience of anytime, anywhere access. However, those same buyers do expect cloud solutions to be more stable and reliable than their on-premises alternatives. I can easily prove cloud solutions are more reliable while also being more cost effective, but it’s difficult to replace the sense of security buyers feel with an on-premises solution knowing that Bob, the IT guy, is a phone call away when the server goes down.

In the earliest days of Intacct, we tried addressing this problem by putting web cams in our data centers. I’m not kidding. The idea was that if you can see the actual servers containing your data, you would feel more comfortable. But here’s the rub: the psychology behind cloud solutions requires the buyer to let go of certain aspects of control. In exchange for letting go of that control, they expect to not have to think about it – they expect the system to simply work.

So the bar we have to meet for scalability, availability, and performance is substantially higher than it would be for an on-premises solution - and we have to essentially offer zero downtime. This is possibly the most challenging design problem for cloud vendors. At any given time, we may have tens of thousands of active users all sharing a common pool of resources. How do you allow the corporate controller to run a ten thousand-page general ledger detail report while hundreds of other innocent users file expense reports, approve purchase orders, or look at dashboards? Better yet, how do you allow a programmer to run parallel processes loading invoices via Web Services without taking all those available processes away from other users? We call this protecting the 10,000 from the one.

The answers are surprisingly simple. Through economies of scale, Intacct is able to invest in pools of resources dedicated to specific types of activities. In the case of the corporate controller trying to run a very large report, Intacct routes that particular request to a pool of servers dedicated to large reports. What’s nice about very large reports is users don’t expect immediate results; they just want to get them in a reasonable amount of time. In this case, Intacct queues up the report and runs it from a server configured to handle very large amounts of data reliably. Because it’s queued, Intacct can manage the load based on other demands of the system and allocate a fair amount of resources across companies. If we find that we’re not delivering reports in a timely manner, we simply add more servers to the pool.

Mimicking this strategy would be very difficult for a local IT shop to manage. Bob would need to either buy a bigger server or add a second one. But in both cases, the systems would not know how to balance or route transaction processing requests vs. large report requests to take advantage of the server configuration.

This brings me to the second answer. Cloud vendors design their solutions under the expectation that they are both the provider and the operator of their applications. Their features are designed, not for some arbitrary server configuration, but for a specific pool of computing resources that does nothing but run the applications designed for it. This marriage of application and data center design leads to an operation optimized to handle many thousands of concurrent requests, from simple transaction processing to very large report requests.

In Intacct’s case, we’ve created pools of servers dedicated to several different types of activity. We have web servers handling requests from our browser-based user interface, a pool of servers handling “offline” requests (like large runs of scheduled invoices), a pool of servers running large reports, and a pool of servers dedicated to web services API calls. We also have pools of servers that do nothing more than cache information so it’s readily accessible to any pool of servers and reduces load across the entire operation.

Load balancing to help with performance optimization.
Sound complex? Actually, it’s quite simple. All of these servers are identical. They all run the same operating system (Linux, in our case), have similar hardware configurations, and run the same code. In production mode, we ask each server to assume a personality and a different job. The advantage comes when we see that one pool of servers needs more workers, we simply ask one of the other servers to assume a different personality.

With these design considerations, we are able to distribute and prioritize requests to handle the peaks and valleys of our workload. However, there’s more to it than just server pools. Check back next week for the second half of this topic, when we tackle the intangibles of scalability, availability and performance in cloud applications: risk management and user guidance.

I look forward to your comments and feel free to follow me on Twitter (@aaron_r_harris). You can also follow Intacct on all our social media channels, including Facebook, Twitter, and LinkedIn. To network with other people interested in cloud financial applications, be sure to join the Intacct Cloud Accounting group on LinkedIn .


Post a Comment