Earlier this month the United States Court of Appeals struck down the FCC's net neutrality directive. Just in case you were worried, let me assure you the Internet won’t be coming to an end anytime soon. While this decision has been covered extensively in the media, not much has been said about the potential impact to IT organizations. So without further ado, let’s discuss what IT departments can and should do about it.
As a quick reminder, net neutrality seeks to ensure by law that the data which travels over the Internet continues to get treated equally, as it has always been. Internet Service Providers (ISPs) are prohibited from favoring certain products or websites over others, regardless of the source. This equal treatment has, up until now, served to level the playing field for everyone using the Internet. A startup website run by one person has had the same opportunity to succeed as one launched by a Fortune 500 company.
Most of us aren’t fans of cable or satellite TV services because they require us to pay for channels we don’t want (ok, service also stinks). We all wish we could customize our own list of channels to access, and pay for just those channels rather than have to pay for the entire ‘package.’ This same scenario also plays out with Internet services, where different tiers charge for set packages of content offerings. While it's possible, and there are indeed examples of this already happening, I really don’t think ISPs will do it on a large scale. It would seriously upset the balance that makes the Internet possible and, therefore, backfire on the ISPs trying to profit from the situation.
There is still a long legal path ahead with appeals and arguments before we know the final outcome. Until then, let’s think about this from an IT perspective and create some theoretical scenarios.
Net neutrality and IT
Your company issues a major press release driving a spike in web traffic to your site, which is good news until your ISP hands you a large bill. Ads and even communications from your ISP’s competitors, which you do business with, are blocked. Your ISP has their own data center hosting service, so they slow down bandwidth for competitors, including access to your data center on a competitor’s platform. Say you are a subscriber to Bloomberg News, but Verizon has a content partnership with NBC, so Bloomberg becomes not so quite real-time. Nothing against Verizon or NBC, I’d do it too if I could.
On the other hand, I can see some benefits. ISPs could create new services that take advantage of their ability to control traffic across their networks, and IT departments will want to buy them. The ISP could guarantee performance for critical applications and lower costs to use the ISP’s own services.
So how can you guarantee your application would be prioritized over your competitors? We all know anything is possible for the right price. But what happens if your provider all of a sudden deprioritized your traffic to your customers? What if you could no longer connect to a partner company? What if your telecommunications bill doubled over night? All low risk, but all potential scenarios in the future.
This brings us to preparing for the “doomsday” scenarios identified above. What happens if any of these scenarios materialize? I honestly think we have plenty of time before any of these could impact us, but it’s always a good practice to have a plan. In this spirit, I recommend the following:
- Take no action today, because nothing has actually happened yet.
- Stay up-to-date on the news. As with any topic, be educated.
- Continuously evaluate your ISP vendors for service and price. Net neutrality shouldn’t be the reason to do it; instead, do it as a best practice. You should do this with all suppliers, every few years.
- Include the potential scenarios you believe are possible in your disaster recovery planning. While not an epic disaster, losing access to a corporate critical website (for any reason) could be a disaster to those affected.
- Have a plan B in case the worst comes true (you get a wildly increased bill).
This article is published as part of the IDG Contributor Network. Want to Join?