The Ruby Freelancers Show 013 – DevOps

00:00
Download MP3

Panel Charles Max Wood (twitter github Teach Me To Code Rails Summer Camp) Eric Davis (twitter github blog) Evan Light (twitter github blog) Jeff Schoolcraft (twitter github blog) Discussion Developers playing Systems Administrators Automated scripting Chef Puppet Heroku Moonshine Phusion Passenger Apache HTTP server Nginx Server Setup Ongoing Maintenance Engine Yard Chef Recipes CouchDB PuppetLabs Ubuntu Debian apt apt-get CentOS LTS Releases Rails 3.x RailsMachine Rails 4.x is ditching plugins Why are you doing DevOps? Stores your Operational changes in git. Saves you time on more than one server. Copy up a script and then script the login and script run. Puppet in Solo mode Bootstrapping your server Vagrant Testing configuration Nagios Virtualbox Staging - should mirror production Chirk Slicehost Linode Rackspace Cloud Make the client pay for hosting and do the systems administration yourself Amazon EC2 & S3 Memcached Deploy with git Scaling Load Balancers Provisioning a VM PostgreSQL VPS - Virtual Private Server Redundancy Monitoring Sinatra Mail Gem Pingdom Twilio New Relic Airbrake Be Proactive screen Picks Deploying Rails (Eric) Zite (Eric) Prismatic (Evan) Wemux (Evan) Solar Clipper (Jeff) Chronomate (Jeff) Getting Things Done (Chuck) Last Pass (Chuck) Book Club We'll be reading Get Clients Now  and discussing it on the podcast sometime in June.

Transcript

