Networking Strategy for Cloud transition

If you decided to build a house in the wild that you have to reach via a narrow and steep footpath, where you want to live and not worry about taking anyone else with you or commuting to anywhere else, then it’s not probably a bad idea.

But sooner you see, more people trying to move closer to where you are and you want to commute elsewhere for various reasons, you might start to think have I made a poor decision!

Yes, for your requirements ideally you should have laid the road networks before you move in and also able to scale in and out your road network based on your demand.

Public Cloud

In the early days when the Public Cloud was introduced, there was a perceived understanding of no longer network expertise required in the cloud, as the networking is managed by the Cloud provider in the Cloud. This has soon become a false assumption due to various factors unless you are a startup and only using one Public Cloud provider in a single region.

• Large on-premise networks and office networks that requires connectivity to Cloud networks.
• Most of the applications in the Cloud requires connectivity to on-premise, Cloud providers backbone and as well as the public internet.
• Some of the shared capabilities such as monitoring, tooling, service bus, domain controls, DNS, API Gateway and many more require connectivity to pretty much every single Cloud applications, which means every single private Cloud network.
• The number of applications that needs to be transitioned to Cloud and limitations from Cloud providers and RFC1918 private IP address space.
• Securing Cloud backbone and internet access from internal networks.
• Able to support network segregations level required by company security policies.
• Able to support local and global on-premise and Cloud provider regions.

And this list will go on and it’s only going to be longer and never going to be simplified.

It requires quite a lot of due diligence, design and planning to make sure your networks are still manageable while keeping all of your stakeholders happy. This also means, unfortunately, before you start your Cloud transition journey, you have to secure people with network expertise who can extend their network expertise from on-premise to Cloud and beyond!

The areas expertise across on-premise and Cloud requires at least the following:

• Routing or Layer 3 expertise, both in terms of static and dynamic routing.
• Network firewall expertise, in terms of network filtering, inspection, detection and prevention using modern anomaly detection techniques and large scale policy lifecycle management.
• Web application controls, in terms of policies, web application firewall rules, API specific policies, inspection, detection and prevention using anomaly detection.
• Internal and external DNS, in terms of managing top-level domains, split DNS, forwarding across on-premise to Cloud and traffic management.
• Expertise in Internet Edge protection services such as DDoS, CDN, data loss prevention and anomaly detection.

Once again, this list will grow as new trends and threats appear.

Depends on the stage of the Cloud transition, what expertise needed can change so the network specialists should be able to adopt an ever-increasing portfolio of services. In other words, the skills and expertise are elastic, you stretch and contract as you see fits into your organisations demand. 

On the other side, no one can predict unless it’s been very well planned when the network of an organisation is going to expand or shrink and again like elastic. This also includes expanding into another region if that’s allowed according to your company policy. 

Elastic Network as a Strategy

AWS has named its network interface as Elastic Network Interface as it can be attached or detached from an EC2, but it’s still limited within an Availability Zone. But “Elastic Network” in the context of this blog, is the “Network Strategy”, not AWS ENI!

• Able to expand and shrink your internal and external network across on-premise, Cloud and Internet.
• Able to expand your network team’s skills as you grow and able to allocate and release network addressing as needed across on-premise and Cloud.
• Able to expand from local to global as needed across your on-premise, office networks and Cloud regions.
• Able to easily provision and de-provision network services from Layer 3 and above with minimal interruption to applications.

In other words, worth re-considering your Cloud journey if your organisation is lacking any one of the above elasticity as in the long run it may lead to blockers, technical debts, unhappy stakeholders and customers.

Networking First

Every network landscape has a different construct, it’s really recommended to create a network model per each scenario.

• Network Model for an on-premise application including access from the office network.
• Network Model for a Cloud application including dependent services and access from the office network.
• Network Model for each environment and environment segregation by network or application.
• Network Model for an external-facing on-premise application.
• Network Model for an external-facing Cloud application.

There are no limitations for Network Model, so focus on what network models that you need to consider based on your organisation’s strategy.

An internal application deployed in AWS VPC that requires access from the office network, requires connectivity from office network to AWS VPC, routing in place for on-premise to and from AWS VPC and network access allowed in on-premise firewall, AWS NACL and AWS Security Groups for same.

The same will be more complex if there are dependencies on-premise or and if the application is for an external-facing application.

The below snippet provides a sample network provisioning request for an application:

enable_network(app) {
	enable_routing_onpremise(app) 
        # internal as well as advertised to cloud
	enable_routing_cloud(app) 
        # via Cloud Gateway or Hub
	allow_inbound_outbound_onpremise_firewall_rules(app)
	allow_inbound_outbound_cloud_firewall_rules(app)
}

If there are hundreds of such applications and if this network model is not managed very well, it can lead to way more complex network and can potentially slow down the cloud transition as the network team managing the same may not have more time to manage more networks.

In case, if there is another Cloud provider to be considered for Cloud transition as a second provider or even as a replacement, things are just going to be going out of control in terms of network management.  

Now you can appreciate the level of complexity, ideally, this entire provisioning can be automated end to end for an application and the same for de-provisioning and updating, all using “application” as the “identity”. If your organisation embracing the “zero trust” model as a strategic position, defining this identity model based on an application from the ground up is quite critical.

In Cloud, the concept Security Group or the firewall ruleset associated to the network interface of an application or load balancer could be an example of an “identity” as far as this identity is owned by each of the application team.

