Architect the Right Solution in Azure
By CMD Technology Group
3 min read
Cloud infrastructure and deployments are usually an afterthought for most businesses. There are several reasons for this, but two are probably the most significant. The first reason is not anyone’s fault because it has to do with business age. A company that started 25 years ago could not foresee the cloud explosion. A business that opened the doors 5 years ago should have started with a cloud-first mindset, and for this blog, we will assume that’s the case.
The second reason cloud infrastructure is an afterthought for most is that the responsibility to design the cloud infrastructure has been assigned to the wrong departments. Deciding who architects cloud solutions is very difficult. However, if there should be a TLDR, then it’s this: your network architect or a partner like CMD should be designing your cloud infrastructure. I’ll explain why.
Developers have an incredible ability to conceptualize application designs, much like an artist can visualize a painting they have not yet started. Mix that with modern application development best practices of release early release often (RERO), or continuous integration (CI) continuous delivery (CD) and they can bring to life their concepts in a fluid manner. You can appreciate this by taking a look at the evolution of a simple smartphone app and the constant updates we receive.
Network architects do not have that luxury. Although they also have the ability to visualize a new network design like an artist, they lack the fluidity of RERO or CI/CD. This is not to say that networks are rigid and unyielding, but they do lack some flexibility. For example, every network needs IP addresses, just like a house needs a physical address. You can’t just change either without intensive meetings, planning, and a lot of work. Don’t believe me? Just look at how many enterprises have not migrated to IPv6.
When setting the foundation of your cloud infrastructure, you want to ensure that it is somewhat rigid but accommodating. In other words, this is my “rigid” IP addressing block, which can accommodate autoscaling and future growth. We never want to allocate all network addresses at once.
Designing a Virtual Network (VNET) or Virtual Private Cloud (VPC) requires the mindset of a network architect. Most environments need more than one VNET/VPC: production, development, testing, private, public, and so forth. All of these need IP addressing, security, and monitoring. Let’s take a look at some of the options of creating a VNET in Azure.
“Designing a Virtual Network (VNET) or Virtual Private Cloud (VPC) requires the mindset of a network architect.”
In the screenshot above, we see decisions made by the network architect. Let’s suppose that this business uses a 10.0.0.0/8 network. The savvy network architect has decided to reserve the IP address block of 10.254.0.0/16 exclusively for their cloud infrastructure to avoid overlapping network addresses with existing or future networks. For this VNET the architect has decided to use the 10.254.1.0/24 subnet and a secondary VNET with 10.254.2.0/24 subnet as seen below.
In the screenshot above, one VNET could be for production and the other for development. By default, Azure does not let these two VNETs speak to each other. Therefore, the development environment is completely isolated from production. What do we do if we want these two VNETs to speak to each other? That’s where VNET peering comes into play. Below, a VNET peering is created that allows both VNETs to speak to each other. The name can be changed to something more meaningful like Prod-Development.
Also, as our cloud environment grows, we can create additional Azure VNETs all within the 10.254.x.x/24 network. In this example, we have created a 3rd VNET named VNET10.254.3. This VNET could have different security requirements than the Development VNET.
It isn’t always necessary to peer every VNET with one another. That could quickly turn into an administrative nightmare. The network architect, security engineer, and/or company policy dictates that all traffic from one VNET must traverse another VNET. Maybe one VNET is home to a central firewall. To achieve this, traffic forwarding must be enabled. In the example below, VNET1 is the central point, and we only need peering between the other VNETs and VNET1. Then we allow VNET1 to forward traffic coming from one or more of the other VNETs.
You can add another layer of security by creating a security group to further protect VNETs from one another, but that’s a topic for another day. CMD is a good bet in laying the foundation for your deployment to Azure. Once we architect and deploy this Azure solution, your development team will be free to do what they do best: develop applications.
If you have a question about any of our solutions or any feedback you’d like to share, contact us. We would love to hear from you!
afernandez@cmdtg.com | (407) 442-0265