Some of the best advice in tech comes before the first computer was ever built. The phrase 'a stitch in time saves nine' dates to the eighteenth century. It means that a little fix now will save a bigger one later on, and it’s a best practice that today's IT administrators would do well to follow.
A little planning goes a long way in tech deployments. Designing software's underlying architecture to support future goals is a top priority, especially in monolithic systems that are difficult to change. Early design missteps can limit software functionality later and affect business operations.
You can change misconfigurations, ill-advised shortcuts, and design mistakes after the fact, but this adds another layer of risk once a system enters production. Products become more complex, and performance can suffer as more users place a poorly designed system under further stress. For example, robust schema design is crucial in relational databases. You can migrate to a new schema in production, but not without downtime and application risk.
Just as eighteenth-century tailors knew to avoid problems early on, today's tech experts should treat the beginning of a project as a pivotal point. It is the golden moment where you can win big with a little planning or fail hard without it. For instance, learning about how design and configuration impact a system in the future can save the help desk hundreds of calls and eliminate the need for time-intensive remediation later.
Getting your Adaptiva configuration right the first time
Let’s apply these 'right the first time' principles to Adaptiva's own products. I will discuss a few specific points on which decisions you make could have long-term implications.
At Adaptiva, we put a lot of effort into ensuring that our products support easy setup out of the box with minimal configuration. This means customers can begin enjoying our solutions’ benefits quickly, proving the business case to upper management. As with other products, however, a little planning goes a long way. A few configuration changes up front will deliver big benefits down the line.
These configuration changes are especially important in Adaptiva's ecosystem because of the unique way our products work. We distribute product updates across large fleets of endpoint devices using the Adaptiva OneSite Platform based on an economical, efficient peer-to-peer (P2P) system. Rather than forcing thousands of endpoints to communicate with remote update servers across bandwidth-constrained WAN links, we use the endpoints themselves to update each other.
Properly configuring the centralized system that manages that process will deliver fast, efficient updates that keep all endpoints in the fleet current and compliant with minimal network overhead.
Proper network setup is key
The key to an efficient Adaptiva configuration lies in applying the right network protocols to the right subnets in your global infrastructure.
This is important because of the default protocol that registered endpoints use to communicate with each other. Adaptiva has two protocols available: the Foreground Adaptive Transport (FAT), designed for communicating across a LAN, and the Background Adaptive Transport (BAT), which supports WAN-based communication.
BAT uses several techniques to avoid throttling other traffic. The first is predictive bandwidth harvesting, which looks for other traffic traversing the network and gives it priority. It transmits individual UDP packets in unused bandwidth, harvesting every bit of spare capacity.
This predictive harvesting technique is great for WANs, where there are often traffic gaps, because BAT will generally find a slot to operate. However, busy LANs are often packed with traffic, reducing the number of spare slots, and reducing this technique's chances of effective communication.
The second technique, called Netboost, is similarly useful for WANs but potentially cumbersome for LAN connections. It examines a connection's round-trip time (RTT) to determine the performance of customers' other traffic. If the latency exceeds a preset threshold, the BAT protocol backs off to let other traffic through.
Finally, our flow equalizer technique uses WAN links economically by ensuring that there is only one BAT-triggered download at a time. This stops BAT from hogging the network on a WAN, but risks making BAT sessions unnecessarily sluggish on the LAN.
When new subnets are not remote
Our products use BAT by default when registering a device on a new subnet that we haven't seen before. This supports our guiding principle: respect for other traffic. We design our products to operate as passively as possible, minimizing interference with customers' other network traffic. In short, we don't hog the network.
In many cases, however, especially in large offices, a newly registered subnet might be on the same physical LAN as another. Using the default BAT option between these subnets will force computers communicating between them to use a WAN connection instead of the more appropriate LAN-friendly FAT protocol.
Why can't Adaptiva's software just choose the right protocol when registering remote endpoints? No product can tell automatically whether two products on separate subnets are in the same physical location. Instead, we must assume that every subnet is physically remote, and choose the least aggressive communications option.
What this means for Adaptiva products
Failing to appropriately configure FAT connections for these physically adjacent subnets has different ramifications for Adaptiva products. For example, our OneSite Health product, which checks and manages compliance across thousands of endpoints, focuses on distributing and checking policies. Allowing this product to use BAT on LANs will delay health checks and policy deployments.
OneSite Health: We designed OneSite Health with speed and convenience in mind. Security teams and endpoint administrators can create policies visually without writing a line of code. They naturally want to implement and verify these policies across the entire endpoint fleet and see the results quickly.
These administrators will face delays when running BAT on a LAN. Clients updating and checking peers on another subnet but located just a couple of cubicles away will treat the connection as though they are halfway around the world. The greater the number of endpoints inappropriately using BAT, the greater the delays will be. Admins might find themselves applying a policy and then taking a coffee break before checking the results. It is a little like trying to pilot a spacecraft remotely with a five-minute delay.
OneSite Patch: Whereas OneSite Health concentrates on relatively small policy files, our new OneSite Patch product for patching Windows endpoints sends larger packages of content. That creates its own set of problems for clients using BAT on a LAN. An update made using BAT inappropriately over a LAN could take just as long as an update sent over the WAN. This delay can adversely affect your security posture, especially when you are racing hackers to patch recently announced bugs.
OneSite Anywhere: Our OneSite Anywhere product sends out even larger pieces of content in the form of operating systems, applications, and software updates. It could take a day for these devices to distribute a patch to inter-subnet peers on the same physical LAN, compared to 45 minutes when using FAT. Taking a day to download this content will impact product performance and make life difficult for administrators.
Planning with performance in mind
It doesn't have to be this way. With a little planning, you can configure clusters of subnets in physical locations to communicate with each other using the non-default FAT option. That acknowledges their proximity on the same LAN, allowing our products to use the network more aggressively and deliver updates more quickly.
Surprisingly, there is no data export industry standard regarding physical subnet proximity flow from modern network equipment. Instead, you must provide this manually (which is probably why not everybody does it). We suggest working with your network team to get this subnet proximity information, typically in a CSV file that we can automatically import. This enables you to configure FAT communications between certain subnets.
Taking a little time to produce and import this information will dramatically improve the performance of the update fabric across all your devices. It also creates a robust platform of edge compute resources to manage this configuration on an ongoing basis. When an administrator notices a new machine registering on a new subnet, they can talk to the network team and work out where that subnet is. Better still, they can ask the network team to warn them in advance.
Adaptiva has a dedicated education team that teaches customers about best practices like BAT/FAT configuration, and we include this information in our courses for customers.
The payoff
Of course, you could avoid configuring for LAN-based communication altogether by selecting a rival product that only retrieves endpoint updates from remote servers. This kind of product usually won't require you to distinguish between LAN and WAN-based communications up front because it defaults to inefficient hub-and-spoke communications. It usually relies on standard TCP-based communication protocols that do not innovate for efficiency.
You might gain up-front convenience with these products, but you will quickly run into problems when you try to scale. You will see capacity issues when running a small number of servers remotely, and performance problems due to extensive WAN communications. You could try to boost performance by implementing more local servers for LAN-based updates, but you'll incur higher costs for the hardware. You will also have to commit more human resources to managing a diverse server infrastructure.
By taking the time to configure our product for maximum performance up front, you'll get a scalable, high-performance P2P-based update solution that saves you from the cost and availability issues of extensive server hardware. The result is fast, friction-free endpoint management at scale.
This is the latest entry in our new Adaptiva Practitioner Blog Series. In these blog posts, we share what we know about managing endpoints. Stop by to hear from our own in-house subject matter experts. We are excited to discuss best practices, technical how-tos, and other topics we think you'll find valuable. Our solution architects, product experts, and own IT practitioners have seen and done it all. We are adding new content regularly and are happy to have you here.
