File shares and WAN
Some moderately sized businesses we have worked with are experiencing issues with file sharing to field offices, scattered around a region consisting of a few states centered on HQ/datacenter. Some recent (painful) testing showed that site-based NetApp SMB2 + latency didn’t work very well with 1 Gbps MetroEthernet (relatively inexpensive!) links and 30 msec latency. That customer and a couple of others have reported good experience with Panzura caching. This solves the problem of trying to manually or semi-manually pre-cache large AutoCAD files, etc. at project sites, especially when your remote workers skills mix doesn’t necessarily align well with a single office managing a project.
I can’t help but think, if that works well out of HQ/data center, it could work as well out of a colo.
Datatility has some interesting things to say about use of such caching with colo or cloud-based storage, particularly for backup and recovery. When comparing cloud to colo for backup, it is important to factor in actual storage costs, which may not favor a cloud-based approach.
It appears there is a continuing plethora of too many vendors and point solutions. Security monitoring architectures and automation are key, unless you’re into building a large security team. I see indications that for small to medium organizations, managed services can be very attractive. As with UC&C, security is just becoming too much for such organizations to handle in-house.
I’ve become a big believer in simplicity, to the extent possible. I also believe that we have created major network and datacenter complexity and fragility catering to poorly written applications. (And thanks to ipspace.net for this perspective.) Yes, some of it is self-inflicted (e.g., by customizing each site’s design). Using standardized designs and sticking to them is key to scalable and frugal operations, support, and automation.
This is why shifting to SaaS-based applications is a winner, particularly for smaller businesses. It lightens the server/application admin burden, and uses applications designed for the internet, which (one hopes) avoids the complexities of the past. Or at least makes them someone else’s problem. It perhaps makes it clearer that customization = additional cost for the life of the application.
We’re not out of the woods yet. It’ll take years, even decades, to rewrite the remaining applications to be “cloud-ready” or at least “robust high-availability supporting.” Some of my wish list: ease of re-IP and DNS name changes for applications, ability to easily clone app front ends to different locations and different IP addresses for use with load balancers.
Unified communications and collaboration
My crystal ball says “cloud-based” and “managed services.” Our UC&C folks may disagree, but I didn’t take the time to discuss this with them.
Network and data center management
Network and other management tools can now collect and process a lot more data. Vendors may be starting to learn how to detect and report potential issues in better ways, ones where we don’t have to go poking around all over the place to find a problem. Reporting changes in routing tables, significant changes in link and router performance, and helping us with “It’s broken, what changed?” is another area where tools might do a lot better.
Having said that, cross-platform integration is hard. It’s even harder when a vendor has several disparate products for various technical niches. Still, I’m mildly optimistic that the opportunity is there for network management tools to get a lot better.
Personally, I think network, data center, server, SAN, storage, and application all need to be more tightly integrated in tools. Security has to tie them together as well, but maybe in a different way, or maybe via a shared topology model under the hood. Whatever the answer is, the tools need to do a far better job of saving us work, especially in detecting and resolving problems.
My theory of sailing: Boat maintenance time must be noticeably less than fun time on the water. My current beat-up dinghy fails that test. A variant of that applies to tools: Tool maintenance time must be significantly less than time the tool is useful for troubleshooting, etc.
Overall, we see small to medium-sized organizations grappling with technical complexity, compounded with finding skilled staff at pay rates they can afford. Even if you have a small number of in-house network, server/storage, and security staff, UC&C and ISE and other specialty areas may be too much to cover well in-house.
One answer is partnering for technical services, something NetCraftsmen has been increasingly providing to our customers. It may be more helpful to have someone with deep knowledge of an area a couple of days a week, rather than a less-skilled full-time employee. While that may sound like a marketing pitch, it is also an observation of what works for an increasing number of our customers.
There are also areas such as ISE or UC&C, where supplementing one employee in that area with expert advice and a sounding board for ideas can help. If you’re the one ISE person in a fair-sized organization, who do you talk to about ISE? Who can advise based on lots of field experience at multiple sites?
I think the above has skills implications, depending on where your employer, network, and interests are going. Note the datacenter doesn’t go away, it shrinks and maybe moves to a colo. So the basic elements are the same, just used in novel and more compact ways.
One shift: You’ll probably be spending more time with your UCS chassis than on the switches in the colo. What else? WLAN, and WAN/internet routing will still be needed. Maybe some IWAN or SD-WAN management, which should be automated for you already or soon.
Interacting with the cloud or colo provisioning and management platforms would be a useful skill, as well as being able to advise on good cloud application approaches and networking, VMware NSX, and/or container networking design. With security, scalability and operational manageability.
Some people think “white-box” switches will rule the world. I view them as shifting device purchase cost to human support costs. Since staff time is scarce already, spending for reliable hardware/software and support is a win. Of course, if you don’t receive said reliability, then that’s a problem.
What I like about some of the white-box switch discussions is that in a lot of settings, all that may be needed is VLANs and MLAG. OK, I get that.
I view white-box devices with a mix of software as a support nightmare. Who validates a combination of a particular white-box switch hardware model and various open source code versions? Who can help me troubleshoot a bug with such a beast?
A recent blog post covered server complexity and being bound to fail is perhaps related; variety causes complexity and failures.
I see the potential cost savings as working for very big organizations, or maybe university/research environments. Maybe. The rest of us don’t have enough cycles as things are.
Sharing the crystal ball
I’m sure I haven’t spotted every change in network design that’s in progress! Please leave a comment to add trends that you’ve noticed, or your thoughts about how things are changing.
This article originally appeared on the NetCraftsmen blog.