Excess Database Capacity for Seasonal Spikes
We see it every year–the merry-making of the holidays is followed by the obligatory New Year’s Day trip to the gym. But while the rest of us are working off our turkey and apple pie indulgences, e-commerce companies are trying to figure out what to do with the excess database capacity they’ve acquired over the course of the holiday shopping season to run their business.
Provisioning always means over-provisioning
Just like the packages piling up on Santa’s sleigh, the holidays can generate 4x or more additional load on an e-commerce store. Insufficient database capacity can result in poor site performance, downtime, lost revenue and unhappy customers who spread negative experiences on social media. To avoid this, businesses will typically provision enough servers to handle the anticipated peak load. However, this means overprovisioning for the non-peak periods. And in many instances it means adding more capacity than is even required for peak workloads, since you’ve got to err on the side of having too much. In other words, ‘provisioning’ inevitably translates into ‘over-provisioning.’
Stuck with a gift you can’t return
Getting rid of tacky sweaters and other stuff you don’t want is easy enough, but shedding database capacity isn’t so simple. MySQL and most other RDBMs powering e-commerce applications run on a single server. At best, those using these databases have purchased a very large server which they are then stuck with. At worst, they’ve exhausted capacity on that server and resorted to sharding or master/read slave configurations– expensive “database gymnastics” that add complexity and fragility to your application.
At this point, the only way to shed unnecessary database capacity is to migrate back down to a smaller server. As many a DBA will attest, this is about as much fun as a sugar-free/carb-free/fat-free diet, and it’s even less fun if your application has been convoluted by sharding, at which point Lehman’s second law kicks in and you’re dealing with trying to relocate an extremely complicated app.
“Flex” your muscles
In exercise, flexing your muscles burns calories. Interestingly, the same principle applies to avoiding excess database capacity post-holiday. Essentially flexing database capacity means that you add and subtract servers (or nodes) based on how much traffic you are actually experiencing, vs. how much you think you might experience.
This is an entirely different model that’s much more like how we buy electricity and other utilities, and is in lock step with the ethos of cloud computing, which asks: “why pay for something you don’t use?”
You still have to do some planning, and you can’t totally wing it, but companies that follow a flexing model are able scale their computing power up to accommodate holiday shopping, and back down after the season in a way that’s impossible for those following the old-school provisioning model.
Flexing takes scale-out SQL
There’s a catch. It’s not that companies aren’t flexing their database capacity because they don’t know about this strategy– unless you’re living in an IT bubble, you’re fully aware of the benefits of cloud computing in terms of agility. It’s that they can’t do it. Most RDBMSs are architected for a single server, so there’s no such thing as adding/subtracting nodes when you’re running on this kind of architecture. Flexing requires a SQL-compatible RDBMS that meets all the ACID requirements of a traditional system, but is built to scale out by adding or subtracting nodes.
No more lingering relatives, fruitcake, or frivolous server capacity
Let’s face it, you don’t want unused database capacity hanging around after the holiday any more than you want lingering in-laws or stale fruitcake. To paraphrase fitness guru Susan Powter, let’s set a goal to stop the insanity in 2017 and switch to a scale-out database architecture that allows flexing, and does away with the need to shed unwanted holiday server capacity.