Understanding and Designing Azure Networking

×

Chapter 1

Introduction

Introduction

Thank you for purchasing Understanding and Designing Azure Networking; whether you are about to get started in the world of public cloud network design or you are a seasoned professional wanting to solidify existing knowledge, we are confident you will find value in this book. Today, networking is more important than ever, and in the cloud, this is no different; users and applications expect ubiquitous and unlimited connectivity, and there are many decisions to be made.

This initial chapter will introduce the rationale for creating the book, present the basic structure of contents, and outline the reasons why network design and architecture are still important in the era of public cloud.

The book is structured in three main sections, which are as follows:

• Introduction: Clearing up fundamental Azure networking concepts as well as necessary requirements that will be crucial for the next chapters.
• Topology: These chapters will focus on the common network topologies that can be used in Azure network designs, including connectivity to on-premises networks, and describe when to use which.
• Network services: Finally, in this last part, you will learn how to enrich the topologies discussed previously with additional services such as application delivery, security, or monitoring and management.

Each chapter can be read in isolation; however, especially if you are newer to Azure networking, it is suggested to read the book from front to back, as later chapters build on the knowledge presented earlier on. The authors have heard most of the questions explored in this book from actual Azure customers. This structure will create a logical arrangement of ideas for the readers going sequentially through the book, while at the same time, it will also help those consulting the book in isolation for the answer to a more specific query on a single technical topic.

Characteristics of this book that set it apart from other options in this technical area include:

• Written by authors who have spent many thousands of hours talking to real companies about Azure networking.
• Not filled with pages and pages of configuration guides and implementation details that can be easily found on vendor websites and makes interesting content difficult to find.
• Balances bottom-up technical details with top-down real-world architectural considerations.
• Adopts a more moderate and casual tone to communicating technical ideas, written for ease of consumption.

Structure

This chapter covers the following topics:

• Networking is fundamental
• Azure networking certification

Objectives

By the end of this chapter, you will be able to appreciate why understanding networking is crucial now more than ever. Whether you are a cloud architect who wants to learn about cloud networking or a networking expert who wants to extend your expertise to the public cloud, this chapter will provide you with the necessary context to start your journey.

Networking is fundamental

You have in your hands one of the few books published lately that does not revolve around artificial intelligence (AI). In fact, it might not even be mentioned at all after this paragraph. This begs the question, however, why should you spend your time reading about technology as traditional as computer networking while you have so many other hotly trending topics such as , machine learning, blockchain, Kubernetes, or DevOps competing for your attention?

The reason is that, even if networking is an older subject area with a 50+ year history, it is no less true that networking underpins everything: without networking, all those other more visible technologies will cease to function. Connectivity is paramount. In this vein, the authors have worked to help countless users of Microsoft Azure to solve challenges that poorly designed networks pose to the correct operation of applications. They have witnessed firsthand how the lack of networking expertise can break even the best-intentioned cloud project. Hence, this book shares the lessons learned and helps organizations lay the solid networking foundation upon which all their applications can thrive and provide a great experience to their users.

History

Even though a traditionalist may question whether cloud networking is, in fact, an entirely separate discipline, it is fundamentally different from traditional networking. First, let us agree upon some basic terms, in this book, the term cloud is used purely in reference to public cloud. Even though the term private cloud is used in certain industries, these environments are quite different from public cloud and resemble more traditional dedicated on-premises infrastructure with a layer of automation on top of it.

However, public fundamentally different. Even though the history of public Cloud has roots going far back in time, many mark as the turning point the summer of 2006, when Amazon started offering infrastructure services as part of Amazon Web Services (AWS): Simple Storage Service (S3), Elastic Compute Cloud (EC2) (with the m1.small instances being the original compute version) and Relational Database Service (RDS) were the initial offerings within AWS. Less than two decades later, the likes of AWS, Azure, and GCP would acquire huge proportions of global IT spending and completely change the way in which companies host their IT services. And yet, these early service categories defined some of the major moving components of the cloud and laid the foundations of Infrastructure-as-a-Service (IaaS) as it is known today: storage, compute, and networking.

