With Sandbox finally out, and having gone through a number of iterations and pivots (more on that on a later post, perhaps?), here is a small and personal account on what got me into this project, and what I see in Sandbox.
When I decided to join the StackFoundation project as a co-founder, I did so mainly out of admiration for both the vision of the project, and the ability to achieve it, knowing from previous experiences the capabilities of this team. The goal was clear, and a path to that goal appeared evident, at the time – to make development life easier.
Writing it now, it sounds awfully generic and bland – which tooling/testing/workflow developing company doesn’t claim this as their goal? Yet while the path to achieving it turned out to be a lot messier and blurrier than we thought it would be, the goal itself was as clear then as it is today. So what does this generic-sounding goal mean to me then?
In a world with hundreds of solutions for building, testing, deploying, creating and managing environments, everything seems to be pulling in its own direction. If a tool pleases a developer, it might not be robust or complete enough for a systems manager. If it pleases a systems manager it will be to complex for a QA to use or adjust. No consistency exists between roles, machines or targets, and no easy communication between these either.
Streamlining processes should start at the personal level
We were from the beginning attracted to the ideas brought by containerisation, as they seemed to be a good answer to the issues we wanted to address – guaranteed interoperability and consistency across systems, reproducibility of testing/production environments, the safety of sandboxing testing and production operations. The problem was – Docker is not an accessible tool (not to mention Kubernetes). If we were looking for a solution to facilitate development, that meant facilitating the work of all roles in a project, from QA to DevOps, and not need to imply a deep knowledge of new technologies by all parties involved.
This was particularly important to me, as my background as a programmer was definitely less backend- and systems-heavy than the rest of the team. To me, in particular, the project needed to tick a few boxes:
Make environments simple to setup
As I said, Docker and Kubernetes aren’t easy. They’re complex tools that imply a learning curve to overcome – a relatively small one for using it if thing have been setup for you, and a deeper understanding of the processes if you are in charge of setting it up.
One of our first mistakes was trying to remove this complexity altogether, in an earlier iteration of Sandbox. This lead to an exclusively UI-based system, which meant a slew of issues
Make environments easy to use for everyone
To me, this was the core of our project. As I said before, there are plenty of build/CI/containerisation tools out there, including Docker and Kubernetes, on top of which Sandbox is built. The missing piece is making those tools available and useful to the DevOps, the developer, the QA.
This meant sharing a workflow should “just work”: workflows are committed to git, and running them will install and run all necessary components in the user’s machine. No need to manually install machine dependencies, running a single command is all it takes.
Scalable up and scalable down
This actually stems from the previous two objectives, and sums them up nicely – a lot of the tools we use for deploying and managing environments, mainly due to their complexity and their weight, tend to be used only in the context of big shared servers – in the testing machine(s), in production, in a cloud CI service, etc. Usually, “containerising localhost”, while appealing for many reasons, tens to be very hard to implement in reality – port issues, setup issues, and just adding another point of breakage to the pipeline can make it more of a nuisance than a solution.
Yet for a lot of use cases (like the aforementioned QAs) it would be the ideal solution, were it simple and hassle free. Our tool aims to do exactly that, and that would mean using the same toolset for uses ranging from running the app on the developer’s machine to building a production-ready build, with all cases in between covered.