CHICAGO — Platform engineering comes from complexity.
It sure seems like it after this week at KubeCon + CloudNativeCon North America, hearing from people like Release CEO Tommy McClung.
“I was the CTO of a public company and had all the problems you just talked about,” McClung said about the degree of complexity that we hear about as much as any matter at a conference like KubeCon, where 10,000 people show up because how else are you going to figure out the deep complexities of Kubernetes and how it can serve as a release from a bespoke world?
Kubernetes will never be completed. Google’s Tim Hockin, quoting one of his colleagues, made a statement to this effect in his keynote at KubeCon last week.
But platform engineering helps get customers closer to a desired state that fits with the “good enough” nature of Kubernetes. An enterprise architecture never really sees completion, either. Technical debt and bespoke systems fit inherently with the enterprise. Platform engineering makes things easier for developers. Platform engineering takes the load off developers who already face cognitive overload.
Spotify: Bespoke Galore
Look at the problem Spotify faced. Its developers wrote code at a blistering pace. But then the IPO came along, and the accountants at Ernst & Young said there were some problems.
The streaming media company’s codebase had custom scripts, various APIs and many CI/CD paths to production. (Thanks Corecursive: Coding Stories, for the excellent podcast on the origins of Backstage, the internal developer platform created by Spotify.)
Spotify symbolizes the mess faced by organizations. Bespoke galore. Quoting Hockin’s keynote:
On complexity, @thockin:…The result is increased operational and conceptual complexity…and that’s this idea of a “complexity budget.” Pretty simple idea. There’s a finite amount of complexity that we can absorb into the project over a certain amount of time. #KubeCon pic.twitter.com/8tEmtjtjDr
— Alexander (@alexwilliams) November 9, 2023
Release: Wrangling Complexity
So, how does Release fit into this scenario?
“We had legacy systems,” said McClung. “We had a move to the cloud going on. We had all these vendors that we were bringing in. We had cloud native stuff that we were using. We had migration to containers. All of it was hard.
“And so I think the platform engineering side of it, if you want to go down that path, is an effort to abstract away that complexity. So developers don’t have to deal with it and that ultimately is the goal of whether you call it Environment as a Service or platform engineering.”
It’s the complexity that makes getting resources to work for developers difficult.
“There’s a bespoke nature of every single customer,” McClung said. “And if you want to make something that allows developers to easily and consistently do their work, then you have to abstract that complexity away, and that is the mission of what we’re doing.
“We want to make it so developers can have access to that bespoke ecosystem without having to worry about the underlying complexity of it all. And that manifests itself in our world as environments.”
Release provides a preview developer environment, McClung said The staging allows the developer to play with what they built and shop what is supposed to get shipped.
“Our job is literally to wrangle that complexity,” he said. “But that’s very complex. Making something very complicated, simple, is very difficult.”
Release offers what it calls a template or a blueprint. Customers often come to Release after embarking upon a modernization path. They’ve already codified some Infrastructure as Code practices. Release consumes all the information from Helm charts, and Docker Compose files — whatever the little pieces may be.
McClung said it’s a standard template that defines the application, its infrastructure, and the workflow required to reproduce it.
“We call it an abstraction above Infrastructure as Code,” he said. “That’s what it is. It’s taking all the parts that you have now and then being able to reproduce the entirety of it.”
It’s an ephemeral environment that analyzes existing reports, code, configurations and other bespoke pieces. It generates a blueprint that reproduces the customer’s environment, accounting for all the tailor-made components.
Environments get spun up on demand without manually putting all the pieces together.
Platform engineering would only exist with complexity. It’s why people come to KubeCon. They want to find solutions to the complexities they face. And more often now, the answer comes in learning about platform engineering practices.
“The platform engineering side of it, if you want to go down that path, is an effort to kind of abstract away that complexity,” McClung said. “So developers don’t have to deal with it, and that ultimately is the goal of whether you call it environment as a service or platform engineering.
“Developers need those resources to get their job done. And getting those resources to work for them is incredibly difficult because of that complexity.”
The post How Platform Engineering Comes from Complexity appeared first on The New Stack.
Platform engineering takes the load off developers who already face cognitive overload. At KubeCon in Chicago, Release's CEO told how his company's tooling seeks to make complexity simpler.