If you’re a developer working on a scalable web application, you’ve had your share of frustrations maintaining a development stack. In a simple LAMP shop, you can get away with running an entire development stack on the same machine … until you need to test code involving load balancers, or test code that is expected to run on a shared database.
If you’re working on a complex, service-oriented website your problem is even worse. It probably consists of dozens of services, each with their own load balancers, workers, and databases, all designed to run on dedicated hardware. With a very beefy workstation, it’s possible to run a local copy of the site with barely enough juice left to run Eclipse. However, a developer still spends a large amount of time making sure installed versions of all the services are reasonably up to date and playing nice with each other.
What if you have a complex web app that inherently runs on different types of hardware, with different operating systems? Well, your development stack story gets hairier still. Virtualization will allow you to divide a development machine into different VMs, potentially running different operating systems, but for any serious work you’re going to have to use a computer in a rack, probably in a closet in your office. But, what happens when you’re hiring and running out of rack space?
At Skytap, we had just such a problem. At minimum, a working back-end development stack here consists of two Linux machines and an ESX machine. All of this takes some serious horsepower to run. As work requires that other components be added, such as a storage system or web application, the complexity and requirements increase quickly. A coworker recently finished cloning our integration environment, and now has over a dozen VMs.
When I joined Skytap, new hires were assigned a blade in a server closet and given a wiki on how to build out each of these 3-12 VMs, then link them together. The process could take weeks, and we were running out of power in our server closet. If someone broke their stack, or needed to change the stack to work on a different project or feature, days of development time could be lost. Luckily, the marketplace has evolved to provide a product that’s perfectly suited to such a large, complex application: Skytap Cloud.
“Yo dawg” jokes aside, the ability to develop on Skytap is a huge boon. In fact, making Skytap Cloud the go-to choice for development environments is what drew me to the company. I know of no other cloud solution that allows complex configurations of hardware to be so effortlessly created, managed, and shared.
Let’s take a look at my development stack from a few weeks ago. You can see my three machines, as mentioned:
Now, let’s take a look at my network configuration:
VPN access, custom subnets, multiple networks attached to multiple network adapters—it’s all there. The multiple network adapter requirement is new as of a few weeks ago. It took about five minutes to update code that required it, then use the Skytap UI to change my configuration.
Just the other week, I needed my networking development stack to support our storage service as well. In the bad old days, I would’ve had to create a new Solaris VM from scratch, then manually install everything necessary to make it a Skytap storage node. But using Skytap Cloud as my development environment allowed me to walk over to a storage guy and ask him to save off his storage node and share it with me. (Remember, Skytap allows you to create a template from any subset of VMs in a configuration.) Then, I saved my running stack as a template (as insurance), and added the storage node to my existing development stack. Here’s the finished result:
Even better, if any of my teammates need a networking stack with storage, they can just create a configuration from the template I created when I was done. In total, the ‘hardware’ part of this upgrade took less than half an hour. I had been warned to set aside at least a full day to add storage service support.
Just about every week I find a new advantage to using Skytap Cloud as a development environment. Need to work on a different branch? Suspend one development stack and fire up another in less than a minute. Doing experiments that might break your setup? Save a snapshot first, or better yet schedule a suspend and save off your stack at the end of every workday so you have an automatic checkpoint to go back to. (This also helps you stay under your SVM quota). Handing off a project? Need to show a bug that’s hard to repro? Save your work-in-progress (with the bug actively on screen) and share it with your coworker. Tired of waiting for tests to run? Run a second stack and start on your next project while getting your first check-in ready.
Thanks to Skytap Cloud:
- Our new hires get to start looking at code on day one instead of enduring a two-week rite of passage creating a development stack.
- The server closet doesn’t melt down.
- Stack upgrades and maintenance are done quickly, and can be shared between coworkers so the same work isn’t done by multiple people.
In my next blog post, I’ll talk more about more ways that developing on Skytap can save engineers time. But in the meantime … do you have any pain points in your development process? Want details on any of the other ways Skytap lets me spend more time writing code? Just ask in the comments.
