Insight Article: Enterprise Network Design for the Cloud Revolution

Pretty much every organisation now has a cloud-first application strategy and an active programme to migrate as many applications as possible to the cloud.

Unfortunately, not every organisation has a network capable of supporting that cloud-first strategy, and many of those that think they do have a suitable network really have a sub-optimal solution.

A significant new challenge facing network architects and engineers is navigating the move to cloud computing. Workload migration to the cloud is forcing network architects to think differently about their network and security architectures as they look to deliver secure application access and service performance to internal and external consumers, all while delivering greater cost-efficiency.

Some of the key challenges facing network architects today include:

  • Legacy network architectures rely on traditional private WAN services. This means that internet- and cloud-bound traffic is typically backhauled from distributed locations to one or more centralised DC or hub sites where internet access and/or private cloud peering is implemented. With an increasing number of cloud applications being consumed as internet SaaS, this approach has become inefficient
  • The move to Software Defined WAN (SD-WAN), plus Direct Internet Access (DIA) changes long-standing WAN performance assumptions, since the internet is a highly unpredictable cloud network environment when compared to carrier-based MPLS services
  • Remote/home working is no longer a “nice to have” capability. Secure and performant application access is now a key requirement as many organisations adopt a permanent hybrid working policy

If you want your cloud strategy to succeed, you need the right network

The consequences of a substandard network are serious – having the right network solution is a critical success factor for your cloud strategy and if you get it wrong, your whole strategy will be put at risk.

The purpose of this article therefore is to help you understand what a suitable cloud native network looks like, and the steps you need to take to land that optimised solution, whilst avoiding as many pitfalls as possible.

Why Should I Care About This?

Simple – if your network isn’t cloud ready, your cloud strategy will fail.

The main reason for this is that cloud strategies often focus entirely on the enormous challenge of cloudifying applications and forget to enable the network which is a critical element of the infrastructure required to make those applications work. The risk of this is that fixing the network can take considerable time and may require significant investment, and failing to factor this time and cost into your cloud strategy, business case, and roadmap will become a serious problem.

There are many reasons why a cloud-first application strategy means you need to address your network, but the key reasons are as follows:

  • Network Capacity

First and foremost, in the world of cloud applications, you are going to be sending a lot more traffic across your network. This almost certainly means you need more bandwidth

  • Availability

Pre-cloud, when most applications were hosted locally, if you lost your network link you could likely carry on working. When your applications are in the cloud, that’s much less likely. Therefore, you don’t just need more bandwidth, you need a more resilient network

  • Multiple locations

It is highly likely that your cloud strategy will mean applications and data are hosted in multiple locations – some on prem, some in your private data centres, and some in one or more cloud locations. Therefore, your network needs to enable you to access all of these locations quickly and securely

  • Flexibility

Your cloud world means data and applications change a lot, and these changes are often outside of your control. Therefore, your network needs to be able to adapt and change very quickly, if not instantaneously to these changes to keep your users connected and productive

Of course, these requirements are in addition to all the other requirements you are likely to have for your network – secure, manageable, cost-effective, able to cope with increasingly hybrid ways of working etc.

In other words, unless you have sourced a new network very recently, or had remarkable foresight 2-3 years ago, chances are your network wasn’t designed for what you are now throwing at it, or are about to start throwing at it.

What Good Looks Like

As detailed above, there are many design considerations to take into account when looking at a network design for cloud. Here we analyse some of the key considerations in more detail:

Cloud Access Optimisation

As more and more workloads move to internet-hosted SaaS, network architects need to consider how traffic paths can be optimised by taking a more direct route between user and application. In a typical modern SD-WAN network this would be achieved by breaking permitted application traffic (i.e. M365 traffic) out locally as opposed to traversing a regional or central gateway service. Equally, for IaaS workloads, the approach of attaching cloud resources to the SD-WAN network using virtual SD-WAN appliances enables traffic to be routed directly to the cloud platform, thus reducing dependencies on any central network resources.

Network Underlay Specification

There are three primary considerations to think about when selecting an appropriate network access underlay for your cloud-native network:

  • Bearer flexibility – It is highly likely that workload migration to a cloud service is going to increase the bandwidth demand at your remote locations. Building in headroom from day one will ensure you have the flexibility to increase bandwidth without long carrier lead-times
  • Bandwidth quality – A network is only as good as its weakest link. If low-cost, low-quality network access is provisioned, it is likely that the overall customer experience when consuming cloud applications will be poor. Right-sized business grade connectivity, backed up with performance and availability SLAs should be sought to maximise the network performance
  • CSP peering – It is best practice to select an underlay service provider who is directly peered with the key cloud service providers networks. In some cases this may mean paying a premium for the access service, but it is highly likely the performance between user and application will be superior to that offered by a lower tiered service

Build Security into the Network

