ActiveBlog

A Small Simple App
by Phil Whelan

Phil Whelan, May 15, 2013

A Small Simple App

This is a fictional story, based in reality.

It sounds as if the idea I have will work. Feedback has been good, and I did not get slammed on Hacker News. There’s a nice flow of people signing up on the landing page, so I think I should be able to get a few people kicking the tires as soon as I have something live.

It should only take me the best part of this weekend to get a simple version of my app up and start iterating, so let’s get cracking…
 
Write some code. Database schema. Add controller. Add view. jQuery. Backbone.js? Get some servers. Linode? AWS? Rackspace? Install software. Configure software. A bit of apt-get install, a bit of tar gunzip. Edit configuration files. Vim vim vim. Read docs. Setup nameservers. Setup DNS. Patch this, monkey patch that. Install plugins. Recompile. Hmm… iptables? Proxy server or load balancer? Nginx! I’ll need one of those. Inter-app communication? ZeroMQ? RabbitMQ! Do it later. Install a mail server. Hmm.. need more RAM? Read the manual. I should have RTFM earlier! Need backups. Rsync or snapshot? Both! S3? Better way? Write code for APIs. Go live. Private beta. “Out of disk space”. Oh no! Where’s my fstab? Mount. Unmount. Mount. Service restart. Sudo service restart. Sudo service stop. Sudo service stop. Kill. Kill kill. Kill term. Reboot. Wait. Serious down-time. Nobody has noticed. New email. “Dude, your site is down”. Panic. Read the docs. Re-configure. Vim vim vim. Restart, reboot. Seems to be running. Pingdom, Nagios, New Relic, Ganglia… Cannot happen again.
 
Google Analytics.
 
Traffic.
 
Traffic.
 
Good press coverage.
 
Traffic!
 
More press coverage.
 
Traffic!!
 
Traffic!!!!! Failing. Bad press coverage. Faster server? More servers! Doesn’t scale. Rewrite code. Migrate database. Deployment failure. Gem not found. Bundle update. Bundle install. Bundle exec rake bundle install!? How to go back?? Must go forward! Logs to big. Disk too full?! Logrotate. Gzip logs. Traffic!! Why is it slow? Bandwidth? TCP latency? Database queries? Which are my slow queries? Must serve images faster. CDN? CDN! CloudFlare? CloudFront? Cloud cloud cloud….? Have to stop hacking in production. How do I replicate this environment on my Macbook? Homebrew. Rvm. Or maybe Rbenv? Hmm… too many moving pieces. Everything is in different locations on my Mac. Where do I restart nginx? I need more people working on this. I should call Bob. How I do I quickly replicate this dev setup when Bob joins the team? I cannot remember what I did. I should write more things down. Bob is a Windows guy. How to set this up on Windows? Impossible! Can I afford to buy him a Mac? Maybe I should buy both of us Ubuntu laptops, so we can replicate our server setup. Site keeps crashing. Memory leak. Restart with crontab. Downtime during restart. Need redundancy! Master-slave? Master-master? Sharding? How to partition data? Need another rewrite. Maybe another datastore. NoSQL? No, SQL. Maybe SQL + NoSQL? Read the docs. Install software. Configure software. A bit of apt-get install, a bit of… wait! I think I’m in a loop. Let me think… Let me breathe…
 
There must be a better way
 
Why are things spiralling out of control?
 
It’s just a “small simple app.” I want it to become a big app, but not at the expense of scaling this complexity. 
 
People deploy applications all the time. Smart people. They must have invented a better way to do all these repetitive tasks. What are the options for deploying an application like this? Google… 28,000,000 results! Hmm… where to start? Maybe with requirements…
 
1) I need to develop on my laptop and have the same environment as production. This will prevent any nasty surprises at deployment time. Down-time sucks. Latency sucks too, so I don’t want to be developing on a remote server. It has to be on my laptop.
 