Three years later, in 2009, AWS fundamentally redesigned its networking platform for EC2, and private networking in the Cloud was born in the form of virtual private clouds (VPCs). Meanwhile, in 2008, Google responded to AWS announcements with the initial version of their cloud offering, named App Engine, which would eventually become the of today.

In a parallel bold move, Microsoft announced Windows Azure in 2008, initially within an immature market where some feared it might cannibalize the Windows and Office business units (fears that would later prove not to materialize). In hindsight, today, it may appear that entering the cloud market was an obvious decision, but back then, it represented a large company dipping its toes into a young technology area. The initial version of Azure focused more on what would be now referred to as Platform-as-a-Service (PaaS) offerings. In 2012, Microsoft added virtual machines to Azure, with which the first virtual networks came to the screens of Azure customers and the rampant growth of commenced.

In 2014, Microsoft renamed Windows Azure to Microsoft Azure, as it was clear that public cloud was closely tied to the company's operating system. At the same time, a new major release of the API called Azure Resource Manager (ARM) was announced, which would replace the earlier Azure Service Manager (ASM), now known sometimes as Azure Classic. This was a slow migration that will reach final completion in 2024, some 10 years later. ARM gave us the modern virtual networks that are available today, with an API that has gone through many new versions since but that has stayed faithful to its core principles.

Whether you are creating an AWS VPC or an Azure virtual network (VNet), you are interacting with the APIs that Amazon and Microsoft give you, not with their networks directly. These API calls will do something in their data centers, but you cannot tell exactly which protocols, which physical topology, or what bandwidth your VPC or VNet will have. This abstraction is in stark contrast with the way in which network administrators are used to working in their on-premises infrastructure, where they have full control of, and full visibility into, the configuration of the system.

This type of friction within the network industry is not new. For example, when Cisco launched its Application Centric Infrastructure (ACI) network architecture in 2013, it incorporated some of the concepts now seen in the public Cloud. The actual protocols running under the hood were hidden from the network administrators, who deployed certain abstractions such as what Cisco called endpoint groups (EPG). Cisco ACI was initially viewed as too abstract by some network administrators who wanted to understand exactly what was going on under the covers.

While network administrators can choose their on-premises infrastructure and opt for modern concepts and abstractions or for more traditional approaches, cloud vendors do not give that choice to network administrators: whether they like it or not, they must accept the abstractions that are on learn to work with them. Within an alternate timeline of history, public cloud providers might have taken a similar approach like Kubernetes radically changed the way in which networks are configured, but they instead opted for a approach. To avoid the alienation of network administrators by this brave new world of network abstractions, most public clouds use familiar concepts such as subnets, network interface cards (NICs), and other constructs originated in the on-premises world. While these abstractions certainly take some fear away from the network administrator, they also introduce certain ambiguity since you soon find out that a subnet in public cloud is very different from a subnet in your on-premises network (Chapter 2, Azure Networking Fundamentals will investigate these differences).

You can certainly say that cloud networking and on-premises networking are quite different animals. Many of the required skills and troubleshooting tools will be familiar, but the network administrator needs to approach cloud networking with a fresh mind, open to being surprised, and open to learning.

Cloud needs networking professionals

It may be tempting, not only for network professionals themselves but also for the companies that employ them, to start thinking that because the cloud service provider (CSP) takes over the running of the physical network components, the value of the network professional is reduced. Hopefully, the medium is the message in terms of this book communicating the complexities and many different networking subjects that are still alive, and well, and ready to be tackled in the cloud today. However, it can be hard to appreciate this from the outside, having not already been involved in the design process of at least a handful of cloud network architectures. Therefore, if you are in these fresher shoes, perhaps this book also helps you justify the need of dedicated cloud networking experts in your organization without having to get the actual experience on the ground. If you are a network engineer looking for job security within a company that is moving to cloud and shutting down their on-premises network infrastructure, just show your this book!

