This is part of a series on Building an Azure Dev Test Lab for software development.

What is Azure and why use it?

What Is Azure?

Azure is more than a marketing term. Today (2023), Azure has grown to ~487 categorized services (some duplicates) to cover a large range of business services.

• General (18)
• Compute (28)
• Networking (24)
• Storage (15)
• Web (16)
• Mobile (3)
• Containers (7)
• Databases (21)
• Analytics (15)
• AI + machine learning (26)
• Internet of things (25)
• Mixed reality (2)
• Integration (26)
• Identity (23)
• Security (23)
• Devops (8)
• Migration (8)
• Monitor (11)
• Management and governance (27)
• Intune (4)
• Hybrid + multicloud (15)
• Other (132)

Focus Business Resources on the Primary Business

Small companies don't have the overhead to hire teams of people just to manage infrastructure. When you migrate to Azure, you have a team of people that manage the security, infrastructure, wiring, power, internet connections, monitor and fix hardware, for all your Azure services. Yes, some amount of time from business resources are needed to create users, set permissions, set policies, but the additional people (or hours) needed to manage everything is all covered by the Azure hosting fees. Microsoft can scale and achieve productivity at a scale small and medium business can't touch.

Availability and Reliability

Microsoft provides between 99.9% to 99.99% Service Level Agreement (SLA) depending on the service tier [4]. Free services have no SLA. Availability of 99.9% translates into a maximum downtime of 8 hours and 46 minutes over the course of a year and 99.99% translates into a maximum downtime of about 53 minutes per year.

Hidden On Premises Costs Covered by Azure

Real estate, buildings, building maintenance, property taxes, electrical costs HVAC costs, hardware amortization, are all covered by the costs of the Azure fees. Because the Azure systems are done at a large scale, there is significant cost savings compared to what a small or medium business could do standalone. Azure also provides the ability to scale systems almost instantly, thus saving time. Doing that with physical hardware takes time.

Standards Compliance

In today's world, there are numerous standards and compliance rules and policies organizations need to adhere to ranging from government regulations to industry guidelines. Global organizations delivering services to customers in multiple parts of the world have varying rules and regulations to follow. The Azure Security portal provides the heavy lifting and supporting documentation to help an organization begin the process to comply with those standards, including PCI, EU GDPR, SOC (1, 2, 3) and numerous others. The Azure Compliance Center [5], [6] provides over 100 compliance regulations for over 50 countries and regions. Companies still must ensure the solutions they deliver comply with those standards, but the Azure systems provide all the supporting documentation to ensure a company's hosted services are all in compliance.

Innovation and Leveraging New Technology

Imagine if you wanted to change all your web servers overnight to support .Net 7.0 what a large effort that would be. When Microsoft released .Net 7.0, the day of the announcement, Azure services were hosting .Net 7.0. Azure has had a very good track record of providing new features at a very fast pace.

Taxes and Financial Considerations

Traditional US Accounting rules required that when real estate, buildings, hardware equipment all had to be depreciated over the life of the equipment. That requires funding up front, and it can (usually) only be written off over time. By utilizing cloud-based services, a company can write off 100% of the expense in the year it is incurred. The term shifting from CAPEX to OPEX [3] is used to describe this.

Automation / DEVOPS

Microsoft has geared its entire infrastructure not just around a portion of what is needed to provide a web-based set of software services, but every single end to end detail from authentication, source control, static code analysis, testing, deployment, scalability, all at a scale we have never seen before in the software industry. By providing all the tooling for automating all those steps along the way, this can reduce costs, reduce the time to market, and increase overall quality.

Summary

Azure provides a wide range of infrastructure and services to cover software and services at a scale few companies can afford to own their own. By using that scale, it allows business to use their own people to focus on business problems and leverage the Azure systems and the supporting teams to provide those services. Azure provides extremely reliable Service Level Agreements, that even most small and medium business would struggle to achieve. Azure provides all the supporting documentation to help companies achieve regional, country, and industry standards. Azure provides new features regularly and rapidly. Companies can leverage other people's real estate, hardware, and employees by using, and take advantage of tax laws to improve financial scenarios when compared to an in-house data center. And lastly, Azure provides an end-to-end eco-system for automating all the steps of the software development and deployment process.

References

• [1] https://www.forbes.com/sites/forbestechcouncil/2021/03/12/why-migrate-to-the-cloud-the-basics-benefits-and-real-life-examples/?sh=2e3b7e275e27
• [2] https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/strategy/motivations
• [3] https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/strategy/financial-considerations/
• [4] https://azure.microsoft.com/en-us/support/legal/sla/summary/
• [5] https://azure.microsoft.com/en-us/explore/trusted-cloud/compliance/
• [6] https://azure.microsoft.com/en-us/resources/azure-enables-a-world-of-compliance/

