When Sellout is a Good Thing: Scalarium sold to AWS

Posted by & filed under DevOps, Ramblings.

The typical life-cycle of a start-up: You start with good intentions, rush out of the gates to conquer the world, then you either crumble, because there is only cash running out but never coming back in, you get exhausted, you fold. Probably happens to 1 out 10 start-ups (I’m optimistic): Which should not keep you from starting-up – as 1 in a million is becoming facebook and 1 in 10.000 is bought by amazon.

There has obviously something missing to AWS from the very start. It was to low-level for most developers: Unless you invested seriously in setting up, monitoring and managing the eco-system around a typical EC2-machine, AWS is not much more than overpriced VM-ware that runs in the back of a bookshop.

So, basically everybody did just that and used some heavy artillery composed of chef-script, installed god or monit or whatever and kept a close eye on these machines. Or went to one of the thousand „Service“-companies that started surrounding the AWS-ecosystem like a swarm of Bluestreak cleaner wrasse a Potato cod (ok, excuse me, this comparison is probably a bit far fetched…).

First there was EngineYard , pretty quickly the companies that promised to ease the pain of running real-world apps in the cloud came in all forms and variations: Range from the one-git-push-heaven of Heroku to the late-to-the-party-but-jee-can-dance-too of OpenShift they come with all sorts of price-tags and feature-sets. It was just a question of time, until the shake-down happens: The market for these kinds of services is obviously big, but I doubt that it is this big too keep all these companies working profitable in the long run. Sooner or later, companies will start to disappear again and the consolidation will leave probably only a handful of players on the field.

Peritor/Scalarium has always been an exceptional player in this game: First of all, they come from germany – I’ll give them a patriotic bonus for that, given the fact the Germany is not exactly known for its startup-culture. And they were just plain good: The things you want, a mix of a great, usable GUI, but also very easy to script&customize with some simple chef they hit the right mix between the no-tool-approach of raw-AWS and the very closed and shielded way that heroku was going at that time.

And now the got bought by Amazon. Granted, the timing of the announcement has morally not been the greatest, as amazon is currently entangled a scandal surrounding the working-conditions for their warehousers – but nonetheless this is something we can congratulate all involved parties upon:

  • amazon: as they have obviously realized this gap and are trying to close it with the help of what has now become OpsWorks
  • peritor: For building a great product and cashing in rightfully so. And they obviously continue to build this thing, as amazon is now searching very actively for engineers to expand OpsWorks – and it certainly is a great opportunity for them: They now have the cash and the backup and the market-exposure to be real contenders to the big fishs like EngineYard.
  • us: As things suddenly got very much cheaper. Amazon suddenly comes with great management-tools right out of the box.

The only loosers here: Heroku, EngineYard, etc. – you have to really, really make a good case to convince people, that you need EngineYard+amazon instead of just amazon.

Screencasts on Speed: Destroy All Software

Posted by & filed under Ramblings, Tools.

Last month was RailsCasts-Pro, this month we Destroy All Software: If you are taking you’re own education serious, you owe it to yourself to invest these 18$ into your future. And there is possibly nothing that can go wrong with that. Where Railscasts is covering mostly new tools, Gary Bernhardt from “Destroy All Software” is covering in-depth fundamentals, lots of work on re-factorings e.g. IMPERATIVE TO OO TO FUNCTIONAL or Primitive Obsession – and he’s doing it quick. Most screencasts last only around 10 minutes and cover lots of ground. So, if you get easily bored by screencasts and find yourself running things on fast-forward all the time, than these are the screencasts for you.

PS: And the git-log-formatting is worth the money alone: You’ll find the .dotfiles to this episode on github.

Part I: Deploying Redmine

Posted by & filed under Cloud, DevOps.

Are our lives becoming easier every day or more complicated? You can ask this question in almost all modern situations, be it buying a book (a real one or an ebook? which reader? or better run to the bookstore? do they have the book I want? Order it there? Or at amazon? choices, choices), or getting news from friends (check your email, check your phone, check you twitter, then again, 20 years ago you just never heard of them again when they left town…) – or: Deployment.

Heroku is an easy option for deploying redmine. Or for any other deployment. Cheap (if you don’t need to scale), easy to setup. That is: until you’re trying to setup file-upload. And your repository. And suddenly things stop being all that simple. You usually realize that when it is already too late and you have invested too much to move). So here we are: We started out with things being complicated: Having a physical box, getting all the stuff onto this machine to make your app run. Along came heroku, which took some of the pains away. Then came all these heroku-lookalikes like OpenShift, or obscurer ones like Cloud 66. Ah yes, and then there is raw ec2 you can try. And yes, you may even have an idle linux-machine sitting under your desktop that you want to reuse. Or the fancier ones have a whole OpenStack built in the their backyard: So many options, so many decisions…

