AWS can be a Differentiator
Updated December 20, 2013
AWS can be a Differentiator
Score 9 out of 10
- Route 53, ELB, EC2, EBS, S3, SES, RDS, CloudFormation
- AWS constantly innovates and iterates, announcing new features several times per year. Earlier this year, for example, they introduced provisioned IOPS for EBS, suddenly providing us with an inexpensive solution to a performance quandary we'd been facing.
- AWS has provided us with access to the product owners and architects of the products we use most. In turn, those resources provided us with visibility into the product road maps. This enabled us to improve our long-term infrastructure planning, and avoid expensive features that we'd get for free later in the year.
- AWS peremptorily lowers costs a couple of times per year. This has helped us keep our bill reasonable even as we consume more and more of the AWS services. We periodically compare the cost of AWS to the cost of moving into our colo, and every year the colo looks less and less attractive.
- Occasionally, we disagree with their roadmap priorities. For example, we really needed Content-Based Routing added to ELB to support our multitenant implementation. The AWS architects agreed that it was a mainstream, valuable request and hinted that they were trying to get it onto the roadmap, but 15 months later there's still no sign of it. I'm sure they have their reasons, but it's a strange and annoying hole in an otherwise invaluable service.
- AWS has had well-publicized outages that have broken the promise of true zone (datacenter) isolation. This was supposed to have been impossible - if you had instances running in two zones within a region, you thought had a solid survivability story. We were forced to react by building out additional redundancy that increased costs beyond our original design estimates. AWS claims to have resolved the problem, but we haven't been confident enough to spin down the extra servers yet.
- There are annoying resource limits, presumably in place to prevent hackers from allocating huge numbers of resources on a compromised account. The problem is that raising the resource limits requires manual action to be taken, and can have a severe impact on production software if your ops team isn't meticulous in checking the limits. As of the last time I checked, these limits weren't available via API, making it impossible to create alarms whenever we get close to exceeding our resource limits.
- AWS is relatively infamous for their poor communications during outages. Their status page will occasionally go without an update for 45 minutes, while half your customers are dead in the water. This is - obviously - infuriating.
- AWS's autoscaling capabilities allow us to automate the provisioning and deprovisioning of hardware in response to demand, allowing us in turn to lower our hosting bills and increase our margins.
- AWS's APIs are comprehensive and well-designed. They have greatly assisted our devops team in the building of tools that have enabled a wide range of operational improvements, including zero-downtime upgrades which benefit our customers directly.
- AWS's friendly administrative panels make it easy for developers to spin up and connect the resources they need to test prototypes and develop innovative solutions quickly. This has increased the velocity of our development team, and helped us turn around architecturally complex features very quickly.
We are almost entirely satisfied with the service. In order to move off it, we'd have to build for ourselves many of the services that AWS provides and the cost would be prohibitive. Although there are cost savings and security benefits to returning to the colo facility, we could never afford to do it, and we'd hate to give up the innovation and constant cycle of new features that AWS gives us.
- The AWS forums are well monitored and very helpful - go there first if you get stuck and you'll get long, detailed answers from AWS representatives who will follow the conversation and come back for follow-up questions.
- AWS is tight-lipped about roadmaps until your bill reaches a certain size (for us, 2 years ago, it was at about $50K/mo that we started getting access to the people who really knew what was going on.)
- Development uses AWS to develop, test and prototype infrastructure stories. With access to the same images that exist in the production environment, developers have confidence that features built in the development environment will work the same way in other (i.e. production) environments
- QA uses AWS to spin up instances of feature branches, test them, and spin them back down
- Devops manages the various AWS environments, and uses the AWS APIs to build deployment and monitoring tools
2 - We have 2 senior devops engineers that maintain 4 AWS 'environments' (dev, qa, perf, prod). The administrative consoles are good enough for basic maintenance, but most advanced work requires that they be capable of scripting interactions via the APIs or CLI. CloudFormation is good at building stacks, but is insufficient for real configuration management, so chef or puppet skills will also be important.
- Development - easy access to hardware and networking resources enables innovation.
- QA - easy access to environments that mirror production enable on-demand testing at the feature and/or system level.
- Production - sophisticated Disaster Recovery, Business Continuity, Performance and Scalability features help us meet SLAs and keep our customers happy.
- Professional Services - easy access to environments that mirror customer environments enable ad hoc customization testing.
- Autosizing - runtime customization of resources like IOPS and storage, combined with the ability to easily upsize and downsize a server has enabled us to build servers customized for its purpose, removing the need in many case to decide between function and cost.
- AWS added the Simple Email Service (SES) shortly after we first migrated, allowing us to get rid of our mail server and all of the maintenance and support overhead that it caused.
- AWS Elasticache - we are currently caching in MongoDB because it was just as fast as our old memcached server. We will probably move to elasticache soon, lightening the load on the database and - possibly - increasing performance.
- CloudFront - we have not needed it yet, but the easy integration to CloudFront will be very attractive when it comes time to commit our assets to CDN.
Evaluation and Selection
Rackspace loses to AWS on both features and price, and their reputation for top-notch customer service just doesn't make up for it, especially if you have talented ops resources who find themselves rarely dependent upon support channels. Even when they do, AWS has a very active user community and very active forums where authoritative responders answer questions at all times of the day.
- Product Features
- Product Usability
- Product Reputation
Price is always a factor and usability is obviously important. The broad feature set made it feasible for us to build complex architectures in the cloud. But it was Amazon's reputation that sealed the deal. It's reputation is solid and so well known that we sell it in sales calls to this day. When customers want to hear about ISO 27000 certifications that we just don't have, we talk about Amazon's certified datacenters instead and -- maybe surprisingly -- this generally works.
Since I'm happy with how the process turned out, I wouldn't change much. If I were going to change anything, I'd look less at the ancillary services that we could build ourselves relatively easily, and concentrate on the core value propositions of a public cloud, which -- to my mind -- are the API and the provisioning capabilities. AWS would win anyway, but for different reasons.