I’m a big fan of Microsoft Azure. When looking solely at the breadth of the product offerings and features from a technical perspective, Azure is far superior to its competitors.
From a business perspective, I'm also a big fan of the cloud in general. We have a server room here in the office at InterKnowlogy and it cost a fortune to build with raised floors and special cooling racks and such. It was originally stuffed to the gills with computers. It has fancy glass walls so office visitors can walk by and see all the fancy lights and multiple servers and go, “Ooh…” But guess what? That server room is now almost empty, is a complete waste of space, and has been that way for a while. All the servers have moved off-site, to some form or another of Microsoft Cloud (Azure and O365). The only thing left in our computer room is our phone system that we barely use because our business is building software, and a Windows server that hosts the domain controller and active directory. I’m told that even that server will move to the cloud soon.
There are just two major weaknesses that continue to haunt me about the cloud revolution. Let me detail them and see if you agree or are experiencing the same pain I am.
“The Cloud Requires an Internet Connection.”
It seems like such a simple statement. But the simple reality is that the majority of cloud solutions are dependent on an internet connection. I don’t know if you are familiar with the term Service Level Agreement (SLA), but SLA essentially encompasses the percentage of up time that a provider, no matter where they are in the stream, provides. Now consider a typical uptime guaranteed by a provider, 99 percent. That seems like a lot, right? But if you do the math, then 99 percent of uptime means you are going to be down for almost 90 hours during a calendar year. 90 hours! So, my guess is that, like me, you have been down at crucial points without internet access. I’m now infamous in my own office for saying, “There ain’t no cloud without local internet access.”
Normally, internet connectivity problems are the provider’s fault. Where we live and where our office resides, which is the 7th largest city in the Unites States, we certainly have frequent and significant internet access outages that prevent our provider from even getting close to the metrics of their guaranteed SLA. Of course, there is always some excuse, blaming an entity “upstream” whose fault it is or “local construction” or some other excuse. However, the simple fact is that we depend on internet access and sometimes it’s just not there. Internet access problems happen everywhere in the stream, too. Lately, we have been plagued with internal DNS and routing problems with our wireless network. It’s complicated with VLANs and routing and such. We depend on other partners for our network, but problems happen. When problems do arise, we can’t get to TFS in the cloud, so the process of building software breaks down.
“Azure: How Much Does it Cost?”
This also seems like a simple question, but it’s not, and let me be clear about it: this question strictly relates to an application built on Azure infrastructure. Figuring out the cost of Azure websites and Azure Virtual machines is a relatively straight forward process, but when you want to build an application and use Azure for your back-end and cloud services, the short answer to “How much does it cost?” is “It depends.”
The long answer to the cost question is related to the components of Azure that the application uses (SQL, Azure, worker roles, etc.), and how many of those components it uses. Herein lies the problem: you need a software architect to adequately estimate the costs of an Azure solution. This means that the architectural decisions that are made when building a cloud application in Azure can dramatically affect the cost of running that application. If you want to anger a business person, just try to explain that concept to them; I know it works, I've tried it before. I always get the same reaction: “You mean I have to depend on a technical person to architect a solution to be cost effective, and they still can’t tell me exactly how much it’s going to cost per month to run it? That can’t be true.” That’s usually when I sigh.
Titles like “Azure architect” and “Cloud architect” are being used liberally these days when describing roles in companies that build cloud-based solutions. I can't remember a time since my COBOL days when a software architect needed to care more about cost than about performance and scale. When I first started programming professionally, every compile cost money. If you had a syntax error and failed to compile, it was costly and you could potentially lose your job for a mistake like that. Can you imagine having to pay every time you hit F5 in Visual Studio? That is the way it used to be, and now a responsible Cloud architect needs to pay attention to cost just like we did 35 years ago.
Let me describe a real use case that will put this concept in perspective. The usage analytics feature of our interactive digital signage solution reports how the digital assets (videos, pictures, web sites, etc.) are being used and displayed. Some digital assets are manually navigated to in the solution by touch, by gesture, and by voice recognition with Kinect for Windows. We capture what is being looked at and how it’s being looked at. There are also campaign-driven advertisements that run automatically in what we call “attract mode,” which is really just a fancy screen saver. We capture every little thing that happens. The cloud architecture for storing that usage data in Azure is pretty simple:
- We have one cloud service that is the worker role
- We have one small storage service that is the queue
- We have one small Azure SQL database to hold the relational data
I won’t go into gory details, but I solicited the experts both at my own company, InterKnowlogy, and at Microsoft to figure out how much that would cost per month. I got the same answer:
“You let your application run for a month watching Azure usage closely. If your application usage is going to be consistent in its use, then you’ll be able to model the costs with relative accuracy.”
Obviously, that was not good enough for me or the business guy involved. So I modeled the costs with everything I knew and factored in the intangibles like estimating the actual use. I told the business guy, “I am 90 percent certain the Azure costs will be under $30 a month.” You can imagine what his reaction was. In reality, the first two weeks came in at $6.39 for the 5 kiosks we had in a test pilot. Excited, I told the business guy the good news about the lower costs. He came back with, “If 5 kiosks operating under an emulated load mode cost $6.39 ($1.27 per kiosk for two weeks) then wouldn’t our Azure costs be closer to $2.54 per kiosk per month based on the current? Is this the proper math?” I sighed and told him, “We really won’t know for sure until we model it after a few months in production.” Business guys just hate variable costs, and I hate explaining to them that “It is what it is.”
