A common trait of high-velocity teams is that they provide independency for teammates collaborating with each other. Internal Developer Platforms are powerful tools in the hands of teams trying to achieve this level of efficiency. Here’s how they can provide for both non-specialists and specialists at the same time.
Low code/no code was the word for the past years for a good reason. As the demand increased for problems getting solved with the help of software, organizations had a tough time to increase their technical staff. Before COVID the low code/no code movement represented a roughly $11 billion sized market.
Long before the low code/no code trend came, abstraction layers with Internal Developer Platforms (IDPs) appeared on the scene to provide for the self-service requirements. Abstraction layers allowed teams to make things happen without completely understanding what, and more importantly, how they did things, like provisioning. The Achilles heel of the process was exposed when the abstraction layers couldn’t deliver the promised results. In other words, caused outages without people ready to take care of the problem, for example.
But how can IDPs balance between deeply technical solutions and abstract ones?
Imagine that you’re a cook. You get an order for a pancake, so you start to prepare it. Soon as you put the pan on the stove, you realize it’s broke. In this situation, you can call for a repairman or try to get the stove to work yourself without knowing how to fix it.
Before the problem occurred, you, as a cook, didn’t have to understand how the stove worked. All you needed to know is how to get it to work. It’s similar to how most developers need to interact with tools that enable self-service deployments or configuration management. Only a fraction of them, usually seniors need to know how the thing they use works.
We wouldn’t encourage chefs and cooks to get their gas-fitter licenses, though. The point is it makes sense to figure out the logistics of sufficient abstractions without going to the extremes of turning everyone working at McDonald’s and Gordon Ramsay into stove-specialists.
As long as no problem takes place, there’s no need to further understand what the Internal Developer Platform does. When things go south, however, some expert assistance is needed, fast. For this reason, there are two requirements for abstractions to be sustainable.
Exit doors: Similar to real-world buildings, Internal Developer Tools need exit routes. This means a way to toggle between abstractions and deep level actions in case something happens. The fact alone that “it’s not working” won’t lead to prompt understanding, crucial to fix the problem. The easiest way to do this is to enable engineers to interact with the tool on a deep level, if they’d like to for whatever reason.
Expert on-board: You don’t need everyone to be a Kubernetes specialist on your team, but it’s useful to have someone on your team who’s specialized with whatever tool your team uses. If something happens, the IDP can help them treat the situation fast.
IDPs need to provide self-service solutions while maintaining the possibility of looking at more complex levels of the infrastructure. The most important trait of an IDP is to support independency of teammates while increasing the level of collaboration.
Sometimes even when both of the factors above are theoretically available, there’s a certain slackness between the problem occurring and the team reacting. The specialist to solve the problem is very likely busy with other things for the time being. Instead of waiting for them, it makes sense to create self-service ways to momentarily treat the problem.
These require fool-proof preparations, de facto internal processes provided by IDPs that can be useful temporarily until the specialist is able to take care of the issue. One of the most powerful examples of these are version and configuration rollbacks. In case of an emergency, the team member experiencing the problem just reinstates the latest working set up and components and wait for the rescue. The point is to allow abstractions to work but be ready for the worst-case scenario.
Old habits die hard, and teams won’t move their processes from one tool to another in an instant. According to Humanitec’s research, forcing your teams to use Internal Developer Platforms top-down is counterproductive. Creating resistance against a product that’d be beneficial for everyone involved in the processes IDPs simplify isn’t what you’re trying to achieve.
What they suggest is to assemble a team that could advocate for the Internal Developer Platform and spend time on understanding the pain points they deal with. Involving your technical staff on this matter from the beginning can lead to success.
The best Internal Developer Platforms provide two major benefits: non-specialists are able to self-service to a certain extent, while specialists and senior engineers can get things done faster by using them. In order to achieve them, IDPs need to be implemented with thorough preparations and defining de facto intrateam processes.
This blogpost was written by the team of dyrector.io. dyrector.io is an open-source continuous delivery & deployment platform with version management.
Find the project on GitHub.
We are pleased to announce that dyrector.io has been recognized as one of the leading Azure Consulting Companies by the prestigious SuperbCompanies platform.
dyrector.io's value can be translated on the level of end-users, business and technology. This is a buzzword-free explanation of what the platform has to offer to everyone.
Internal Developer Platforms, or IDPs are the closest to a cheat code when it comes to DevOps. They bring tools and processes together to save you tons of time and headache. If you don't use one, you're missing out.
