ADD SOME TEXT THROUGH CUSTOMIZER

The Road to HybridCloud

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:

  • How the enterprise applications should operate to serve the new strategy
  • What enhancement or optimization will be gained or expected?
  • What are the applications’ inter-dependencies (multi-tier applications, whether the entire application stack to be migrated, etc.)
  • How the enterprise applications will react and operate in different failure scenarios
  • Where the data going to be stored and how data/storage is going to be replicated
  • Is there any security controls implications

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):

  • Retire
  • Retain
  • Re-host (Lift and shift)
  • Re factoring
  • Re architecting
  • Re Platform

for more details about these migration strategies refer to this AWS blog:

6 Strategies for Migrating Applications to the Cloud

Also, this session from Google Cloud Next 18 is worth watching about the same topic:

Application Migration and Hybrid Deployments in a Multi-Cloud World

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:

  • Number of applications that need to be migrated
  • Scale of each application
  • The selected migration strategy of the application(s)
  • level of application criticality to the business Vs. Risk
  • Expected or anticipated time frame for the migration project
  • Cloud technical expertise within the organization

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.

Google Cloud vs. AWS vs. Azure – Hybrid Network Architecture

WAN Routing in the Cloud Era (Cisco SD-WAN)

Marwan Al-shawi – CCDE No. 20130066, Google Cloud Certified Architect, AWS Certified Solutions Architect, Cisco Press author (author of the Top Cisco Certifications’ Design Books “CCDE Study Guide and the upcoming CCDP Arch 4th Edition”). He is Experienced Technical Architect. Marwan has been in the networking industry for more than 12 years and has been involved in architecting, designing, and implementing various large-scale networks, some of which are global service provider-grade networks. Marwan holds a Master of Science degree in internetworking from the University of Technology, Sydney. Marwan enjoys helping and assessing others, Therefore, he was selected as a Cisco Designated VIP by the Cisco Support Community (CSC) (official Cisco Systems forums) in 2012, and by the Solutions and Architectures subcommunity in 2014. In addition, Marwan was selected as a member of the Cisco Champions program in 2015 and 2016.

71 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Order Now