On November 8, 2022, Microsoft released .Net 7. After getting Visual Studio Professional 17.4 installed, updating to .Net 7 was fairly painless.

Changing the obligatory TargetFramework entry in all the projects:

<TargetFramework>net7.0</TargetFramework>

Updating the package references from 6.0.0 to 7.0.0:

<PackageReference Include="Microsoft.Extensions.Hosting" Version="7.0.0" />

Updating the github action yml file to use the new dotnet version:

dotnet-version: '7.0.x'

Azure even had all the website hosting ready so I didn't have to wait for anyone to deploy .Net 7. Microsoft does list some incompatabilities in .Net 7, but it's not a long list. This has probably been the easiest migration since .net46 to .net48.

References

• https://learn.microsoft.com/en-us/dotnet/core/compatibility/7.0
• https://devblogs.microsoft.com/dotnet/announcing-dotnet-7/

Microsoft has a very large quantity of documentation on Azure. But most of those articles are focused on new large-scale production scenarios or migrating existing production scenarios to Azure. For a software development firm that is looking only to leverage Azure for software development and testing, and not expose public web services to the internet, where does one start?

The Microsoft documentation that I've read leads one to believe that it's a simple as just creating an Azure VM or an Azure Web service and you're done. The reality is there is much more infrastructure required to do that. This series attempts to put together a roadmap or summary of some solutions aimed solely toward software development for Enterprise services and applications. You may find it helpful for preparing your Azure migration or if you have some services in Azure extending it.

Assumptions

Azure is a big world. To narrow down the scope of things, I'm going to create a narrow set of assumptions to build a development and test lab in Azure.

• Software development teams are distributed in multiple locations in Europe, Asia, and the United States.
• There is an existing Windows on premises Active Directory system in place for Authentication.
• There is an existing Windows network system in place in at least three physical locations / offices.
• There is an existing Wide Area Network system in place between the physical locations / offices.
• There are existing file shares / network shares in place for software distribution and storage.
• The software development team utilizes Visual Studio 2022 Professional.
• There is an extremely large source code base in Microsoft Team Foundation Server.
• The development lab utilizes Microsoft Hyper-V Virtual Machines for dev / test servers.
• There is an extremely large code base of web-based services used for an Enterprise Suite of applications.
• Microsoft Office 365 (hosted in the cloud) is used throughout the company for email and team communication.
• All remote access to Azure systems requires Multi Factor Authentication.
• No "production" and no "public" facing websites, databases, or services.
• For Dev Test Labs, no load balancing or hot failover and no region failover.

Articles

1. Building an Azure Dev Test Lab - Why Azure
2. Building an Azure Dev Test Lab - Authentication
3. Building an Azure Dev Test Lab - Azure Devops Migration
4. Building an Azure Dev Test Lab - Data Centers
5. Building an Azure Dev Test Lab - Networking
6. Building an Azure Dev Test Lab File Shares
7. Building an Azure Dev Test Lab App Services
8. Building an Azure Dev Test Lab Virtual Machines
9. Building an Azure Dev Test Lab Remote Access
10. Building an Azure Dev Test Lab Azure SQL

In 2022, I decided to make a significant update the the code base and hosting platform used by this site. I decided to migrate to .Net 6 and host it on Azure.

I could have taken the old site to Azure, but I wanted to start with a cleaner code base. I removed some of the old dependencies, libraries and assumptions to lighten up as much as possible. A general list of the new requirements:

• Store content as XML or JSON.
• Do not require the use of a database.
• Provide support for as much of the original content as possible.
• Remove dependencies on third party packages as possible.

The main course of effort was the original site was written in ASP.Net Web forms. The new site was written in ASP.Net Core Razor pages in C#.

Some interesting points:

• Start: 2022 06 10
• End: 2022 07 31
• 32 days of working changes, a few hours on nights & weekends
• Occurred over 50 calendar days
• The equivalnet of about 15-20 full time equivalent working days
• 15,552 Lines of Source Code
• 4,438 Lines of Executable Code
• Go Live: 2022 08 28

Here is a summary of some of the key points of the new site:

• Developed using Visual Studio 2022
• Targets .Net 6
• ASP.Net Core Razor Pages
• Content / object model is all XML based
• Supports pages, posts, tags, categories, authors, and site statistics
• Uses Azure DNS
• Uses Azure App Services / an Azure Website for hosting the site
• Uses GitHub Azure integrations to publish software updates to Azure
• Uses prism.js for code formatting
• Uses tinymce for content editing
• Uses bootstrap for a CSS styling.
• Some moving parts were greatly influenced by Miniblog.Core. This site is not a derivative of Miniblog.Core, but I did use some of the ideas as a base for this sites code base.
• The Table Of Content generator leverages the HtmlAgilityPack