The ubiquitous nature of the network and its role in connecting physical and virtual cloud resources, inside data centres and beyond, positions it appropriately for providing comprehensive security, from the infrastructure all the way to the application. The network provides an ideal platform to consistently enforce security policies from physical to virtual stacks, from local data centre to remote virtual data centres.

What Should You Do Now?

TNC has developed a 5-point plan for organisations pursuing a cloud-first application strategy to make sure their network will be ready to meet the forthcoming requirements.

The key steps of this plan are as follows:

Step 1: Baselining

If you don’t know what you’ve got deployed today, you’ve no chance of transforming it. So, start with the basics – what network services do you have deployed today, who are they deployed with, how much do they cost, and when do your contracts expire?

Step 2: Requirements Capture

In parallel with baselining, you need to get a really good handle on your future requirements. What applications will you be using, where will your applications and data be, where will your users be, what is your future workplace strategy, what are your budgetary objectives?

Step 3: Strategy Definition

Building from your baseline, and your understanding of your requirements, you can map out your network strategy and develop a roadmap and timeline to execute. TNC often sees organisations focusing only on the technology element when they develop their strategies, so make sure you also develop your operational and commercial strategies as well as your technical strategy

Step 4: Procure

Once you’ve defined your strategy, it’s time to start buying. This could mean going to tender to find new partners, or it could mean engaging with your incumbents, but either way, you’ve got a complex process ahead of you.

Step 5: Deploy

When you’ve completed your procurement, the final step is to deploy your new network so it’s in place to support your new application environment.

As most readers will know, TNC has been supporting organisations to execute these plans for many years so has a very good idea how long this process steps will take. In TNC’s experience, Steps 1-3 of this plan will typically take 4-5 months to complete. Step 4 is then likely to take anything from 6-12 months dependent on the size and scale of the network, and Step 5 will typically take from 9-12 months. In other words, from start to finish, most organisations will find it takes 24 months to make their network ready to support a cloud-first application environment.

Of course, many organisations think they can move more quickly than everyone else and they are uniquely able to complete this process in much shorter timelines. Put simply, they can’t. TNC often finds organisations trying to skip steps, or combine steps, or think that working just with their incumbents means they can short circuit the procurement process. However, in almost every case these organisations find they have to re-run elements of the process, or they have ended up with a terrible deal. In other words, it is almost always the most sensible approach to set aside the time to execute this plan properly – it is going to underpin your application strategy for the next 5, 7 or 10 years, so it’s worth doing right.

Conclusions

  • If you are pursuing a cloud-first application strategy, you almost certainly need to review and re-develop your network strategy to ensure it will provide the connectivity you need to successfully migrate your applications.
  • When you are developing your network strategy, make sure it aligns to the key principles TNC sets out in the “What Good Looks Like” section above. If it doesn’t, you almost certainly need to re-work your network strategy.
  • Take the time to do it right. This is one of those areas where trying to cut corners will give you big problems down the line.
  • Set aside the time and budget you need. In the scheme of your total cloud migration budget, the network won’t be a huge number, but if you don’t get it right, the rest of your strategy could collapse.

 

How Can TNC Help?

Achieving the optimised end state for networks for most organisations has become considerably more complex, challenging, and risky.  With networks touching almost every part of the organisation, increasingly part of the go-to-market strategy and reflecting the radical pace of change in the industry, it is easy to see why changing networks can no longer be considered a “migration” – these days it’s a “transformation”. 

Achieving a successful transformation requires you to tackle a much broader range of elements, and to nail them all.  Of course, it’s not easy, but what is key is that you take the time to tackle all these elements completely, and ensure you have the skills and resources in place to do so. 

To help customers with the strategic planning and preparation for their network transformation, TNC has developed a strategy development and transformation framework to assist customers at each step of the process from baselining current services, business case creation, statement of requirement development, option analysis, and sourcing strategy. 

If you would like to find out more about how we can help you on your network transformation journey, we would be delighted to talk to you and share our experience and knowledge.

TNC supports the sourcing of network and telecoms services for 20% of all major corporate organisations in the UK

Disclaimer

Other than matters relating to The Network Collective, this research is based on current public information that we consider reliable. Opinions expressed may change without notice and may differ from views set out in other documents created by The Network Collective. The above information is provided for informational purposes only and without any obligation, whether contractual or otherwise. No warranty or representation is made as to the correctness, completeness and accuracy of the information given or the assessments made.

This research does not constitute a personal recommendation or take into account the particular investment objectives, financial situations, or needs of individual clients. Clients should consider whether any advice or recommendation in this research is suitable for their particular circumstances and, if appropriate, seek professional advice.

No part of this material may be (i) copied, photocopied or duplicated in any form by any means or (ii) redistributed without the prior written consent of The Network Collective Limited © 2022