AUSTIN, Texas — DevSecOps platforms operated by in-house service providers are becoming more common, but simply providing infrastructure to developers is not enough, experienced platform engineers have learned.
Leveraging a DevOps platform tends to create a shift towards a product mindset, with platform teams acting as service providers who deliver an organized set of tools and pipeline frameworks to customers internal developers. As their products mature, platform teams must also focus on improving the experience of their developer customers, or risk losing those customers to shadow computing and others. risky practices, according to IT experts at this week’s cdCon.
It’s especially important to focus on the developer experience given the recent volatility in the job market, also known as Big resignationsaid KellyAnn Fitzpatrick, analyst at RedMonk, in an introductory presentation.
“In addition to a big resignation, we’re also seeing a big onboarding — of people trying new careers in tech,” she said. “Developer experience can be essential for onboarding and training and keeping new developers up to date.”
Developer onboarding was the driving factor in creating a “golden path” to production for Spotify engineers, according to a 2020 blog post by Gary Niemen, product manager at the music service in streaming headquartered in Stockholm, Sweden. This Publish used the term “golden path” to describe an approach that places as much emphasis on detailed developer training tutorials as it does on packaged platform tools.
The “golden path” concept influenced the development of the DevOps platform of UK IT consultancy Kainos, which began building a centralized CI/CD pipeline tied to a cloud provider’s PaaS infrastructure in 2018. This platform, now running on Azure Kubernetes Service, replaced a set of ad-hoc pipelines and became the only production method of deployment supported by the company. But the transition is the result of developer training and awareness, rather than fiat.
“We recently adopted the Golden Path methodology, obtaining [developers] on board from the start to find out how [continuous delivery] work, leading training sessions, [providing] documents and [support] said Tim Jacomb, lead software engineer at Kainos, in an interview with cdCon. “Rather than just giving them documentation of the different things they can do, it’s like ‘start to finish, this will make your service operational.'”
Fidelity Investments underwent a similar consolidation of bespoke pipelines on a centralized DevSecOps platform beginning in 2019. The financial services firm could have relied on the “stick” approach rather than the “carrot” approach when made this change, given its compliance and security requirements, and simply required developers to use its sanctioned toolchain.
But instead, the platform engineering team made developer customers its collaborators in building the platform from the start, emphasizing education and discussion rather than the app.
“Everyone had a voice; it was a democratic situation,” said Jamie Plower, director of cloud platform architecture at Fidelity, during a cdCon presentation. “Developer experience is essential to ensure that everyone, whether you’re a seasoned programmer or systems engineer, or even just want a light touch [with the system] can get involved in how we design it.”
Balancing DevSecOps Guardrails with Developer Flexibility
While centralized DevOps platforms allow organizations to control application deployment processes that maintain application security, they also offer self-service controls that support customization by developers.
“There are very few lines of code that load the pipeline, and then there is a [domain-specific-language] which allows you to add your own steps,” Jacomb said. “The selling point was that all teams should have these mandatory checks and steps, but then they can add more — it’s expandable.”
Fidelity’s platform team also had flexibility in mind when it developed an event-driven architecture to orchestrate its pipelines, according to Plougher’s presentation. It’s a leaner and less labor-intensive approach to interoperability than direct integration, so developers can easily add and remove pipeline stages while compliance data is captured reliably in Fidelity’s Pipeline Intelligence repository.
In addition to automatically applying security and compliance policies in real time as pipelines run without developer intervention, the Pipeline Intelligence repository has also helped Fidelity platform engineers improve the experience of developers by giving them access to data that shows the performance of deployments.
“We get engineering metrics that we can provide to our larger teams, and it gives them the ability to do analytics [specific] to the race that’s happening, which we couldn’t do before,” Plougher said.
Fidelity profited from building its DevSecOps platform the same way it built apps using Agile workflows — in a collaborative and iterative way.
“Coming together, we have more richness, robustness and reliability – we haven’t had a drastic change since the launch of this project,” Plougher said during a question-and-answer session after his presentation. “Many problems we found [before] were [from]essentially, the teams that were throwing [platform designs] on the wire, then the developers would test them.”
However, developers’ appetite for “left shift” can vary by team or organization, which can make it difficult to improve DevSecOps platforms. Kainos’ platform team surveys hundreds of developers in its organization every few months, but gets between 20 and 50 responses, Jacomb said.
“[The platform] is under their control now and they can do anything, but do they want to? Some want it and some don’t,” he said. “Should they need to know all this? Has it gone too far? And how can we make it easier for them?”
Beth Pariseau, Senior Writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.