Part 2 – The Most Common Surprises When Moving to the Cloud
Feedback from Part 1
In this three-part series, I’m going to talk about the most common surprises I see when those companies move to the cloud — and how they could have avoided them. If you missed the first part of the series Redundant Systems, you can find it here.
Some of the feedback I have received about the post was interesting. I want to make a quick comment about one: “Of course, you have redundant systems, that is the point of setting up a virtual data center.”
Although that point is clear, to everyone, the fact that managing two different systems, using different tools and, requiring different skill sets was understood. However, the difficulties in maintaining multiple systems have taken some of my clients by surprise. If you can do the same job and get the same results with the same system, why would you manage two systems? The answer of course is: you shouldn’t.
If you have other thoughts about managing redundant systems, please let me know. Let’s talk about the second most common surprises when going to the cloud.
Surprises in Accessing the Cloud Apps
Surprise #2 – Cloud Access.
This is one that I know everyone thinks of, but often times it’s taken for granted. After all, the cloud is highly available and access is everywhere these days — from cable to DSL to FiOS to free Wi-Fi. Bandwidth is cheap at the office; just get more. Right?
Legacy Architecture
As it turns out a lot of companies are interconnected via a private WAN. This makes sense. It has been the default standard technology of the past 15-20 years or more. Regional, national or global companies all interconnect without going through the public Internet. Until the cloud prevalence this was the best way to do things.
When all of a company’s resources were centrally located in one or two or three hubs and all of the spoke sites connected into those hubs, everything worked well. Once again fast forward to where most resources are located in the cloud and you quickly figure out that the old MPLS architecture is not going to work. It creates too many bottlenecks.
Additionally, it is only a matter of time before the development group demands their own dedicated access. Worse yet, you found out that they already acquired their own dedicated (unprotected) access. What is the best way to provide this access? Remember, now that you are in the cloud all data transfers are not free. Getting your data from the corporate office to the cloud, and through the cloud, and back out requires some thought. Absolutely it’s easy to do — but what is the most cost-effective way?
The Problem with Open Doors
One of the solutions may be just to get a cheap internet connection at each site. Then, route internal traffic to internal private WAN resources, and route cloud traffic over the public Internet. Great. Now you just added 20 doors that you have to protect to your once-private WAN. After all it’s not an Internet connection that is dangerous. It’s the users on an Internet connection who create problems. Now you have all of your users coming in and going out 20 new egress points instead of all nicely controlled through your hub sites.
The solution here is SDWan. SDWan is a set of physical controllers that sit on top of your existing transport and make logical decisions for the best way to route application traffic based on the integrity of connections and the importance of the application flow. In other words, SAP traffic would likely get preference over YouTube, but its not just QoS. SAP is not just reserved bandwidth and it doesn’t just take priority. It also gets the more latent free path with multiple redundant paths.
Not all SDWan are created equal
You can of course design your own, but with SDWan being a newer technology, why not rely on someone with experience to help you design it. After all, performance is only one aspect of SDWan. Along with performance also comes security and cost savings. If done right, you can have 100% uptime (yes 100%), much more visibility into traffic flows and a sizable cost savings over what companies pay traditionally. Not only that, but you can also do it on an OPEX basis with no cash out of your pocket to get you started.
SD-WAN Recommendations
Go for experience, it pays off in the short and long run. My recommendation is to rely on folks who have been doing this for at least two years. Not the people that adopted the latest buzz word.
Most of my customers don’t want to be completely hands-off in a managed scenario, and I don’t blame them. Look for a SDWan provider that provides options for management. You manage/co-manage/we manage options are a must.
Finally, is cost. If you are not working with a broker – if you are working directly with the provider – you are likely missing out on 20-30% savings. If you think you can get a better price directly from ATT/Verizon/L3, etc., you are wrong. This is the complete opposite of networking or security hardware purchases. If you can beat up your direct rep for a better price on traffic, imagine what the people that do this for a living can do. Similar to a financial brokerage house — no matter how much you trade, the brokerage house has more money under contract than you. They get a better deal.
Contact us today and we can put you in touch with a reputable broker. Test them out and see for yourself. Regardless of how you do it, SD-WAN is necessary to optimize your traffic, prioritize your applications, improve your uptime, reduce your packet loss and reduce your jitter. When you do it right, the cost savings is the cherry on top.
In part three of this three part series, I will be discussing the second most common surprises when moving to the cloud. Visibility in the Cloud.