Red Hat introduced Red Hat Enterprise Linux 9, the Linux operating system designed to drive more consistent innovation across the open hybrid cloud, from bare metal servers to cloud providers and the farthest edge of enterprise networks.
As DevOps adoption continues to rise, developers and IT leaders are getting more frustrated with specific aspects of their implementations. In a recent survey, three quarters of developers and DevOps team members said time spent on manual DevOps tasks is generally being wasted. And in Puppet's 2021 State of DevOps Report, 62% of IT leaders say their organizations are stuck in mid-evolution on their DevOps journeys despite high levels of automation.
There's a disconnect. DevOps is supposed to improve time to market by encouraging collaboration and efficiency. In some cases it does. But too often a lack of cohesion in DevOps processes is pushing developers, operations engineers and IT leaders apart.
One way to connect all sides and get them reading from the same script is for organizations to commit to adopting Platform Ops. Platform Ops is an approach that aims to instill more structure into DevOps practices across an organization so they can scale more efficiently.
While it may sound like the addition of just another layer will complicate an already complex set of software delivery practices, it shouldn't. Platform Ops actually provides structure for DevOps processes, allowing stakeholders access to centralized resources so they can handle tasks more efficiently by themselves.
To adopt Platform Ops, organizations need to form a dedicated team that maintains the internal marketplace of resources that acts as a self-service platform. The platform should include everything developers need to build an automated DevOps value stream. Rather than worrying about infrastructure and operations tooling, developers can focus on what they do best — building software.
Platform Ops isn't a return to centralized IT. No one wants that. Years of IT controlling every tech resource within an organization gave rise to shadow IT in the first place. Too much central control would frustrate developers even more and decrease the level of collaboration on teams.
Making the concept work requires that organizations balance rules with freedom to innovate. While development teams still need the flexibility to do their work, Platform Ops teams should provide systems to ensure consistency and better governance.
Developers need to control things that are part of their workflows — like continuous integration systems, source control platforms and how to control integration tests. The idea is not to limit their creativity and their ability to work independently. Giving them control and a say in day-to-day.
Platform Ops, on the other hand, should control things where there is less room for flexibility. This includes infrastructure automation, artifact repository, alerting and emergency response, infrastructure and application security, CI/CD and overall metrics.
You could make the argument that Platform Ops opens up a new future for a scaled-up DevOps itself — opening up channels to innovate and collaborate while installing a dose of discipline. Balancing developer creativity with the necessary administrative work that's required frees up resources to successfully implement DevOps processes in the long-term. As organizations weave Platform Ops elements into their processes, DevOps will work more productively.
If DevOps is about automation and collaboration, Platform Ops enables teams to do what they do better. Separating the core business from the platform that the organization uses to build the core business simplifies processes and enables the DevOps practice to scale. It makes it easier to integrate best practices, and it provides the consistency that stakeholders need to make DevOps culture a reality across organizations.