Whilst it is true that many areas of the network are indeed managed by a CSP, not least the time-consuming deployment, cabling, and upgrading of the physical network, most common networking areas remain topics waiting for design and configuration using a combination of knowledge you already have, and the knowledge you will acquire in the future. Examples include the following:

• DNS is still priority number one, with the ability to take down your cloud network or in the background in a resilient fashion.
• You still need to plan your IP address allocation.
• You still need to know how to configure complicated global networks based on the Border Gateway Protocol (BGP) routing protocol.
• You still need people in your company who can still prove it is not the network when users or systems are reporting unspecified slowdowns or performance issues.

In your career as an IT-expert a part of your success will be attributable to the scale at which you operate, and how easily you are able to map your individual activities to the success of the company you are working for. Spending one week cabling and configuring switches for a local company is one thing, spending the same amount of time deploying a global network for a Fortune 500 business is a totally different job. This is not to suggest the former is not important work, but it is supposed to highlight that cloud is a lever for your career, allowing you to do more of the networking that moves the needle for a company, enabling IT to provide new services faster. As a network engineer in cloud, you are closer to this transformation, and hopefully, you will find it a rewarding exploration into a new technology area as well.

Infrastructure-as-a-Service vs Platform-as-a-Service

As introduced above, the initial intent of the product now referred to as cloud was much more hands off than some of the offerings found in the market of 2024. It was envisioned that a viable approach to all cloud migrations would involve the radical transformation of legacy systems and applications to utilize 100% cloud native architectures with a heavy emphasis on re-writing of application code and microservices based architectures. The reality is that this vision was indeed massively successful: many thousands, if not millions, of customers have used cloud as the rocket fuel to accelerate their digital transformation and radically reduce spend by moving to these lightweight approaches to infrastructure design. However, what is also equally true is that for every customer who did the heavy lifting of cloud-native transformation required for a 100% PaaS-based approach to cloud, there is another customer that is entrenched in decades of technical debt and legacy systems. Some monolithic systems would take further decades to rearchitect to fit within the bucket of a pure cloud-native framework based on PaaS-only services. There are also those customers that could spend a smaller amount of time transforming their application code, perhaps one or two years, but decide that doing this from a foundation where their systems are already in the cloud will be beneficial.

In other words, there are many companies who also have valid reasons for wanting to simply migrate their existing virtual machines into Azure, out of their on-premises data centers. In parallel, there has been a softening of the CSP approach related to how customers can access the PaaS offerings already discussed. For many years, PaaS products were exclusively in the domain of public interfaces, being accessed via API or interface that ultimately ended up going via a CSP-owned public IP address. Today, most PaaS services come with , offering private interfaces for connectivity whilst retaining the PaaS operating model for the other infrastructure elements, such as node scaling and management. The combined result of these trends is that the consumption of cloud for most companies involves the use of private networks; VPCs, virtual networks, etc., in addition to PaaS offerings. This domain of private networking, building your own overlay network configuration, running on multi-tenant physical infrastructure but virtually separate from other customers, is where cloud networking design is more applicable. IaaS and the world of virtual networks is, therefore, the primary focus of this book, but the intersection of IaaS and PaaS in the form of PaaS privatization is covered later in Chapter 9, DNS and Platform-as-a-Service (PaaS).

Automation

In short, you can automate your cloud network configurations, and you should. One of the many benefits of public cloud is the existence of a consistent API that manages all components of an application: compute, storage, databases, and, of course, networking. For the first time, you necessarily have to use infrastructureascode (IaC) framework to deploy all the technologies required for an application to run: whether it is Azure CLI, PowerShell, ARM, Bicep, Terraform, or any other environment, you can control your environment without having to interact with a heterogenous set of APIs.

This is one of the reasons why network automation has struggled for traction in on-premises networks for so many years. While most current on-premises networking hardware and software offers application programming interfaces (APIs) and software development kits (SDKs), their extensive usage has not propagated through the industry due to some factors:

• Most network designs are snowflakes, unique, and different from the rest. The many options offered by networking vendors to configure and design their networks result in infinite combinations of topologies and features. For example, there is no software that can help administrators to deploy a VLAN in every possible vendor environment, since most network topologies out there will have Spanning Tree Protocol (STP) complexity, vendor-proprietary or not, that the automation software will not be able to tackle.
• Network automation is not impactful in isolation. If the deployment mechanisms for the network are different from those of the rest of the infrastructure and the applications, the automation framework for the network will live in isolation and not benefit of the advances of the rest of the organization. Opposite to that, in public cloud, the network is deployed along with the rest of the infrastructure and even application components in the same Terraform configuration or Bicep template. Improvements to the IaC pipeline will in benefits for all the technologies, including networking.

Take, for example, the softwaredefined networking (SDN) excitement in the years around 2013, with technologies such as OpenFlow threatening to change the way in which networking was configured forever. Yet, in 2019, Gartner called the end of the SDN cycle by describing the OpenFlow technology as obsolete, it failed to materialize because it completely ignored the bits that matter: the data, the users, and the applications. Ironically, while evangelists were loudly touting the benefits of OpenFlow, companies like Amazon and Microsoft were quietly working in parallel on the real SDN transformation that would conquer the world years later, the one that would serve as the basis for what cloud networking is today.

Azure networking certification: The AZ-700 exam

As discussed above, knowledge about cloud networking is very relevant in the industry today, and it can help you not only to solidify your position as a network administrator in an organization moving to cloud, but to advance your career since this space is not that crowded yet. Certifications help in that goal, and Microsoft has included Azure networking in the list of technologies where practitioners can get accredited for their knowledge. Passing the AZ-700 Microsoft exam will get you the Azure Network Engineer Associate certification, proving to yourself and to third parties (such as potential employers) your knowledge of planning, implementing, and managing Azure networks.

This book focuses on the design skills of network engineers, or if you will, the why you would want to implement Azure networking services in a certain way. The actual configuration details, or the how, is thoroughly described in Microsoft official documentation. Therefore, the authors dont think that additional material is needed on this area. Even if occasionally other chapters will contain screenshots describing how to perform certain configurations or troubleshooting steps, the main goal of this book is teaching you about the different Azure network architectures and their trade-offs

Building the right architecture for your requirements is the most important part of the job. However, you need to consider that the AZ-700 exam will include questions covering both angles of Azure networking: design and implementation. Consequently, although this book will help you if getting certified is one of your objectives, you will certainly need additional learning materials as well as some practice.

Regarding the technology areas, this book covers all topics included in the AZ-700 exam. The following list maps the subjects in the blueprint for the AZ-700 exam to the different chapters in this book:

• Core networking infrastructure: Chapter 4: Network Topology.
• Connectivity services: Chapter 5: Connectivity to on-premises and Chapter 6: SD-WAN.
• Application delivery services: Chapter 10: Application Delivery.
• Private access to Azure services: Chapter 9: DNS and Platform-as-a-Service (PaaS).
• Secure network connectivity to Azure resources: Chapter 8: Network Security.

Although this book has not been specifically conceived as a study guide to make you pass the AZ-700 exam, after reading it you will be in a much better position not only to get the Network Engineer Associate certification, but to understand Azure networking as a whole, and to make balanced network designs tailored to your organization’s requirements.

Conclusion

Thank you for choosing to read this book; in this first chapter, you have learned who this book is for (hopefully, this matches your background), how to read it, and, more importantly, why to read it. This chapter discussed the history of cloud and how it initially ran in parallel with advancements in , to converge today more ubiquitously and capture the minds of network professionals. Finally, it talked about why adding cloud as a string to your bow is an advantage to network professionals, and it highlighted the major areas needed in addition to the typical on-premises skillset, including topics such as automation. Continue reading in Chapter 2, Azure Networking fundamentals, to begin dipping your toes into the technical aspects of networking inside of Azure.