The Changelog: Software Development, Open Source - DevOps and Chef (Interview)

Episode Date: October 12, 2010

Wynn sat down with Corey Donohoe from GitHub and Seth Chisamore from Opscode to talk about DevOps, Chef, agile infrastructure and innovation in the datacenter.

Welcome to the ChangeLog episode 0.3.8. I'm Adam Stachowiak. And I'm Winn Netherland. This is the ChangeLog. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also up on GitHub. Hey, at thegithub.com forward slash explore, you'll find some trending reposts, some feature reposts from our blog, as well as the audio podcasts. If you're on Twitter, follow Change Log Show, not The Change Log. And I'm Adam Stack.

And I'm Penguin, P-E-N-G-W-I-N-N. Fun show this week. Talked some DevOps and Chef with Corey Donohoe from GitHub and Seth Chisholm from OpsCode. A lot of fun stuff happened in that space. You guys talked about Chef, and what else did you guys talk about? Just the whole topic of DevOps in general and how it's kind of an amalgamation of development and sysadmin,

much the same way that we're amalgamation of design and development. Yeah, and Chef is a pretty wild tool for building some servers and doing some automated stuff, so I guess that's got to make their job a little bit easier. And our job easier, too. We don't like to play too much in that area. We usually hire folks for that, but it makes it a lot more approachable for front-end folks like you and me. Very cool. We also have to do a little build pan.

We work with Jason Seifer over, GeniusPool.com. He runs an awesome job board. So we've got a few jobs to listen off. So Wayne, why don't you take the first one? Sure. You know, I think every developer wants to be a gamer developer when they first start out. Well, here's your chance. Agora Games, hiring a Ruby engineer, can work locally or via telecommuting so that's also a dream flexible hours free time for personal projects and awesome co-workers plus you'll enjoy quadruple bacon pizza at least occasionally nice and the next one is dealbase.com they're looking for a ruby on rails developer hey i got a couple questions for you bud do you like

git you know it do you write write Ruby like you write English? Probably better than I write English. Sweet. Do you like Rails 3, and are you itching to use CoffeeScript? Yes and yes. Sweet. Are you interested in writing mobile applications? You know it.

Well, that's good, because if you answer yes like you just did to all those questions, then Dealbase wants to talk to you. Dealbase is a well-funded, deals-based site looking for someone who knows Ruby, Rails, JavaScript, and test-driven development. Don't tempt me. I may give them a call. Do it. And finally, Media Temple is hiring a senior Perl developer, and we don't know if this is age or title. Everybody knows Media Temple. They're a leader in the web hosting space. They want you to work in their Culver City, California office.

Your primary mission will be to interact with customers and business owners as you add to and maintain their customer portal and user interface. If you're looking for a challenge and appreciate being recognized for your efforts, explore this opportunity with a recognized leader in the web hosting space. And if you want to check out any of these jobs whatsoever, go to the changelog.com forward slash jobs and or geniuspool.com to find all these listings and more. If you want to have your job read on this podcast, just let us know through geniuspool.com. Fun episode this week.

Should we get to it? Let's do it. Chatting today with Corey Donahoe and Seth Chisholm from GitHub and from OpsCode, respectively. Corey, why don't you introduce yourself and let the folks know who you are. Hey, my name is Corey Donahoe. As Wynn said, I work at GitHub. That's kind of a new job for me, but I've basically been an open-source hacker and part-time or sort of sysadmin for the last 8 to 10 years.

I have a number of projects available on GitHub at github.com slash Atmos. That's A-T-M-O-S. And, you know, I basically am trying to wade my way through a very large code base that's been in use by most of my friends for the last two to three years. So it's been an interesting month to just kind of come up to speed on a larger legacy application. Fun times at GitHub. Seth, how about you?

My name is Seth Chismore, and I'm a technical evangelist for OpsCode Inc., the company behind Chef. I've been a developer for the last 10 years and found my way into operations system administration over the last few years. Right now, I'm just helping evangelize Chef, do training. I also help write cookbooks for customers. I'm a user just like everybody else at Chef and do that type of development. That's a little about me. So we're chatting today about DevOps in general and then chef more specifically. Corey, why don't you make a stab at defining DevOps? It's a buzzword.

No, it's kind of things that have been emerging from really talented system administrations that have kind of embraced reproducibility and automation. And I feel that there's been a number of people that have been doing it, but those people have kind of started to cross paths and there's kind of a little movement brewing where people are really excited about kind of taking almost agile methodologies

