This article is not what you think it’s going to be.
Earlier this week I ordered a Kindle from Amazon, their lightweight, purpose built, e-book reader. I bought one as increasingly more of the material I chose to read come as a PDF, whether it’s an Apress $10 e-book of the day or a downloaded PDF, however reading “books” on a traditional PC just doesn’t work for me. I can’t take a laptop everywhere I like to read, nor sit comfortably in a reading position with one. Amazon’s Kindle however is a handheld electronic device designed just for reading with; a screen optimised for fine print, a battery life of weeks and a screen contrast to make it readable almost anywhere. On top of that it can store thousands of books and using its free 3G connectivity I can get newspaper and magazine subscriptions to it.
I can hear some of you saying it now, “if you’re going to buy handheld device why didn’t you buy an iPad?” Although an iPad costs more it can do more. The reason I didn’t buy one was because the extra functionality comes at the expense of portability and simplicity. I want a portable device which was designed to be a master at the one thing I want, lightweight, functional, reliable almost dependable, and from a reputable vendor. Also, I wanted something I could use on public transport without being mugged for.
So what does the have to do with technology decisions in the mid-enterprise? My point is that we should think twice about whether we always need the “business class” option of having more features and scalability available to us than we immediately need. Sometimes having flexibility for the future comes at a price, whether that’s commercial cost, a larger exploit surface area or more installed components which need patching. At the same time future scalability needs to be considered; we shouldn’t implement something which would struggle to cope with our wildest of realistic growth expectations, even if they’re not used, businesses get nervous about that sort of thing. Good planning is a happy medium.
Microsoft’s SQL Azure advocate, Buck Woody, made some interesting points this week on Twitter related to this topic. He suggested that regardless of how large in total an operational database might be systems today typically have less than 4GB of operational OLTP data. This suggestion aligns with the positioning of SQL Azure in that although the service’s database sizes may look and feel too small for most applications today they’re actually perfect. It’s unlikely that a web based services application performing business transactions will ever need gigabytes of data immediately to hand, the large volumes of archive data will be kept in an OLAP optimised data store.
If Buck’s suggestion is correct then SQL Azure is perfect for this next generation of web oriented applications. Typically, what these applications require is a SQL Server compatible database engine, just fast enough storage, reliable Internet connectivity and programmability and management interfaces similar to what we’re already used to. This makes SQL Azure perfect for this task. What we must stop doing if we’re to benefit from this new era of technology, agility, rapid delivery and zero-management is comparing everything our on-premise services can deliver, regardless of whether we use everything, with what services like SQL Azure can offer.
Our requirements are often a lot less than we think they are, and we may be missing out until we realise that.