Megaport Connect Cloud Networking Summit

Cloud Networking 101: How Cloud Changes Traditional Network Architecture – Full Transcript

Host: We’ve gone from environments where engineers were configuring physical hardware to managing infrastructure through APIs, automation, and code. And if you come from a traditional networking background, that can be a pretty big adjustment.

Our next speaker is Holly Podbielak, a solutions consultant at Palo Alto Networks and co-host of the N Is for Networking podcast on Packet Pushers. Holly is going to walk us through some of the fundamentals of cloud networking and how it compares to traditional network architectures. So please welcome Holly.

Holly Podbielak: Good morning, everyone. Thank you for joining us here. It is such an honor to be speaking to you all today.

This is going to be a little bit of a step down after listening to Roy’s very technical conversation. So for any of you who felt a little bit lost, don’t worry. This is going to be the 101 session. We’re going to kick this off with how cloud changes traditional network thinking. Since this is a 101 session, I’m going to stay deliberately high level. So no config, no CLI.

The goal is to lay a strong foundation for the rest of what you’ll hear today. So how many of you in the audience today come from a core networking background? A few. How many of you come from cloud specifically? Maybe one or two. That’s great. By the end of the session, you should have a working framework for why cloud networking is different and where you should focus if you’re starting to build your foundation.

So why the strange accent? You’re going to hear a couple of accents today, and I think mine sometimes confuses people, but I’m originally from South Africa. I took the leap of faith about four years ago to move to the US on a whim to complete a master’s degree in engineering. I focused on operations research and information engineering at Cornell Tech.

When I completed this degree and started transitioning into the workforce, I didn’t quite understand how it was going to help me in my day to day. But upon entering the network engineering world, I started to realize the math, the linear algebra, the optimization algorithms that I’d spent over a year doing actually formed the basis for all routing protocols.

I’m currently an SE at Palo Alto, but I started my journey at Juniper Networks, and I’ve been working my way through all parts of the industry ever since. On the side, as mentioned, I’ve got a podcast called N Is for Networking, where my co-host and I deconstruct the complex topics of networking to make them a little bit more digestible. I’ve been in the industry just over three years and have already experienced the transition from CLI to scripting and automation to AI.

And I guess that begs the question of how I am presenting this 101 session today. Well, who better than someone who isn’t a cloud expert? I went about prepping for the session by doing a bunch of research around all the things I don’t know and the gaps that I felt were necessary to fill in order to set the table for the rest of the sessions you’ll attend today. So I’m going to touch on many topics at a high level. I strongly recommend that you take note of any questions you have and see if later on, in the more technical sessions, they get answered, because I’m sure that they will.

So this is what I’m going to be talking about. The goal is to help you understand how to transfer your networking knowledge to the cloud space and where things differ between the two. We’ll start with why organizations go to the cloud at all, because that context explains most of the design decisions that follow. Then we’ll look at the assumptions that carry over from on-prem infrastructures and the ones that quietly break. We’ll spend the middle of the session on the operating model, because that’s the part that catches experienced network engineers off guard. And finally, of course, vocabulary, architecture patterns, and how you connect it all back to what you already know.

Let’s get straight into it. Now, I know this says “Why cloud?” But the question is actually not a question of if you should use the cloud. It’s where are you already using the cloud today? Businesses have to use it whether they like it or not, as almost every aspect of modern digital life, business, and technology relies on cloud today.

So what causes the shift to the cloud? We’re going to go through the four main reasons organizations make the move, and surprise, surprise, none of them have to do with networking being better.

Firstly, speed and scale. You can prototype something in an afternoon that used to take a quarter-long procurement cycle. When it works, you scale it instantly without starting another procurement cycle.

New cost models. CapEx shifts to OpEx, with low startup costs and pay-as-you-go consumption. This turns into a finance conversation just as much as a technology one, altering who approves what.

Third, you start to have a new operating model, where infrastructure is defined in code and deployed directly by the teams using it. We’ll dive into this a little bit later.

And finally, emerging technology. With cloud, you have access to managed AI and data services that you wouldn’t be able to easily stand up on your own in an on-prem environment.

So here’s the key takeaway to keep in mind for the rest of the session. Public cloud is a business decision. It is not just a technology one. That means as a network engineer, often you aren’t making the choice of whether we should go to cloud or not, but you are the one making it work.

So what really changes when moving to the cloud? Let’s look at three practical consequences of the business decision.

We overbuy on-prem because we have to. Procurement is slow, so you size for the worst case three years out and eat that idle capacity. In cloud, you provision what you need now, and getting it wrong is much cheaper to fix.

Everything is entangled on-prem, so a change gets a window, a committee, a rollback plan. In cloud, the units are smaller and more isolated, so the blast radius is smaller and you can move faster.

Geographic redundancy on-prem is an enormous engineering project at every layer of the stack. In cloud, multi-region is largely a design decision. It costs money, but it’s configuration rather than actual physical construction.

Notice, none of these are networking features. They are operating characteristics, and that’s the theme of this whole talk, really. How do you shift your thinking as a network engineer?

