What do successful hybrid cloud migrations all hinge on?
Lifting and shifting your data center to another data center (aka “the cloud”) is pretty straightforward if you move everything all at once and into one other data center. In both instances, this is rarely the case. You will not move everything all at once. And the cloud doesn’t ever reside in one data center unless it’s just your rack(s) in a Colo. So if needing a hybrid cloud strategy is the case, what should your concerns be as you move applications (one by one) into the cloud? My previous blog post (https://www.infolob.com/blog/important-lessons-to-ponder-as-you-move-data-center-to-the-cloud/) was about how to make cloud deployment more efficient (read: less costly), so this one is about the afterthought that usually comes back to bite you when you’ve just lifted and shifted: the network.
Let us first contemplate what your network most likely looks like today:
With all of your applications centrally located within the confines of your data center, essentially all of your users, customers, developers, etc. are home-run back to a single location. Sometimes, there’s a stop through a Colo or cloud/Internet point of presence. This makes life simple; users send a request and the answer is sent back via the internet.
Before I get any angry emails, I understand that sometimes the “internet connection” and “private connection to Colo” can be the same line. This is a design preference, not gospel.
What will your hybrid cloud strategy look like as applications are migrated to the cloud? The thought of drawing this is making me sweat in real-time. The cloud is complicated, and the killer isn’t bandwidth, it’s latency and waits for states. How many I/O round trips between dependent applications need to occur before the “customer” gets an answer? Where are these applications hosted? Where is the customer? The last drawing was simple because all of this I/O was in a single data center, single rack, or even between two ports that were controlled by the same ASIC in the same switch! Now, not so much. However, I am going to do my best here to draw out an example:
This got a little more complicated. Let me explain the change in architecture. First of all, we all know there are applications that aren’t going to make it to the cloud. That AS/400 is staying put in the data center until we migrate those apps off of there. Second, a good practice is to keep ownership of your database(s) versus keeping local disparate databases across various SaaS/PaaS/cloud offerings.
The latter is more expensive and less secure. This hybrid cloud strategy would necessitate migrating your database(s) and low-latency servers to a Colo facility such as Equinix. Since this tends to be higher in cost than spinning up a few Amazon instances, this footprint will be kept small. Oracle/Amazon/Microsoft cloud will then host your secondary apps, SaaS, PaaS, etc. You may also want to utilize WorkDay, ServiceNow, etc., under the heading of “various SaaS vendors.” You will then need an “integration cloud service” to translate between these SaaS applications and your central ERP/CRM/HCM etc.
The fun begins when one starts to look at the I/O here. How many round trips need to occur between various data centers in various locations to complete a single task? Where are all of these applications hosted? What is the latency between them? How many private lines to various cloud providers do I really need to buy?
A qualified partner can help you navigate these questions. Infolob has done this before. We understand the pitfalls of migrating applications to the cloud, and it’s almost never the application. It’s almost always the network. While this may look complicated, the cloud can still save you money. You just need to do it right the first time. Give us a call or shoot us an email to get started.
This blog post was written by Glen Shok, Sr. Director at Infolob Solutions. He can be reached at Glen.Shok@Infolob.com.
