Amazon Web Services
Kalen Delaney is having a tough time getting her arms around Amazon SimpleDB as a concept, and I hear this kind of question a lot. What is Amazon S3? What is Mechanical Turk? How do these things matter to a real business? I’ve got a story I like to tell around how to use these services, but for a couple of years I’ve held back from posting it publicly because I dreamed I’d build that business. Those days are over – I’m too comfy in my job to start a business, hahaha, so here comes the story!
Pretend We’re A Survey Company
I used to work for a hotel & restaurant survey company. Believe it or not, there’s good money to be made in comment cards, and it’s a much more complicated business than you might think. Turns out it’s also a perfect candidate for doing business in the cloud. Hotels are switching to email-based comment cards that lead to surveys on the internet, and it’s a whole new ball game.
Some of the challenges involved with running a survey company on the internet are:
Instant scalability needs. When you sign large hotel chains as a client, you don’t have the time or money to pour into more IT resources. The money won’t come in for months, but the data starts coming in right away.
Huge load fluctuations. Everybody wants their month-end reports on the first of the month, and everybody wants high-end analytics that require a lot of number crunching. You can’t precalc them ahead of time even on a daily basis because they rely on things like standard deviation, which have to be calculated on the whole set of results. If we build a datacenter to handle these needs, it sits idle all but two or three days per month.
Worldwide user base. Hotel guests all over the world take surveys around the clock. Throw in language barriers – not only do your surveys need to be translated into many different languages, but even the survey responses have to be translated back for the hotel staff. Hotels in New York City receive comments in many languages, but the hotel staff only speaks a few. Every comment matters, and we have to get them into a language the hotel can understand.
Diverse source systems. Hotels want their front office computer systems to drive the survey process. They want to send a survey to the guest the morning of checkout, automatically, without doing a lot of manual data shuffling. That means accepting a lot of data feeds in a lot of formats, parsing and importing those, and then sending out the surveys. We need a really robust set of pipes for our data.
Need to accommodate old-fashioned surveys – some hotels still use paper survey cards, or they might leave paper cards out on the desk for people who didn’t want to provide an email address. These paper surveys may get into our system via fax or via scanner, but the end result is always an image of a survey card. We need to parse that survey to determine who it belongs to, which checkboxes the user colored in, push the results into our database, and snip out the comment and contact areas to be manually transcribed by a typist. These results also need to get into our monthly (or daily) reports just like the electronic cards. Note that this makes our time demands even tougher – hotels will send in their paper comment cards on the last day of the month and expect them to be on the month-end reports the next morning. (Customers – the bane of our existence, right?)
Amazon Web Services solve these problems. It’s not the only solution, but it’s an intriguing solution. But let’s not get ahead of ourselves – let’s design our ideal solution first, and then see how Amazon’s services work.
Our Ideal IT Solution Includes…
If we could start from scratch, we would design a system that includes:
Services, not servers. For example, I know I’m going to be storing images from comment cards, but I don’t want to start guessing when I need to buy more hardware, and I don’t want to buy too much that sits around idle. I want a file storage service that charges by volume, because I can relate those costs back to specific customers easily. Heck, I can give a discount to customers who don’t use paper cards, or I can charge extra for paper card image storage. Want to keep your images online for six months? No problem – here’s the charge. (That service is Amazon Simple Storage Service.)
A data queue that scales. I want an Enterprise Service Bus, but without the crazy expense. I need to be able to have a queue that takes in hotel guest information from all my customers, and I’ll have servers handling those results. I need a queue that lists which comments need to be transcribed, another queue that lists which hotel results are ready to be crunched, and so on. I don’t need to handle them instantaneously – a queue rather than a database would be fine if it would save me money. (That service is Amazon Simple Queue Service, and it’s absurdly cheap: one cent per 10,000 messages!)
When I do need servers, I need to change numbers by the hour. When I can’t have services, like when I need to crunch complex information or when I need to import those paper survey images to determine which checkbox a user filled in, let me spin up and spin down servers with a mouse click – or even better, automatically via an API. I want to be able to code something that will check the incoming survey queue results and turn on servers to accommodate demand. (That service is Amazon Elastic Compute Cloud.)
A human translation service that scales. Machine translation sucks. Hard. It works great in theory, but it’s still not good enough to pass the sniff test by hotel general managers who speak multiple languages. They spot machine translations from a mile away. We have to use a human translation service that passes each comment through multiple people, and maybe uses a reputation factor to decide which translators are good (and therefore don’t need as much double-checking) and which ones are wasting our money. (That service is Amazon’s Mechanical Turk, perhaps my favorite of the Amazon Web Services.)
And finally, I need a database. I don’t have complicated data needs – especially once I brought in that queueing service, which takes a lot of processing load off. I just need to store basic data. It needs to handle a lot of throughput, but not necessarily have fast response times, because the heavy crunching is going on on my analytical boxes anyway. In a perfect world, I’d have SQL Server – but I might be willing to make compromises here if I can get the rest of my needs taken care of. (So for better or worse, that service is Amazon SimpleDB.)
Our Ideal Solution Doesn’t Necessarily Include…
And let’s take a moment to look at what we’re NOT including, because that affects our cost equation too:
Point-in-time auditing. I don’t need to restore my entire infrastructure back to January 7, 2005 in order to examine financial records. I need to be able to restore for disaster recovery, but otherwise, keep it simple.
Very high security. Don’t get me wrong, we need to keep one hotel from seeing another hotel’s data, but if they do, the world isn’t over. This isn’t financial data or personal health data. We won’t have anybody’s credit card, social security number, and we may not even need their address. Sure, we’ll have their email address, and we need to guard that.
High-end business intelligence. This solution doesn’t necessarily restrict me from data warehousing and analytics: if I want that stuff, I can bring the data over to my own datacenter to do it, or I could run BI at Amazon, but high-end BI isn’t my first priority. If I can get the rest of the solution right, I can live without it. (I can hear the BI people loading their shotguns now.)
AWS: Greater than the Sum of its Parts
If you look at each of the Amazon Web Services pieces individually, they’re nothing amazing. (Except Mechanical Turk – that is effing amazing. Check out the Sheep Market.) They’re just building blocks. They’re not as strong or as cool as the building blocks you might use internally already – but then again, we’re professionals at building stuff. Not everybody wants to hire an army of professionals like us to build out and maintain these systems.
I could get a survey company off the ground with zero infrastructure investment, and better yet, only pay for what infrastructure I need this month. If I only have one small client today, I only pay by the month for that one small client’s needs. If I sign Holiday Inn, I don’t sweat bullets wondering where I’m going to put all these servers or how I’m going to get the credit to buy them. I still need to architect my coding solution in order to maintain a big jump in load – but I’d have to do that regardless of whether I owned the hardware or not.
I’m not only a cheerleader, I’m a client. At SQLServerPedia, we launched a SQL Server tutorial podcast series. Visitors can watch video in their browser, subscribe with their iPods and Zunes, or download the files for local viewing later. I had absolutely no clue whether anybody would sign up, but I was faced with hosting the files. How big of a hosting plan would I need? What if I got too big of a plan, and nobody came? What if I got too small of a plan, and we got overwhelmed? How fast could I upgrade or downgrade the plan? Enter Amazon Simple Storage Service, or S3: I simply pay for what I use. We got almost 9,000 downloads in our first month, and I was completely surprised – I hadn’t even looked at the download numbers until the bill came in. (Seriously, people, stop watching videos and get back to work. Or play. Whatever.) We’re on track for 15,000 this month, and I haven’t had to do anything at all – Amazon just handles the infrastructure. Best of all, it’s cheaper than any podcasting service I’ve found!
It’s not perfect. My biggest concern as a startup would be lock-in: a lot of these services simply aren’t available from other vendors yet. If I code my solution to work with Amazon Simple Queue Service, and Amazon decides to crank up costs tomorrow, I have tough work ahead of me to build my own queue service or buy somebody else’s. But at the same time, if Amazon did that, there’d be a number of Amazon customers with that same business need, and someone would spring into action to service that need.
And yes, there are outages – you can track them in the CloudComputing:Indidents Database wiki at CloudCommunity. But frankly, the big providers are doing pretty darned well. When you factor in the peace of mind of not sweating over server firmware upgrades, air conditioning and power needs, and all the other “fun” involved with managing a datacenter, it can be compelling for business developers who just want to get their application seen on the web.
Learning More about Amazon Web Services
If I’ve whetted your appetite, here’s a few links I’d recommend:
And I’d even keep an eye on this here blog too – Amazon Web Services can offer value to us SQL Server DBAs, as I’ll be announcing in a blog series and whitepaper in the coming month.
Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.
Website - Twitter - Facebook - More Posts
