Building for Amazon

Recently there has been a bit of comment from a couple of people around an article that appeared about using Amazon Web Services (AWS).

To be honest I'm more than a bit annoyed about how they were written up. The article made it sound like I'd given a talk about my use of AWS at work, or had helped write an article. I hadn't done either, but was part of a panel discussion around cloud. I do note that one of the other panellists was similarly written up too... Most of the article was from an answer to a question about what was good, and what was bad about Amazon with other bits picked out from other things. Some of it was not quite sensationalised and I didn't know the article was happening or a chance to review (something that has always happened before and I've spoken at around 20 events).

So first of all I want to go on the record and say I am a strong supporter of Amazon. They, Google and Salesforce are the companies who have done more than anything else to push cloud forward. Also anybody else who has heard me speak knows I am a strong proponent of AWS. Going forward though I think I'll just refuse to talk about any areas of improvement needed, but focus on the strengths. I have been in communication with AWS staff to tell them my view hasn't changed and I back them 100%.

So I'd know like to focus on what I was intending to convey, and did convey but wasn't reported, at the panel discussion. Building a system on Amazon does not mean that you stop making proper design decisions. Some people have assumed that because Amazon is such a great company that they can forget about system architecture and everything will be fine. You can't. You wouldn't build your physical machines or VMWare and not do backup, do no performance tuning, and have no redundancy. Most of what people use Amazon for is for running machines (They do do many other things too, like a CDN and NoSQL on demand etc). So you need to design your systems. I learnt this many years ago.

When it comes to performance you can't necessarily throw everything at it on AWS like you can with a traditional architecture as you don't know the full underlying design and you can't fix your bottle neck in a traditional way. But running your on-prem architecture in this way can cost you absolutely millions. There are numerous cases of media organisations, life science companies etc doing large batch processing for hundreds or thousands of dollars that they just couldn't do cost effectively before and to do it very quickly also. What you do need to do for AWS though is try and parallelise your workload wherever possible as Amazon works well in this model. You can also vary your machine size as you need to - and now Amazon allows 64 bit machines for all size types it makes this even easier, and saves more money. So you can go all the way from a free Micro instance up to new Sandy Bridge based machines without rebuilding your image.

Make sure with Amazon that you have machines running in another area as redundancy and you have a way of activating them. You wouldn't run your own data centres like this, so why do it differently on Amazon. The "horror" stories around when businesses struggled when an Amazon Availability Zone (AZ) went down are really a horror story about bad architects in my mind.

Backup. Yes, that is a command! Any IT exec who doesn't ensure that their data is backed up needs to be shot. Why should this be any different on Amazon? Firstly people had problems as they didn't realise that Amazon can lose changes when you do some kinds of restarts (as config runs in RAM in effect), then they didn't realise that only backing up in the data centre was a bad idea (EBS backing for the EC2 instance). Amazon do make it easy here as S3 allows you to do quick, cost efficient backups - how many other services are designed for 11 9s - that is 99.999999999%? Again, if you get data loss it is not Amazon at fault, but your architects.

Amazon do status reporting online here. Do you get that from your other vendors, or internally in your own IT function? AWS are to be applauded for their transparency. The one corruption event I referred to was documented on the status page (an EBS fault occurred). It should be noted that no data was lost at all from this as it was failed over to another system. I have had on-prem failures in the past where I have lost data or took a long time to recover. This incident was all sorted in less than an hour - AWS allows you to build solutions like this easier in many cases to avoid this problem having high impact.

So in short would I go with Amazon AWS again? Absolutely!! I have never had any significant downtime with them in my roles, and it has saved money and been extremely flexible.

NB This is all my own opinion, and not that of my employer - something I also said at the panel discussion but was also omitted.


Popular posts from this blog

Getting Apple USB Ethernet adapter working with Windows 8.1 (or Windows 10)

Setting up a Raspberry Pi 2 as an Access Point

Setting up a SoftEther VPN server for personal use