New development practices in Bloomberg’s software dept. are landing big, as software engineer Mikolaj Pawlikowski explains to John Bensalhia
Kubernetes is headline news in Bloomberg’s software department. The Wall Street powerhouse started investigating Kubernetes about two-and-a-half years ago, after forging a tool to manage the deployment of 6,000 instances of Apache Solr – an open source enterprise search platform – across around 1,000 servers. Bloomberg then started writing containerization software and orchestration software to support it.
Mikolaj Pawlikowski, Bloomberg’s software engineer, is responsible for the construction of a microservices platform based on Kubernetes.
“Our microservices platform was born out of the observation that a lot of how our code was deployed and updated could be automated once for many services,” explains Mikolaj. “At the same time, we are operating at a scale where anything that wasn’t fully automated was costly.”
Bloomberg needed a platform that would take care of the repetitive aspects of building, deploying, scaling, and recovery of a variety of critical services.
“We decided to build it on top of Kubernetes, which was still pretty experimental at the time (three years ago),” says Mikolaj. “Since then, the speed at which Kubernetes is being improved, its momentum of adoption within the industry and the amazing community that has formed around it has reassured us that this was the right decision.”
Kubernetes operates much like other Function-as-a-Service offerings, as it handles all the actions that need to be taken between putting some code in a git repository and running it in a production-grade setting.
“There is a twist though, as we go a step further. In order to increase confidence in your new deployment, the platform allows you to run multiple versions of a service in parallel, compare the outputs and confirm that your change works as expected, and even backtest a brand new version on historic data for that service. Once you’re happy with your change, you can just switch that new version to be the one running in production.”
“This allows our developers to spend more time doing what they love – solving challenging technical problems – and less time on the deployment, roll-back, and management of the lifecycle of their services and/or applications.”