and applying them to deployment practices and systems operations. So Seth, where does Chef fit into the DevOps landscape? Well, I mean, Chef's an important piece of that. I mean, we fit into sort of the configuration management and automation piece of that. But obviously, you can be doing DevOps and be doing it right and not be using any tooling, right? I think that once you adopt some DevOps practices within your organization, you start to look to things like automation, configuration management, that question comes naturally. But we at OpsCode, and me in particular, I'm a big believer that you can be lo-fi and still

be a DevOps shop. But obviously we'd like everybody to use Chef. I think it's awesome. So. So is DevOps, is this an evolution of the sysadmin role or something totally different? I mean, I'll step in. I sort of think that the biggest thing to remember about DevOps is it's a cultural and professional movement. So, I mean, if you think about that, that sort of drives everything through the rest of the DevOps discussion, right? So it's really just about that culture that a company is willing to adopt where their development team and their operations team is seeing that

chasm that exists between the two and that sort of like broken wall that develops toxicity that develops between the two groups. So, you know, I think that, you know, just following that, you start to see that, you know, that it's an evolution that's happened for both the developers and the operations roles. Yeah, I definitely think that that's kind of the awesome part of DevOps or the theme that really wins out is the cultural shift where everybody just gets along rather than, you know, everybody looking at operations as the BOFH that is keeping them from shipping their code.

It's just a matter of getting everybody on the same page and understanding that the product lifecycle goes all the way through to deployment, not just tagging or release, and that they're going to need to work together in an ongoing fashion in order to basically, you know, be a successful company and basically have a little bit of, you know, extra, you know, I don't know, extra expertise or extra interaction that's going to make them, you know, a more successful shop than the next one. You know, with the term web 2.0, and then now recently HTML5, we found the term means different things to different folks. And it evolves as you go. Are you finding the same thing with this DevOps term? Yes. Yeah, definitely.

And that's why the confusion, right? And there's a lot of people trying to co-opt this for their own gains, which is another thing that's sort of bad about it and it confuses people. But again, trying to keep things simple and just understand that it's purely a cultural movement. It's about culture and process.

Helps sort of wade through some of the BS that comes out. People trying to say that they sell DevOps or they have DevOps-compliant tool sets. It allows you to use that as a litmus when you're seeing what somebody's selling. I think the other thing that's really interesting is it's like in development world, agile, the agile development movement sort of got the business in line with the development team, right? Those two teams were working closely together. And I feel like this DevOps movement, sort of that final thing to bring the DevOps in line with operations, right? And now we finally got this like full life cycle where business is fully in line with the product all the way

through. And I think that's really cool. So it was sort of like that last link that we needed, uh, to make it all happen. Yep. Cause I was like, one of my first jobs when I got out of college was like supporting a whole bunch of J2E app servers and they had like complex QA and things like that. But there was definitely like a lot of finger pointing and basically, you know, the, the throwing the code over the, over the wall and hoping that it works track. Um, you know, but it was, it was nice to see this start to emerge the last few years and people, you know, work more effectively together rather than, you know, complex, just really annoying meetings where everybody's talking about, you know, circumventing the process in order to meet deadlines and things like that.

It's more, you know, from an upfront perspective, everybody being on the same page and working more effectively. You know, Adam and I are both front end developers, and there's been this healthy tension between developers and in designers and trying to get designers to be a little bit more technical and trying to get developers to be a little bit more design focused. Do you see the same tension between sysadmin types and developers and where that kind of crosses? Definitely. I think those three roles, definitely. Traditionally, everybody has kind of said, I'm one of those three things. And the really talented people generally bridge the gap. And I think that enough people have seen that

people can do more than just one thing effectively, that it's almost inspirational and you want to be good at those other things too. So, you know, if the operations team is really good and the developers are really good, you know, you should be able to mask a lot of the production type things to the designers. So they don't even have to worry about, you know, oh, are all the services running on my local machine in order to spin up and like design some views or something like that. But it's more of a modern thing now. And a lot more people are doing it rather than just, you know, a few small shops that you happen to read blogs about. Yeah. And I think the other thing we have happening is this line blurred between what is the application and what is the infrastructure, right? And so the fact that the infrastructure

is the application, the application is infrastructure, right? And so the fact that the infrastructure is the application, the application is the infrastructure has really started to change a lot of that. I think we all realized we're there to enable the business. That's our ultimate end job, right? Everybody on the team. And I think that's a great thing, and it's brought people into better alignment across the board.

