Podcast #002: We don’t need no steenking editing!

Podcasts – Strictly Professional

A second podcast! So, I reckon we’re already in the 75th percentile of podcasts, just by doing more than one — 90% of life is showing up, etc etc.

Recorded on 11/19/2009, this episode features myself, Chris Miles, Joe Brandt, Michael McIntosh, and Michael Klatsky (see links to people’s sites, etc. in the sidebar). We talked about a smattering of things related to “the cloud”, IT management, Amazon AWS, Rackspace, CouchDB, Redis, and other bits. A couple of topical highlights (mostly in order):

• M. Klatsky was kind enough to bring some of his homemade chocolate coffee stout, which we all enjoyed quite a lot.
• Chas described Snowtide’s in-progress move away from any shade of in-house hosting to using Amazon AWS.
• We talked quite a bit about Amazon’s (relatively) new Relational Database Service, and how the real value of “the cloud” may not be the outsourcing of infrastructure management, but the value-added services like RDS that take a ton of busybody work out of the mix for companies for whom the related “bare metal” services are simply cost sinks.
• There was a fairly extended discussion of the mechanics of managing cloud nodes, specifically Amazon EC2 instances, along with the security issues surrounding AWS’ specific authentication mechanisms (e.g. keys, certs, etc). Update: Here’s a good rundown of EC2 key management strategies, focusing on the security ramifications of each.
• Some talk about cloud federation, cloud service lock-in, and maybe how things like Eucalyptus (an open-source reimplementation of (parts of?) AWS’ cloud APIs) might be a way to mitigate the consequences of cloud vendor lock-in.
• Man, what happened to the Sun and IBM clouds?
• Everyone seems to agree that Rackspace is somewhat out of touch w.r.t. “the cloud”, and have fallen behind Amazon AWS technologically.
• How do you prepare for system failure and disaster recovery in the cloud? Whoa, it’s a lot easier to test recovery in the cloud than in other environments. Also, mobile self-contained server rooms, and the pain of depending on unresponsive commercial backup software vendors.
• M. Klatsky reveals the origin of his mapu handle for all to know!
• Miles has been checking out Redis as a zero admin message queue
• Chas likes CouchDB because of its pleasant programming model and rock-solid real-time multi-master replication (in contrast to mysql replication, which is touchy at best)
• We all hate the nosql moniker — catchy, but too easily interpreted as confrontational.
• “Functional programming lends itself for deploying in an elastic, distributed infrastructure…” – Miles
• Single sign on options, including Joe’s shop rolling their own (“Ouch!” – Chas), OAuth, OpenID, and Shibboleth, etc.
• Miles wrote an emacs twitter client (called Parakeet) some time ago. (TweetDeck, watch out! ;-))
• We’re all REST fanboys, apparently. Although, if you have a toolchain that deeply supports it, SOAP can be pleasant.
• There appears to be a debate out there between “the purists” that consider REST to be only what was described in the original paper that coined the term, and most of the rest of the world that uses the term “REST” to describe any protocol that is stateless and uses HTTP for transport (e.g. not necessarily including URLs for additional operations on a resource, etc).
• Finally, this episode includes the first Strictly Professional easter egg. Maybe it was funnier in person.

BTW, it turns out that I was totally off-base w.r.t. a couple of facets of CouchDB:

1. We’ve never had to think about CouchDB’s versioning at all, so my description of how it works was simply wrong. Sorry, folks. Check out the chapter of the CouchDB book versioning and conflict management for the real skinny.
2. Further, I had some wires crossed in my head when I said that CouchDB had an option for using a binary protocol like stomp. CouchDB only supports JSON over HTTP, with binary attachments encoded as you might otherwise do for an HTTP request.

I hope people continue to enjoy the material. If you have any comments, or questions for us, feel free to leave them, and we’ll see about addressing them in future episodes.

http://s3.amazonaws.com/strictly-professional/sp-podcast-002.mp3