Microsoft Azure is accelerating past every other cloud infrastructure provider. Amazon, Apple, Google, Rackspace, and all the others are being left in the dust.
If you want virtual machines Amazon is the big dog. And there’s a lot of major players here, not just Microsoft, Apple & Rackspace but all the usual suspects including AT&T and IBM. And this is irrelevant. While virtual machines will continue to see a lot of use, they are an obsolete technology surpassed by PAAS and SAAS. They’re also a commodity that you can easily move from one vendor to another, a recipe to a race to minimal profits.
Our experience developing Enforced Vacation (EV) opened our eyes to this new world. We figured at first we would use a hosted VM and throw SQL Server and IIS on it. That’s what we had done in the past for hosted apps and it does work. But we had selected Azure (because Microsoft has been very transparent when they hit issues). And we found all these other services in Azure.
Ok, so looking at what is offered we figured instead of a VM we would use a SQL Database and a website. That way we could scale each by changing settings and did not need to administer a VM, Windows, SQL Server, & IIS. Straightforward shift, but with this we had moved from purchasing VMs to purchasing services. This is a substantial shift and one that once you have done it, you’re hooked. The ease of scaling the database and web service up/out, while not having to screw around with keeping them up to date and running is a gigantic shift.
As we started diving in to using this we asked Microsoft support questions. Lots and lots of questions. Starting with basic ones and from those diving in further. (I don’t care how stupid I sound from asking questions, I want to fully understand how best to do something.) And from this we learned – a lot.
We need to update the database based on activity. We can do that on each call to our service, but that slows down the response time. We’d always used a worker thread in our IIS app but that is problematic when you have multiple instances that can be spun up, because what can be spun up can also be spun down and that’s a problem. So Azure has worker roles. This are essentially worker threads, but each runs in its own VM and has a controlled shut down process.
You need to communicate with the worker threads, and for that they have queues that persist their data and can be written to and read from by multiple services. So each web service writes its update data to the queue. This is very fast and so has no impact on our service. Each worker role can read from the queue and so one of the roles reads the message and writes that data to the SQL Database.
This is a small example of the beauty of the set of services Azure offers. By using two simple specific services we could simply and safely update our database in a way that did not slow down our response to users querying EV. And Azure has this architected in a way that is infinitely scalable. Larger queues, more requests, just spin up more worker roles.
As we progressed we discovered more services that help, some we’re using now and some we’ll use if EV is successful enough that we have to scale out. Cloud services is a raw network server, that you can write for using ASP.NET. We use it for our IMAP network services. Traffic Manager will send requests to the closest server we have running. Redis provides caching of objects across all of our services. Web jobs is great for the nightly billing processing. And the list goes on (DocumentDB is solely for storing JSON documents – talk about specific functionality.)
What makes this all work so well is each service in Azure is designed to perform a specific type of task. By designing each to perform just one task, Microsoft has been able to design each to be simple to understand and use. As you understand each service you need, how to use it becomes natural. And that makes it easy to split out how you architect your app.
Equally important, architecting a cloud app correctly requires that you embrace delay and failure, not fight it. A query against a database might take a minute (the VM its on is rebooting due to a service pack). A data center might be down and services there are unavailable. Your app might be so popular requests to it have to be throttled (please, please let that be the case with EV). You might have 100,000 web services all running at 100%.
All of Azure is architected around this. It gives you the tools which not only helps you handle the problems you get in the cloud, it forces you to embrace architecting your application to work well in the cloud. This is why Microsoft is coming to own the cloud. It not only gives you an incredibly well designed toolbox of services to create a well architected cloud app, it guides you into creating an app that works well in the cloud.
Once a developer understands what they can do with Azure, and why that is so valuable to them, Microsoft has them. I can’t imagine going back to using a VM. I can’t imaging going back to using just a web service and database. As Microsoft grows the number of Azure services from 15 to 50 to 500, how will the other out there ever catch up. They could, Amazon, Apple, & Google in particular have very talented people. But I don’t think they’re even aware that the future, even the now, is no longer VMs and web servers.
Microsoft also has another giant advantage – they “get” developers. Better than any other large company. Far far better. The support from Microsoft as we’ve learned Azure has been superlative (especially the SQL Database group). They need to educate developers on how to best use Azure to pull more in, and they’re doing it really well.
Microsoft may be losing in social, search, & mobile, but they’re well on their way to owning the cloud server stack.
If you've just discovered us, we're excited! Try Windward with our 14-day free trial and start creating documents in quick time with our low/no code solutions.