Deploying web apps at Substrakt
Deploying highly-available, redundant and responsive full-stack web-based applications is not easy. But we’re pretty good at it.
First off: Hi, I’m Max. The new Senior Developer at Substrakt. My expertise are in native iOS development (Objective-C) and web apps (Ruby on Rails) as well as knowledge of DevOps tools such as Ansible and AWS which is what this blog post is about. I love writing code, developing in an agile way using test-driven development, continuous integration and I love teaching others to code. That’s enough about me, you can find my bio on my blog.
As a very experienced developer friend of mine once put it, in no uncertain terms: “Computers are hard.” He’s right. Long gone are the days where we deploy software by distributing CD-ROMs or buying software from retail stores. More and more applications are dynamic, complex websites but the software has to run somewhere! Generally web apps running on full-stack frameworks such as Django or Rails run on ‘cloud’ servers.
“But everyone uses the word ‘cloud’ now. What does it actually mean?”
For our purposes, a cloud server is a virtual server that acts just like a physical server. They’re usually owned by a one of a handful of cloud service providers (Amazon, Rackspace, DigitalOcean, etc.) They take advantage of their economy of scale to offer dirt cheap servers on a humongous scale. For example, all of Netflix’s infrastructure is actually run on Amazon cloud servers. That’s right; Netflix don’t physically own any of their own servers!
At Substrakt, we take much the same approach. We develop our web-based applications using Django; a full-stack web development framework written in Python for “perfectionists with a deadline”. Django is great; it lets us write modular, well-tested and easily maintainable code but we need somewhere to deploy it. Just like Netflix, we use Amazon Web Services to deploy our applications. We use several of the services provided for different purposes.
Elastic Compute Cloud (EC2)
This is the heart of any cloud-hosted web application. EC2 provides virtual servers on which to run the applications. Each server is referred to as an ‘instance’. They typically cost pennies per hour and allow for quickly scaling by only using resources that we need at that particular moment in time.
Simple Storage Service (S3) and CloudFront
Elastic Load Balancer (ELB)
Each of our applications has at least one ELB. This distributes traffic evenly between EC2 instances so that they do not get overloaded during a spike in traffic.
Relational Database Service (RDS)
This is where the data is stored. We keep it separate from the main application server to avoid issues. If an application server fails, we can just turn it off, spin up a new one and point it at the existing database, minimising the risk of having a single point of failure.
Elastic Beanstalk (EB)
Despite the odd name, Elastic Beanstalk is a state-of-the-art deployment platform that lets us write applications that scale from tiny applications with 1-2 users all the way up to huge multi-server infrastructures with no fuss. It monitors the application and starts new EC2 instances if traffic gets higher or deletes them if traffic slows down ensuring that we only pay for servers that we actually need. Elastic Beanstalk is the glue that sticks all of the other services we use together. EB lets us deploy once, twice, thirty or a hundred times a day. Each deployment takes ~20 seconds and so we can be constantly showing our clients the awesome work that we do, allowing us to constantly get feedback and to improve.
tl;dr – Deploying web apps is tricky. We use Amazon to do it usually. It’s slick, awesome and makes everyone happy.