The London Continuous Delivery meetup group had its first session of 2013 on 17 Jan. We were fortunate to be able to use the offices of [my employer] thetrainline.com in central London, and doubly fortunate to be joined by Andy Hawkins from Opscode, who ran what turned out to be a brave demo showing how Chef can work with CI tools to provision EC2 instances.

Andy’s demo was interrupted by some technical difficulties in the US-EAST region (at least it showed the demo was real :), but we eventually saw a new EC2 instance provisioned via Eclipse, TW GO, and Chef ): 

2:51 PM PST EC2 API error rates and latencies have recovered. Customers are currently not able to provision new ELBs in a VPC. No running ELBs are affected.

For me, one theme in particular stood out from the evening’s discussions: auto-scaling and how (not) to do it. Andy was adamant that although people are using Amazon EC2 features such as auto-scaling he knows no-one who would want to scale anything but trivial systems without manual intervention. at least in January 2013. Changing the resources available and active in a system can substantially change its behaviour, and even make a minor problem just worse. An extreme example is the “EastEnders power surge” which happens in the UK every time a popular TV programme is shown: http://www.bbc.co.uk/britainfromabove/ stories/people/teatimebritain.shtml – if additional electricity generating capacity were managed in a fully automatic fashion, parts of the UK would likely see regular blackouts (for the tl;dr version, watch from about 3’30”).

At a smaller scale, a few years ago I worked on an ecommerce web site for a major telecoms operator in the Middle East, and our initial bandwidth from the data centre was capped to a modest 2Mbps outbound. As the number of users ramped up after launch, the decision was taken to increase the outbound bandwidth to something like 5Mbps, the idea being that we’d be able to serve more requests and therefore generate more revenue. In practice, what happened was that the database became the bottleneck, and we had to reduce the bandwidth back down to 3Mbps in order to restore service. Lesson: auto-scaling is tricky and can have unexpected consequences for your application or service; use with care.

A colleague of mine in kindly recorded the session, so we’ll get a podcast out  some time soon and post it on thetrainline.com engineering team blog.

In the pub afterwards, at the excellent Craft Beer Company in Clerkenwell, we (perhaps influenced by the surroundings and the beer) decided that more pub meetups would be A Good Thing, so I think we’ll be seeing a combination of more structured meetups (like the one on 17th Jan) and more informal meetups (with good beer). I was also introduced to TOFT, a library for testing Chef cookbooks using Cucumber. Like many other Chef TDD tools, it relies on User-mode Linux, plus Vagrant.

The photo gallery on the London Continuous Delivery meetup pages gives a flavour of the evening. For me, it was humbling to be amongst so many clued-up and enthusiastic practitioners of infrastructure automation, and I’m looking forward to the other meetups during 2013: see http://londoncd.org.uk/ for details.