Editorials

Planning for Expansion and Contraction

Planning models are changing, along with the considerations as projects are starting.

It’s interesting to see the influence of technology capabilities coming to be considered as part of mainstream applications and solutions development. In particular, the thing we’re starting to see and feel as an important piece of the overall solution puzzle is the bookend issue of expansion and contraction.

While traditionally we’d be looking to figure out what growth the database would be incurring so we could plan for that, plan for storage and such, now things must surely include that, but also the flex and planning needed for expansion and contraction for specific workflows and operations. That’s a round-about way of saying that people are expecting systems to be able to scale to meet a termporary flow, then scale back when the need has passed.

I’ve seen this a few times now and the requirement has either been stated specifically, or inferred in the overall flow of the system. This last one, the “inferred” is particularly dangerous from a planning perspective because if it’s missed, it can spell all sorts of trouble for the application as it gets rolling. We’ve seen this with on-premise systems largely – and the scale often times comes from an extension onto cloud resources. Of course at it’s most simple, this could be backups, or a simple database growth operation.

But in a more complex model, this requirement is all about handling a “flash” or “swell” of information coming into or being processed by the system. Oftentimes this centers around storage, but it also impacts processing power as well. Traditionally, we’d think about things that infer a scale to be ready for, but in the ease of adding resources, possibly even in realtime automatically, means that this can be much more dynamic.

The flip-side of this is the scale-down – the recovery from the swell. We’ve had a couple of cases now where we wanted to find the markers that indicate the data flow is easing and we could scale back. Rather than constantly be at a higher capacity, we wanted to be able to take advantage of the lower server requirements and take the costs savings (or at least not continue spending at the higher levels).

So capacity planning takes on some new dimensions – you have the long term storage and processing capabilities, along with the growth curves and utilization of those resources. This is a pretty traditional need. But the new addition to all of this is the surge or swell planning, and how you want to handle it. This could be fixed resources (and may need to be if it’s on-premise so you don’t allocate those resources to other projects) or it could be variable, as may be the case with scaling out a server or dynamic storage.

These variable workloads can be tough to plan for. The goal is to provide the coverage, but not over do it so as to incur costs that aren’t needed… I haven’t found the magic formula yet – the application environments and their expected swells in activity just are so variable that it’s been tough to wrap structure around it thus far between environments.

How are you approaching this?