For our project, heroku was out of the picture: For legislative reasons, data is not allowed to leave the companies datacentre. Now, can we have our cake (push-button-deployment of production-ready redmine-machines) and eat it (host it in a private datacenter, on either virtual or non-virtual machines without vendor-lock-in)? Yes, we can: Here is what we need:

  • Vagrant/VirtualBox: You don’t want to develop these kind of scripts against an ec2-instance: There are lots of moving parts involved, consequently many things can (and will) go wrong. Vagrant gives you a local virtual machine that you can develop against. After the machine-images (in this case the 64bit-Precise Pangolin Version of Ubuntu) have been fetched, starting and stopping these machines is as easy as
vagrant up

and

vagrant halt

.

  • roundsman: You will probably be doing two things on this machine: A) set it up with all prerequisites needed to run redmine(e.g. ruby, bundler, imageMagick, mysql/postgres etc.) B) deploy redmine. You will do A only once per instance, but you will be probably doing B a lot: Whenever you make configuration-changes (add/remove a plugin), you will need to update the redmine-app: roundsman uses chef for A) and capistrano for B) – which gives you the two of the best tools for the job. It wraps these tools into a tiny shell-script, that even installs the correct ruby-version, which is what you need to run chef. Kudos to Iain Hecker for coming up with this approach!

  • recipes: Here is where it gets opinionated. ImageMagick is mandatory, apart from that we used a fairly standard stack of apache, passenger and mysql. This is the basic stuff you need, apart from that, your mileage may vary: The only thing we added for now was a graphviz that we needed to visualize some processes. You need to check the requirements of your plugins, but you should find every recipe you need in the opscode-cookbooks.

Basically, that’s it: roundsman extends capistrano with a set of tasks that setup the remote or the local virtual/vagrant-machine:

cap roundsman:chef:chef_solo                        # Runs the existing chef conf...
cap roundsman:chef:install                          # Installs chef
cap roundsman:chef:prepare_chef                     # Generates the config and co...
cap roundsman:configuration                         # Lists configuration
cap roundsman:install:check_ruby_version            # Checks if the ruby version ...
cap roundsman:install:dependencies                  # Installs the dependencies n...
cap roundsman:install:ruby                          # Installs ruby.
cap roundsman:install_ruby                          # Prepares the server for chef
cap roundsman:run_chef                              # Runs chef

that you can either call separately or just use the hooks that roundsman provides and use the well known capistrano-tasks. We added

namespace :complete do
  task :setup do
    deploy.setup
    deploy.default
    deploy.migrate
    redmine_configurator.load_default_configuration
  end
end

to setup the machine for deployment, run the default deployment, which now also installs all dependencies on the machine, migrates the database and than finally loads a default-configuration into the installed redmine-instance (I will talk extensively about the last task in Part III of this series).

Summary

I have uploaded a working example of this approach to github – please try it out, tweak it and don’t hesitate to ask/criticize/improve. I like this approach, it takes a little more time to setup and get right, but you will end up with something that is very flexible and can be deployed not only to amazon, but basically everywhere where you can deploy your ssh-keys too: I’m currently also using this to setup some machines at a traditional, non-cloud-hoster. These machines are way cheaper than ec2-machines and these off-the-shelf machines usually offer much better performance for the money. I use this approach to get documented, non-historic machines (machines that have not accumulated any history of installs/updates, you know these machines, where nobody can remember who has installed what year ago).

Pitfalls&Outlook:

  • Stay away from the microinstances of EC2: Surprisingly, the most memory-hungry task in the installation process is the generation of the ruby-docs. When we first developed this approach, there wasn’t a switch to turn off this step and the micro-instances simply went dead on compiling the ruby-doc. Terribly hard to figure out, why this actually happened, as “being dead” also meant that you have no means of looking into the machine anymore. The problem went away once we moved up to the on of the payed amazon-instances like the m1.medium. This also speeds up the start-up significantly.
  • debugging: Try to go slow. The ideal approach here would be to drive this process using TDD. It gets hard to debug this when you have lots of recipes: Manual testing is not exactly fast and it can take you some time until you arrive at the recipe that throws the error – so better make sure that you test your recipes separately before throwing it all together.
  • testing: What’s missing from this example is testing. There is a series of excellent articles from IBM on Agile DevOps that covers an approach how to test-drive these setup processes: Essential Reading! Also an essential reading: Test-Driven Infrastructure with Chef.