Chris Kacerguis is an affable guy with an easy grin, a second-degree black belt, and two dozen years of experience writing software, designing systems, and leading teams at some of the top tech companies in the world. He’s the kind of person who likes to tinker and try new things. With a little coaxing, he will turn his webcam around in his home office to show a stack of a half dozen servers that constitute what he calls his home lab where much of his tinkering takes place.
When Chris was hired by Symphony AyasdiAI as its senior director of application architecture in the late summer of 2020, he knew that some changes had to be made.
Symphony AyasdiAI makes the #1 artificial intelligence platform for financial services. Large banks use their products to analyze their market and operational risks as well as to detect patterns of potential money laundering. They employ a truly global workforce, with employees spread across the US, the UK, India, and Ukraine.
“When I joined Ayasdi,” he said, “development was very disjointed. People were doing their own thing with their own setups from different types of machines all over the world. Individual computer setup was a nightmare. One of the first things I did was say, ‘This isn’t working.’”
With developers spread out across the United States and several continents, the team faced challenges. Developers were running a variety of operating systems on hardware that ranged from current to outdated. Ensuring consistent development environments across the team was impossible; configuration drift was inevitable, resulting in costly delays debugging code that — as the saying goes — “worked on my machine.”
In addition, the company incurred considerable expense and delays while onboarding new engineers. The IT department attempted to forestall support issues by purchasing and shipping maxed-out laptops to new hires. This approach was not only costly but also sometimes impossible for some of their international team members. Once the laptops arrived, new hires were responsible for configuring their own machines with the libraries and IDEs they would need. It was not uncommon for more than a week to pass before a developer was able to make their first code commit.
Ayasdi needed a solution that would reduce costs and onboarding times while providing consistent workspaces for development across the entire team, regardless of the individual’s hardware or physical location.
Chris researched several possible solutions; however, none of them seemed viable as they were too tailored to individual repositories or restricted users to less commonly used IDEs. Chris needed a solution with more flexibility that wouldn’t lock his team into a particular ecosystem.
Chris next turned to the open source project code-server. He had used code-server for some personal projects and loved it. By enabling access to VS Code through a browser code-server had allowed him to leave behind his heavy laptop while traveling and still make changes to his codebase using just a tablet.
His original idea was to create a code-server installation for each developer, but while poking around the code-server repository he discovered that Coder offered an enterprise solution built upon code-server. Coder makes reproducing and managing consistent development environments in the cloud simple.
After a two month trial, he knew Coder was his solution — and more.
Ayasdi runs Coder on Amazon EKS. Remote developers connect through a VPN to access their environments and use VS Code through a browser from wherever they are physically located. Since the environments are cloud-based, developers no longer need powerful personal devices for compilation and assembly. As of January 2021, the standard-issue device for a new engineer is now a Macbook Air, saving the company over $2,500 apiece over the costly maxed out laptops they previously provided.
Chris’s team set up multiple Docker images. To create a new workspace, the developer simply selects the appropriate image for the project and Coder launches a new container that is configured the same as for every other team member working on the project — no more “it worked on my machine.” Best of all, according to Chris, it only takes minutes.
"With Coder,” he says, “I can get a new developer up and running in a day versus two weeks, and from an engineering perspective that is worth its weight in gold."
Ayasdi is currently rolling out Coder for all of its engineers, but Chris sees potential uses beyond the development team. He could, for example, see Coder being used by the sales team to spin up instances for demos. It would be entirely self-service, no tickets required. Since each container would be created from the approved image library there should be no mid-demo surprises caused by misconfiguration issues. He also loves that inactive environments are automatically shut down after a specified time, which should result in an end to ghosted EC2s slowing draining the department’s budget because someone forgot to shut them down after they were no longer needed.
Chis is also starting to ponder whether there might be a way to leverage Coder to allow third-party partners to use the Ayasdi SDK to develop plugins and customizations without revealing actual Ayasdi source code. As he discusses the possibility he gets a certain gleam in his eye and unconsciously glances over his shoulder at his home lab...