As network engineers, we obviously need to understand the technical shifts as well, not just the business impact. Most of the pain of your first cloud project isn’t necessarily learning new things. It’s unlearning the old ones. These are five assumptions around on-prem versus cloud environments that break most often.

Firstly, there isn’t a traditional Layer 2 in a form that you can design against. No spanning tree, no trunking, no stretching of VLANs. Everything is typically routed. For a lot of us, that’s genuinely disorienting, because Layer 2 adjacency is load-bearing in on-prem designs.

BUM traffic, as in broadcast, unknown unicast, and multicast, largely doesn’t exist in a traditional sense in the cloud. That matters enormously if you’re lifting and shifting an on-prem design into the cloud, because that relies on discovery protocols and clustering heartbeats. So it’s a common migration failure, and actually one that you can predict on a whiteboard before anybody touches the keyboard, if you are aware of it.

Now, you’re not forming adjacencies inside a virtual network as you would with traditional on-prem routing. You are writing entries into a route table that the provider manages. So peering doesn’t behave like you’d expect from the name. We’ll come back to this.

And visibility, of course. You can’t tap a link or span a port. You can turn on flow logs or a mirroring service, but you pay for it, and it’s not the same fidelity.

My favorite is that change control becomes a cultural shift. The maintenance window and the CAB largely go away, replaced by code review and automated deployment.

So the skills transfer. Subnetting, routing logic, security policy, troubleshooting methodologies, all of that still applies, but it’s the assumptions that you leave behind.

This is the change that catches experienced engineers the most, and it’s one worth investing time in first. The theme here is operations, not tooling. Automation and infrastructure as code change how work actually gets done day to day. This can be difficult to wrap your head around, because initially it may feel like you’re losing control, but in reality, you’re just becoming more efficient and scalable in your day-to-day operations.

Provisioning becomes declarative. On-prem, we configure procedurally. Log in, enter the commands in order, and that order matters. Infrastructure as code flips that. You describe what the end state should look like, and the tooling figures out how to get there. This is a real mental shift from writing instructions to writing specifications, or intent.

Next, we have deployment, which moves into a pipeline. Instead of a change going straight into production, it goes through review and automated testing first. A peer looks at that diff, checks run automatically, and only then does it ship. This catches mistakes before they hit anything live, and not after.

Operations shift from typing to authoring. Instead of an engineer repeating the same manual configuration on device after device, and I know if you’ve done this, everybody’s configured some subnet on a router where the one suddenly turns into a two. Well, with automation and infrastructure as code, you write the definition once and apply it everywhere. Your expertise stops being something that you retype and starts being something that you encode.

And change windows, as mentioned, give way to continuous, auditable change. Every change is a commit. Who made it, why, and exactly what it touched. Rollback is just reverting that commit, and not a heroic exercise at 2 AM.

So the uncomfortable part of this is that you are working in a developer workflow, with version control, code review, and pipelines. If you’ve resisted that as “this is not networking,” this is the point where it becomes networking and part of your job as a network engineer.

So here’s a useful reframe. Every cloud provider’s web console is a front end to an API. Nothing you do in the GUI is unavailable to a script. For example, when you click “create subnet,” a REST call goes out. That’s what software-defined actually means in practice. The control plane has been lifted out of the boxes and turned into a service. You don’t run the control plane anymore. The provider does, and you send an intent.

This, again, is somewhat of a loss of control from how you would typically troubleshoot and manage on-prem. You can’t log into the router. You can’t see the routing table the way you used to. And when something breaks, you’re now reading flow logs and API responses instead of running a traceroute from that device. But you get something back, programmability. Networks you can test before you deploy them, policy you can assert on, and configuration that you can generate rather than type.

If you take one practical action from the session, go read the networking API documentation for whichever cloud your organization uses. Not the console walkthrough, the API reference. This will actually tell you what the platform thinks a network is.

So every cloud has the same rough set of building blocks. Virtual networks, interconnects, route tables, security policies. So far, I’m sure this is all very familiar. The trap here is that similar names hide very different behavior.

AWS and Google both call it a VPC, or virtual private cloud. They are not the same object. Azure calls it a virtual network, or a VNet. All three of these answer basic questions differently. How many routes can I hold? How do routes propagate? Is peering transitive? Where does security policy get enforced?

Think about how Cisco and Juniper are similar at a high level. But if you try and plug IOS commands into Junos, it may not go down so well. So when we look at the terminology, it’s like ACLs versus firewall filters, or, with cloud, comparing Direct Connect versus ExpressRoute circuits. These are different names for similar features, which may not act exactly the same.

Now, the differentiators when deciding on what cloud to go with are similar to what you would typically encounter, but there’s also a lot to consider. AWS has a large footprint of SaaS apps. Google’s network infrastructure is really good. Azure is from Microsoft, so of course there are lots of integrations with those platforms. There’ll be a whole session today on how to choose the right cloud for you, so I’ll leave it at that for now. But as you can see, it’s much more than just speeds and feeds.

