Developing on a VPS

Everyone should take some time now and then to look for optimizations in their work environment. For a software developer like myself, this usually involves tools. Also, as a freelancer there are a lot of optimizations that can be done in getting a new client setup, both the business processes (onboarding) as well as getting their application up and running.

One difficulty I had in the past was when I worked on multiple clients on my laptop, was setting one up could disrupt another. In the Ruby community this commonly was because different versions of gems were used and the different client applications wouldn’t specify them correctly. As you can imagine, this meant I had a huge productivity drain when I had to switch from project to project.

(This was pre-Bundler. But even now there are gem issues and other component issues that make this a time drain.)

Virtual Private (Development) Server

Then last Fall, in an effort to delay a new laptop purchase as long as possible, I decided to use a VPS as my development environment instead of my laptop. At the time my laptop was aging and I’d be running out of resources on a weekly basis (disk space, RAM). Add to that several years of client projects installed, uninstalled, and never fully purged and I was looking forward to using a clean VPS to develop on.

Since I have a puppet infrastructure setup already, including a CI server, taking the puppet configuration from other servers to spin up a development VPS was easy.

Seven months later, I can now say that using a dedicated VPS for a client project has been one of the best infrastructure decisions I’ve made in years. The benefits I get out of it are quite amazing.

Writing code in the cloud

With a VPS in the cloud, I can easily have other developers or my client connect to it to see the development versions of code I’m working on. I’ve had my client on the phone looking at my server while I made UI changes live, which is normally something you have to do in-person. I’ve also added a second account to do pair programming with another developer and it took all of five minutes.

Having the entire configuration (except for 2 manual steps) in puppet meant that I could destroy the server and get a fresh one with a little effort. One time my VPS started lagging pretty bad, even typing on the SSH console had a noticeable delay. So I make sure my changes were saved in Dropbox and rebuilt the server in under an hour (about 55 minutes of puppet and Ubuntu running, about 5 minutes of my actual time).

When doing my one week on schedule, I setup the server the Sunday before I start and destroy it at the end of the week. That not only decreases my costs but it also makes things a bit more secure since I don’t have a public server running with my clients’ code.

Scalibility

Using a VPS makes it easy to scale it up if I need to. One client’s application went through a major growth period where our test suite increased three-fold over a few weeks. Before I was using a small 1GB server for them but that became so slow that upgrading to a 2GB saved me at least a few hours each week. With physical hardware on my desk, that wouldn’t have been possible or it would have resulted in a few hours or days off while I move everything over. Total time upgrading the VPS, about 30 minutes.

Having my development environment in the cloud also gives me a bit of resiliency. Since all I need is SSH and a web browser, if something happened to my laptop I can easily grab another computer and get right back to work. Worst case I could run to Best Buy and buy a $400 laptop to get by. Although I haven’t tried it with a client project yet, I could in theory use my ipad too.

I also have another form of resiliency. If the VPS crashes or dies, I can spin up a new one and get back to work with a small delay. Since all of my code is in Dropbox and git, the server configuration is in puppet, and I dump copies of the database regularly I don’t have to worry about losing anything.

Isolation

Each client gets their own VPS so their applications are completely isolated. Not only in terms of gems, libraries, or system services but also in terms of legal boundaries. I haven’t seen a client NDA or contract that specified their code needed to be on an isolated system yet, but I have heard stories from other consultants where they are only allowed to work on a locked down client workstation.

Digital Ocean

At the moment I’ve had some great success with Digital Ocean’s servers. Since they bill by the hour, I’ve been ordering a 4GB server for my week on and spending about $10 each time. Compared to a week’s revenue from consulting, $10 is a pittance.

Vagrant and local VMs

Now that I’ve upgraded my laptop and have a lot more spare resources, I’m beginning to explore using Vagrant for my own projects. But having a remote VPS is still useful because it’s publicly demonstrable to people who aren’t physically with you. For Chirk HR and my other projects a local VM should work just fine. A nice bonus is that is I can use the same puppet configuration for both a VPS and a Vagrant VM.