What’s this all about?
In the last year, the adoption of containers and Kubernetes has spread rapidly across the company. Docker was seen as a cool new technology for the future. We had one small team using it for a brand new product, but adoption wasn’t happening at all in any other part of the company. A little less than a year ago, an infrastructure team started looking at Kubernetes and fell in love with it. We now have many internal services running in Kubernetes, and adoption on new teams is almost assumed. Even some legacy production services are being considered for Kubernetes. The goal of this writeup is to look back on how this shift occurred and provide an example of how a company or team could make the change themselves.
There are a lot of inputs to this equation
Creating a paradigm shift across a software development company is not easy. This worked for us because a lot of pieces came together very nicely, and a few people were very passionate about making it happen. What I’m about to demonstrate here may not work for you or your company, but hopefully it will provide enough insight into our process to give you inspiration for your own environment.
ReadyTalk has a history of empowering engineers to make development decisions. There has rarely been a company-wide mandate to use a specific language, tool, or stack. This meant that shifting the company to containerized services running in Kubernetes would have to be a grassroots movement. There are three things implied by the goal in that statement, and we had different history with each one:
We already had a history with services-based architecture. For a long time there has been a general understanding that there are clear benefits to this type of design, so we didn’t really have to fight hard for that one.
Containerization has been getting more and more popular, and just about every engineer at least knew what it was when we started our journey. A good half of our development team went to DockerCon this year, so I think we had a good start there. For those that were on the fence, it is pretty easy to show some benefits of containerization quickly.
This is where we had zero background. The team that was already using containers in production saw absolutely no need for an orchestration layer, and they felt that it would be impossible with the media-based services they were creating. The teams that hadn’t even begun to containerize didn’t even know what orchestration even was. This would prove to be the hardest part of the change.
So why do we need an orchestration tool after all?
This is something that came naturally to me as an operations guy. I started out by trying out some services in Docker. This meant that I was creating multiple containers that needed to talk to each other. Once I started trying to get individual containers networked together, I began to see where Docker by itself ran out of steam. This meant that I needed more. Then came the question of how to keep the containers running, how to deploy the containers, etc. Thanks to a co-worker of mine, I started looking at Kubernetes. I quickly realized that it had the potential to provide tooling for all of these operational issues. So our team set out to start running our internal tooling on Kubernetes.