Network Team Driven

If you are planning for a large scale Cloud transition, the first team to get trained to be prepared MUST be your network team, other than your security teams. The infrastructure team and application teams come next.

Your funding vehicle here could be an interesting challenge, if your organisation’s strategy is operational excellence and funding is only allocated for aligning towards that strategy, then it needs to be handled very carefully by still meeting stakeholders’ expectations while working towards “Elastic Network”.

If your network team need to collectively improve the operational model, then all of their services need to be clearly defined, automated and key matrices such as SLA are to be measured based on application onboarding, maintenance and decommissioning. For the organisation, operational excellence is all about how easy to introduce a new application, manage and dispose of it.

The following is a high-level guideline to define the operational model:

• Based on the application, select the Network Model
• Based on the Network Model, select the dependencies
• For all dependencies, define the interface to execute.
• For each interface, work with the appropriate team to implement possibly using automation.
• If that appropriate team is your Cloud infrastructure team and if it’s funded, you can engage them to automate it.

The last step above is agnostic of which Cloud Provider and your network team not necessarily have to debate about whether talking about it or even thinking about it is funded, in other words, if you are not even thinking about it, you may not be aligned to your operational excellence strategy when Cloud transition starts!

Aligning to your organisation’s strategy is a commitment expected from every single person in your organisation, business or project management won’t say how when it comes to networking, it’s in your hand to make it work, so that’s more important to remind yourself before next time you start debating about in scope vs out of scope.

Operational Model for Elastic Network

Let’s look at how an operational model looks in a truly Elastic Network aligned network strategy. 

One of your application team wanted to want to deploy their application into Cloud and they requested the network team:

• The network team select the right network model and provision all network constructs end-to-end.
• The network team updates the CMDB for the respective application with the new network.
• The network team handover the network to the application team.

Now the application team has gone live and they requested to decommission the on-premise network that hosted the on-premise instance of the application.

• The network team select the on-premise network from CMDB using the application identifier.
• De-provision the on-premise network that belong to the application.
• Update the CMDB as the on-premise network de-provisioned.

The application team received a feature upgrade, now they requesting on-premise access from their Cloud application.

• The network team select the Cloud network from CMDB using the application identifier.
• The network team updates the network model to introduce on-premise connectivity in CMDB.
• This event triggers an update to the Cloud network of the respective application, this may involving creating on-premise connectivity if not exists already.

The application team once again received a feature upgrade, now they wanted to connect to a SaaS service from their Cloud application over the internet.

• This pretty much follows the above sequence, except the fact, instead of on-premise connectivity it’s the Internet Egress connectivity is requested.
• Also additionally the SaaS application should get registered in CMDB and its own network model, if not registered already.

Now the sales team found external customers, who wanted to access the same Cloud application, so they requested the network team to allow access from the internet.

• Once again, the sequence is quite similar, but this time it’s the Internet Ingress will be allowed and a new network model will be selected.
• Based on your organisation, there may be more teams interested in case if you opening up your application to the public internet.
• Notify all your interested parties including invoking their process as sub-processes.

Now as the application exposed to the public internet, it requires additional scaling capacity and it’s currently limited by the network size.

• The network team updates the network and increased the existing CIDR or added a new CIDR.
• This triggers updates to the already provisioned network based on the latest network model as per CMDB.

Every service offered by network team here comes with it’s SLAs and better the SLA the better the Operational Excellence, better the Operational Excellence the transition to Cloud also can speed up.

Even better, due to agility and pay as you go model in Cloud, the Operational Excellence improved more in Cloud than in on-premise.

To quantify how important your network team’s ability to execute the “Elastic Network” strategy, let’s say you have a hundred applications and your network team takes a day to provision just the network for each application, which is almost a year. If your network team takes a week a two, this simply become 5 to 10 years, again just to provision the network for your Cloud application. 

For the application and infrastructure teams, they have their own work to provide each of the application in the Cloud and normally that takes much longer than networking. So if you have some serious Data Center Exit Strategy, then make sure your network team is able to execute the change in days or even better hours rather than weeks or months.

No Silver Bullet

You might be wondering whether I am re-inventing SD-WAN solution as part of this blog, the SD-WAN solution may help “Elastic Network” strategy, but SD-WAN itself does not guarantee help to realise “Elastic Network strategy without people, process, modelling and readiness.

Even with SD-WAN, you will still have to create Layer 2.5 circuits, manage Hubs in Cloud as well as on-premise and use another solution to provide network controls, inspection, detection and prevention. 

Once again, cannot emphasise more on people and skills required before you start your Cloud transition journey.

The Strategy is yours

Any strategies, such as Elastic Network, belongs to you, you cannot expect the Strategy from your partners or solution providers. Your partners, vendors and other solution providers may be able to help provide the solution to realise and execute your strategy but the Strategy always belongs to your organisation and you cannot purchase it from anyone. 

In order to make use of the Elasticity of Cloud computing, your network should also be elastic, like Cloud you want to provision networks when needed and de-provision them when no longer needed, able to scale out and scale in as you see it fits. In other words, align your Networking Strategy to your Cloud Strategy as well as your organisation’s Strategy! 

Disclaimer

This article was produced in my own capacity and experience so it could be beneficial for others; no association could be assumed with the organisation that I am working for now or the organisations that worked in past.