So, Seth, what's the elevator pitch for Chef, infrastructure automation for the masses? So, Chef. Well, high level,, like Chef is a couple of things. It's sort of like all these things at once. So it's a library for configuration management. And it's also a configuration management system. And then an important thing, it actually does systems integration, helps you do that. And then it's also an API for your infrastructure.

And so I'll go back and sort of explain each of those. So, I mean, Chef, the actual core product, is a Ruby gem, and it's a library that you can use in other products. So you see things like Cori Cinderella that actually leverage Chef to do some lightweight configuration management within another application. And obviously, we've got the whole system, which we have, which is a Chef server, the Chef client that helps you actually configure your infrastructure and get things in line. But an important piece of all this is Chef takes, I think, things a step farther past things

like Puppet and CF Engine, and we're a big believer in systems integration. And the fact that you can do live search within your configuration management and actually do things like a load balancer can call out and get a list of all the app servers he needs to balance, right? Or an application server can actually call out and get a reference to the master database server or the slave database servers, things like that. That's taking things to another step. And you've actually got a data-driven infrastructure, which is really cool. And obviously, it's a RESTful API at its core,

and it can be an API for your entire infrastructure. The Chef server, the centralized Chef server that's indexing all this information about your infrastructure can be searched from a command line using Knife or actually in real time in other applications could leverage that data. So, I mean, that's sort of the high-level pitch about it.

And I mean, you know, we can get into maybe some of the principles and stuff later. But I don't know. Corey's working with Chef. Do you get, like, the configuration management search style stuff? Is that available on the platform and if you host Chef Server yourself? Oh, yeah, definitely. Or is that just a bit? Okay, cool.

Yeah, I've pretty much only messed with Chef Solo. Yes. And that's, I mean, Chef Solo is awesome. And I think it's a great place to start, but if you want to really get into some of the cool stuff, you lose some of the benefits of that systems integration, and you do need to leverage that centralized index data. And the platform, really,

there's a lot of people get confused on the platform versus the open source Chef server. They're fully API compatible, and we plan on keeping them that way for the future. Now, our big play on the OpsCode platform is it's highly available. It's multi-tenant. It's scalable. I mean, the guys that sort of started OpsCode, you've got Adam Jacob, who'd worked with Puppet for years. Jesse Robbins, who used to be in charge of all of Amazon's infrastructure. And Chris Brown, who's sort of the core architect of Amazon

EC2. So these guys definitely know how to build like scalable systems. So, you know, for us, we sort of say, look, just give that to us. We know how to scale the Chef server. We know how to make it highly available. You know, it's something you definitely don't want going down. And then we also add some extra things on top of that, like role-based authorities for doing some of that stuff. So you can actually put all kinds of different authorities on each different component of the Chef platform, whether it be nodes, who can see this node,

who can touch this node, or data bags and all those different things. And that's another thing that if you leverage the Chef servers, you can use data bags, which allow you to have this centralized store to drop data. It could be user data for all the users that you need to put on each of your nodes. It could be application data for apps that you need to deploy out on your app servers, things like that. So, you know, that's definitely a huge win.

And I think if you really want to do it sort of the Chef way and truly go data-driven, at some point you'll realize you sort of want to leverage a Chef server. And you also have a growing community around it with sharing cookbooks, right? Yeah, yeah. And that's actually something, you know, I've been a Chef user for about a year and a half. Before I started with OpsCode, I actually was in the Chef Alpha, my former company, and so I've been there since the start

and seen it sort of evolve. And I think the cookbooks, you know, until I started Ops since the start and seen it sort of evolve. And I think the cookbooks, you know, until I started OpsCode, I never really clicked with me. That's one thing we're gonna try to get the message out. cookbooks.opscode.com is sort of like rubygems.org. You know, a lot of people just thought like, okay, we've got, you know, there's a GitHub repo for the OpsCode cookbooks, and I should just submodule that into my Chef repo and go ahead and start using those. But the really the better way is to leverage cookbooks.opsco.com and use that as your, your main source. Just like when you install a gem, right? You do a pseudo gem install and it

