What are the most important topics that experienced .NET Architects need to master for Azure?
This is important for architects because… Azure is core knowledge.
We are assuming that readers understand that Azure is a well-established cloud platform with over 600 services in over 50 major data centers throughout the globe. For the record, however, the key difference between Azure and so-called “on premise” IT infrastructure is that you don’t have to build and maintain your own systems, but rather pay only for the actual computing power and resources that you use.
We are also assuming that the term “architect” is applied only to application architects rather than database or IT specialists.
There are other cloud systems, most notably AWS, but we are only discussing Azure here.
For those who would like an overview in layman’s terms, it is available at https://azure.microsoft.com/en-us/overview/what-is-azure/
Why is Azure Core Knowledge Difficult to Master?
It is difficult to understand what the most important topics are to an architect for a variety of reasons.
(1) Platform. Azure is a platform rather than a development tool. There is a lot to know for many different IT departments, but it is not necessary for architects to know all of the areas in depth. Example: There are a lot of impressive features for networking and database administration, but we have IT teams that will have to master that.
(2) You Need to Know Something About Everything. For those of us who had to introduce client/server systems on Windows NT in the 90s, the Windows platform was so new that architects were responsible for all aspects of the technology. The Azure platform is in the same position today – the architect does not have to “master” everything, but they do need to understand everything. Example: If your organization does not have an IT person who understands Azure networking, you may have to fill in until you get someone trained.
(3) Microsoft Marketing. Microsoft encourages clients to use Azure for a lot of the latest trendy technology in the IT industry such as artificial intelligence and IoT. While these things are cool and fun, they are not really core functionality, so you should ignore them and focus on core functionality until you need the new things. Example: Containers, IoT, and Bots are very cool, but most architects don’t need them and should thus simply ignore them for now.
(4) New for Developers vs. New for IT. The technology that is new for developers is the technology that architects should focus on first. Fortunately, there is less new for developers than there is for DevOps specialists.
(5) Azure is a Big Place. Microsoft has over 600 services available, but developers and architects only need to know a few of them to get started effectively. If you are familiar with perhaps 20 of the most important services, you can pick up the rest of them as needed. You don’t initially need to worry about Azure service offerings from third parties.
(6) Hands-On Required. You have to get “hands on” to understand Azure. If you want to learn .NET development, you need Windows and Visual Studio. If you want to understand Azure, you need to set up an account. Fortunately, there are a sufficient number of free options that you can do this from home if you’d like.
(7) Conflicting Sources. There are a lot of sources for Azure knowledge, many of which are too focused, not focused enough, too high level, or conflict with other sources.
(8) Azure is Where the Money Is. There is a lot of investment in infrastructure and people right now. The more money you see invested in something, the more conflicting opinions you will see.
(9) “Architect” is an Overused Term. Microsoft, other vendors, and authors often call everyone in IT an “architect” of some kind. Consequently, most of the material that is published for “architects” has modest relevance for developers.
The Key Areas for Architects, in Order
Scalability. Scaling is adaptability of the system to the changed amount of workload or traffic to the web application. One of the great features of Azure service is its ability to “auto scale” according to application usage demands. You mainly want to master the auto-scaling support.
With auto-scaling, the scaling is done by creating more instances – this is called scaling out. Another way of achieving the scaling is provisioning larger systems, also called scaling up, but scaling out is generally preferable.
Microsoft has a scalability checklist at https://docs.microsoft.com/en-us/azure/architecture/checklist/scalability
Availability. Availability is the proportion of time that a system is functional and working, and is one of the pillars of software quality. You don’t really need to know anything about Azure to address availability concerns – availability techniques are drawn from other systems. We have published a blog post on availability at http://saipx.com/designing-for-availability/
Microsoft has an availablity checklist at https://docs.microsoft.com/en-us/azure/architecture/checklist/availability
Security. When we talk about security, the discussion includes compliance with various regulations, especially in industries like healthcare, finance, and government. Compliance concerns with security or government regulations can easily derail a movement to the cloud, so architects have to pay special attention to those concerns. There is a TechRepublic article at
Compliance could kill your cloud deployment: Here’s how to handle it that might prove helpful.
KEY POINT: The main thing to ensure for security is that your data is encrypted both in transit and at rest.
There are a lot of potential risks associated with sharing infrastructure and using vendor APIs, but you can rest assured that those concerns have been addressed if you are using a top cloud vendor like Microsoft, Amazon, or Google.
Naturally, you will need to accommodate user accounts and permissions as well, but you should be able to do so with Azure Active Directory. Users are always the weakest part of security, of course, but Microsoft does provide enough clean options that you probably won’t things any worse
Data Solutions. Naturally, you will need to create data solutions on Azure, but as long as you stick to SQL Server, you won’t have to learn a lot of new things right away. You will want to review some of the storage options and terminology such as queues and blobs. You can skip NoSQL options for now unless you need them.
Cost Management. While we have not listed cost management as the #1 concern, that is only because you can’t even attempt to introduce Azure unless you have addressed some of the technical concerns above. Cost management will undoubtedly the most important business concern. The simple truth about cloud costs is that they really are less – typically a lot less – than on-premise infrastructure, but only if the costs are managed correctly.
There are cost management tools from both Microsoft and third parties to help you manage costs. There is a good article on this at
Use the free Azure price calculator to determine what services will cost before you sign up. These cost management tools, however, should be used last rather than first.
In practice, the main problem with cost management is that developers and other stakeholders will typically be biased towards provisioning more infrastructure than they need. Provisioning resources is easy and most of the people doing it don’t understand the costs. Combine this with typical enthusiasm for new technology and you have a case for people being less than cautious when provisioning.
Business Continuity. For those who have never been exposed to it, “business continuity” is simply about having a structured plan to respond to unplanned downtime. Equipment will fail and data centers can burn down. Azure has a lot of features that not only allow for “disaster recovery”, but allow it to be done more effectively and less expensively than for on-premise installations. While enabling these features is not difficult, it is important simply because you cannot allow a site to transition to Azure without having a business continuity plan that is at least as good as that for the previously existing on-premise installation.
DevOps. We are defining “DevOps” here as managing builds, deployments, and other routine system administration tasks. DevOps is arguably the aspect of Azure that is the most different from on-premise installations. Because it is so different from on-premise, this would be the most important area on our list if it were not for the fact that you will need an Azure DevOps specialist on your team. That is, it is the most important area for moving to Azure, but not for the architect.
KEY POINT: DevOps is the most important are for moving to Azure, but not for the architect.
Serverless. When moving to Azure, 100% of existing .NET knowledge is still usable, but there are many new “cloud native” features that the organization should aspire to use. While there are other aspects of “cloud native” architecture, serverless computing with functions is arguably the most important and is quite different than server-based computing. The architect needs to have a firm grasp of serverless computing in Azure. This would be higher on the list, but it is not necessary for the initial move to Azure.
Hybrid. If you are moving an existing system to Azure, some elements of the system will be in Azure and some components of the system will likely remain on premise initially, at least for any non-trivial system. Azure supports a huge number of features for hybrid development.
Design Patterns. When we think about design patterns, we often think about the 23 patterns initially published in the book “Design Patterns”. While those design patterns have withstood the test of time, the concept of design patterns is broadly applicable to many different software design domains. There are a large number of general cloud design patterns and specific Azure design patterns. While you don’t have to master these patterns, it will help produce better designs in many ways. More importantly, it is generally expected that architects will be very knowledgeable about such design patterns. Microsoft has a catalog of such design patterns available at https://docs.microsoft.com/en-us/azure/architecture/patterns/
Monitoring and Auditing. Monitoring and auditing are part of DevOps, but architects do need to be familiar with it because you cannot reasonably bring up a new system on Azure without at least cursory monitoring. More information is available at https://docs.microsoft.com/en-us/azure/azure-monitor/continuous-monitoring
Networking. Networking is a big and important aspect of Azure, but architects can reasonably assume that there are IT personnel in the organization that are taking responsibility for networking. Nonetheless, architects need to have at least a rudimentary familiarity with Azure networking because you can’t use Azure without setting up the networking first. As a minimum, architects need to understand the network topology and terminology.
How do I get Microsoft Azure?
For individual developers, new registrants receive a $200 platform credit applicable toward any Azure service, excluding third-party offerings in the Azure Marketplace. New users can register here.