Posts Tagged ‘aws’

Recently I launched a new website, Rena Men. It is deployed onto the Heroku platform and does quite a bit of cool stuff, so I thought I would document what I have done here.

Code

It is implemented in PHP, using the Rauma framework. Rauma is a project I developed for Learn Finnish and subsequently open-sourced.

Rena Men is built in several modules. There is a website, a content management system (CMS) and an image server. Because they use common functionality like the entity classes, there is also a shared library which is brought in as a Composer dependency.

The website itself is fairly straight forward. Beyond the PHP, there is only the CSS, pre-processed with SASS, and a tiny amount of JavaScript loaded in with require. The CMS is a bit more complicated, using Babel to transpile the ES6 JavaScript, and styled up with Bootstrap.

Deployment

Each module is deployed onto the Heroku platform. This makes it really easy to do as I can roll out an update just using git push. The code itself is stored in a series of private repos on BitBucket, and the Heroku build process fetches them from there.

In the case of the CMS, it also uses the Node build pack to run a Bower install. Third-party additions such as Bootstrap are pulled in on-the-fly just like we do with Composer dependencies. Heroku does not have SSH key integration for Bitbucket (it does for Github) so I’m using a ready-only account with Basic HTTP auth access.

The database is provided by one of the Heroku app add-ons. The storage is provided by Amazon S3. Heroku is built in AWS, so that fits nicely. We store originals in the file system and then crop them on-demand using the image server.

Delivery

Because cropping images is expensive, the image server originally had a local file cache where it would store each crop. However, as Heroku has an ephemeral file system, you cannot write to it, so I had to turn that off in production.

Instead, we’re using the AWS CloudFront CDN. This was super easy to implement. I just created the settings in AWS, pointed CDN subdomain at AWS and it started working. Like other web proxies, it caches your content based on the headers you send it.

We recently launched Village Chief, a Facebook game in which you take on the role of a local village chief with the aim of growing your community into a thriving settlement.

The project was designed from the ground up to be highly scalable – Facebook cames can go viral very quickly so you need a system which can scale up very quickly if your game suddenly becomes very popular, or you risk losing out on huge amounts of market capitalisation.

First off, it’s written in Ruby. Ruby is a cool scripting language that is similar to Python and it’s popular web framework Ruby on Rails has received a lot of praise being the framework that Twitter and 37signal’s suite (Basecamp, Highrise, etc) are written in. It’s a very forgiving language, even compared to PHP, so if you like your static typing consider Scala instead, but for rapid web development, Ruby is a gem.

Despite the popularity of the Rails framework, I was looking for something a little more lightweight, so Village Chief is built using Sinatra. The documentation is a little underdeveloped but is never the less sufficient to get buy and lets you get a web application up and running nice and fast.

Ruby also includes a great module system called Ruby Gems (spot the earlier pun now 😉 ), a system similar to PHP’s PECL. The game makes heavy use of these – for example, using Koala to interact with Facebook and Dalli to handle our caching.

For a data source, it made sense to use a NoSQL solution. I originally settled on Apache Cassandra. It doesn’t have the flexibility or functionally of Mongo but it terms of raw speed it’s hard to beat and scales onto multiple servers with eventual consistency beautifully.

When it came to deployment, I decided to go with Amazon AWS’s DynamoDB instead. I’ll discuss more about why this was later but this meant rewriting the database interaction. This was easy to do thanks to our database abstraction layer and allowed us to continue using Cassandra for our testing systems while rolling out the production environment on DynamoDB.

Some data was also rolled out using SQLite. This was used for data such as the product catalogue which doesn’t contain user data – just things you can buy. Keeping it in an SQLite database allows us get quick access while still being able to query against the records – and importantly, allows us to version control our product catalogue.

To keep the database load down, some of the sorting was moved into the web server layer instead. On top of this we built a caching system using Memcache to save a lot of the data in memory, thus making things much faster.

When it came to deployment, I decided that Amazon’s EC2 cloud. You can start up a new server in under a minute, which is fantastic for scalability. Thanks to Amazon’s Elastic IPs, you can maintain a set of public IPs and map them to any one of your EC2 servers.

The servers are based on the latest Ubuntu release and to make sure that they are delivering content at top speed, I choose to go with the nginx web server rather than Apache, which works in conjunction with Passenger to provide the platform.

One limitation of EC2 is that you either have to allocate EBS (Elastic Block Storage) which adds additional cost, or use the ephemeral storage which you lose every time you turn the box off. The solution? Put everything into an external database so that we can switch boxes on and off without a problem – hence the decision to use DynamoDB rather than running Cassandra on the servers.

Code is then deployed using Capistrano which goes onto each of the boxes and performs a structed deployment that you can easily roll back, pulling the code direct from our Git repository.

That is a whistle-stop tour of the technologies used in Village Chief. If you have any questions about any of them, feel free to post a comment.