skip to main content

James Blizzard –

How we use AWS to manage our application services

All Blog posts
Computer code on a screen

At the end of last year, our flagship product Twine completed a migration. From Amazon to… Amazon.

Perhaps I should explain.

Previously our systems were all hosted on Amazon EC2. We had some servers running applications, some running searches, some running databases and so forth. We treated Amazon like a normal hosting company. There were all the usual benefits to this, we could quickly create new servers, add disk space, work out why our search server was running slowly and all the other mundane daily maintenance tasks you’d expect any software-centric company to do.

Early last year (2015) we decided that we needed to make some updates to our software stack and at the same time move Twine onto its own set of servers, separate from Browser. We brought in our DevOps specialist to help architect the change and help leverage Amazon Web Services (AWS) to focus our IT assets, you may have heard from him on our blog recently ‘How we autoscale our products with AWS‘. 

Amazon the force multiplier

Much is made of the scalability of both AWS and other platforms (Azure, Google, SoftLayer etc) but there are two other key points for us… managed services and automation tools.

The depth and breadth of the AWS offering mean that we can offload almost everything to services managed by AWS and the resulting change to our network setup is quite dramatic.

  • Instead of managing database clustering and backups, we let AWS handle it.
  • Instead of managing cache servers, we let AWS handle it.
  • Instead of managing clusters, Elasticsearch we let AWS handle it.

And I could go on.

We’ve reached a point where we can offload virtually everything that is not our core application to an AWS-managed service of some kind, and we’ve now begun moving parts of our application to services like Lambda. This allows us to go one step further and only pay for the compute resource when we need it rather than the “always on” approach of traditional virtual machines. Taking this concept further we are now able to use tools such as Cloudformation to automate the orchestration of the entire Twine stack giving us a dependable and repeatable process.

So…

If a client needs an entire copy of our Twine product hosted in China? No problem, give me an hour and it’s all set up.

Does a developer want to compare MySQL vs MariaDB, Redis vs Memcache? No problem, give me just a few minutes.

The impact

The result of offloading all of these services means that every single person in our team is able to focus on what we’re passionate about, the product. This way of working means we have more time to innovate and develop our product rather than devote time to day-to-day operations work.

The result

Exploiting these services allows us to truly deliver fast and efficient service, teams like ours can effectively supply innovative and reliable products to clients much faster than before.

If you’d like to read more about our web hosting and infrastructure James’ latest blog post details the results of our 2019 modernisation program.