A few years ago, in the "dark times" of early 2013, the company I was with at the time had me working on a project that would let them outsource projects which used third-party APIs, but not require them to provide their keys to access those APIs, and at the same time prevent overuse of those same keys (which, thanks to a coding error in one such project, had already cost them several thousand dollars). There were other project requirements, but those were the core of it. I’d spent the majority of the past several months designing the project, and ensuring every piece would perform as desired. Essentially, it was an internal API which would sit transparently between our outsourced applications and the third-party APIs we used to make them work.
I shared the project design with my project manager, who started asking some hard questions I hadn’t properly considered before. The project was redesigned, in a few key areas, to make it more robust. One of those considerations was how to handle long-running tasks. We could hold the connection open while waiting for the upstream server to respond, but this would be highly inefficient, and require a server far more capable than all of the ones we intended to connect to, combined. Since that obviously wasn’t a good design, I started to look into using background tasks, a concept which many server-side web development languages don’t support natively, but generally have ways to support. I finally decided on using a queue manager, and the redesign was approved. I got to work.
Finding the Right Fit
In the process of coming to this point, I’d looked around to see which platforms would be best able to accommodate this project. Shared hosting was already biting us in the backside with numerous other projects the company had been working on, and options like AWS and Azure weren’t quite as flexible or mature in the ways we needed as we wanted them to be.
I looked into Heroku, which seemed promising, but then discovered Pagoda Box (albeit with some helpful pointers in that direction from my project manager). A very similar approach to deployment - commit to version control, then push to a special remote which would build and deploy our code automatically - was coupled with a much more friendly configuration to make it work. Its main restriction was that it only supported PHP, but as we were working with PHP at the time anyway, this wasn’t actually a problem for us. I fell more or less in love, and pitched it to the team along with my queue manager redesign.
That project was eventually completed, and I spent most of the rest of that year maintaining it, adding functionality as desired, until I finally left near the end of the year so I could focus more on other projects. Pagoda Box, then at version 1, served us very well over that entire span, and I had even started using it for other, personal projects. Eventually, version 2 was released, which introduced a large number of improvements over version 1, while retaining all of the simplicity and power it had provided before. I migrated as many projects as I could immediately (I couldn’t afford to run most of my personal projects there). As I write this, Pagoda Box version 2 is still powering along quite happily. But the team behind it wasn’t just sitting around keeping things running smoothly.
The Beginning of Nanobox
Work had already begun on the next iteration of the idea, called Nanobox. This revision came with a new name because it revised the approach a bit. One of the main complaints any developer makes is about the differences between their development environment and the ones used in the wild. For web development, this includes not only the live "production" server, but also any testing servers, and even other developers’ computers. Unsatisfied with existing tools that addressed bits and pieces of these concerns - often in incompatible ways - the Nanobox team set out to build a tool that would both drastically simplify the creation of consistent development environments (“the same on my computer as it is on yours”) and support deploying all the way to production servers using that same consistent environment. This was, of course, coupled with all the best practices of running scalable web applications they’d perfected over the years of managing Pagoda Box.
I was actually initially very resistant to the ideas behind Nanobox. I was told it was like Pagoda Box, but it didn’t care about version control, and would run on your development computer. This was all true, but I didn’t quite understand what that all meant. I felt the push-to-deploy approach was quite simply the best way to work, and to be fair, I still find it to be superior to most approaches. It took some time to realize that, while moving away from enforcing push-to-deploy, Nanobox wasn’t actually preventing it. Indeed, it actually offers far more control over push-to-deploy architecture than Pagoda Box had allowed - Nanobox can actually be inserted into the integration testing phase. Plus, unlike Pagoda Box, Nanobox offers the choice of virtually any (cloud) hosting provider on the planet, provided one can expose access to certain key functionality via a simple ReST API.
Now, in mid 2017, Nanobox is my go-to tool for web application development. I can use it to develop my application locally, run the actual tests on my CI server, and then - depending on whether or not those tests succeed - deploy the resulting code to wherever it needs to go. If I need to bring in collaborators, I simply ensure they have Nanobox installed, then they clone the code and are up and running in minutes, in an environment identical to my own. It does all of this without tying me to any given version control system, hosting provider, workflow, or even programming language - with the Nanobox architecture, the team was able to open up support to a wide variety of programming languages without too much maintenance overhead to keep up with them all. That’s why I was able to add Nanobox support to Mastodon, a Ruby on Rails project, while still using PHP for a number of other projects.
So Why Do I Use It?
I’ve had people assume a number of reasons for my use of Nanobox:
Because I work for them? Nope. Not a bit. I actually, at the moment, work for OpenVPN. I just really like the product. (Edited 18 Aug 2017: This has changed a bit since I wrote this article; I now work for both companies. This still isn't the reason I use it, though.)
Loyalty to Pagoda Box? Sure, that’s a factor, but it’s a minor one. As I mentioned above, I was strongly against the idea of Nanobox, at first.
All the time I’ve put into it? Well, I have put quite a lot of time into learning how Nanobox works, at every stage of the application lifecycle, and I even spend a good portion of my time on the Nanobox Slack server, helping solve issues users come across - especially while the actual Nanobox staff members are out of the office for the night. But I’ve done that for numerous other projects I’ve since moved away from.
Because it’s a shiny new toy? Nanobox just left beta early this year, but that’s not a major factor, either. I’ve been using it for far too long, and far too consistently, for it to still be shiny and new.
Because I live within about thirty minutes’ drive from most of the development team? While that’s kinda cool, I don’t have a whole lot of love for most of the local companies in my area. That’s a whole other story, though.
No, in the end, I use Nanobox because it does exactly what it says it will. It gives me all the power of other tools, but does it in a way that is not only much simpler to use, but is also predictably consistent across my entire development cycle. I know my code will be in the same environment while I’m writing the code as it will be during testing, and that it’ll continue being the same all the way into deployment. That’s an assurance I need in today’s market.
Subscribe to Nanobox
Get the latest posts delivered right to your inbox