2) I need be sure that anyone who works with me, developing this app, can get up and running quickly, regardless of their technical expertise or [bad] choice of operating system.
 
3) It has to scale. It may be a small app now, but I do not want to hit a wall when it starts growing.
 
4) It must provide a database, message queue, maybe memcached, and a few different programming languages and web frameworks.
 
Back to Googling…
 
A Better Way
 
Hmm… top hit on Google is an ad for “Stackato PaaS.” Looks like they are spending a lot of money on Google Ads. They must be doing well, so let’s check it out…
 
There’s the download link. Skim over docs. Looks good. Check languages. Check frameworks. Memcached. RabbitMQ. Perl, old. Node.js, new. Even got Java. Well, you never know. Rails, Django, Drupal… ok, it’s a long list. This will work. Download VM. Download VirtualBox. Fire up VM. Starting. https://stackato-4dwe.local Open Chrome. Username. Password. Password again. Passwords don’t match. Typing too fast. Try again. Ok, we’re in. Back to docs. Need a stackato.yml. Vim vim vim. Stackato client? Download client from my Stackato VM. Check docs. stackato target. stackato login. stackato push. stackato open. There’s my app! Kinda of… Needs some tweaks, but that was quick!
 
Ok, so I can run my app on my Macbook Pro. Check. VirtualBox runs on Windows, too. Check.
 
How about production? Hmm… what’s vSphere? What about hosted? HP Cloud Services. Amazon EC2. ActiveState Sandbox?
 
Ok, let’s go with Amazon EC2. I know that.
 
Enter AWS Account Number. Check email. Check email. Check email. Got it! Login to AWS. m1.medium. Find Stackato AMI. Install. Wait. Security groups. Port 80. Port 22. ssh. kato node rename.
 
Stackato seems to be running on Amazon EC2.
 
Back to Chrome. URL of EC2 machine. Username. Password. Password again. I’m in! Back to the terminal. stackato target. stackato login. stackato push. wait. stackato open. There’s my app! “In the cloud”. Not perfect. Needs some tweaks, but it’s the same tweaks that my dev deployment needs. Wow, I’ve actually replicated the same deployment. Check!!
 
Off to grab a coffee…
 
Back. Ok, what’s next?
 
Has is got “web-scale”? Hehe. Let’s add some more instances on AWS. 5 machines should do. All m1.medium.
 
ssh. kato node attach. ssh. kato node attach. ssh. kato node attach. ssh. kato node attach. ssh. kato node attach.
 
Let’s scale my app. Stackato web console. Applications. There’s my app. Instances: 1. Drop-box. Select 5. More instances are starting. Started. Instances = 5. Sweet. These machines are not doing much. I should probably scale that back and save some AWS $$.
 
What’s next?
 
Let’s checkout the App Store on the Stackato Web Console. Cool. WordPress? I should write a blog post about this experience. Select WordPress. Name “blog”. Click install. Wait. Running. Neat, it’s already running on a “blog” sub-domain. Go through blog setup. New post. Title? “A Small Simple App.”
 
Hmm… how best to explain this experience in a blog post?
 

Subscribe to ActiveState Blogs by Email

Category: stackato
About the Author: RSS

Phil Whelan has been a software developer at ActiveState since early 2012 and has been involved in many layers of the Stackato product, from the JavaScript-based web console right through to the Cloud Controller API. Phil has been the lead developer on kato, the command-line tool for administering Stackato. Phil's current role is Developer Evangelist for Stackato.

Prior to coming to ActiveState, Phil worked in London for BBC, helping build the iPlayer, and Cloudera in San Francisco, support Hadoop and HBase. He also spent time in Japan, where he worked for Livedoor.com and met his wife. Phil enjoys working with big data and has built several large-scale data processing applications including real-time search engines, log indexing and a global IP reputation network.

You can find Phil on Twitter at @philwhln, where you can ask him any questions about Stackato. Alternatively, email at philw at activestate.com