DNN Evoq on Azure? Not So Fast …

17 July, 2013 CloudContent ManagementDNNDotNetNukeEvoqSoftwareTechnologyWindows

Five Things Everyone Should Know First

Microsoft has spent a ton of money and time on Azure and they have done a pretty good job of hijacking the term “the cloud” as well. I do not want to take anything away from their accomplishments: they are very close to achieving a limited version of grid computing. Grid computing is a great solution for certain CPU/IO related tasks, however, when deploying websites on a grid infrastructure, there are important potential issues that you should be aware of.

1. Grids: A World Without Backups With Azure, You're On your Own

Grid-based infrastructures treat resources similar to the way that most people treat electricity: we might have redundant power grids and we might have a battery backup for our mission critical device, but nobody ever worries about having a copy of the electricity that comes over the power lines in an emergency. Grid based systems have no backups.

In fact, Microsoft will be the first to tell you this:

“A backup and restore strategy is a necessary [sic] to protect against data loss. The built-in fault tolerance capabilities of Windows Azure protect your data from individual server, network, and device failures. However, in order to protect your data against user or application errors, or a total loss of a region, you must create your own backup of the data.” [Emphasis Added]

Ref: Microsoft Azure Policies – viewed July 13, 2013

Fault tolerance is different from backups. Fault tolerance protects against simple things like a bad hard drive or a failed NIC. Backups protect against things like a failed upgrade or accidentally deleting the wrong file. You need both fault tolerance and backups.

With Azure, if you make a mistake, you are on your own.

The team at DNNCorp has tried to mitigate this by implanting an “in sever” backup and file export function in the DNN Platform and Evoq products.  But this is a far cry from a professional, regularly scheduled backup and restore policy to a distinct server NAS that is designed for complete data protection and point-in-time restoration (this is so important that we have an entire set of documented policies and a white paper on it).

2. The Pitfalls of “Unlimited” Scalability Blog Text Box 2

Often times grid providers talk about scaling an app “from one server to thousands of servers.” This sounds great, but what does that really mean? How will your site perform and what will it cost?

In order to provide that “unlimited” scalability, grid providers allow resource fragmentation. Even at Azure’s exorbitant prices (see below), the only way they can make their margin is to pack interconnected servers and racks as full and as tight as possible. So, when you order more resources, what happens? Bits of CPU, RAM, and disk are accessed from other virtual servers. Those servers may be in the same rack, the rack next door, or theoretically across the datacenter. This is why when a single rack goes haywire it can bring down an entire region—impacting thousands of sites (as has happened on Azure a few times already).

There is another thing about fragmentation that you should consider—performance. Just as a fragmented hard drive slows down file access and overworks the drive, resource fragmentation adds latency. Firing up even a simple DNN website takes literally tens of thousands of interactions and the farther apart the resources are from each other, the slower the end result will be.

As you scale over time, you might find that—in addition to the direct cost increases—you pay an additional price in performance.

3. Not “Really” DNN Anymore … nor is it Evoq – Speaking with a “Forked” TongueDo You Want Forked Software?

Most of the time, a software company works very hard to avoid “forking” a software package. Maintaining two packages in parallel is difficult at best and almost never fully successful—at some point a feature or function usually ends up missing or different from one or the other branches.

DNN Corp has recently rebranded and retooled. Now you can get the various flavors of DNN—including DNN Platform, Evoq Content, and Evoq Social—in both Professional and Enterprise versions. But you can also order “Evoq in the Cloud,” which are versions of the paid-for software installed and hosted on Azure. Importantly, they are specially modified versions—meaning that they are different from the other ones sold or for free on the DNNSoftware website.

This makes sense at one level in that it can take a bit of juggling to make an application that is designed to run on a single cloud server run reasonably well spread across an unknown number of servers or resource sets. But any good website developer will also tell you that this can present some major problems: captivation and migration being the two biggest ones. If you are launching/building a brand new site, you may not even notice … at first. But:

  • If you ever think that you might want to migrate away from Azure for growth or cost reasons, keep that in mind.
  • If you want to migrate into Azure, it is problematic from the get-go.
  • And finally, if you want to build a skin, module, or architecture once and use it multiple times, consider that building “for” Azure carries its limitations.

4. Azure Uptime: You did maintenance when!?!

Turns out that all of those interlaced server racks sharing resources is pretty complex. Faults and failures in one area are magnified to impact far more sites. Even Microsoft itself clearly states that their uptime SLA is only 99.9% for caching, Content Delivery (CDN), Media, Mobile, and SQL Database. Datacenter pros call this “3 nines,” and unless you are an internet professional, that sounds pretty good. If you are an internet pro, you understand that this is at least one full order of magnitude less than industry standard. It means that Microsoft allows nearly 9 hours of unplanned downtime per year without violating their SLA. For Virtual Machines (VMs) and Cloud Services, their number is about half that—4.4 hours per year. There is anecdotal evidence that they have struggled to meet even these marks.

Most cloud hosting providers set the mark at less than 53 minutes of unscheduled maintenance per year—ten times stronger that Microsoft’s Azure SLA.

Ref: Microsoft Azure SLAs – viewed July 12, 2013

In addition to that, consistent performance has been a continual problem for Azure. Would you want someone rebooting your server in the middle of the day? Believe it or not that happens all of the time on Azure. At any point throughout the day, your services on Azure may be “recycled” (a fancy new marketing term for a “super reboot”). Azure doesn’t give you a warning or let you stop it. When your customer asks why their website was running slow or was unavailable, you may be limited to saying, “Azure might have been rebooting our server, but we’re not quite sure.”

5. Cheaper … Not! Azure is Expensive

This one confounds me. Maybe it is because the marketing teams at Microsoft and Amazon are pretty good at their jobs, but resource-for-resource, Amazon and Azure are some of the most expensive hosting that you can buy anywhere.

We did an exhaustive cost comparison complete with references and screen shots for a white paper on the subject. But what it boils down to if that Amazon EC2 and Azure offer generally lower up-time SLAs, no backups, and higher  prices under a cloak of ethereal marketing hype for “the cloud” based on technology that is little different from that offered by other professional hosting companies. If you’re interested in reading the pricing comparison details—along with an architectural analysis—shoot us an email at: sales@powerdnn.com

Read for yourself. You make the call.

Again, DNN Corp has attempted to cover this on the short run by bundling Azure in with certain paid licenses—obscuring the related costs … for now.  But those costs are there.  I have been around hosting for some time and it is a common tactic to offer free or steeply reduced hosting when trying to break into the business and gain a few customers to test your new services.  But we are all smart enough to understand that nothing is free and that hosting costs something.  Every company that has used this tactic has had the strategy to bring prices up to market rates.  Indeed, that’s the whole point of captivation, right?  The most expensive cloud services available cannot keep their costs in the shadows for too long.

Thanks for reading.

(This post was our most-read of the year and stirred up passionscheers, jeers, and questions from the DNN community. Those questions and jeers deserved a response, So we followed up with a second post the following week.)

Microsoft, Azure, and Windows are trademarks of Microsoft Corporation [MSFT].
DotNetNuke, DNN, Evoq, and DNNSoftware are trademarks of DotNetNuke Corporation [DNN] – used with permission.
PowerDNN and the “Power P” logo are trademarks of PowerDNN.