Take It or Leave It!


A client approached me recently wanting to move their entire infrastructure to the cloud. Besides the need to follow the hype of the cloud, I also understand such requests from clients in this country, especially considering the costs associated with maintaining a decent server room. Considering the lack of reliable electricity, the CapEx and OpEx to be spent on power systems to compensate for that, as well as the cooling requirements for even the smallest server room, is quite a handful. This poses a threat for almost any small business nowadays (which is what the majority of businesses around here are by international standards), especially in a country where most of the local software houses are still coding in a “legacy” manner (to put it nicely). So we have a market producing legacy client/server applications that require locally hosted servers, and a national infrastructure that justifies cloud migration more than any I’ve seen to-date.

I dove into my research to try and find a solution to this issue and resolve my client’s pains. Now, I’m the first to say that migrating an application to the cloud isn’t a simple 1-2-3 process, which is why my very instinct was to tell him “Ditch this software and find something that’s web-based.” Unfortunately that’s not a viable solution (as expected) since the software happens to be at the core of their operations, and so changing it would imply some serious downtime, and a learning curve to follow that with the new software. My only option—if moving to the cloud is absolutely essential—would be to find some sort of a migration tool/method.

Enter, Microsoft’s RemoteApp!

Microsoft RemoteApp Logo

I remembered reading about a product that can virtualize applications in a manner that would have them run on a remote server, while appearing as if they’re running locally. This is exactly what RemoteApp does! It presents an app to the user on almost any client device, as though it were a native app not their device, when it actually is a confined remote desktop session to the window border limits of that app on a remote server. Sounds like such a sweet solution, right?

Thank you Microsoft!

I loved it, I got excited, I even spun up a few Windows Server 2012 R2 instances on AWS to try it out. Lo and behold, it worked like a charm. I was able to load a native Windows application, which was running on a virtual Windows Server 2012 instance, locally on a MacBook Pro, on a Windows 7 machine, and even on an iPhone and also an iPad Air. The techie in me was extremely satisfied, however being a solution architect I also had to consider the other side of the story… the $$$!

So once again, I dove into my research to figure out if this solution is even financially viable; I’ve had a run-in with Microsoft licensing issues in the past. Let me just say, Microsoft Licensing is no walk in the park. To be honest it’s surprising that anyone dares to purchase their software without having a lawyer look over their user-agreements first… it’s INSANE!!! I even came across a whole blog that is solely dedicated to explaining the different licenses for different Microsoft products and the different use-cases. So if someone says you can write a book about that, they aren’t kidding.

Thank you Microsoft!

What I came to find from my research was quite a disappointment. Microsoft have a license that they call a “Client Access License”, which by definition is “a license that gives users and devices the legal right to access Microsoft server software installed on a (Windows) server”. Great, so not only do you have to fork up the $$$ to purchase the software, and the license to run the software, but you also need to pay for every user that needs access the server in your organization. You know what else? They’re not even cheap (close to $100 per user/device). So let’s say that you are running Microsoft Server 2012 R2 as a Domain Controller; apparently every user in your organization that needs to login to their domain-joined PC will need to be accounted for with a User CAL. While I was aware of this business model (that I am not a fan of whatsoever), I came to find out that it doesn’t even stop there. Apparently there are different flavors of CALs, depending on the service that you want to run. So in order to run a RemoteApp infrastructure in the AWS cloud, you would need to purchase a User CAL for each user that will be accessing the hosted application; this flavor of CAL is called the Remote Desktop Services (RDS) per User CAL. And to add to this, it will cost you approximately $120 per user CAL per year. Let’s put these numbers together:

Assume we have 10 employees in a local small business, and they want to run a RemoteApp in the cloud, to save on investing in local server resources. The RDS licenses needed JUST to run the RemoteApp will cost them about $1,200 per year. You know what’s great though, RDS doesn’t work without Active Directory, and it needs to run on another Windows Server. So that’s $10 per User CALs just to be part of the domain, and of course you can’t forget that every instance of Windows Server in the cloud is costing you an hourly (or annual) fee. A Samba4 Active Directory hosted on Ubuntu Server for approximately $75 per year isn’t sounding too bad right now, is it.

Alternatives???

I figured, what the hell, let me check out Microsoft Azure’s offering of RemoteApp, I’m sure they’ve gotten agile enough to decrease prices for such a deployment. Lo and behold, I was wrong, yet again. To run a single RemoteApp on Azure (assuming the cheaper, “Basic” package) your starting price is $10 per user per month, or $120 per user per year. With 10 users we’re back up to $1,200 per year. Now to add to that, you only get 40 hours worth of access time to app, and anything beyond that is billed hourly, up to a  maximum of $17 per user per month, or $204 per user per year… That’s $2,040 per year for a SINGLE RemoteApp. But that’s not where the catch is, and this is my favorite part… For either the Basic or Standard package of RemoteApp on Azure, you will be billed for a base of at least 20 users per app, so in the best case scenario you’re forking $2,400 per year for a single RemoteApp on Azure. So much for an alternative!

What started off as an exciting venture, and possibly a noteworthy solution for a number of local firms to circumvent the realities of our national infrastructure turned into a whole new can of worms in an endless labyrinth of user licensing. It’s no wonder that Microsoft is so wealthy on paper, and there aren’t even any ways around it, because at the end of the day it’s a Windows app that needs to run on a Windows Server that needs to be accessed by multiple users.

What to do???

With no alternatives to the RemoteApp solution, and with Microsoft hoarding the market with its recursive licensing schemes, you really get the sensation that Microsoft is telling its customers, “Here is our solution, it will cost you quite a bit, so take it or leave it!” Coming from an open source background, I find all these licensing terms to be relatively irrational. But when a company practically owns the market (as Microsoft does), you can’t really argue with them. It’s times like this when I wonder, how is it possible that the open source community did not sky-rocket yet.

So in conclusion, this all boiled down to one solution that is even remotely cost effective. That is to work together with the company that developed the original application in an effort to port it to becoming a web-based app. Now if I can convince them to move it over to becoming PHP-based (or any other open-source language), or even run ASP on Apache with mod_mono, then we’ll be in serious business.

Advertisements

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s