Considering the migration to HybridCloud model “hypothetically” can be as simple as selecting a suitable connectivity model (from the possible ones illustrated below), typically based on the applications’ communication patterns and the anticipated traffic load of the users and applications.
For more details about hybrid cloud connectivity options refer to this blog Click Here
Following the selection of the connectivity model, the application team may ask the infrastructure team if they can stretch Layer 2 segment to the cloud to run certain applications seamlessly with this hybrid model?
So at this stage, it is a bit of a challenge, because cloud providers don’t support Layer 2 extension, in which an alternative (typically a workaround ) need to be found, like considering: a tunneling mechanism, host-based routing or a 3rd party overlay/SDN solution.
Nevertheless, let’s take a step back and think about this oversimplified example. Is it really the network or infrastructure team problem to come up with work around? Applications’ team problem? Or the CIO Problem?
In fact, it’s the problem of all of the above.
The reason why, simply because moving to the cloud or considering a hybrid model, is not about the connectivity, its all about the applications (in which, the CIO must set the strategy for that, and the infrastructure team should’ve analyzed and questioned the strategy and requirements at the first place). From application team point of view, first they need simply to understand:
At this stage the application team should be able to have a good foundation to start look into how they can “Think” of adopting a hybrid cloud model in a more efficient way.
You might be wondering, why at this stage they can “Think” and not to move to the design or execution? Simply because this is where the application team needs to look into the real value of cloud solutions and native cloud architectures, and how they can take advantage of.
Because considering an IT strategy using public cloud “IaaS” and putting on top of it legacy applications, or might be a modern application but it was architected for On-Prem type of environment, shouldn’t be the ultimate goal
You may find these type of applications’ architectures were not designed ‘with the ability to be scaled out’ in mind, in which the application or underlying infrastructure can automatically scales out in response to the increased volume of certain metrics such as CPU utilization. Instated, commonly you may find these legacy applications rely on traditional scaling approach which is vertical scaling that is based on adding more hardware resources to the same system (scaling up). With this approach such applications won’t take advantage of the cloud elasticity capabilities.
That’s why in my previous blog (Moving to The Cloud – Myths & Facts for Solutions and Cloud Architects) highlighted a common Myth or misconception which is “Enterprises can achieve more efficient applications’ performance with lower cost by migrating existing applications to the cloud”
Without understanding the application architecture and how this application will operate in a cloud environment, do not expect better performance, lower cost etc. because you may find there is a different or modern way the same application can be designed with when it is operating in the cloud to provide more effective and efficient way of operation e.g. taking advantage of the elasticity capabilities, microservices model, etc.
Similarly, the way the application does replication of geo-clustering could be based on starched layer 2 segment, in which the infrastructure team need to find alternatives that are almost always not optimal.
These are two simple examples, to answer the question why the application team should start ‘thinking’ after identifying the IT strategy and applications needs, in which they can mix and match from different applications migration strategies which are ( these migration strategies based on the 5 R’s that Gartner outlined 2011):
for more details about these migration strategies refer to this AWS blog:
Also, this session from Google Cloud Next 18 is worth watching about the same topic:
The next logical question someone may ask is, where should I start?
There are multiple approaches, the selection depends on a few factors such as:
Note: it is critical to keep in mind that migrating to a hybrid cloud model or considering cloud as a DR model, is not only about having you’re your data and applications running and available or recovered within the anticipated Recovery Time Objective (RTO), you also need need to make sure that the enterprise security controls and standards in-use by the on-premise DC, is also applied to the cloud DC environment.
|Migration Path Option||Time Frame||Risk||Complexity||Description|
|Big Bang||Short||Very High||Very High||Any failure of any component may lead to a complete migration failure. No chance for validation|
|Phased (per application)||Long||High||High||Having an application stack in a distributed manner, may lead to nondeterministic applications’ behaviors and traffic flows, which could impact users/business experience. May create security concerns for intra-applications communication across on-Prem and Cloud|
|Phased (per application Stack)||Medium to long||Medium to low||Medium to low||More deterministic applications’ behaviors and traffic flows, and offer easier path to consider application architecture modernization > cloud native etc. for the entire application stack. Offer more controlled applications communication within an application stack. Offers better validation for subsequent applications migration in terms of what additional things need to be considered before, during and after the migration|
Last but not least, there is a few misconceptions around cloud benefits or disadvantages, that needs to be considered when thinking or architecting for a HybridCloud model for more details refer to the previous blog: Moving to The Cloud – Myths & Facts for Solutions and Cloud Architects. Also, from connectivity point of view the following blogs are recommended when planing and designing a hybrid cloud model.