Series brief: Self-service developer tools
Software application developers love users and operations professionals… and that feeling holds for database administrators to sysadmins to penetration testers and security professionals.
What’s wrong with the above sentence? Trick question. All of it.
In truth, software developers can tolerate admins a little more than users (those pesky scoundrels that are generally responsible for so-called “operator error” and not much more), but there’s not a whole lot of love lost in between. So we can say that (although it’s an unquestionably large generalisation) developers would rather do it themselves wherever possible.
The good news is, now, increasingly, they can.
Self-service developer tools
The rise of self-service developer tools has been fuelled in part by the automations and accelerations that have stemmed from the rise of robotic process automation and the wider transepts of predictive, generative and agentic artificial intelligence as forces have variously collided and colluded to enable new ways of working at the command line.
Designed to allow developers to work without any level of heavy reliance upon centralised operations, self-service functions are designed to allow coders to independently build, test, deploy and manage applications.
With an emphasis on automating the donkey work of repetitive tasks associated with infrastructure management, system provisioning, live production maintenance and updates, self-service software tools aren’t just DevOps and platform engineering combined; they are an elevation towards infrastructure abstractions that allow software engineers to spend more time building code and less time managing dependencies, interconnections and configurations.
If the operations function was ever regarded as a gatekeeper that sometimes got in the way of things happening a) the way the software development team wanted and b) with the right platforms and toolsets deployed, plus c) fast enough… then self-service tools have an ability to democratise access to infrastructure. This is a way for developers to move onward from ticket-based requests to a new level of autonomy.
Internal developer platforms
Fundamental to self-service developer tools are Internal Developer Platforms (IDPs).
As defined here, “An Internal Developer Platform (IDP) is built by a platform team to build golden paths and enable developer self-service. An IDP consists of many different techs and tools, glued together in a way that lowers cognitive load on developers without abstracting away context and underlying technologies. Following best practices, platform teams treat their platform as a product and build it based on user research, maintaining and continuously improving it.”
TechTarget defines and describes this technology (in a piece by Twain Taylor) saying that a key benefit of an IDP is that it allows developers to enjoy a self-service experience — they have the entire deployment process at their disposal.
“Developers can request resources, control environment builds and set deployment automation in one place. This removes, or at least reduces, the need to raise support tickets and wait days for busy operations teams to process the request manually,” wrote Taylor.
But what are self-service software tools when we talk about real-world offerings in this space?
Editorial series scope
Now commencing an editorial series on this subject, the Computer Weekly Developer Network wants to know the shape of the tools in question (are they predominantly cloud-native subscription services) and what kind of best practices controls exist here.
Do developers using self-service tools need extra guidance in terms of the templates and guardrails on offer… and is there any degree of industry standardisation surfacing here?
Which categories do self-service developer tools mostly fall into? Can we see self-service tools manifesting themselves in source code control; Continuous Integration / Continuous Delivery (CI/CD); Infrastructure-as-Code (IaC); container orchestration; API management; configuration management; observability & monitoring… or all of the above.
Should self-service developer tools be used in concert with workflow automation and developer productivity analytics tools… and do they need testing & quality automation functions to be present at the same time?
Which companies work most prevalently in the self-service developer tools market? We can think of Atlassian, HashiCorp, AWS, Microsoft Azure, Google Cloud, CircleCI, Jenkins, Docker, Argo, LaunchDarkly, Datadog, New Relic, PagerDuty, Snyk, Sonatype, Harness and many more.
Down up the upside?
On the flip side, what are the downsides of self-service developer tools? Some say that there’s a cultural change that needs to be worked through (and that goes for the operations staff as much as it does for the developers) to get these systems working properly. Others talk about new security fragilities (surely developers looking after security provisioning is not as secure as security professionals handling this function, right)… and there are questions surrounding the management complexity thrown up by the constant maintenance to ensure IDP services and other self-service tools stay current, secure and able to evolve and scale.
… we need to hear more, let’s dive in.
Image: Google Gemini