building easel.ly

Referring to Instagram’s stack and what they used… (http://bit.ly/ZmX6l6) Their model is fairly complex, although much of the article talks about the tools they use to monitor and configure their system. The fundamental approach is how it’s distributed and written using the right technologies.

With easel.ly we were completely undergunned having just Pat and me. (Pat managing all marketing, business, networking and raising capital, while myself creating the actual product). At this point it’s a constant battle with both time and money. Writing your platform the correct way is essential for any small company to be successful.

easel.ly and its stack.

We chose to go the Cloud Computing route using Amazons Web Services. Easel.ly being a bootstrapped company, AWS allows us to scale horizontally both up and down. With a few clicks we can drastically change our instance(s), volumes and the way we distribute them, enough said… We looked into a couple different Cloud Computing Services including Heroku and Google App Engine. Heroku being built upon Ruby and seems to be mostly used with Rails applications while GAE is still very much a work in progress. Both these services can be cheaper but the learning curve and lack of documentation helped make our decision.

AWS is an interesting creature and it’s hard to put into words how advanced they have become over their competitors.

Easel.ly is using a Medium-M1 EC2 instance running an Ubuntu Linux distribution from an Amazon AMI. Besides installing a handful of libraries for image manipulation and transformations we really didn’t have to mess around with our distro to much. We have played with Amazons Elastic Load Balancer and in the future will most certainly make use this fulltime. ELB detects when easel.ly is under significant stress and shifts to other instance(s). Similarly a couple clicks to setup CloudFront will help with content delivery reducing web latency for faster response times in specific parts of the world.

Naturally our web server is Apache, although with more resources we might have looked into a few alternatives. Easel.ly is pretty light on the backend and Apache seems to carry more unneccesary weight then some of its counterparts.

For Data Storage we currently run two mySQL Databases, abstracting our users from their created content as best we can. These run on Amazons EBS (Elastic Block Storage) service. Currently setup under a 100GB volume. Originally we used RDS (Amazons Relational Database Service) which sit on its own endpoint however a good friend strongly advised us against it. RDS having more network latency, a 4/hr a week maintenance downtime and more cost then EBS. We also setup a 4GB swap file for our instance. A Large-L1 EC2 instance would no doubt temporarily fix our problem but with limited cashflow an L1 isn’t in the cards right now. Swap space can keep a system running when quickly overloaded but used incorrectly can severely impact system performance. (we have seen both these scenarious)

Anything actually created using easel.ly (both Visuals and the JSON behind them) we save to Amazons S3 storage with its absolute path stored in EBS. This allows us to have significant traffic without tying up bandwidth or taxing our instance(s) with S3 managing most the heavy lifting. A users created visual can be viewed 100,000 times without easel.ly ever even noticing.

For DNS record management and email routing Amazons Route53 did the trick. Cheap and simple.

To backup easel.ly Amazon makes it extremely easy to take snapshots of EBS backed Instance(s). Interesting enough Amazon uses their own S3 service to store snapshots incrementally. For testing and new development we spin-up a new Instance from a snapshot allowing us to mirror our production Instance. We can quickly setup a new dev-box endpoint through a temporarily allocated elastic-ip.

Front-end

Besides a modest amount of PHP and a handful of AJAX calls, most of the work is done on the clients browser. Easel.ly is built upon HTML5, Canvas and a lot of JavaScript. Creating in easel.ly is done using Canvas, for us its pros heavily outweighed its cons over its near cousin SVG. We have seen a slew of Canvas and SVG related projects lately in the startup scene. With Flash slowly being phased out, Canvas and SVG are quickly corner-stoning their stake in web 2.0.

Testing…

We have tried a handful of server tools, scripts and the like including Amazons CloudWatch. The clear winner is New Relic, a fantastic server monitoring tool. It’s easy to setup as a deamon and captures all types of server and browser events. I highly recommend it!

Refactoring and rebuilding… Some of easel.ly most likely will be rebuilt. Hindsight says Django / PostgreSQL over PHP and MySql. Nginex instead of a sluggish Apache. Still not sure how stable Fabric.js runs on Node.js but throwing this on a separate box to handle image processing and speed up save times might make sense in the near future.

Looking back there are many things that will change with easel.ly but at a high level our foundation stays the same. If your also a bootstrapped company trying to put a dent in your respective market we would love to hear your thoughts on what you have learned.

Leave a Reply

Your email address will not be published. Required fields are marked *