When I started my career, I had no focus on infrastructure at all. The work in commerce was a typical set of features where I would implement some logic that would help produce an automated solution to electronic signatures for licensing agreements between Microsoft partners and customers. As a software engineer, I did not bother myself with the behind the scenes essentials to run a web service or site because it just did not interest me. Many software engineers try to focus our work on the features which are core to the business and when we encounter this other work such as setting up foundational components we cringe.
I remember days in my commerce team where we worked with service engineers. For those who don’t know what a service engineer is, they typically operate and maintain the online service. I’ve had the pleasure to work with some great service engineers. At the time I was assigned someone who made you feel like you are hand holding an experienced professional through their job. I was working on a new Azure web service responsible to produce and maintain the agreement documents for customers. It was based on a new Azure technology called Azure Web Sites and it was going to make team’s work much easier to produce the solution we needed. It turns out that it was much easier to develop and deploy my code to this platform compared to previous Azure Cloud Services. When the time came for production we had to deploy to multiple regions and introduce a traffic manager for failover situations and simple latency improvements.
Adding this traffic manager created my headache. The service engineer at the time did not understand why the browser would return a big red error saying the web site is not secure but it would be secure when you went to the site directly at WestUsSvc.azurewebsites.net. Well, you can read all about TLS protocols and understand how the server will provide a handshake to your browser but I will save you some time. He needed to provide a certificate with a subject alternate name to support the svc.trafficmanager.net.
This means that we need to provide certificate(s) and set up them up for HTTPS for the service. There are a few options to do this:
- Provision a single certificate that supports the union list of these 3 names.
- Provision 2 certificates with the region entry plus the traffic manager entry. (Preferred / Recommended)
It was a very odd situation because there was no web site or pages to be viewed in the browser. So, there was no real practical reason to address this issue. However, with anything, I suggest you take it as a teaching opportunity and help the service engineer. I showed him that he must create these certificates and installed them for SSL in the Azure Web Site.
Moral of the story
The moral of the story is that you should involve yourself in the infrastructure even if it’s not pretty or sexy. It keeps the features running and it’s critical to your success. In more recent days we build off these common problems and address a lot of the manual work of managing these problems. I’ll explain in another post how we can get our hands off these manual processes and leverage our wok in the Azure / Microsoft stack. If you are interested in the history of Azure Websites take a look at ScottGu’s blog post from 2015.
Stacking Opportuntity 