January 5, 2015

AWS and making better software in less time

Written by

We want it better quicker cheaper, but that costs a bit up front.

In todays rapidly changing online world the demands on software development are increasing. Time to market, minimum viable proposition and shippable product are all terms that are regularly used. All this really means is:

– I want to get something out as quickly as possible.
– I want to spend the least amount that I can to get something out the door.
– Despite the above two statements I want high quality, reliable software.

Based on the better, quicker, cheaper mantra (which conveniently ignores the time-cost-quality triangle) how can we achieve this and how can AWS help?

I know this is the same as that and why it is important.

Getting software to production is less about writing code, but more about testing code. Assuming that we have sensible and well-understood requirements (something for another blog) it will be possible for developer(s) to write code that we think meets the requirements.

The next step is to test that what was written actually works as expected and where changes need to be made this can be done in an efficient manner. This involves a series of tests starting with unit tests and expanding through various test cycles. When defects are found updates are made and pushed through more tests.

Some problems are code related and some problems can stem from ‘environmental differences’. These problems are time consuming as code that works in the development environment may function differently in test and so on. If we can remove the environmental issues then the issues raised in testing are all ‘real problems’. This means that developers can work on fixing actual defects rather than trying to work out what is a real problem.

The way that we can remove environmental issues is a combination of two things:

– Programmatically building environments using tested, source controlled build configurations
– Taking advantage of the AWS architecture to create dynamically scalable environments

The development environment should [logically] look like test should look like PVT should look like UAT should look like production. The only difference between the environments should be the amount of computing resources allocated.

It should be possible for developers to create and destroy local sandbox environments (in the cloud) that are the same as the environments that the code is tested in or running in production.

This means that the only defects found should be real defects.

With AWS the use of cloud formation and similar tools to create environments allows the concept of ‘infrastructure as code’ to be implemented.

Using virtual private clouds (VPCs) with AWS allows non-public addresses to be used so environments can be genuinely identical.

There is an up-front cost in defining the environment build process. Once this is in place development, testing and deployment becomes a much more streamlined process.

Security is important from the start

One additional thing to consider is security. Typically the development environment tends not to use SSL between web servers, application servers and databases. This usually results in testing problems – (It works with SSL turned off) or development problems – (I have to write it differently with security turned on).

Having a common security implementation that addresses the needs of production means that security can be baked into solutions from the beginning. The things that need to be part of the standard environment builds are:

– Secure all communication with SSL/TLS between all nodes
– Encrypt data at rest where appropriate from the start
– Run your own Certificate authority for non-public facing infrastructure

More on security specifics in a later post.


– Programmatically building environments allows code to be developed, tested and released without losing time due to environmental issues.
– Take advantage of dynamic scaling to ramp up (or down) the load capability of your environments.
– Bake in security from the start.


Categorised in: Devops, Technology

This post was written by Paul Hawkins