I have been reading recently about the “Lean Startup” concept, which is funny since I have been working with and been part of more than a few without knowing there is a nifty catch phrase for them. So now I am all up on the lingo and hash tag #leanstartup I can speak on it. Today is the perfect time to take a gamble and dive into a lean startup. Being that there are so many free tools and services you can use along with very inexpensive solutions to infrastructure that were not available even a few years ago. By using the power of Open Source software, free online services, and cloud computing one can build a scalable and very cost effective lean startup.
Let’s first look at your new companies hosting and servers. being that you are lean you may most likely be working from home. So let’s look at hosting and services you will need in order to host some of the Open Source applications will will talk about in a moment. In my experience the basic things you need to get going in terms of setting up shop are the basics:
I wanted to touch again on the use of Subversion (SVN) to populate the /var/www of app servers on Scalr. Basically the issue is how to add your web content to a new instance once it has automagically launched a new instance due to high load. So Scalr will launch another app role once the server reaches a load threshold you have previously set. So the issue is I can have the instance started, but once it has launched the /var/www needs to be populated for that server to be able to serve content via load balancer.
Scalr Scaling Settings
This is where SVN and Scalr Scripting come into play. I keep all my site content in a SVN repo. So I link to whatever production tag I want to be live at that time. In order to get the directory populated I make a simple script to do an svn checkout of that tag to /var/www. A simple bash script is added to do the checkout and is added to the “OnHostUp” option. This way once the server sends its SNMP trap saying it is up the script will be executed. This is also a helpful means of updating your servers to a newer build. I DO NOT checkout the tag directly into /var/www instead I make a symlink to /var/svn where the tags are checked out. So when it is time to roll out a new production tag I simply checkout the new tag to /var/svn and redo the symlink to point at new tag. This way if there is an issue that was not forseen in the QA process I can roll back to known good tag by redoing symlink. This is an easy but very effective way of using Scalr scripts and SVN to manage content loading on servers.
I am a big fan of using Subversion for things other than just versioning code. In the past I have used SVN to manage configuration files across many servers. Making it easy to deploy and (if needed) roll back changes. It is also a big help on development servers for PHP developers to commit changes and see them live on the development server. This is easily accomplished using SVN hooks. There are plenty of HowTos on this topic if seeking that information.
Now that I am up to my eyeballs in Amazon Web Services I am looking to use SVN to help me leverage the new found power of the cloud. Now I am not saying it is a good thing to use SVN for things other than code versioning. But it has always worked for me in many other ways as well.
Some of the things I am thinking of using SVN:
Update DEV web server using hook scripts for devs to see changes to trunk.
Maintain Apache and other config files for AMIs.
Maintain code repository for versioning along with take advantage of S3 for backup and processing power of EC2.
This is a work in progress so I am looking to perfect the design to my liking soon.