just comes on your system. So, you know, using knife, which is our command line tool, you can do the same thing and sort of bring the cookbook down and then you can start sort of leveraging and building on top of it. But, um, that, that central community of sharing is one of the big things where chef shines compared to some of the other configuration management tools. And I think it's one of the coolest parts. And we're definitely going to be evolving that in the next year, sort of making that site better and sort of, you know, making it more community driven. Closer to something like GitHub, where you've got feedback from people and you might have some stats that tell you how many people have installed the cookbook, how many are using it, stuff like that, which I think would be really cool.

Is the idea more with that type of platform to have the one MySQL cookbook to rule them all or different flavors or just kind of embrace the community to collaborate and kind of agree upon what's the best general MySQL for deployment? I think we're definitely always going to have multiple versions because one of the big guiding principles of Chef is that there's more than one way to do it. We obviously, everyone models their infrastructure slightly different. We're going to hopefully, with the ops code cookbooks, sort of put forth some of the best practices and best configurations to get you started, but we know that people are going to have to change that.

So there's probably always going to be some multiple cookbooks out there and we're working right now on figuring out how we're going to namespace those. You know, the discussion we've had internally going back and forth is like, you know, in Ruby, everyone comes up with clever names for gems and we sort of want to make sure that the cookbook names give some indication of the function that cookbook's going to fill. So, you know, we're still trying to figure some of that out, but I think you're always going to have the fact that multiple people can, you know, place multiple MySQL cookbooks. Maybe they're, they're all for doing different things up there. And that's cool. Like we're all about that and all about embracing that. And just like in the rest of the Ruby world, you know, there might be multiple ones up there and

one's going to win out maybe just because of popularity or doing it slightly better. So I think that's a good thing. Speaking of creative names, Seth mentioned it. Corey, tell us about Cinderella, nay Cider. It used to be called Cider. Cinderella is basically a chef solo run on your MacBook Pro. So the idea is to leverage RVM and Homebrew and get people going on OS X for open source collaboration trivially. So you get a system that's bootstrapped with MySQL and Postgres and Redis, Memcache, Mongo, like Python, Node.js, and Erlang. And so that just seems to be kind of the fashionable libraries that people have. And the idea is that it's a centralized gem that you run when you boot your system for the first time, like when you do a fresh install, but you can continue to run over time. And it's the chef item potency where Cinderella just runs.

If anything needs to be upgraded, it upgrades it. And if everything's fine and you have the latest version of things, it just exits really quickly. And so the idea was, you know, kind of like we were talking about earlier with bridging the gap with designers, this came out of trying to get one of our designers going on a system. And it's cool when developers are in charge of their own machines because they're usually pretty anal about where things go and how they're set up. But when you're just trying to get a designer, you know, able to run your application that has some complex components, you know, they just want it to work.

So the idea was just to give it to our designer and say, hey, you have a running system. Like, you're good and you're basically set up with all the same tooling that we are. And you don't have to care about knowing, you know, how to add things to your startup environment with LaunchCTL or what version of Ruby you should be on because you might want P248 or P305. There's all these little things that basically people know what the best practices are, what you should probably be developing on.

And if you just give that to them, they're generally happy to move on and just get some work done rather than spending a day or two messing around getting their system going. We had Max from Homebrew on the show recently. What's your take on Homebrew? I love it. I think it's a really good model. I mean, Homebrew is actually, I think it's probably the most forked project on GitHub now. And so they're actually, they are stress test for a lot of new features. It's like, will Homebrew kill the site, yes or no? But I really like the model. I was really impressed when I tried to get NPM merged into homebrew. And not only did they notice that I had forked it, amongst all these forks that they'd done, they noticed that I'd forked it. And two guys from the homebrew project were commenting in line and saying,

oh, there's a slightly better way to do this. Check here. And it was the right kind of community. Those guys really stay on top of it. And things might be broken one day, but they're generally fixed the next. So it was nice to just basically take the Ops Code Chef Solo and what they have normally is like a package manager.

And so what I was able to do was mimic the default package manager with Homebrew. And then you just declare you know homebrew npm and you get npm so it was it was kind of cool just to take advantage of that and to have those guys working hard to make sure that those packages work whereas you kind of just glue it all together with chef yeah i don't know if you know too um up in the in in the core chef project there is a homebrew provider now so like the package resource so it's sort of cool like that's actually there's a mac ports one and a homebrew one that are shipping with chef at this point so i need to actually check that out i want to try 0 9 10

