I was recently chatting with a good friend of mine who’s very highly placed in the Microsoft SQL Server team. Our conversation was wide ranging and covered a lot of topics, such as internal features and upcoming announcements. (I’m under at least three different NDA’s. So don’t expect me to give up anything too juicy or gossipy.) For example, we spent quite a while discussing the ton of great new features and improvements just over the horizon with the recent release of SQL Server 2014 CTP1.
But one of our topics of discussion really surprised me – the big upsurge of adoption in WASD (Windows Azure SQL Database, the artist formerly known as “SQL Azure”). Again, I can’t betray any confidences. But the number of customers, size of their installations, and amount of business that WASD is generating were all far above where I expected.
Since many big organizations are successfully migrating to WASD, I thought I’d cover some hallmarks of the most successful applications and databases residing on the Microsoft cloud that I’m aware of:
- Reverse-order architecture: Many on-premises applications I’ve worked with started with end-user mockups, screen demos, and requirements docs describing what the end-user needs. While this is still important, the end-user component of cloud apps has no physical cost beyond building the front-end. For example, there’s no cost to deploy a new version of a cloud app, since it’s basically just a website. The vast majority of cost for cloud apps is in the CPU and IO consumed by the application running in cloud. That means that application architects need to start first with the data architecture and data movement. A client-server app might not care that it takes 350 calls to the database to launch the startup screen. But, for a cloud app, each of those calls has a price. And it adds up quickly! Similarly, an app with poorly written SQL code might not be too big of a deal in a local client-server deployment because LAN latency masks slow query speed. But with the cloud, any extra CPU the SQL statement consumes is just going to cost you more. So adjust your design process accordingly.
- Last considerations become first considerations: In the previous bullet point, I mentioned calls to the database as a specific consideration. In fact, many aspects of a database application that are often taken for granted must now become top of mind if you want to successfully deploy to Azure. For example,
- Network latency: If you’re used to on-premises applications, you normally never think twice about network speed. But now, it had better be one of your first considerations. For example, how close is the cloud data center? If you have users in Singapore, the U.K., the U.S., the Netherlands, and India while the data center is in the U.S., you’d better do some planning! In fact, the most successful cloud applications build their entire design anticipating extremely limited network bandwidth. If you can make it work over low bandwidth, then you’ll save yourself a lot of heartache later on in the deployment process.
- Rampant roundtrips: If you’re considering using an application development framework to build a cloud application, think twice. Many frameworks, such as nHibernate, naturally default to multiple database queries, when a smart human SQL programmer would get the needed info in a single query. In fact, the smart money spends a lot of time figuring out not only how to reduce multiple transactions and data calls into a few, but also how to pre-calculate and cache as much work as possible.
- Backup and recovery: WASD has a variety of high-availability and recoverability features built-in to the product. But many IT shops don’t fully understand the differences between the on-premises approach to B&R and the cloud approach. Learn about cloud backup and recovery before the application is even developed, so that you can fully leverage one of the clouds strongest value-adds of having data available all the time, every time.
- An API mindset: The Windows Azure cloud has built up a strong third-party ecosystem. That means you can often buy and integrate offerings from other vendors, on the Azure DataMarket, into your own application. For example, if you wanted to add data quality services to your cloud application, a quick search at http://datamarket.azure.com/browse/data?category=dqs could easily fit your needs. The more your Azure application can hand off data through an API-like approach to its various components, the more likely you are to exploit the offerings of other SaaS vendors.
These are just a few high-level considerations that, when applied early to a new Azure application, can help ensure its success. Of course, there are many individual tasks to each of my earlier bullet points. You can drill down to get more details about how to tackle some of these low-level considerations using these resources:
Finally, I wanted to offer a special thanks to Dr. Greg Lowe for providing some much needed inspiration for this article. See his post at http://sqlblog.com/blogs/greg_low/archive/2013/07/09/is-there-more-to-using-sql-in-azure-than-redirecting-your-connection-string.aspx for more discussion about the challenges of deploying on WASD.
Follow Kevin Kline on Twitter and Google.