For years and years, developers have used automation tools to make our lives easier. In recent times, CI/CD - including GitOps and ChatOps - have been the cornerstone.

Many DevOps practioners have found great success adopting these tools into their delivery practices to provide a conveyor belt like model, configured for pushing lines of code through build, test and delivery cycles, on the way to production.

This approach started with one of the very first, mass market CI/CD tools Jenkins, back in 2011 when it was initially released. Jenkins gained a large following in the open source community and then was followed by closed source solutions like CircleCI, Github Actions and eventually tools like ArgoCD and FluxCD came along.

Largely all of these tools follow the same approach. A server is setup, listens to webhooks, pulls code you commit, then runs some more code someone else wrote, to try to test if the code you wrote is able to be safely deployed with code that other people wrote. If the tests pass then an artifact can be built and released to different cloud environments, however if the test fails, the process is stopped in its place until a human can debug the code to unblock the operations. This human is often called a DevOps engineer or sometimes a release manager and they spend most of their time unblocking these servers to make sure developers can deliver.

All of this is a fairly mundane and spiritless experience where a developer is stuck to try to debug a remote system which has little empathy for their user experience and a DevOps engineer is constantly being asked to unblock the build so they can work.

As a developer you are provided logs and then left to recheck in code, time after time after time to retrigger the build in hopes you can debug the remote system and gain some insight into why the system failed. This has sucked up countless hours of developer productivity over the years at great expense to businesses every where.

As a DevOps engineer, you want nothing more then to not have to debug the developers code and usually just send a few links to Stack Overflow in an attempt to help the developer, so you can get back to more interesting "systems architecture".

When you stop & think about it. It's is kind of a brutal experience.

Fast forward to 2022, and the emergence of Kubernetes, alongside Platform Engineering and SRE titles has begun to inspire more distributed ways of working & lets be honest we're all ready for different ways of working with infrastructure!

I don't know about you but I've always dreamed that one day we'd eventually find a set of operational practices that are more adaptable to our needs and can be programmed to not just interface with our commits, but also with our intentions...

Developer Control Plane is the future...

In the brave new world of Platform Engineering (which is arguably killing off the traditional DevOps model) the systems that we now create to enable developer teams to deliver software more efficiently, have started to look more like products.

We now have the ability to adapt and evolve to meet the developer at the intersection of their intention and their abilities. These new ways of working don't require us to transcribe machine readbale YAML or perpetually push empty commits to try to debug a heartless remote system that seems like it may even be laughing at us while it sits there holding up our entire team.

No a world with a Developer Control Plane is a much brighter future.

A Developer Control Plane, like the one we've built at CTO.ai, allows us as engineers to continue to write automation using the containerized environments we've grown used to in our build and test workflows, but it goes beyond this to provide us a more flexible and adaptable set of building blocks for tooling that give us the ability to create powerful developer experiences that priortize people over systems. It also gives the ability to reliably measure the outcomes we care about so that we can proudly demonstrate what productivity actually means to our peers & leaders.

A Developer Control Plane not only gives us a more flexible way to support more developers with safely delivering their code to production, but it also allows us to implement best practices that can actually meet developers where they are. In a world where a full stack engineer means having 5 years experience in technologies that may have only been around for 4, this is more important than ever for us.

Platforms like this are designed for empathic enablement of developers and leverage the Platform as Product approach which is a critical component of Platform Engineering. Not only does this produce more developer productivity in practice, it also creates a far more interesting, diverse and supportive world for the next 50M developers to make a mark by being a platform for others to succeed, themselves.

I'm not sure about you, but in a world where technology is advancing faster than it seems that our collective empathy for one another does at times, I think that's it's a good time to consider a different approach to developer productivity technology.

After all, technology was created to enable humans. Not the other way around. Right?