but i haven't yet i was hoping to try it because of some of the newer dependencies that are out that i'd like to take advantage of like being able to run you know rubinius as the default room or something like that but we weren't able to run, you know, Rubinius as the default room or something like that. Uh, but we weren't able to previously because of the Jason gem, but yeah, it was, uh, Kurt Meikle, I think actually added that he hit me up when he did it and I've just been kind of busy and it works. So I haven't adopted the new stuff yet. That's cool. You know, with tools in this space, like chef and puppet and Sprinkle, I'd like to propose that the Swedish Chef be the mascot for DevOps. What other tools are out there,

and what's the complete landscape look like other than Chef? You've got, obviously, the old-school CF engine, which a lot of shops are still using, and they've modified it heavily to add the features they need. And then Puppet, you've got a lot of places that depend on Puppet. I mean, Twitter, Google. And a lot of the things that were lacking in Puppet, these guys just sort of put a custom layer on top of it.

The centralization we talked about a little bit, that's sort of a big differentiator between Chef and Puppet, but a lot of people have sort of found ways to make that work, right? Yeah, we're using Puppet at GitHub, and we were using Puppet for a lot of the internal servers at Engine Yard. Most of the App Cloud, the newer Amazon offering is all Chef-based,

but a lot of the older stuff is still managed by Puppet. So it's, you know, I think it really depends on what people are more comfortable with, and as long as they can get the job done and it's automated, it's generally a good step forward. Yeah, something's better than nothing at this point. If you're going to meet cloud style still, you've got a problem there.

Nothing else immediately comes to mind as far as config management. I mean, I think one of the other things that's kind of been left out is so many people just kind of take the whole DevOps idea for being just like configuration management, where it's a whole bunch of other stuff where it's like metrics and things like that built around your system. We use a tool at GitHub called Silverline. It's like silverline.com, or I think it's labrado.com. I'll just send you the link in a minute. But it's an amazing tool that basically allows you to take process groups on your systems. And basically, it's almost like if the nice command worked very well. But we have

like containers that, you know, the Git server will run in and then like our unicorn front ends, and then Redis and, you know, all of our disk activity and things like that, which you can do is build policies and get really cool metrics about the state of your system and how, you know, introducing changes into your system impacted performance. And so it was really cool. One of the first things I got rolled out at GitHub, I basically killed performance. And so we have this neat way of approaching the problem where, you know, we can't go down, like the whole world goes crazy when we're down. So we basically rolled it out to a subset of the front ends and then just started looking at Silverline. And it was like, well, this isn't up to snuff. So we're going to roll it back

and we're going to do some performance analysis on the changes that were made. And we're going to roll it out again and look at these things. And metrics, I think, are like a huge part of that, because without that, you know, the site would have gone down. And even without the Labrado tool in place, basically the changes that I rolled out would have killed that front end. So it kind of managed everything in the system and kept it from just like killing the server more or less. So that is like... How much of DevOps is being, I guess, driven by this move to the cloud recently? I definitely think that that's an enabler. It makes it easier to do a lot of this stuff.

And I think the fact that we've gone to this spot where we've got all these smaller nodes that are there to serve the application, we're spreading things out and have all these things to manage, it's made it harder, right? It's that I think we're splitting things up into smaller servers in a lot of ways versus in the past, let's say 10 years ago

when we had these huge servers and we threw a bunch of apps on them and scaled them vertically. Now we're actually creating stacks that serve the application. And there's complexity that's added there, right? Even though the servers might not be that big, you still have more of them to manage.

And we can't just keep hiring sysadmins to do it. So we have to get smarter. It was kind of interesting to go from EY, which is basically all VMs, where, you know, we would almost tell people, oh, you need a search server? Well, get one with, you know, this amount of memory over here, and that's just going to be a search server. And then to go to GitHub and see how they're using big, beefy physical servers from Rackspace, and just kind of using a tool like Libretto to manage that all in user space rather than having to do VMs or something like that. I think VMs make a whole lot of sense to a lot of people. Like the stuff you can do on Amazon and Rackspace right now is

amazing. But I still think a lot of performant apps are going to have, you know, really racked boxes for, you know, at least a couple more years until somebody really comes in and gives people the, not quite virtualized, but the performance they need that they'd get out of something like a traditionally racked box versus something like a VM. VMs are good enough for a lot of people, and kind of the world's exploding with applications and utilities that help people,