JEFF: Evan, do you have a mic on your headset? EVAN: Yes, I do. JEFF: Put it away from your mouth. EVAN: I already did. JEFF: Put it away more. CHUCK: [Chuckles] [This podcast is sponsored by Harvest. I use them for tracking work and invoicing clients. You can get a 30-day trial at getharvest.com. Use the offer code “RR” after your 30-day trial to get 50% off your first one.] CHUCK: Hey everybody, and welcome to episode 13 of the Ruby Freelancers Show. This week on our panel, we have Eric Davis. ERIC: Hello. CHUCK: We also have Evan Light. EVAN: For the record, I'm drinking green tea. CHUCK: [Chuckles] Green tea? Okay. We also have Jeff Schoolcraft . JEFF: What's up? CHUCK: And I'm Charles Max Wood from teachmetocode.com. This week, we are going to be talking about Dev Ops. So I've heard the term Dev Ops. Is there kind of an official definition what this is or is it just developers that run severs? EVAN: I thought it was developers who basically play at being sys admins. ERIC: The way I've always seen is it's not developers doing something, it's more along the lines of instead of logging in to a server and doing stuff manually, you write code that does it for you. So it's more of the automation scripting side. Most of the people who I know are actually system administrators that get into it, but some developers get into it because they know the code side. CHUCK: Okay. So we’re all pretty familiar I think with the tools that are out there like Chef and Puppet. What are you guys doing? EVAN: Heroku. [Chuckles] I thought I’d get that out there early. CHUCK: That’s fair enough. ERIC: I'm using Puppet, and so basically standard Vanilla Puppet and I'm also using a Rails plugin called Moonshine, which is by Rails Machine. It takes Puppet and hooks it in with Capistrano, and does a whole bunch of stuff. So the end result is whenever you deploy using cap, it actually runs your Puppet stuff, so it's kind of like dev ops on deploy. CHUCK: Right. So when you deploy, it goes in and if you specify the specific version of Apache or Nginx or something, then if that’s not the version that's running it will upgrade it or what have you? ERIC: Yeah, and you get a couple configuration files and stuff, and you can say it like, “Oh, there's a bug in Passenger, so we'll going to redeploy; download Passenger, recompile it and it will know that, ‘I recompile Passenger, I need to restart Apache.’” And all the standard dev ops recipe type stuff. CHUCK: Okay, cool. So is this something then that you would run against your server when you need it to deploy a new instance of your application? ERIC: No, and that’s actually a good thing. There's kind of two styles when doing dev ops: there's kind of the server setup like you go from blank server, to I have all my stuff configured. And then there's also the kind of ongoing maintenance, which is you already have a server that’s running, you need to do upgrade, you need to make changes to it. And those actually, some people actually try to split them to different tools, but the better tools actually merged into the same thing. So Puppet can work with a clean server, or it can work with stuff already there. Moonshine is basically because it's using Puppet, it works in either case; there’s like a bootstrapping script where it gets Ruby installed and all that. But for the most part, every time you deploy, it runs through and says, “Do you have your database installed? Is your database running? Is Apache installed? Is Apache running?” All of that kind of checks. So it slows down your deployments quite a bit, but it also makes sure your server is always running right. CHUCK: So, has anyone here used Chef? EVAN: I've tinkered with it just a little bit, but nothing serious. JEFF: One of my clients uses Chef. They’ve been Engine Yard deploy, so everything’s managed through Chef. CHUCK: Yeah, I've used them under the same context. I haven’t actually setup a Chef server or anything and done deployments, but I've heard a lot of good things about the recipes and just the breadth of the recipes. I don’t know a whole lot of about Chef though. There is a show out there, a podcast, that’s kind of inspired by the format that we follow with this in Ruby Rogues and JavaScript Jabber, it's called “food fight”, and they talk a lot about dev ops and Chef. It sounds like there's a recipe for almost anything you need with Chef. Eric, why did you choose Puppet or Chef or some of these other ones? Was it just because of Moonshine or was there another kind of driving reason for that? ERIC: There's a couple reasons. The first one is I started looking at it a long time ago. I think Chef just came out, and it wasn’t really that stable. And I don’t know if it's still anymore, but it used Require and CouchDB and a whole bunch of other things. And I honestly just couldn’t get it running. And kind of a side note, I've been doing system administration 5,6,7 years now, so I know my way around Linux, but I couldn’t get Chef working. And another thing is Puppet Labs, the creators of Puppet, they were actually one of my past clients, so I know the founder, I know some of their guys, some of their support teams, so it's just easier for me to get Puppet running. And then I found Moonshine and figured, “Oh look, Moonshine actually does what I need for this actual app,” every deployment type stuff. So, just all of those factors combine to, “I'm going to use Puppet instead of Chef.” And really, they are both good tools; they both do the job. It's just a matter of which one fits your style, and if you have existing infrastructure like Engine Yard that’s Chef-based, if I was going on Engine Yard, I would learn Chef. It's that kind of thing. CHUCK: Right. That makes sense. I actually know Andrew Shafer. He used to live out here at Salt Lake City and he was one of the co-founders of Puppet labs. And then I guess the other founder is Luke Red path? ERIC: No, not Redpath. Kanies. CHUCK: Kanies? Anyway, they’ve done some really cool stuff. I don’t remember which ones it is, but I think one of them uses a DSL, and the other one uses just plain Ruby for their DSL, I guess. ERIC: Yeah, Chef is plain Ruby with like Chef DSL past stuff. Puppet has it's own DSL. It’s very Ruby-based. I've actually found it’s kind of similar to JavaScript in the way you use it, but it looks like Ruby. But Puppet also has its own Ruby DSL too, so Puppet can actually do two different styles. But I mean realistically for what I do, and what most people who are probably listening to this podcast are going to do, they are going to basically download and use open source ones that are already out there, and all that they are going to do is kind of glue in the components together. So the DSL stuff really doesn’t come up as often as you would think. It mostly comes up when you are writing brand new code. CHUCK: Right, that makes sense. So I'm a little curious, what Linux distributions are you guys using? I know Evan keeps saying Heroku. EVAN: I didn’t say anything, because you already said it. CHUCK: I tend to like Ubuntu if I can pick, or a Debian-based system. I was a systems administrator in the university that used to RedHat for 6 years, so I'm pretty familiar with the tool sets that come on RedHat. But I just like the way that apt get, I liked the way that that runs maybe a little bit better than RedHat stuff. It seems like it's more up to date and things like that. EVAN: When I use Linux for home use, it's usually for home use. I use Ubuntu. And yeah, pretty custom to apt get and yeah, it works fine for me. ERIC: For me, I use Debian quite a bit, but now all my stuff is Ubuntu. Laptop is Ubuntu, servers are the Ubuntu long-term support versions, which kind of sucks because they’ve been out for a while now And there's a new one coming soon. So it's like you got really old stuff, but it's nice because it's long term support, it's going to be stable and especially for servers that you really don’t wanna be changing things a lot. And I think Heroku actually uses Ubuntu or they might use Debian, I don’t remember whatever they use under the scenes. CHUCK: Yeah, it's one of those. So I'm not sure if I was completely clear. So does Moonshine then do server setup for you, or do you have to do that for yourself and then they will maintain it from then on? ERIC: Kind of both. For Moonshine to work, you need to login and set your root passwords, set a couple directories. And I think you just need to create a user, so whatever deployment user is. And then if you've used Capistrano, there's a cap setup test, which basically gets everything ready for Capistrano. And then there's a cap deploy that actually deploys and does all that. Moonshine is similar. There's a Moonshine setup that will download whatever Ruby you want, get it in there, install Ruby gems, install the few gems that moonshine needs to bootstrap. And then when you do your normal deployment, Moonshine runs through its entire batch of recipes and sets everything up. CHUCK: So there is some setup then. Is Moonshine available as a gem? ERIC: Last time I checked, no. last time I checked, it's a plugin. It might be getting gemified, but I don’t remember. CHUCK: Okay. JEFF: It's only been very recently that Moonshine has even supported Rails 3, right? ERIC: Yeah, Rails 3 is semi-new. It's supported bundler a bit before that, but both of those are semi new Stuff. And most that I do are  Rails 2.3 pre-bundlers, so it worked perfectly. I have it on a Rails 2.3 that uses bundler. And Moonshine is kind of a bit tweaky, but it's just a matter of you got to setup bundler and Capistrano and a Moonshine, I think. But it's actively worked on. I know Rails machine uses it for most of their infrastructure, so it's not like someone wrote the scripts, and put it on GitHub and kind of walked away from it. It's probably something that will be supported for a while. CHUCK: Alright, sounds good. So one other thing that I'm a little concerned about then if it's a plugin because I'm assuming that it is not an engine, is that as of Rails 4, they are getting rid of the plugin infrastructure and forcing you over to engines. ERIC: Yeah, I don’t know.  The idea of getting rid of plugins like that just in general for Rails is kind of suspicious, like it's a big major change, and they are going to require like a lot of changes in the community, so I wouldn’t be surprised if there is some gem you can install that  basically re-enables plugins. And you can always load plugins yourself, just with manual require. So if stuff isn't gemified by that point, you could probably hack around it. And just conceptually, I think Moonshine and Moonshine actually has its own plugin systems too. I think all of those could be gems. I think it's just a matter of like doing the work to get them packaged and tested. CHUCK: Any other comments or questions about some of the technology behind dev ops? Because I have other questions, but they don’t directly address that. ERIC: One things that’s kind of more of a higher level like you need to think about why you are doing dev ops. For me, the reason my I do it is because I can login to servers and do stuff, but I don’t wanna have to all the time. And I can actually change one thing, and it's stored in Git as I get upgrade it to Passenger 3.1 or whatever. And if I need the roll back, I can see when I upgrade them  and actually track like why I made this change with the Git log. So that’s a reason for me. Some people go and do a lot of dev ops because they have to manage a dozen, two dozen, three dozen servers. And so sitting there in the console and doing it all by hand is a waste of time. EVAN: Well, not only that. I mean, you will have more consistent configuration management that way if you script it. That way, you know when run a command, it will execute across all those machines rather than if you do it manually, you might forget to hit one of them, possibly. ERIC: Yeah, that too. EVAN: So, repeatability. CHUCK: Yeah, and that was a big thing when I was a systems administrator at Brigham University, was I mean, everything we did was scripted and it was really for that reason was just so that you could make the changes, roll them out and know that they were consistent everywhere, and you could target the machines that needed it. And you know, skip the machines that didn’t. ERIC: Yeah, and when I was a system admin, I had a bunch of little scripts that we had like a definitely like, “Here’s our web servers, here's our data base servers.”  I can run the command, and what it will do is it will over each web server, log me through SSH. When I close that SSH session, it logs me to the next one. And so it's like, I use that to make sure I would actually do everything on every server I need to, but it's still a matter of once you logged in through SSH, you have to remember to type all the commands and have all these wikis before your documentation and step 1 through 42 and all that. CHUCK: In a lot of cases, what we would do, and I think some of these systems actually work this way is that we would actually copy the script up into some kind of bin directory or bin folder that was in our path, and then you could just script the login and run the script from there. ERIC: Yeah, and that’s actually my Puppet configuration right now, so Chef does this and Puppet does it. You have a client server model, you have your server where everything is stored in all the clients connect to and get all like, “What do I need to configure?” I use Puppet in a solo mode where there is no server; you basically log in to the system you wanna do the work on, and you run Puppet for a few flags, and it just applies whatever it needs for that system. And so I actually have a couple simple wrapper scripts and shell scripts, so I log into a system and say, “Run my Puppet stuff.” And it's just a command line thing, it's manual, but it's kind of a step towards where I need to be. And I have the same thing for actually bootstrapping; it's a shell script that would download Ruby 1.9.3 I think, get a compile, download Ruby gems, install the Puppet Ruby gem and basically then my server is bootstrapped and ready to go. I mean, no matter what you do in dev ops, you still have like those little shell scripts that gets you bootstrapped and get everything started. CHUCK: Another question I have then is do you use something like Vagrant to set up staging servers locally? ERIC: Not for staging servers. I use Vagrant if I'm testing configuration, or if I wanna… so I use Vagrant like if I'm writing a new… I was working on some Nagios stuff. And Nagios, if you don’t know, is monitoring of like you have a Nagios server that checks and does a ping like, “Is this other thing up and running? Is the site down?” type thing. So you need at least two servers to really do it the good way. So I use Vagrant to kind of boot up those two virtual machines using Virtualbox. And then my Puppet stuff, destroyed those machines, booted them back up clean and make sure that my code worked. Once it was done, then I was able to push it out to actual production. But I don’t know if you could use it as staging because staging implies this is the same as production, but live users aren’t going to it; just internal users are. And so Vagrant kind of… I think it requires Virtualbox. It's not really the right tool for that. CHUCK: I agree. I just meant in general, if you just wanna machine up, that’s in your local network that is running your apps, you can test it out there, test your deploys or whatever. ERIC: Yeah. In that case, like the test server you can just throw away later, yeah Vagrant is perfect for that. Because once again, you can write a Vagrant file where it's like, “I want a server of this much RAM, this IP address,” that way, you are once again storing in Git , what you are using to test against. Maybe you were testing against the latest Ubuntu, but your actual live server is an older Ubuntu and you can look in that Git and you can say, “That’s going to be my problem. I'm going to have problems with package versions later on.” CHUCK: That’s one thing I wanna bring up really quickly is that usually, in smaller applications, I mean, I've seen everything from having an actual staging server and a production server, but I've also seen set ups where it's literally, you finish the code, you check it in and you deploy directly to production, which may or may not be the right way to go.  It depends on the tradeoffs and the return on investment for your staging server, how much money are you going to lose if you deploy something that doesn’t work the way that you need it to or it doesn’t work at all. But it seems like the most robust setups they have some concept of like a development environment and that can either be running on your local development machine, or can be something like what's running on Virtualbox or something like that, if you want it to more closely emulate what's going on out in production. And there's a staging system, that as Eric said, basically mirrors in every way possible, it looks exactly like production, except the only people who are going to be hitting that are basically your people who are verifying that it works right. So it's usually stake holders, developers, QA people, and anyone else who’s kind of on a beta program like that. And then the last thing is then you have your production, and so the production machine is where you are running your application. It's usually a little bit more secure. You restrict who has access to that and things like that. Anyway, I just wanted to kind of walk through that, because a lot of people I found aren’t really familiar with that kind of setup. ERIC: For the past couple of years, I basically told every client, “You need to have a staging server setup.” Because I'll write code on my development site or development machine, push it up the staging, that’s where they are able to do the acceptance test and run through themselves and make sure everything is good, and then it goes out to production. And so you have kind of a three step process. With Chirk, because I'm kind of my own internal customer for building Chirk, I actually skip the staging environment. And so I write on in development, I push it up right into production. The only reasons I can do that is because I have a continuous integration server to make sure stuff doesn’t break stupidly, and then I have kind of a couple tools around to make sure like if in production things break, I'm notified about it really quickly. Actually, I'll get a phone call. And so that way it's kind of like I remove that whole staging thing that I have to go through, and so I can deploy faster. The other thing is like if I had a staging site, all I'll have to do is push through, click through on the mouse a couple of times and just click around the site and not actually really test it. So the value for staging is really low. And that’s something like as a freelancer, you kind of need to talk to the business, forget what the risk is. Like if you're doing sites that’s going to take their main site down, that might be too much of a risk and they might want you to set up a staging server. Or I've seen one where you have a staging server where code goes through right away, and I've seen one that also has a QA server, where once things are good on stage and it goes to QA, and that’s where the formal QA process takes over and all that. CHUCK: Yeah, that’s something too where it really depends on the client’s risk in my opinion as well. I mean, I've hosted stuff for clients, and that’s another  question that I wanna ask is when you wanna do that and how you manage it. But anyway, yeah it just depends. If they are just doing a beta and people just kind of understand, “Hey, this might be a problem,” or what have you, then you can kind of figure out what the tradeoffs are , but once they are out in production, they are making money with it, then they will assess where the downtime is and how that will affect them. So that does lead in to the other question and that is in a lot of cases, I have clients that come to me that don’t know how to host a Rails app; either they are a shop that does have servers and does have IT guys, but they are not familiar with setting up a Rails hosting server with Passenger or anything else, or they are just some guy that has some idea that’s paying me over the next few months to develop a website for them. So, what's your take on setting up hosting for a client, and do you ever actually host the clients’ kind of a beta site where they can go and look at it. ERIC: So for me, I used to use Heroku for some things, but I've had some problems with Heroku just outages and stuff. But I still use Heroku for my own internal apps, and for like free apps like if it goes down, I don’t really care. All of my customer apps, and all of my own like ‘mission critical’ site apps are all on virtual private servers; either at, it used to be Slice Host with my main one, but they’ve been bought by Rackspace. So I'm either at Linode or I'm at Rackspace in the Rackspace cloud. Both of them are really good. I'm trying to evaluate which one is the better one for me. Linode is a bit cheaper. Rackspace has a bit more support, so it just kind of tradeoffs. I don’t host them myself. I make my client actually buy the server, but I actually do most of the sys administration for them, so in once case I've actually set up Moonshine for them and so whenever I do deployment, it goes out to their server. And then a couple other clients, I would just push the code through their Git repository, and they would actually go and do a deployment, and then a couple others ones, I wouldn’t use Moonshine. I would just login every month or so and just do the manual systems administration stuff. EVAN: So I guess that I get to play Heroku advocate during this whole conversation because I generally have used Heroku for pretty much everything. I've had clients who did their own hosting, and actually have moved to Heroku. And for the most part, the reason is that a lot of people just don’t want to have to deal with dev ops. I've used Linux since the mid-90s. I've used it off and on though. I developed on it before, and yet I don’t like having to play sys admin. I just wanna build stuff and deploy it. If you don’t need a particularly customized deployment environment, that is if you don’t mind having each and every component of your system on a different virtual machine somewhere, well in the amazon cloud, and in the same zone, then Heroku is not too bad. You are pretty much guaranteed with Heroku that you are going to have your Memcached be on a separate machine for your Rails, and on a separate machine from your database, etc., etc. The only problem there is you just have to be aware that every single time that you call from one service to another, that there's never [unintelligible], and so it adds up. But as far as outages, this is where I feel like I'm defending Heroku. Can you guys send me a credit to Evan@tripledogdare.net? CHUCK: [Chuckles] EVAN: But that said, I only had the one bad outage with Heroku when EC2 went out, and Heroku didn’t come back when EC2 came back. But other than that, I think it was just one or two very small outages on the order of like hours. And otherwise, they’ve been fine. I used them for staging servers all the time for clients to play with things, before they go to production. I usually use a free environment for that, and I guess a rare case is when the app has been so complex, that it just wouldn’t work in a completely free environment or there were features, moving parts, like for using web solr or something like that, I’d have to pay for that. I said I pay. No, I don’t. I would have the client have the Heroku account, have them give me access to project so that way, I could manipulate things but they pay the bills. And that tends to work pretty well. And in terms of justifying to the client, all I have to tell them… I mean, Eric, I assume in your case that you have a bunch of scripts written in Moonshine that you just reuse across projects, right? ERIC: Yeah. EVAN: So if the client doesn’t already have that… sorry I've got a cat here who is getting into things. If the client doesn’t already have that, then either they are going to write stuff like that on their own because I don’t have either, or they are going to use Heroku. And that automation saves them the investment of having to build their own automation. So the money that they spend on Heroku – at least for a while – is cheaper than paying for someone to do the dev ops work. CHUCK: I agree with what most of Evan said. He outlined the tradeoffs pretty well. The things that I like about Heroku, are yeah, the deploy via Git is like dead simple. EVAN: Oh yeah, I didn't mention that, but the deploy via Git is nice. CHUCK: The other thing is if the client is insisting on using a database system other than PostgreSQL, then you can't host it on Heroku. EVAN: Not true. Not true. CHUCK: You can, but you have to point it to a third party system that’s running the database. EVAN: But that’s not hard. I've done that before, because I've had one client that for whatever reason, wanted to use Amazon’s MySQL. It was just a matter of setting environment  variable in the Heroku configuration. It's a piece of cake. So it's just yet another component that’s external to Heroku at that point. CHUCK: Yeah, I mean that’s pretty much all there is. The other nice thing about Heroku is that as you upgrade the plans and you get more… I don’t remember if they still call them dynos or something else. EVAN: Yeah, they still call them dynos. CHUCK: But basically, they are just units of utilization. I don’t really know how to define them well. EVAN: They are single Rails instance, and yeah, they have some equivalent amount of memory and horse power associated with them. CHUCK: Right. So you know, as you use more resources with your application, then they may say, “Okay, you’re out of resources. You need to upgrade.” But the nice thing is that it scales up pretty seamlessly. I really haven’t seen anyone have any problems with scaling on Heroku. So that’s another trade off, where with the other dev ops solutions like hosting it on virtual server or something somewhere, you have to setup the load balancers, you have to make the backend machines available to the load balancers, maybe setup some kind of a reverse proxy to handle all of the caching. EVAN: And if you are concerned about how quickly you can scale up and scale down, well, scaling up in Heroku is just a matter of literally throwing a switch and waiting a few seconds. And scaling up when you're handling your own scaling is usually a matter of provisioning another VM, and then firing it up. And that could take an hour or two maybe, unless you have them sitting around in which case, they are costing you money anyway. CHUCK: Well on a lot of cases, you could clone them. ERIC: Here's something else I think about and so it doesn’t seem like it's a pro-con Heroku argument: all of the things you guys talked about are ease of deployment, the scalability all that. The ease of deployment is for people that don’t have scripts already. The scalability stuff is about for public sites. For me, 99% of my apps are internal business.  And in order to require to scale one of these apps, these companies has to hire a thousand people. And you know, there's a bottleneck in the organization. And the other thing you need to think about, I mean it comes down to client requirements. I had a government agency as the client, and I had a European educational institution as a client. The government said, “No, we will not let our data go on a public cloud,” like Amazon S3 or any of that stuff any data. I mean, I can't use S3 uploads to get those files. And then the group at Europe, they are like, “It's too much lag to get on to use Heroku,” and so your client requirements are going to really dictate your hosting a lot more than anything else. If it's the standard US based startup type thing, Heroku might be the best thing to go, but it boils down to what your clients want and what kind of risk they were willing to accept too, because like you were saying like Heroku has outages, but when it has an outage, your hands are pretty much tied; you just got to wait for them to bring it back up. Versus a VPS, you might be able to do some system admin work to kind of patch that along or whatever. And so it just depends on where you're shifting the risk too. CHUCK: That’s true. And the other thing is we're talking about scaling tradeoffs, but there are other tradeoffs. I mean, if you need some kind of specialized service or things like that, and you don’t want to worry about connecting from Heroku to the third party servers or whatever, or you feel like if you had kind of an overall security protocol that you have across all of your servers to manage this that or the other, then in a lot of cases, you may wind up setting something up to manage that kind of thing across all of your servers and you might be better served by getting some kind of virtual network on Amazon or going through one of the other server providers. And they may even set you up with like a subnet in some cage somewhere and you are actually running on bare metal on the actual machines of the virtual machines. And you know, there are tradeoffs to that as well. Whatever your requirements are and what you think is the most cost-effective for your clients, or what they think is the most effective for them because sometimes they can just an opinion and you know, no matter what you say, that's the way it's going to work, you may find yourself in a different position. But for smaller apps or depending on what the stack is that you are dealing with, Heroku may be a really nice way to go because they can just manage the whole thing and you just deploy your Git and done. EVAN: Like you said Eric, you are dealing with a lot more enterprise clients; I tend to deal with a lot more start up clients, so Heroku tends to suit them pretty well. Completely agree about the risk. I've had one client who uses Heroku, who was concerned enough about having some redundancy that they were talking about -- I think I parted ways with them before they got around to it -- but they were talking about having a very simple VPS setup, and emergency backup just in case. But something just something very simple that they  could cap deploy to, but using Heroku as their primary system. ERIC: Yeah, and that’s something I wanna bring up too is some beginning freelancers don’t think about this, but your project might be to build this thing for customer. A piece of software. That piece of software doesn’t have to be one Rails project. For example, I had rather large Rails project I was working on for a client, and we needed to send email, and this was all hosted on VPS and so, instead of actually putting all that email code in the actual main Rails app, we built a simple app through it on Heroku using Sinatra, and think the mail gem or pony gem or something like that, and basically use Heroku’s free hosting and do our mail. So an actual main app just did an API called from the VPS to Heroku and sent our mail. And so you can actually kind of break apart apps if you wanna take advantage of the certain things on the Heroku system that’s always up. They have integration of SendGrid or this and that, and kind of figure out what your clients really needs and then from there, devise how you are going to architect it all. And so if the mail server goes down for a little bit, that wasn’t the problem because in the mail app, we had a simple queue, so it kind of just store mail that the API have failed or whatever. EVAN: For my own personal development, I tend to default to Heroku. With the client, I don’t default to Heroku at all. It's all usually a matter of assessing what they need. And often, I find that Heroku tends to suit them better than dealing with their own hosting. But there have been a couple of, at least one occasion, where having their own hosting made more sense. With mostly, for I think similar reasons what you said there Eric, the client would not let certain pieces of information out of their control, to get out of their control at all, so they had to be on a dedicated hardware, so on those circumstances well there was no discussing it. That was going to be a cap deploy. CHUCK: Yeah, so one other thing I wanna get into here, and again, Eric has kind of a alluded to this,  he’s been using Nagios for monitoring. So do you set up monitoring for your client applications? Do you only worry about that once they are in production, and kind of being used as a public site? How do you kind of deal with that? ERIC: For my client applications, I don’t do any monitoring, because mostly their business internal stuff, some of them I can't even get to. I don’t even have SSH access to one of my clients. I have to push code and say, “Hey, upgrade it whenever you want. Here's the upgrade instructions.” For my own stuff, I used the combination of Pingdom, which just pings I think every 5 or 15 minutes, and make sure the request comes back. And then I have Nagios for heavier stuff. Nagios test like for normal stuff, “Is the site up? Is Apache responding?” But also, “is PostgreSQL responding on internal socket. Is Memcached up and running?” All that stuff. And so I actually have a combination of my Pingdom checks if my Nagios server is up, and my Nagios server checks if all the other services are up on certain apps. And then I kind of talked about this earlier. I have hacked together a script that if Nagios detects there's an outage, what it will do is Nagios will email you, but email doesn’t get read while you are sleeping, so my Nagios will actually call my cellphone using, Twilio or whatever it is. And it will say, “Hey, your server is down. Your server is down. Your server is down.” It will keep calling me until I actually respond to it and say, “Look, I'm fixing this. Quit calling me.” type thing. So I will get that 4am in the morning page to kind of get up and fix critical servers. CHUCK: Right. Makes sense. What about the rest of you guys? EVAN: Monitoring? Again I'm using Heroku, but I ended up using New Relic a lot from performance and New Relic also reports errors, so at least when things get bad, otherwise, I'm using Air Break. I mean, I'm not worrying about server outages when I'm using Heroku, because if that goes down, I'm going to hear it. [Chuckles] Because lot of things go down if Heroku goes down, usually. CHUCK: Yeah, that makes sense. I either get a phone call from one of clients, because I haven’t really set up monitoring on this stuff, but again most of my clients are still in kind of a private beta or even alpha state, and so the only people using it are them and their friends. EVAN: I've been kind of on the same boat there too. I've only had one client; it was production deployed when I got there. And that was an entirely different story. So otherwise yeah. CHUCK: Yeah, but other than that, I use Pingdom for my websites. As long as they are up and getting response from Apache, I really don’t worry too much about them. If something is broken, I tend to hear about it on Twitter though. ERIC: So I will say though like having monitoring and proactive about it and saying, “Hey client, I just found your site is offline. I'm on the server right now fixing it.” That is huge for goodwill. Like me and my wife were out shopping Sunday at Ikea, so about an hour away from our house, and got a notification. I actually, on my iPhone, logged in to the server. I don’t know if I rebooted the server or whatever, but I've fixed it and got their server back up and running within like 20 minutes of hearing that it was out. And that kind of stuff is not that hard to setup Pingdom, and it's really cheap as a service. And you can just get paid back so quickly on goodwill, even if the site is not very used, it's a private beta, there still might be people trying to use it. CHUCK: Yeah, I think that’s true. So one other thing that I wanna jump in on real quick and just talk about is am I the only one that’s ever hosted my client’s app on my own servers? ERIC: I've done it. I got my own server setup so like it will be whatever, clientname.client.mydomain, and it was like a cheap passenger type setup, but I only did that for a few months. Ended up just telling the clients that they need to get their own staging server, because it's killing the rest of the server. CHUCK: Yeah, I kind of ran into the same thing with my client. And it was kind of interesting because he switched it over. What he wound up doing was he talking to another company about doing some of the mobile styling on his website, and so he moved it over into his server. And yeah, it looks like I lost him not too long after that. And so, it turns out to be more of a pain than it's worth, so I really like the approach that you guys have brought up, where it's like, “Look, here are my recommendations for hosting. Let’s get something set up, and then we will move it over and get it running over there.” ERIC: I mean the hosting industry in general, it's built on volume like a lot of customers, and it's built on support. Everything else, like the technical aspects, and all that is very tiny compared to those two things. And so, taking on hosting for your clients or doing  any kind of reseller things is really completely different skillset than I think most people listening would actually have. And it might not be an actual business service they want to provide. There's companies out there that are going to do it more inexpensively and better than you, and it's outsourced if you don’t have the skills for it in a way. JEFF: And this is… [Chuckles] yeah, I'm still in the call, so… [Laughter] EVAN: Hi, Jeff! You woke up! JEFF: This is the one thing. I fairly, I would never, ever host for somebody. I mean, you know, it sounds like a good idea, right? EVAN: No. No, it doesn't. [Chuckles] Go ahead. JEFF: But there is, “Oh, but they need a host anyways and I can do it for them.” And it's the same as registering domain names or people. I don’t do that either. I have one client that I actually bought SSL certificate for, but even that’s a headache. I mean, it sounds like easy money. I mean, it's going to be up most of the time and I'll get whatever, $30-$40 a month extra from this client. But I mean, it only takes one time for the server to go down in the middle of the night, and the client to be upset with you, or if you'll have to get up and deal with it, just make it completely not worth it. I don’t wanna do any server maintenance. Anything with servers, really. CHUCK: Yeah, it makes sense. It's one thing if it's your own deal, but yeah but I found that it turned out to not really be worth it. I mean I have one client that I'm still hosting his app for, but he’s like super-duper forgiving, and realizes that I'm using the server for other things. So it's okay there, because if it's down, he just kind of, “Hey, it's down.” And then that’s it. But yeah, I've moved all of my other clients off and helped them find another place to put their app. ERIC: And that’s something like, I did this a while back is, if you are coming to the freelancer as kind of like the consultant. You can say, “Look, I don’t provide hosting services but here’s the list of the hosting services that I recommend to my clients, and here’s my own review my opinion of them.” You can say Heroku is inexpensive to get started on, init can be more later, blah, blah, blah. But the point of like going to your client and saying, “Here’s the resource of the tools stuff that I don’t provide, but I've used,” and my opinion on them, that’s another really good thing you can give to them. And if you've been in the Rails community for a little bit, you can probably mash a one page PDF for about 20 minutes for that. Nothing crazy, information-wise. CHUCK: Yeah, absolutely. Alright so shall we get to the picks? Is there anything else you guys wanna add before we do that? ERIC: Dev ops isn't fun, and it's kind of trendy, I guess right now. But before you get in to really think about it if it's something you want. I've always enjoyed tinkering on servers, so I have kind of a personal interest in it, and scripting servers is always been kind of a passion. But if you hate system administration, and you hate servers and you'd rather things just magically work in the little cloud in the sky, don’t get into dev ops. Hire someone else to do it or pay someone like Heroku, where they have most of these stuff set up. Don’t think that you have to do dev ops or you have to do server administration because you don’t. CHUCK: I totally agree. So let’s get into the picks. Eric, what are your picks? ERIC: So there's one that’s really relevant. I might have picked it before, but they are pragmatic programmers have a book. I think it's called Deploying Rails. Let me check it real quick. EVAN: It's a fairly recent one, right? ERIC: Yeah. There's an older one Ezra wrote. So deploying Rails application is Ezra’s. There's a new one that’s out. I'll put it in the show notes, but it basically walks through using Puppet of how you do dev ops. It sets up the standard Passenger stack. I think it sets up PostgreSQL or MySQL. It actually sets up Nagios, and something that's actually graph like how your  cp is doing over time. It's a really good book. And I've actually copied and pasted some of the things right out of it. So that’s my first pick. The second pick is non-dev ops related. It's called Zite. It's called, “a personalized magazine that gets smarter as you use it.” If you've ever used Flipboard, it's kind of the same thing as Flipboard; it's an iOS or it looks like HP Web OS or Android app. And it basically uses your Google reader account. And I think delicious and a whole bunch of other things. And it will kind of suggest things for you to read. I logged in with mine and it basically picked up automatically that I like to read about Ruby and Rails, I like reading about Ruby and I like reading about business. And so it's like pretty customized, and it will actually give you new content that you probably wouldn’t see or you would have to find on like Hacker News or on Twitter. So it's a pretty neat little app. It's free and I've been using it for about a week now. CHUCK: Alright, Evan what are your picks? EVAN: I'm going to one up Eric on Zite, and I'm going to mention a new startup called Prismatic. I've been hearing about them on Twitter for a few weeks now. And I started using them, I guess it was a couple of weeks ago. They connect your Twitter account. What they do is they look at your twitter feed and they news out of there, and then they find content with similar themes and similar topics to the content that it finds in your Twitter feed, and then you can customize it from there, telling you which pieces of content you like and which ones you don’t. And then, it continues to get smarter and smarter. And I've been loving it. I've been looking at Prismatic more often than I look at more RSS feed, because well it just seems to find me very interesting things because it's based on the people I follow on Twitter, and the people I follow on Twitter has similar interest to myself. So I'll also put out there, I have one invite left for Prismatic. So I guess I'll say that if you are interested in getting it, the first person to comment on this podcast when it goes out, say you want the invite and get in touch with me, and I'll send it to you. So a contest, oh my gosh. The other thing I was going to mention this week is I started using something called Wemux, which is a nice little wrapper around Tmux, which I typically use for remote pairing. I've been using it for a few days now. It's still Tmux, but it just makes using Tmux a little bit easier.  Attaching to a Tmux session or really a Wemux session now doesn’t require finding the socket in the file system to connect to anymore. You actually run Wemux attach, and if there's only one session running, boom, you are in it. So it just makes finding other Tmux sessions easier. And so I'm liking that for when I'm pairing with clients remotely. ERIC: That’s kind of funny because that’s how I use my screen like… EVAN: Yeah, that’s how a lot of people use Screen too. ERIC: Well I'm saying, I don’t know if people know, but if you use “screen –S” and then a text, you actually label session. And so I have like 5 or 6 sessions and I just say “screen attach system admin” and it actually knows which one to attach to. CHUCK: Oh cool, Alright. EVAN: So I'll have a link to Wemux in the show notes, because I like Tmux over Screen. So, there. [Chuckles] CHUCK: [Chuckles] Yeah, it seems like the two of them… EVAN: They are basically the same. CHUCK: Yeah, how long has Tmux been around? EVAN: I don’t have a good sense of it. I only started using it fairly recently, but I heard about it a couple of years ago. I think it's been longer than that. CHUCK: Yeah, I know that screen has been around for freaking ever. EVAN: Yes. ERIC: Tmux came out in 2009, so that’s almost 3 years, September. CHUCK: It's just a baby. EVAN: Yes. You looked on Wikipedia also? ERIC: Whereas GNU Screen came out in 1987. EVAN: Yay! CHUCK: I think I was on twitter and it was kind of funny speaking of the Wikipedia stuff on when stuff came out, and I think it was Thomas Fuchs, he said that… it could have been somebody else, but he said that “My favorite text editor was created in 1976,” or something. And it turns out that that’s when both Vi and Emacs were both released. They were both released the same year. I think he was kind of doing that tongue in cheek. EVAN: I've been using Tmux locally… actually, I was just experimenting with it yesterday where I was doing all my development in my console using Tmux, so that way, I could switch shells without having to move my fingers over to where iTerm makes me do. I could do it all very easily off of the letter keys, so my hands have to move less. And I was kind of digging that, just using Vim for my editor and Tmux to control my shells. CHUCK: That sounds really cool. ERIC: Yeah, we should do a show on that. Like you guys would be like, “Oh my god, what the hell is Eric doing?” If you saw what I was using, because everything is on the keyboard for me. CHUCK: Nice. Alright, Jeff what are your picks? JEFF: Alright, mine are the Solar Clipper, Golden Ages Solar Clipper by Nathan Lowell. We've probably talked about that before. If we have, then this is a repeat. EVAN: If we haven’t, then yes, you should listen to it, it's good. JEFF: Yeah, so the thing is I bought the first three books, and he’s been waiting for like 6 months now to get the fourth book published. A bunch of stuff with  the editor, and finally. Evan mentioned it the other week. I don’t know, he mentioned a while ago about listening to it and I forgot you could listen to it and so, I went through the last three books in the last week or so. CHUCK: [Chuckles] EVAN: [Chuckles] It's kind of like what I did. You couldn’t stop listening, right? CHUCK: Yeah, sounds familiar. JEFF: They are addicting. EVAN: Yeah, they are. I was up really late listening to them when I did it. JEFF: It's sort of an anti-productivity tip… sort of. EVAN: [Laughs]  Anti-sleep tip. JEFF: Mass Effect or something. So that’s one. The second one is Chronomate. I mentioned Eon a while go. Eon, I don’t wanna say jumped the shark, but they jumped the shark and went from $20 single purchase or whatever that connected to a ton of different services for time tracking, to a $20 service that connected to nothing, and you have to pay $5 to the service you want to connect in that purchase. So I found Chronomate. It hooks up to Fresh Books. It's got this interesting feature that lets you round up your time tracking, so if you bill in ten minute increments or fifteen minute increments, it will round up for you -- which is convenient if you do that stuff. But it hooks into Fresh Books and works pretty well. I've been using that, so those are mine. CHUCK: Alright, so I'll jump in with my picks then. The first one that I'm going to pick is something that has been probably recommended on the show, but it's something that I just kind of finally got around into getting into, and that is Getting Things Done or GTD. EVAN: Yes! You’re welcome. CHUCK: Yeah, Evan is a very big proponent of this. EVAN: Physically and literally. [Chuckles] CHUCK: So I've read the first 20% of the book. I'm reading it on my Kindle, so I have no idea how many pages I've read. Anyway, I started applying just the stuff that’s covered in like the first two chapters, and I have to say that it's already made a huge difference. I mean, I'm not worried about what I forgot to do. EVAN: It's a load off your mind, right? CHUCK: Yeah, and the thing is the funny thing is that I am getting more done, which you would think, “Okay, having all of the ten million things that I’ve had to do in this list, well, now I know how much I’m getting done.” But that’s really not the case. It's really kind of interesting. So, I've made progress in a lot of different areas that I've wanted to make progress in, and I have this information that I just drop it into Things is what I'm using right now. And I've had several people tell me, “Yeah, once you finish and kind of get your head around the process, things won’t do everything you want it to do.” EVAN: I'mma let you finish but… [Chuckles] sorry. But as far as GTD goes… so I bought that book for a lot of people. What I tell most folks is, “Just get through the first exercise, and if you are not feeling less stressed out by the end of the first exercise, fine stop reading. But if you are feeling less stressed out, you owe it to yourself to get through it all.” CHUCK: So I haven’t read anything that said, “This is an exercise. Do this.” I think I'm still just… I've just made it through like the intro of, “This is how it works. And this is how we kind of think about it.” EVAN: Really? CHUCK: Yeah. EVAN: So you haven’t gotten to the “Dump everything in your brain on a piece of paper” kind of exercise? CHUCK: No. EVAN: Oh, wow. ERIC: That alone is good to do, even if you don’t know the system. EVAN: Exactly. But that’s the start of it. CHUCK: Anyway, I was talking about like their next steps, and you are going to have like a next steps list, and a someday list, and this kind of stuff. But he hasn’t actually said, “Okay, so to get started, you need to go and do this.” It was just kind of a, “Here’s a quick overview of the system.” And so the thing is, as I've gone along, I've just kind of applied that because it made such intuitive sense that it was really easy to integrate with my workflow. And so I mean doing that, and just getting it into things. And I don’t know if I'm sorting it all correctly, but I mean even when I just been able to do has made a huge difference. I'm really looking forward to getting more this in place and making it work. Anyway, I'm super excited about it, and I'm probably going to finish this book this weekend. EVAN: Awesome. CHUCK: Because honestly, it's also freed up a bunch of time – believe it or not. I'm getting more done and I'm freeing up more time. So all of these being said, it's just been awesome for me. So I'm really enjoying it. I think I picked Things on a past show, so I'm not going to pick it today. But one other thing that I really want to pick, I'm not sure if I've picked this before. I know I’ve picked it on other shows, but Last Pass is something that I use a lot. And many of you know that I have a virtual assistant, and the nice thing about Last Pass is that it allows you to share passwords. And now I understand that it's not totally secure. I think you can inspect the password field and get the password back or something. But I mean if these people are technical, and they are not using trickery to work around it, then you can share passwords. And you shouldn’t be putting in passwords that they can just steal or remember anyway. But it's really nice. So, everything I do now, logging in to my account and this and that and the other, it's all in Last Pass. I've only shared like the passwords to my podcast websites and things like that, that my VA needs to just do his job, and it's just been so, so nice to be able to get that stuff done. So yeah, if you wanna check it out. I've also heard good things about One Password, but I'm not sure what it's capabailities are. EVAN: What do you wanna know? That’s what I use. CHUCK: Does it do all those same things? EVAN: I heard some of that. Let’s see. One Password uses Dropbox, or can use Dropbox for synchronization, so I use it on my iPad, my iPhone and my Mac. I suppose if you really want to share it with someone else, then you could put it on the Dropbox folder that you share with the particular user, and then they could get access to your… you would have to give them your master password which is also an encrypted file. But if you give them access to that directory and Dropbox and the master password, then they could get all your passwords as well. ERIC: But isn't Last Password kind of built where you can put in all your normal passwords, but they get their own passwords that unlocks one password they are allowed access to?  Or am I thinking of a different service? CHUCK: So Last Pass is software as a service. So, you put your passwords into their system, and you have a plugin for your browsers. I believe it does work on the iPad and iPhone and all them as well. I haven’t done a whole lot with it because I generally don’t browse a whole lot on my iPad or on my Android phone, so I just never bothered. So anyway, what you do is you go in and then you say, “Share this password with the person with this email address.” So then they can go in, they setup a Last Pass account, of if they already have one, that’s fine too. And then it will add that password to their account. So then you can give them piece mail access to just the things that they need access too. EVAN: Yeah, One Password is a app that you buy on multiple platforms. It is not a software, it's a service. CHUCK: I can definitely see where One Password is probably a little bit more secure if it's an encrypted file on your machine, that you have to have the master password to in order to unlock, but if you need to share passwords and stuff -- which is something that I'm finding myself more and more needing to do -- then Last Pass has really paid off that way. EVAN: Yeah, it sounds nice. CHUCK: Anyway, I think we are done. Thanks everyone for listening. We are talking about doing a book club. We're probably going to need Get Clients Now. We're trying to line up a date with the author of the book, or atleast somebody from his or her organization. So once we have a date on that, then we'll let you know. But in the meantime, go ahead and pick up the book. I'll have the link in the show notes where you can get it on Amazon. And yeah, that would just be great. You can go read it. That should get you going with your marketing staff. And beyond that, we'll catch you all next week… or in two weeks. It's going to be in two weeks because I'm at Rails Conf next week. ERIC: And only Chuck knows how to record these things? [Laughter] CHUCK: Yeah, I dial Skype and push a button. ERIC: Yeah, well the dialing Skype and pushing the button, that’s like two steps that will cause Skype to crash. CHUCK: I know. If you do it the same time. I'm actually recording this on an external device so, yeah I don’t know how that could screw Skype up, but it might could. EVAN: “It might could”? CHUCK: It might could. Anyway, two weeks. EVAN: Hasta la vista, baby! I did it.

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.