Quick take
Docker won. Kubernetes is next. Go keeps earning its place. I was wrong about serverless timing and right about containers. Building two startups simultaneously taught me more about operational discipline than any conference talk ever could.
2016 felt like the year the industry collectively decided to stop debating containers and start running them. For me it was more specific than that. It was the year I stopped treating infrastructure as a thing to fight and started treating it as a thing to design.
Docker finally stopped being a toy
I spent most of 2015 defending Docker to skeptics. “It works on my machine” jokes were still the dominant reaction. By mid-2016, that conversation was over. Docker went mainstream. Not just for dev environments – for production workloads, across teams that had never touched a Dockerfile before.
At Dropbyke, we containerized everything. Location tracking, payment processing, fleet management. Docker Compose got us off the ground fast, and when we outgrew single-host scheduling, the migration path was clear. The tooling matured enough in 2016 that containers stopped being a bet and started being a default.
What changed wasn’t Docker itself – it was the ecosystem around it. Registries got better. Logging and monitoring caught up. CI pipelines learned to build and push images without a week of YAML wrestling. The boring parts got boring, which is when you know adoption is real.
Kubernetes momentum was undeniable
I wrote about this earlier this year after evaluating Swarm, Kubernetes, and Mesos side by side. My conclusion then: Kubernetes is going to win, but the operational tax in late 2016 is genuinely painful.
That assessment held up. We ran Swarm at Dropbyke for three months before migrating to Kubernetes, and both decisions were correct. Swarm gave us speed. Kubernetes gave us a real platform. The CNCF formation, Google’s backing, and the velocity of community tooling made the trajectory obvious.
What I underestimated was how fast managed Kubernetes would become available. GKE was already solid. By early 2017, the “Kubernetes is too hard to operate” argument will start losing force. That’s a good thing.
Go kept earning its place
We chose Go for our backend services at both Dropbyke and the fintech startup, and 2016 validated that decision repeatedly. The language grew in adoption. The tooling stayed excellent. The deployment story – single static binary, no runtime dependencies – kept saving us time in production.
Go 1.7 shipped with context in the standard library, which was a practical win for anyone building HTTP services with cancellation and timeouts. The ecosystem filled in noticeably. More battle-tested libraries for common patterns. Better database drivers. gRPC support matured.
The trade-offs I wrote about earlier remain real. No generics. Verbose error handling. A younger ecosystem than Java or Python. But for the kind of services we build – concurrent, networked, performance-sensitive – Go in 2016 was the right tool. Not the trendiest. The right one.
What I got wrong
I thought serverless would matter more by now. Lambda launched in 2014, and by early 2016 I expected it to be a serious architecture option for startups. It wasn’t. The tooling was immature, cold starts were painful, and the debugging experience was bad enough to kill productivity. Serverless in 2016 was interesting to watch but not interesting to use for anything beyond simple event handlers.
I also underestimated how long microservices confusion would persist. I assumed the “monolith first” message from DHH and others would settle things. It didn’t. Teams kept splitting services prematurely, then drowning in operational complexity they weren’t staffed to handle. This is still happening as I write this.
What I got right
Containers as the default deployment unit. Called it in 2015, and 2016 delivered. Kubernetes as the orchestration winner. Called it in October, and the trajectory only accelerated. Go as a serious backend language for startups. We bet on it early and it paid off consistently.
The one I’m most satisfied about: investing in operational discipline over feature velocity. At both Dropbyke and the fintech startup, I pushed hard for automated deploys, rollback capability, and monitoring before we added features. That discipline saved us multiple times this year. One Dropbyke outage that would have been a multi-hour firefight turned into a three-minute rollback because we had the infrastructure in place.
The fintech angle
At the fintech startup, the ML side of the business grew significantly in 2016. TensorFlow matured, and our team started using it for financial content relevance scoring. The accessibility of ML tooling improved noticeably – pre-trained models, cloud GPUs, better documentation. But the gap between “can run a model” and “understands what the model is doing” remained wide. We hired for ML literacy, not just ML capability, and that distinction mattered.
Looking forward
2017 will be about consolidation. Kubernetes will keep winning and the operational burden will drop as managed offerings improve. Go will gain traction in infrastructure tooling – I expect to see more CLIs, more Kubernetes operators, more network services written in Go. Serverless will get better but will remain niche for another year at least.
The thing I care about most heading into 2017: security as a first-class engineering concern, not a compliance checkbox. GDPR is coming. The breach headlines keep getting worse. At both companies I pushed for security review in the development workflow, not as a gate at the end. That investment will compound.
Discipline over heroics. That was the lesson of 2016. The teams that shipped reliably weren’t the ones with the best engineers. They were the ones with the best habits.