Architecturally, Is There Such A Thing As Too Scalable?
We’ve all had that chilling moment when the gate attendant at the airport comes over the loudspeaker, and doing her best Charlie Brown’s Teacher imitation, announces “Jursim Puzzling vlordid Netting, gollink dummole Neptune.” (This flight is in an oversold situation, we’re looking for volunteers…). While we could discuss the causes and solutions to this being an all-too-frequent event in the daily operation of airlines, for the purposes of this blog, let’s talk about the back end. The problem on the back end is, quite simply, that the plain cannot be expanded to handle the burden demanded of it. That makes perfect sense in an airplane, I for one would be slow to get onto an airplane that could be expanded like a pop-up camper.
But it makes no sense whatsoever in an IT infrastructure. While a particular application might never need to expand, the overall architecture of the datacenter must meet shifting demands on a minute-by-minute basis, and must be prepared to offer more power to an application that is currently overburdened. There are many parts to making your architecture that dynamic in the application sense, developers (be they internal or external) need to have thought of the issues that scaling brings up, you will likely need a virtualization engine – you can do it without one, but that means leaving a lot of servers sitting idle all of the time, and in the 21st century we don’t tend to do a lot of that. You’ll also need a dynamic infrastructure. It does you no good to scale up a server unless the network, security, and optimization tools available can not only handle the additional load, but adapt to the presence of a new server popping up or an existing one going away.
In short, you want the functionality of a hardware ADC with an adaptability to match the VM capabilities of your organization. And as time goes on you will want the same functionality to extend to the cloud, because your ADC brings your datacenter policies to VMs running on your preferred cloud vendor.
But that’s the problem with a single-faceted deployment model where architecture is concerned, in the old world you wanted hardware ADCs to offload things like encryption and compression to, so your servers could be servers and not bulk-processing engines. In the virtual world, some would tell you that you want virtual ADCs to maintain a level adaptability that matches your virtualization environment. The problem is, where to put all of these virtual machines? When virtually offloading encryption or compression to a VM on the same machine, you’re offloading nothing, just shifting which VM makes the request of your hardware, the burden is still there. Much like an airplane, it just doesn’t expand very well unless you dedicate hardware to the ADC, making it less of a bargain in terms of architecture and cost savings.
We have talked in the past about the hybrid model, but this is where it shines. By maintaining a central, physical ADC at the WAN strategic point of control (that point between the world and your servers), you can then give a separate virtualized ADC to your virtualized environment – or a dozen virtualized ADCs – with computationally expensive operations like encryption and compression turned off, and route their traffic through the physical ADC for that processing. Your applications get the benefits of an ADC – from load balancing to security – from the virtual ADC, and the benefits of offloading the heavy lifting items to the physical ADC. By placing the physical ADC at the WAN strategic point of control, you can also place virtual ADCs at your cloud provider and either physical or virtual (depending upon throughput needs) ADCs at remote datacenters. With the physical ADC coordinating the efforts of this network of ADCs, you can create centralized policies and profiles that are applied no matter where the final target ADC resides.
And if your network grows, you can exponentially expand your physical ADC with a Virtual Clustered Multiprocessing system, so that scalability becomes an issue of yesteryear. More on that in a future blog, promise.
No, there is not such a thing as too scalable from an architectural perspective. Putting the right tools into place means your options are practically unlimited as your traffic patterns grow and change, day by day, month by month, year by year. And with an ADC processing data as it passes through – before it ever reaches your servers – you are also able to offer a more secure environment, should the organization have that need.
It’s a bright future, and the more technology moves forward, the brighter it seems to get. Soon you’ll be able to meet all of your employer’s IT architecture needs with the speed and grace that virtualization allowed you to spin up new servers on demand. Without working weekends and dropping entire systems to achieve upgrades.
So ditch the airbus architecture, save your customers the “We are in an overutilized network situation…” horror, and usher in the age of adaptability, your network, your staff, and the business will all thank you.