Some of you may have noticed something happening lately in the press, in our communities, and in our businesses. Shelves are barren, networks are saturated, all phone lines are busy, please try to call back later!
Yet at the same time, services like Netflix, Facebook and Twitter have been operating mostly without flaw. I wish the same could be said of many video/web conference services, VoIP services and VPN services. People have been noticing fatal flaws in their original designs.
Have you had to take a moment and revisit the size of VPN appliance you’re supporting your business with, or the bandwidth of the network link that provides mission-critical capabilities for your employees? This is one of the fatal flaws of just-in-time delivery, or sizing and scoping for a particular use case, only to have it upended and needing hundreds or thousands of connections supported instead of just a handful of remote VPN users, as an example.
You may have noticed this impacting in the retail sector all the same. When one or two people buy toilet paper an hour or one or two users connect in on the VPN per minute, it’s not that big of a deal. When everyone rushes in at once, suddenly your resources are exhausted and people are left in a lurch with a need.
The Delicate Balance of Sizing
Anyone who has ever had to do architectural design and sizing knows that some resources are finite, and some can be flexible. CPU and memory can be made flexible in virtual infrastructures by letting them “share” resources, and the same can be said of virtual network adapters, and while storage can “fake it ’til it makes it” with deduplication and compression. In the physical network, like network adapters or toilet paper, when you run out of resources the only way to get around that is to add more; and when you’re out, you’re out.
This phenomenon has rung true when sizing wireless configurations, too.
Take this Aruba 550 series access point, for example. The maximum throughput on this unit is 6 Gbps, which sounds like a lot of 1 Gbps interfaces. However, if you’re sizing each AP to be able to handle an aggregate of 6 Gbps of traffic, you’ll want to connect to switches that support 5GBASE-T.
Sometimes the team supporting and purchasing the wireless network might be different from the team supporting the edge portion of the network (I’ve seen it many times) so scaling and anticipation by one party isn’t always fulfilled by all parties. Then you bring a third-party into the picture, the cable dogs who run a single RJ-45 to each of the APs because that is what you requested, but perhaps not what you intended.
This is a true scenario I’ve seen played out many times and this planning, forethought and preparation have fallen on its face. Not for the day-to-day everyday operations when first deploying with a handful of users and connections, but instead when you experience your holiday load, or under more severe circumstances, when some kind of critical event occurs where your resources might start to reach the top of the load.
A load that perhaps you designed for by making the right purchasing decisions for one piece of infrastructure, but it was lacking in another (physical with cabling or also physical with network port specification), and no amount of throwing more data at an insufficient link will cut it.
Adopting a Just-in-Time Culture
Do you remember your parents ever saying, “We’ll just buy a bigger one (shoe, shirt, etc.) because you’ll grow into it!”
I’m not saying that’s the reason many of us size our infrastructure in such a way but makes for a good analogy as to the logic behind it! And that’s ever so poignant, because in most cases, the ability to adopt a just-in-time infrastructure is exactly that, having something to grow into. Virtualization, cloud, service mesh, microservices, containers, Kubernetes and even more buzzwords have all been tools at our disposal to help us be able to just “grow into it.”
It’s through using one or all of those technologies layered with a heavy dose of foresight, planning, preparation and incorporating all of that into how the technologies will scale. Similar to how in my previous article “2020 is the Year of the Networked API” starts to get you organized in preparing the components of adopting this just in time culture, also it leverages characteristics of the article, “The DevOps Triangle – Lost at Sea.”
So, you must ask yourself, regardless of the size of the infrastructure:
- How do we handle just-in-time delivery today?
- What if we experienced a crisis, would it change how we handle delivery today?
- If that crisis were elevated to a disaster, what is our recovery plan?
These all become the making of scalability, disaster recovery planning, business continuance planning and general tenets of security modeling. None of these can or should be able to be addressed and answered overnight, but they also shouldn’t be so overwhelming that no action is taken on their part.
The best piece of advice I can leave you with right now is, take note of any disasters or crises that have occurred at any point in the past. Are you prepared to repeat it? If not, start there, since it’s something you’re familiar with. And once you get that wrapped up, move onto the next predictable disaster, one after the other and you’ll be ready for the next crisis to strike.
Originally published on the Aruba blog, May 18, 2020, by Christopher Kusek.