and a lot of those don't have crazy performance needs. And I think you're going to see more of those in the future than people with crazy performance needs. But I think that both of those are going to be valid models for at least another, you know, two to three years. And the other thing that's really cool is we've seen some customers doing some very innovative things with their infrastructures that without VMs would be really hard to do. We've actually got a customer who every, so they, they sprint, they, they, they sync their sprints for their code releases with infrastructure rebuilds. And every two weeks, they actually rebuild their infrastructure from scratch and lay the code on there. They go ahead

and QA it and then they release it. And, and so at the end of that, they kill the old infrastructure and start over. It's awesome. And you're seeing just things like that. Yeah, it's awesome. And I mean, buying into this whole infrastructure is code thing that basically says that, right, you know, we could rebuild our infrastructure just using a source code repository, you know, bare metal and app backup. That's all we need. I mean, that's a really cool thing. No, definitely.

That kind of innovation is, it really would be not as cost effective or possible without something like virtualization, I think, to help you. Do projects like this offer some sort of de facto standardization where if I've got multiple infrastructure providers that I want to shop between, that I can move back and forth between those relatively more easily? I think that's on the horizon. I think the marketplace you sort of are talking about,

you hear a lot of innovators or people, you know, future thinkers talking about that, this idea that you could actually multiple times a day switch your infrastructure around based on who's giving you the best cost. And I know there's some people out there starting to solve that problem. And I think it's just inevitable

that that's going to happen, right? You're going to have this real-time marketplace. And yeah, you're going to need someone like Chef that says, okay, you know, either sync my infrastructure, rebuild it over here. And obviously something like Chef makes that pretty easy to do. You know, you still have to worry about how do I get my application data moved around, stuff like that. You know, those are those kind of issues. But in theory, you know, you would need something like a configuration management tool that sort of rebuilds or has a copy of your infrastructure in some kind of repository to do that. Yeah, there's a guy named Simon Wardley who gave like an OSCON keynote, and he has a really good blog that I've been enjoying.

And he actually kind of commented on this where as more of these cloud providers emerge, I hope I get this right, but as more of these cloud providers emerge, the people who are going to be able to work on each of them are basically going to have to adopt the lowest common denominator. And as a result, people probably won't like it as much initially, because they won't be able to take advantage of what each of those are. And he basically referred to the cloud providers as islands. And so if you're on the Rackspace island, or on the VMware island, or on the Amazon island, and right now they're not all interchangeable, but like Seth was like, uh, Seth was saying that that'll eventually happen. Uh, I just don't know how soon. What's your take on open stack in that effort? I'm a, I think it's awesome personally. Um, I,

I think it's, it's good to finally have hopefully one API to rule them all. And, and, you know, it is going to be a little bit lowest common denominator, but I don't think that's a bad thing. Um, so I don't know, starting to see the people get behind it. It might start to be a little that lowest common denominator but i don't think that's a bad thing um so i don't know starting to see the people get behind it it might start to be it's open stack versus amazon you know there's it seems like all the smaller players are starting to sort of rally under open stack is this the devops uh version of facebook versus open social well i hope not because i want open social to succeed or open stack to succeed or OpenStack to succeed. Yeah, I feel like it's just market positioning. Basically, if those companies don't do it, someone else will eventually.

So they're trying to get people together and do it, but it feels like a bunch of traditional companies banding together to kind of embrace open source but also stay viable as the market changes. And I think it's a viable option for a lot of enterprises who maybe can't use a public cloud i think it's cool that they can in their data centers install a private cloud that uh its api is fully compatible with a lot of the tools i think that's really cool um and it allows an enterprise to maybe mix data between

stuff that maybe they have to keep internal stuff that they can put out in the public cloud so i think that's that's a really neat thing because I think all of us get caught up in this. Remember, we're working for startups and all these innovative companies, but there's still a lot of enterprises out there that they can't move quite as fast. And I think something like OpenStack

is going to be a good thing for them. So you guys have seen the Twitter account ShitMyDad says that Shatner now stars in on CBS. Have you guys seen ShitMyDevOps says? Yeah. Yep. That's not either one of you ghostwriting this, is it? No.

The one that cracks me up is every time someone mentions a SaaS app as an example of cloud computing, I throw up in my mouth a little bit. Yeah. There's also DevOps Borat, which is kind of hilarious at times, too. DevOps Borat. Yeah. It's really dated jokes. It's also DevOps Borat, which is kind of hilarious at times, too. DevOps Borat. Yeah. It's really dated jokes. It's like your friend, if he was still making Borat jokes at work about cloud technology. But it's pretty funny occasionally. Do either one of you have a good way to explain to your folks on Thanksgiving what you do for a living? No. It's difficult.

