Those of you who know me know that I have been focusing on the adoption of Microsoft Azure since before it was actually called Azure (Circa 2008) when I originally stumbled upon it while working as an Architect for Microsoft. Since I had previously worked as a consultant to Bell Labs on the ill-fated AT&T NET1000 Cloud project as documented in The Slingshot Syndrome: Why America’s Leading Technology Firms Fail at Innovation) I immediately recognized its potential.

Since then we have seen a lot of companies adopt Azure and have helped many of them make the jump. Recently our focus has also skewed towards helping companies that may have jumped into Azure without adequate planning to remediate their architecture and their implementation.

Our experience is that it is very easy (perhaps too easy) to get into Azure without a well-thought-out architecture and a good plan. We cannot fault Microsoft for making it as simple as possible, however it is very easy to do it without adequate planning. In our InfoQ article The SaaS Development Lifecycle we outlined how a company should approach their first Azure project. Although published in 2011 IMHO it is still valid today.

At some point you will realize that you may have created what Grady Booch has called an “Accidental Architecture” or what Eric Evans and Brian Foote have called “A Big Ball of Mud”. 

Azure Accounts

Note that there are typically two ways to experiment with Azure. Recently Azure introduced a simplified Free Trial model that give you access to a limited number of Azure resources over a 12 month period, some free resources indefinitely and a limited amount of Azure resources that burn-down against a 30 day allocation of metered usage.

The other way is to have an MSDN subscription which includes a monthly amount of free Azure resources as part of that subscription.  Since the Free Trial only presents a very limited set of options compared to an MSDN subscription, and since we want to discuss not only experimentation but real infrastructure and applications in Azure, we will use an MSDN subscription in this post.

You should also note that there are other non-Trial and non-Free pricing plans such as Pay-As-You-Go and Enterprise Agreements that are more relevant to production architectures.

The “Easy” path

As an example, let’s take the easy-path scenario.

You sign up for a free trial using your personal credit card and telephone number. (Just needed for identity verification, of course.)

Next you create a VM in Azure taking most of the default values presented during the creation process. You are amazed at how easy this is to do.

Naming conventions are important.

You would never think of creating a physical or virtual machine on-premises without paying some consideration to a sensible naming convention. Take the same care here. The naming convention should take into consideration the type of resource (VM) as well as additional characters that serve to define the purpose and (perhaps) location of the VM. (The challenge here is to do this within the VM resource naming limitation of 15 characters.)

By the way, note that the VM here defaults to SSD (Solid State disk!). If you are just experimenting you should quickly change that to HDD to save money (or reduce free trial resource consumption).

Resource Groups are important.

Next you will be asked to specify the name of an existing or new resource group. Here a naming convention is also important and you should lay out your resource groups based on a naming convention that takes into consideration the purposes of resource groups. 

Over time there have been three purposes for Azure resource groups identified:

1. As a LifeCycle container for resources that have the same life-cycle; which means that they contain resources that are normally created and/or destroyed together.
2. For Role Based Access Control in the case where different departments in a company need to exercise control over a subset of all resources. An example might be a Network Management group that needs to “own” all network related resources in Azure.
3. For Billing and Charge-back purposes; although the need for this has been largely supplanted due to the use of Resource Tagging as a Billing and Charge-back mechanism.

Save money with Hybrid Use Benefits

If you have on-premises licenses for Windows Server you may be able to take advantage of a substantial discount (up to 40%) by applying your Hybrid Use Benefits (HUB). See the “Save Money” section above.

Choose a VM size

Next you get to choose the VM specs that you want to allocate. If you neglected to change SSD to HDD you can do it  here.

Although Azure only presents you with a few choices here you can see them all by clicking on the “View all” link. There are a lot! Pick one.

The next page is very important.

Availability Sets

Creating an Availability Set in Azure in order to maximize your service level and avoid downtime is a great feature of Azure. If you are just experimenting it is OK to leave High Availability set to None. In a production environment you will want at least two VMs in an Availability Set to maximize availability.

Managed Disks

Managed Disks great option. In most cases you should let Azure manage the storage for the VHDS that back the VMs that you create.

Network Considerations

Network Considerations are extremely important. In a production architecture you need to be explicit about your subscription (or subscriptions) as well as the environments that you want to support. Over time we have come to adopt a model that has a single subscription with VNets defined by environment (Dev, QA, Prod, DR, etc.).  Then each VNet is broken down, in turn, into SubNets for architectural tiers and specific purposes such as network gateways. You should give some detailed thought to this design.

All other items on this page should be given specific names rather than taking the defaults.

Before moving on pay particular attention to the Auto-shutdown feature. As you can see in the example the VM will be automatically shut down by Azure at 7PM. This is great feature to prevent burning through resources that you forgot you allocated. Turn it off if you don’t want that to happen. (It will not be restarted automatically the next day.)

At the end you will see an excellent summary of what you are about to create. Until you click on Create you haven’t created the VM.

What’s next?

Based on the above experience you start migrating servers and applications to Azure. You don’t spend much time thinking about things like naming conventions or other architectural considerations such as organizing resources into well managed resource groups.

At some point you will run out of your free resources  and change it to either a pay-as-you-go subscription or one of the other subscription types such as an Enterprise Agreement.

At this point you may not even be worrying about cost. That is until you get hit with the first bill from Microsoft that demonstrates the penalty for sloppy planning and careless resource utilization.   (BTW: In Azure, unlike on-premises, you can  save money by shutting down VMs when they are not needed.  In one case we were able to save a company 40% of their Azure spend by identifying resources that could be shut down when not in use and automating that shutdown.)

Conclusion

As a consultant I can’t complain too much about this state of affairs, since we are often asked to come in, assess a client’s Azure architecture and make recommendations on how to remediate it. Sometimes the restructuring can be minor. In other cases, major surgery is required.

In subsequent blog posts we will discuss the better way to Adopt Azure or to remediate what you already have in Azure.  We will discuss how to perform a Current-state Assessment of your infrastructure and applications, develop a Migration/Remediation plan, as well as how to assess whether to retire, replace, migrate or reconfigure your current infrastructure and application resources.

Until then.

Bill Zack