A few things about Azure I learned along the way.

Pick carefully what Azure Datacenter you want for hosting. Not all Azure Datacenters have the same features, or the same pricing and you cannot easiliy mix parts from other Azure Datacenters. For example, once your publishing a site from Github to Azure, moving that Azure Website to another Azure DataCenter basically requires configuring everything back from scratch.

Using an Azure Static Website is really for a "static" site. A dynamic site that runs ASP.Net Core isn't suited for a Azure Static Website.

Using GitHub actions to publish to Azure is a timesaver. However, each action stores the result as storage, and if your not careful, very quickly you will exceed the 500 MB storage limit for "free" GitHub repositories.

Azure App Services provide several layers of scalability for the Azure Hosting Plans.

Using Azure App Services / Azure Websites for a Developer Lab Instance provides a free hosting service (F1), an SSL certificate, and is extremely helpful for go live preparation. The D1 service plan provides the bare bones minimum to host a non azure domain name.

You can't get an SSL certificate (even if you buy one) on a custom domain name on the F1 or D1 service plan. Microsoft tells you that a B1 service plan or higher is needed.

The D1 service plan provides:

• 1 GB of memory
• 240 minutes / day compute

The D1 service plan is more than enough power to drive this website. It uses about 250-350 Mb of memory (everything is store in memory since there is no database). Because everything is stored in memory it barely uses any compute time.

The positives of moving to Azure App Services:

• Github Actions to publish to Azure is a great timesaver.
• Azure DNS is much easier to administer than other DNS services I've used.
• The minimum D1 plan is still screamingly fast.
• The Azure monitoring provides some usefull analysis tools.

The only negative I've experienced so far with Azure is that it tries to steer the creation to a default S1 plan. If you accidentally setup an S1 plan, and remove it from you site, you still pay for the plan until you remove it from the subscription. If you don't pay attention, you can quickly run up a hefty bill. Few people really need an S1 hosting plan to start a small website.

This site (tim-stanley.com) was first started in February 2006. It first went publicly live October 8, 2007. The engine used to power this site was used from 2006 to 2022. The main technology really hadn't been modified since 2010. Not bad for a sixteen year run.

In 2022, this site was updated, but this is a summary of the underlying technology that powered this site for sixteen years.

Original Site Platform

• ASP.NET 2.0
• .Net 3.5 SP 1
• Visual Studio 2008
• C#
• Windows Live Writer Build 12.0.1366.1026
• Windows Live Writer Code Snippet Plugin Code Snippet download Polaroid Picture Plugin
• XML based content
• SQLite based DB (for content and relationship data)

Original Blog Platform

The site utilized BlogEngine.Net with several Extensions. Some custom controls are used on a lot of the pages.

• Content Management System - BlogEngine.Net
• Table Of Content Generator [ tocautogen ] extension by Klaus Graefensteiner
• Most Popular Posts extension and TopPosts control by Al Nyveldt
• Copy Code To Clipboard Extension by Troy Goode
• Social Bookmarking extension by Danny Douglass
• Icons from IconGalore, FastIcon, IconDrawer, WebDesignerDepot and Artura
• Background image from AbsoluteCross.com
• Custom Control for ArchiveList - sortable grid layout of contents
• Custom Control for Contacts - allows positioning the contact information in a page instead of a specific link.
• Custom Control for Flickr Slide Show - via Paul Stamatiou
• Custom Control for Simple Viewer Photo Gallery via Airtight Interactive.com
• Custom Control for Page Includes
• Custom Control for Page Layouts
• JQuery Snapfish menus

As I developed one site, I had another, then another, then another. Before long I was spending more time applying patches / changes to the main code base and distributing it to all the sites than I was on content. That lead me to try to focus on one code base for multiple websites and that eventually led to a multi-tenant solution.

The main portions of BlogEngine.Net provided a solid basis, but it was heavily modified to support a multi-tenant blog platform. That meant some pretty significant changes to the model and code base. What was left had it's origins in BlogEngine.Net but it was pretty significantly different than BlogEngine.Net.

When running a service under IIS, the HttpContext.Current object is not available, so HttpContext.Current.Server.MapPath will fail.

fileName = HttpContext.Current.Server.MapPath(fileName);

The solution is to use Hosting.HostingEnvironment.MapPath instead.

fileName = System.Web.Hosting.HostingEnvironment.MapPath(fileName);

ASP.net has that neat little feature where all the controls can start with <asp:.  It makes it easy to code.  I had numerous custom controls and I always had to register the control on each page to use it.  Scott Guthrie had a great tip on how to register the controls in the web.config file so that it doesn’t have to be done in each page.

I’m really surprised I haven’t read about this earlier.

References

• How to register user controls and custom controls in web config