11 problems with AWS – part 6

Today’s issue may also be described as a great opportunity. Deploying applications to AWS requires that developers lift their game. I’m a systems guy from way back so I’m sceptical about the ability of development teams to change. I’ve seen a lot of dodgy code. The problem is that AWS forces change on you as a developer, and there are many development groups who won’t be able to.

A few years ago Platform-as-a-service providers such as Heroku and Engine Yard started appearing that would only concern themselves with application platforms. The entire infrastructure stack, including hardware, operating systems, middleware and databases, were managed by the cloud provider.

In response to this, Amazon created Elastic Beanstalk which manages the deployment, capacity provisioning, load balancing, auto-scaling and monitoring of your application thereby behaving as a “PaaS-like” service whilst still leaving you with control of the underlying infrastructure. It’s also free.

Amazon have done a lot of work to minimise the transition costs of applications from internal IT To AWS by providing integration with popular IDEs such as Eclipse, and support for common languages such as Java, PHP and Node.JS.

Despite all this there are some gotchas that need to be overcome. Your development teams need to overcome these or the benefits of AWS and cloud will not realised. In no particular order:

1. Amazon Auto Scaling allows application infrastructures to scale up (for days when marketing has done their job) and down (for night time). Therefore applications must be stateless and handle fluid creation and destruction of application servers. Previously an in-house deployment would be pretty static. Developers will now need to “get” what load balancing and session persistence mean. There is little point developing for AWS if you don’t use Auto Scaling.
2. Amazon integrates CloudFront and Caching services for better performance of static objects and applications with a high read requirement. Content Deliver Networks (CDNs) are also used to distribute static objects closer to the end user wherever they are globally. Internal IT Infrastructure teams have typically managed application caching but this now needs to be considered and understood upfront by the development team.
3. Amazon provide a Relational Database Service (RDS). Effectively Amazon becomes your DBA. Any application performance issues relating to the database tier can typically be hard to analyse. Development teams will need to be cognizant of database performance issues.
4. Amazon provide a bunch of other native services such as Amazon Fulfilment Web Service (FWS), AWS Identity and Access Management (IAM), Amazon CloudSearch, Amazon Simple Workflow Service (SWF), Amazon Simple Queue Service (SQS), Amazon Simple Notification Service (SNS) and Amazon Simple Email Service (SES) that need to understood to be exploited by developers. This also represents a kind of vendor lock-in that makes extraction from AWS difficult.
5. Amazon provide a detailed API for creating and managing Amazon instances. The developer can now manipulate these objects as part of the deployment cycle or even as part of the application. SDKs for most major languages are available that allow deep integration with native Amazon services such as DynamoDB, EC2 and S3 directly. APIs provide great flexibility but your developers need to understand how to exploit them.