Azure Networks for Architects is a series of articles where I’ll go over some of the aspects of designing networks on Microsoft Azure. This series will have multiple blog posts and in each article, I’ll go over one aspect about networks on Azure. The series is aimed to cover from very trivial and small concept to important ones.
Though the title of this series says “Architects” this will be helpful for multiple category of poeple including developers, IT professionals, project managers, technical leads, consultants… who want to understand much fine aspects about networking which is much beyond “How to” aspects. In the articles you’ll also find that there are very small things that we tend to overlook but they play important roles in overall design for any enterprise level deployment.
The concepts presented in this series come from a wide variety of sources including my experience while working with hundreds of customers in Microsoft as a Sr. Consultant, my takeaway while working with customers in ComTec as Solution Architect, my learning from some very knowledgeable people in the industry, my mistakes and my little power of visualization and analysis.
Why Networks only? I’m aiming to cover multiple aspects on cloud computing and I’m only “starting” with networks. In future you’ll see other components of designing cloud solutions like “storage”, “communication”, “security” and so on.
Why starting with networks? Networks for the backbone of any solution. The first step in deploying any solution involves creating its underlying infrastructure upon which entire solution is built. As you’ll see in articles of this series, Network design dictates many things about your solution like performance, availability, scalability, security, maintainability and cost. I’ve not used these terms to impress, as you’ll see, these are indeed affected by network design. I’m ignoring about a small set of solutions which are built on PaaS or SaaS and may not need network as such.
Solution vs Application/Software: You’d have seen me using the term solution very often. My title with ComTec also says “Solution Architect”. This is also a buzzword that many people use as it sounds fancy and kind of “deep” and “better” than other terms. Some thin k “Solution” is very large and complex software application. However, I’ve tried to take utmost care about terms that I use (I may still have have used some terms without much thought). The term “Solution” refers to the “Answer” to a “Problem” that we are trying to address. Some times answer to a problem may be a software application but not always. As we move beyond this networking series, you’ll see that the articles are more abstract (farther from “how to”) … more “strategic” than implementation oriented. Even a decision to not use a software could be a solution to problem.
This series is also mirrored at blogs.comtecinfo.com. The links in this article below will be updated as and when new articles are posted.
List of Series Articles:
Stay Tuned! Subscribe
42azure 
3 thoughts on “Azure Networks for Architects”