When creating a platform engineering team, an important first step is the interview process. What do developers want and need? What works, and what doesn’t?
Sounds like what companies do when reaching out to customers about new rollouts, right? Well, it is, when you consider your development team as being customers of the platform.
“Treat your developers, treat your DevOps teams, as your own internal customer and interview them,” urged Bill Manning, Solution Engineering Manager at JFrog, which has created an end-to-end Software Supply Chain platform to speed secure delivery of new applications and features. Once you’ve listened to the developers, Manning went on, you can roll their feedback right into the next iteration. This feedback helps organizations find ways to be more efficient, and to create more value by reducing costs – a practice today known as continuous improvement.
The reason platform engineering is becoming so important is that the days of each little team having their own tool set and unique processes are numbered, according to Sean Pratt, product marketing manager at JFrog. “Because when that happens,” he said, “you lack repeatable processes that can be tracked over time, and monitored and automated.”
Standardization and intelligent consolidation of tool sets, which can reduce the time, effort and cost needed to manage the sprawl many organizations face, is but one of the core tenets of platform engineering that JFrog talks about. Among the others are reduction of cognitive load, reduction of repetitive tasks through automation, reusable components and tools, repeatable processes, and the idea of developer self-service.
Organizations using DevOps practices have seen the benefits of bringing developers and operations together, to get new features released faster through the implementation of smaller cycles, microservices, GitOps and the cloud. The downside? Coders have now found themselves smack-dab in the middle of operations. “The complexity [of software] has increased, and even though the tool sets in a way were supposed to simplify , they’ve actually increased it,” Manning said. “A lot of developers are suffering from cognitive load, saying, ‘Look, I’m a coder. I signed up to build stuff.’ Now they have to go in and figure out how they are going to deploy, and what’s the container going to run in. These are things a lot of developers didn’t sign up for.”
Platform engineering has grown out of the need to address the burden organizations have placed on their development teams by shifting left more practices with which developers are unfamiliar, and which they never really wanted to do.
This takes a toll on developers, Manning said. “Developers, they’re artisans. Artists want to sculpt, they want to paint, they want to code. They don’t want to be involved with a lot of the minutiae that comes along with things like, ‘I’ve got to go ahead and learn how to do Terraform because now I have to do infrastructure code. If I have to do it, I only want to do it once.’ This all points to the need to incorporate automations into your practices, to free up developers to do what they do best – innovate.
Manning said automating things like Terraform to provision infrastructure, or Helm charts for Kubernetes, for example, frees up developers to do what they do best – innovate and create new features at the pace the business needs to achieve. A developer would rather get a notification that a particular task is done rather than having to dive into it and do it manually.
While platform engineering can help standardize on tools, organizations still want to offer developers flexibility. “In a microservice world, for example, certain teams might need to use certain tools to get their job done; other teams might need to use different tools,” Pratt said. “So there’s a need for a solution that can bring all those pieces together and wrap them under one umbrella, which is something that we do. So it doesn’t matter if they’re using Rust over here and Java over there, we can still bring all those technologies together under one platform in order to use consistent processes and practices across teams.”
As for the tools, Manning said there’s a lot of dissonance between groups picking the tools that work for them, which adds more layers of complexity. “One team might say they want to use Azure DevOps as their CI server, and other teams use JFrog Pipelines, or use GitHub Actions. The more tool sets over time adds complexity.”
To be sure, a mentality shift is required for successful platform engineering. “You know what, maybe we don’t need 25 tools. Maybe we can get away with five. And we might have to make some compromises, but that’s okay. Because the thing is, it’s actually beneficial in the long term.” Regardless of how many tools you settle on, Manning had a final piece of advice, “Think about how you bring them all together; that’s where universal and integrated platforms can help connect the disparate tools you need.”
The post Platform engineering brings consistency to tools, processes under one umbrella appeared first on SD Times.
from SD Times https://ift.tt/yU3oxSY
Comments
Post a Comment