If uptime is important to your company, make it clear to the vendors – for now at least, they don’t seem to be getting the message.
If the hardware doesn’t get you, the software will.” Or at least this is how it seems sometimes. Last time, I wrote about the trials and tribulations of unpredictable hardware. This time, we’ll look at things from a software perspective.
With broadband and wireless now ubiquitous, there are likely few small-office locations that don’t avail themselves of this technology. Broadband routers – inexpensive but “sophisticated,” with firewall, DHCP and frequently integrated wireless access points – can be found stacked alongside more mundane items such as wireless phones.
When it works, it’s great. But few of these offices have on-site support, so when something goes wrong, it spells trouble. And all too often the culprit is software – poorly written software that seizes up with no warning and for no apparent reason. I call it “infirm firmware.”
Years ago, it was much harder and much more expensive to set up a remote office. Such an office often would be composed of, say, an IBM AS/400 midrange connected via a leased line to headquarters. It took time and money to outfit and set up such an office, but once running such sites typically stayed running. When failures occurred, they usually were accompanied by a detailed error code.
You’d have a problem, identify it, fix it and THAT problem would be gone. Not so today.
Broadband router outposts are not so predictable. They’ll work – and work fine – for days or weeks and then just stop or seem to “just stop.” Sometimes nobody can get on, sometimes people already connected are fine but no new users can connect.
When this happens, we all sigh, reset the power on our broadband routers and soon we are back in business. As this usually fixes the problem (until next time), no vendor tech support log is called.
I think many vendors implicitly recognize their own infirm firmware by specifying that a power reset be the first step in problem resolution. This saves time and money for the vendors but doesn’t solve the problem for end users.
Every time a router reset is required, the branch office goes down. For years, vendors have touted the cost savings of availability. Yet, when it comes to small remote offices, nobody seems to care.
Because many of these broadband routers are notoriously unstable, the power-reset solution – which cuts off all users – often can be the first step taken when a user reports a problem even vaguely related to connectivity.
The worst part is that this is a problem that vendors could solve if they so desired. Instead of building a solid code base – a “boring” broadband router – that is a workhouse, vendors seem intent upon piling on new features and functions all the time and making these the standard loads for their products.
Looking around on vendor support sites, users will find dozens of firmware loads but no information about how well they were tested before posting.
I’ve often thought of proposing a test wherein we take these routers, run them 24/7 for a month and then, without rebooting, go through and verify that all the core functionality was still working – but I probably wouldn’t get any takers.
If uptime is important to your company, make it clear to the vendors – for now at least, they don’t seem to be getting the message.
