The Pre-Container Age
Prior to 2014, containerization was an alien concept to most developers. Virtual machines were the norm, deployment meant FTP file transfers and in the development environment, "it works on my machine" was a fact of life. As a student of computer science, I needed the ability to have reproducible, isolated environments for my thesis which consisted of a mobile code editor capable of deploying and running web applications on-demand.
It was then that I discovered Docker.
The Early Days of Docker
Docker was less than a year old and had scarce documentation and a nearly nonexistent ecosystem. Most developers were doubtful. My thesis project was revolutionary in 2014. A mobile-first Angular code editor, custom PHP micro-framework, on-demand container provisioning, and automatic deployment with DigitalOcean.
Implementation Issues
Working with Docker 0.8-1.0 was rather restrictive. No docker-compose, limited networking, and basic Dockerfile definition. I had to build everything from scratch:
- Custom PHP Framework: Routing and logging aware of containers
- Mobile Angular Editor: Management of containers from mobile web browsers
- Automated Deployment: Custom orchestration layer for container management
Technological Advances
I implemented on-demand container creation and destruction. Users would be capable of creating projects, coding from their mobile devices, seeing their work in real time, and destroying their environments instantly. This was custom container orchestration before Kubernetes, mobile-friendly development long before it became fashionable, and microservice pattern implementation before it became mainstream.
Major Issues
Poor Documentation: Solutions were only obtainable by experimenting and reading the source code. There were countless hours spent in IRC begging for solutions to the issues.
Networking Difficulties: Crude container networking required lots of custom proxying logic for networking.
Performance Issues: Containers took seconds to start as opposed to milliseconds.
What It Actually Taught Me
Working with Docker 0.8 taught me things that polished, well-documented tools never would.
Read the source when docs fail. Docker's documentation in 2014 was sparse and sometimes wrong. I spent hours in IRC channels and reading Go source code to understand how networking actually worked. That habit — going to the source instead of trusting the abstraction — has been useful on every project since.
Build abstractions over unstable foundations. The container APIs changed between minor versions. My custom orchestration layer had to absorb those changes without breaking the user-facing code editor. I learned to put a clean interface between my code and anything I didn't control. That same instinct showed up a year later when I designed a unified interface across four inconsistent social media APIs at my first job.
Bet on the problem, not the solution. Docker in 2014 was rough. Slow startup, no compose, primitive networking. But the problem it solved — reproducible, isolated environments — was real and important. The roughness was temporary. The problem was permanent.
The Thread That Kept Going
A year after my thesis, I joined Oxygen Ventures as their first developer hire. One of my first moves was introducing Docker to the team. In 2015 Melbourne, nobody in the startup scene was using it. The team was skeptical. But I'd already lived through Docker's worst version. I knew what it could become.
That pattern — discovering a tool early, living through its rough edges, then bringing it to a team once I understood it — has repeated throughout my career. Docker in 2014 was the first instance. It wasn't the last.
The technology from my thesis is obsolete. The mobile Angular editor, the custom PHP framework, the DigitalOcean provisioning scripts — all gone. But the instinct to evaluate tools by the problems they solve rather than the polish they have? That's still how I make technology decisions today.
Related Reading
- The Patterns I Found at My First Real Job — How Docker in 2015 Melbourne became my first technology bet at Oxygen Ventures