Enterprise Software in the Cloud: Why We Chose Azure as our First PaaS Platform
I’ve been absent from the blog too long, but if you’ve been following my colleagues (Mary and Marilyn) postings, you’ll see it’s been a very busy and fruitful time at PatternBuilders. While I’m still overdue for the next segment of the architecture blog series, I thought I would take a break and talk a bit about some of the things we learned as we moved our product and business model to Microsoft Azure.
As someone who has worked with Microsoft technology and partnered with them off and on over the last two decades (even flirting with going to work for them a couple of times), the most surprising discovery was how serious Microsoft has become about the cloud, open source, and being an active and supportive partner for startups. As many of you who have been around as long as I have will no doubt remember, this is a very different, some would say revolutionary, move for the world’s most powerful proprietary software company. We had some concerns when we became members of Microsoft’s Azure Startup program BizSpark Plus and subsequently the more exclusive BizSpark One, but it has turned out to be a great experience for us on both the business and technical level.
On the business side, Microsoft has bent over backwards to make the Azure platform affordable for us during our transition from on-premise and more traditional IaaS (infrastructure-as-a-service) vendors. This wasn’t unexpected, since before we joined BizSpark Plus, we did an exhaustive study of all the options available for us from both IaaS and PaaS vendors. But beyond the better business terms and proactive support around both marketing and sales, we found that the Azure platform was better suited for our real-time, big data analytics solution for a number of reasons: particularly IO stability and ease of deployment. We also appreciated, since we are bootstrapped, that Microsoft saw our potential even though we didn’t come attached with a big name VC.
On the technical side, of course, the choice we made at the inception of the company—developing on the .NET platform—made using Azure a good fit. However, since we are heavy users of MongoDB on Linux VMs, we needed a platform that supported both a PaaS and a heterogeneous IaaS.
We started our development on .NET 3.5 and VS 2010 and what Microsoft has done with .NET 4.5 and Visual Studio 2012 has done nothing but confirm our initial bet. As a company, we pay a lot of attention to the state of other frameworks and languages, particularly around the areas of web scale, highly distributed, and near real-time highly concurrent programming. In those specific areas, I don’t think that we could have made a better choice, particularly given the turmoil caused by the demise of Sun.
Oracle’s takeover of Java took an already fractured Java community with an increasingly dysfunctional standards process and turned it into a community under the control of a single despotic overlord. One, by the way, who doesn’t seem to be particularly interested in making Java into a 21st century programming environment. And though they are very productive, none of the newer dynamic languages that have risen to prominence recently are the right fit for the sort of product we are building. There is some interesting stuff out there like GO! from Google but they are all still too new to bet a business on.
The existence and health of a Linux based .NET (Mono), Microsoft’s new friendliness towards open source, and the huge pool of skilled .NET developers makes .NET (the jury is still out on Windows 8) the low-risk choice for ISVs. This is despite some truly nutty anti-Microsoft technology bias, some of which we refuted here. Before everybody goes crazy and starts calling me names, understand that I started programming on a VAX, did C++ for over a decade, and was using Java before it appeared on magazine covers. In other words, I am NOT a Microsoft fan boy. But I am willing to acknowledge Microsoft’s huge lead in development tooling and the cohesive nature and very high quality work that has gone into technologies like SignalR, Powershell, MVC 4, Task Parallel Library (TPL), TPL Dataflow, and OData – all of which we use heavily and that are particularly well suited for the types of problems we solve. We firmly believe that the combination of the above has allowed us to leapfrog our big data competitors who are mostly still stuck on some version of a traditional Java stack.
All of this would be amazingly cool, even without the Azure platform. But when you toss in how integrated Azure development has become with Visual Studio as well as the ability to mix cloud services with both Linux and Windows Virtual Machines, you start to get an amazingly productive development environment. One of the things that has amazed us about the Azure / Visual Studio combo has been how seamlessly you are able to deploy complex cloud services. In point of fact, it is much easier to deploy to Azure than it is to Windows Server 2012/IIS. On top of that, the Azure emulation environment, works extremely well – although if you have more than 5 roles doing serious work, you need a really big dev machine.
One nice thing for ISVs is that the intense competition between AWS and Azure not only has benefited us all in terms of better pricing, it has also led to technology innovation. For example, one of the reasons that we chose Azure was because their IO was more predictable in our tests than AWS. But in a recent discussion with AWS, they told us about a new feature (new to us anyway) called Provisioned IOPS that promises predictable performance for IO intensive operations. That, combined with DynamoDB and its pay-for-higher-performance database model, shows that continued innovation by the major cloud vendors will allow ISVs to delight customers for years to come.
A shout out to David Makogon and Neil Mackenzie of the ISV developer evangelism team at Microsoft for highly useful and unbiased architectural advice. You helped us solve some very thorny problems and it’s much appreciated.