Virtualization Technology News and Information
How to be an Effective Trip Planner for your Data

By Colleen Hamilton, Principal Product Manager at Skytap

In just about every context, data networking is hard. With the added layer complexity that comes with moving applications to the cloud, it only gets more so. If you're struggling to understand why (and trust me, even some network engineers do), here's a simple analogy to help.

Imagine you need to make a trip from a gated community somewhere in rural Canada to another gated community somewhere in the rural United States.

You need to plan a route. But rather than just calling up your favorite booking site, your Travel Safety Team says, "You can't just go via any route and stay in whatever motel you find-bad stuff will happen. You have to use only approved travel providers or show that no such provider exists. You may only use pre-vetted lodging destinations. And we're happy to pay for the extra expense because that's how important it is."

After days of diligently and tediously plotting options and confirming approved layover points, you develop a plan that seems to meet all your team's guidelines. It is both safe and efficient: it uses private travel carriers, highly reviewed and approved lodgings at your layover points, and minimizes your own travel time. But when your Travel Safety Team looks at the budget estimate, they balk. "We need you to be safe, but is there a cheaper alternative?"

Now you have to drive. But your team requires you to talk to the travel and road-planning commissions for every major municipality you will pass through on the way to your destination, so you need to do the following:

  • Figure out what the local ordinances are: some towns allow you to come in for as long as you like and then return home, but you can't pass through - or stay overnight - on your way to somewhere else.
  • Find out if any private roads will grant you access or if you need to charter a helicopter for certain legs of the trip.
  • Negotiate with your Travel Safety Team: can you use a dedicated lane for places that don't have private roads or helicopters? They're going to ask you - and expect you to know - if it has double-white lines, double-yellow lines, medians, or something else.
  • Know exactly what luggage you'll be carrying, because certain checkpoints will only allow bags of a certain count, size or weight. Frequently these restrictions are not publicly known or even documented, and you may have to redistribute your luggage when you arrive.
  • Obtain detailed interior maps - including cross streets and one-way street indications - of the gated communities that you're departing and arriving at because the neighborhoods are labyrinthine.
  • Understand how the address/house numbers for each municipality relate to "general" addresses because every place seems to have its own system.
  • Pre-write scripts to help you carefully explain your destination and purpose of visit to each of the border security agents along the way, with a location address that each particular agent will understand.
  • Make sure you have passports, contact names and gate codes for every stop along the way.

Then, just when you think you've got a working plan, you find out you need to make another stop at a third gated community along the way that's not on your existing route.

If that all sounds a little complicated, it is. But every one of the above obstacles corresponds to a specific network challenge when you try to establish routing from your local offices to the destination of your choice:

  • Your corporate LAN might feel like a sprawling local neighborhood with specialized address numbering; the broad private IP spaces and network address translated (NAT'ed) subnets can make the "simple" act of leaving your on-premises network a hurdle unto itself.
  • Carefully planned dialogs with border security agents are just like the negotiations between VPN routers or transit through firewalls: even completely valid traffic must be thoughtful about how to avoid rejection at the border crossing.
  • Local city ordinances around thru traffic are similar to SaaS vendors' transit-routing policies: many network providers are fine with traffic that arrives and then returns home but have special (and often expensive) requirements for traffic that needs to be passed onward.
  • Unpublished luggage restrictions are like Maximum Transmission Unit limits, with individual routers along a path unexpectedly rejecting packets that are "too big" until a compromise in size can be negotiated.

And that's not all. Unlike a human, a network packet can't improvise when challenges arise along the way. If it gets stuck somewhere, it's done. It can't even call home to get help. It just languishes wherever it lands, never to be heard from again. It's a good thing packets are so highly replaceable, unlike you and your luggage.

You, a human, can most likely tell the difference between a freeway, a highway, and a toll road; know all about overpasses and underpasses and on-ramps; know the purpose of immigration checkpoints; and can describe at length how gate codes work. But when it comes to this trip, that is only the beginning: you also have to know the SPECIFIC on-ramps, freeways, immigration checkpoint routines, surface streets, addresses and gate codes, all planned perfectly in advance, in order to make it all work.

All of this means there is no single "right answer" to the question of how you should route your connectivity to your cloud service provider. It might be a VPN directly to your corporate premises, an ExpressRoute to Azure, or multiple cloned NAT'ed environment subnets. In addition to your application's specific destination and performance needs, the networking and security teams will have their own requirements, and your project will have its own specific budget targets. The right solution will be a specific network path that blends (or at least finds an acceptable compromise between) all these constraints.

When each new journey requires this level of detailed knowledge, planning, and flawless execution, it should come as no surprise that establishing new network routes is so difficult.

So, what do we do about it?

First, accept that networking is hard. Rather than denying or fighting it, attempt to mitigate the difficulty. Networking technology has evolved significantly over the last 50 years. Unfortunately, over that time malicious actors have also been working hard to exploit these systems for their own benefit. All of this time and tension has resulted in layer upon layer of complexity, checks and balances, that need to be thought through carefully, with no one-size-fits-all solutions. Making sure that your team has the right stakeholders (representing all legs of the trip) and support is critical to avoid any unpleasant surprises.

Secondly, just like your original application wasn't built in a day, neither will your new network route. In the best traditions of software development, it's going to require iterative rounds of careful requirements gathering, planning, implementation, and testing to succeed. That kind of effort takes time, and can't be abbreviated, so plan accordingly.

Next up, remember that - unlike you - network packets are dumb and cannot improvise. You're spinning up a fleet of little robot drones to make the journey over and over. It's natural that in the first few (maybe even several) attempts, there will be wrong turns and unexpected blockages. Plan for these failures to occur and build in ways to monitor the truth on the ground: you'll need visibility on the real status and location of your packets at each leg of the journey to diagnose wrong turns and get back on the right path. And just like an unexpected snowstorm or power outage can occasionally waylay even the most seasoned traveler, unexpected changes will cause delays and reroutes, and then you'll need to improvise again. You'll want to be able to switch your network visibility monitors back on, even after weeks or months of flawless autopilot.

Finally, the point about understanding the full path your data will take bears repeating. If there are gaps in your plan, it could mean your data doesn't complete the trip. Gather your requirements thoroughly, do your research, find out exactly how all the points connect. If there's a leg of the trip that seems mysterious or a bit of a black box, keep asking questions until you know exactly how it fits into the plan. That kind of due diligence up front can help you solve problems later on.




Colleen Hamilton is a Principal Product Manager at Skytap focused on user-focused design, information architecture, UI framework design and usability. Prior to Skytap, she spent nearly fifteen years at Microsoft as a Program Manager and Design Engineer working on Windows Shell and Cortana. She has a B.A. in Computer Science from Harvey Mudd College.

Published Wednesday, February 23, 2022 10:48 AM by David Marshall
Filed under: ,
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
<February 2022>