Now, transitivity is the one that bites the hardest. On-prem, if A can reach B and B can reach C, you would assume that A can reach C. Well, in cloud, peering is frequently non-transitive by design, and every provider gives you a different construct to work around it.

So there are two failure modes when you start. Assuming cloud works like on-prem, or assuming one cloud works like the other one you already know. And the second is a little bit sneaky, because it feels like experience. So read the documentation for the specific cloud you’re in, every time. The details matter, and they change.

It’s important to know the three patterns you’ll meet in almost every cloud network, regardless of the provider.

Hub and spoke. In the cloud, a hub-and-spoke topology uses a central network to handle connectivity while workload networks are attached as spokes, functioning similar to a traditional data center collapsed core or edge design. While the conceptual patterns transfer directly from your on-prem architecture, the implementation differs, because peering is frequently non-transitive by design, and this requires you to route through a central hub rather than meshing everything together. You set up your private cloud as the starting point, placing connectivity and security workloads in the hub while separating development and production environments into individual spokes across each region. The pattern transferred. The implementation didn’t.

Shared services. DNS, identity, inspection, logging, things every workload needs, but nobody should have to build five times. So you put them in one network, and everything reaches them through the hub.

Controlled egress. By default, workloads can often reach the internet far more easily than anything in your data center can. So a common pattern is deliberately constraining that to one inspected, logged path out. This is usually where network engineers add the most value early on, because it’s the pattern closest to what you already know how to do.

Notice what these have in common. Again, these are answers to questions you’ve already answered before. The architecture instincts transfer. What doesn’t transfer is the specific implementation. So don’t copy a topology from on-prem into the cloud, or across different clouds, and just assume it works.

So now we need to connect the cloud. Let’s go through four ways to connect what you already own to what you’re building. And we can discuss these in order of speed to deploy.

VPN over the public internet. This is the fastest to stand up and the cheapest, and you inherit the internet’s performance characteristics. It’s fine for management traffic and small sites, and honestly, it’s underappreciated as a backup path.

Direct connection from your data center into the cloud. This has dedicated predictability and better performance, but it’s slower to provision because there are physical cross-connects involved.

Partner-provided connection. A provider who already has the physical presence sells you that connection virtually. You’ve got dedicated characteristics without building that physical path yourself.

And finally, cloud to cloud, because you’re going to be multi-cloud whether you plan for it or not, and routing between two providers over the internet is rarely what you want.

So the decision drivers are the same ones you’ve already used. Bandwidth, latency, reliability, time to deploy. That analysis transfers completely here.

So this begs the question, how do you actually connect to the cloud? Because traditionally, it can be a pretty time-consuming process when dealing with ISPs. Traditional connectivity meant rigid, dedicated circuits, physical cross-connects, and procurement cycles that took weeks or months just to establish that link between your data center and the cloud. You had to overprovision capacity, because scaling up later was a heavy operational lift.

When we compare that baseline to modern demands, the friction of legacy infrastructure becomes more obvious, which is exactly why NaaS, or network as a service models, have emerged to bridge that gap. When we look at how NaaS changes that operational model, it mirrors what we love about public cloud and brings everything I’ve talked about together.

You get pay-as-you-go pricing with no setup fees, real-time provisioning in 60 seconds instead of waiting weeks and months for that physical circuit, and elastic capacity that scales dynamically with your workload. You aren’t locked into that rigid legacy contract, and you manage your entire network through an intuitive portal.

Crucially, because NaaS is fully API-driven, it integrates directly with your infrastructure as code workflows. Instead of manually clicking through a portal or, I can’t even imagine this, calling your vendor, you define your network connectivity as code right alongside your cloud workloads, bringing the same declarative, automated deployment pipelines that you use everywhere else to your network edge.

So from the perspective of a network engineer, this shifts your operational model away from managing physical circuits and manual configuration toward elastic, right-sized capacity and infrastructure as code integration.

So I’m going to go through some final things to take away.

Your skills transfer. Subnetting, routing, security policy, troubleshooting disciplines, they are all still valuable. It is the assumptions underneath that need replacing. And that’s a much smaller job than starting over totally.

The operating model changes, and that’s the real work. It extends far beyond the network team. Procurement changes, change management changes, and you’ll likely start to see new functions appear in your organization, FinOps being the obvious one.

Details matter, and every cloud is different. Read the documentation for the cloud you’re actually in, not the one that you just happened to learn first.

And of course, do not port architectures blindly. The patterns transfer. The topologies do not.

Finally, going to public cloud is usually a business decision more than a technology one. The most valuable thing that you can do as a network engineer is stop arguing whether you should or shouldn’t go to the cloud and start being excellent at how you can implement that change.

Thank you so much for attending today. Scan the QR code if you’d like to find me on LinkedIn. And of course, if you are newer to networking and want to brush up on your networking basics, head to the N Is for Networking Packet Pushers podcast. We’ve got some great episodes on all the things, from VLANs to multicast.