I mean, especially if I try to explain the software you make and then try to explain what an evangelist does. You know, that's tough. But, yeah, it's definitely trying to explain automation, virtualization. I actually was trying to explain it to my, we just moved into a new neighborhood, and I met my 75-year-old neighbor yesterday. And that was very difficult to explain what I do to him.

And he sort of just glazed over and smiled. I know that conversation. I meet my neighbors and I tell them I work for Hewlett-Packard. And it's, oh, I need you to fix my printer. Yeah, exactly. No, I don't. GitHub is kind of easier to explain to people because it's just like, hey, it's where a bunch of people get together and share code to make. If you just tell them websites, they can understand that.

But when I was at Engine Yard, it was a little more difficult. But if you try to explain that you help people make online businesses that process credit cards and do transactions, and sometimes they need a whole bunch of servers, and some days they don't need as many. They kind of got virtualization, but in general, my parents just think I'm a computer nerd. So this is the part of the show where we kind of turn it around and see what has you guys excited about open source.

So Seth, you're up first. What's on your open source radar? Well, in particular, since I'm a user chef, there's two things that I've actually started committing code to and I love. The Fog Project is awesome and I'm sure we've all heard about that, but it's sort of the Ruby abstraction layer for all the cloud providers.

And it's sort of an interest to me because our tool knife, which is our command line utility, and it's sort of how a chef cook, like all of us us that are using Chef actually interact on a daily basis with Chef. It's this awesome command line utility that 37signals donated to the community and sort of taken on a life of its own. And under the covers, you can actually call Knife EC2 server create, and it'll pick up your credentials, and using F using fog under the covers it'll actually start an instance uh get the information back about how to log in that server and then start bootstrapping it with chef which i think is really cool so i've really started messing with that

quite a bit more and i think you know cory actually being an engineer those guys are the guys that started the project i think and it's it's a very cool project um other than that i've got a lot of interest lately with rvM and Homebrew and some of those things just for the reasons that Corey mentioned just being able to configure and test under multiple versions of Ruby and that kind of stuff so those things have really made it a lot easier on me Speaking of RVM I've gotten

into Infinity Test and some others lately that allow you to test multiple RVMs as you're developing gems to test multiple versions of Ruby as you go and those are really cool That's very cool Corey? as you're developing gems to test multiple versions of Ruby as you go. Those are really cool. That's very cool. Corey?

No, basically Fog's pretty amazing. Wes has been doing a really solid job of just kind of working with the community and getting people, if you're into working with clouds and things like that, it's a really pretty powerful tool. It's not open source, but the Labrado tool I mentioned earlier is just amazing for keeping systems under control and getting metrics around what the different components in your system are working with. There's also, we use CollectD for certain parts of our reporting.

So we've been using a tool called Visage. I think that the guy, he might work at, he works at Bulletproof Networks. Okay, I thought he worked on Chef or something like that, but he apparently does not. But it's a different and slightly newer and nicer interface to collectee. The old collectee standard graphs are like GD,

and they feel like they're from 2000. The newer stuff at least feels like, you know, it was written by people with a little bit of taste for designing things. So I'm pretty impressed with that. Other than that, there's been very little that I can think of right now that comes to mind. The OpsCode platform is pretty much what I would tell people to check out, so I'm not really sure.

The platform, that's the other thing I just want to mention to everybody, is you can sign up right now for free and you get five servers for free. So you can manage up to five servers right now. And honestly, we're in beta, so if you have more than five servers, we're probably not going to charge you. So definitely if you're getting started, I, we're probably not going to charge you. Definitely, if you're getting started, I would say get out there and just sign up. There's some really cool getting started guides that can help get you rolling. I'm usually in the Chef IRC rooms, too, if you're getting started.

It's just my Twitter handle, which is S-C-H-I-S-A-M-O, S-C-H-I-S-M-O. Like I said, I'm sure Corey can tell you the same thing. It doesn't take a lot to get rolling and start doing something productive. Yeah, that's kind of the best bet is when the next time or when you need someone else to do it, it's pretty trivial. It's always kind of nice. Well, our users have been hankering for some non-web content on the changelog, and this is right up their alley. So certainly appreciate you guys joining us today.

Cool. Thanks for having us See it in my eyes So how could I forget when I found myself for the first time Safe in your arms As the dark passion shines