What is Developer Self-Service?

Spacelift team - Oct 29 - - Dev Community

Efficiency and autonomy are key in the software development lifecycle processes (SDLC).  For this, developer self-service has emerged as a game-changing approach, empowering engineering teams to access various resources and tools with minimal dependence on other departments. 

This article walks through what developer self-service is, the challenges and benefits related to it, and how to effectively implement developer self-service.

What is developer self-service?

Developer self-service refers to providing developers with all necessary tools, resources, and permission levels to perform specific tasks independently without relying on other teams or waiting for approvals. This will allow a developer to provision infrastructure and even the application independently and spin up all the required components to carry out their job.

By removing dependencies and empowering developers, organizations can achieve faster turnaround times and more efficient workflows.

What is DevOps self-service?

DevOps self-service is similar to developer self-service; the only difference is that it empowers DevOps engineers with all the necessary tools, resources, and permissions levels to perform their tasks on their own.

How does the developer self-service model work?

developer self service model

The developer self-service model works in the following ways:

  1. There is a centralized platform (catalog) on which developers can discover pre-approved resources, tools, and services they can access. These might include infrastructure, applications, and others.The internal platform engineering team builds these resources, or if you are using external applications, the service provider may build them.
  2. Self-service provisioning - Some of the templates in this catalog can be applied automatically by developers, while others may require additional approval before having these resources up and running.In the first example, this means that developers will be able to quickly provision whatever they need to test their features. In the second example, the process can be more lengthy, but its length won't compare to a traditional process.
  3. Automation - Behind the scenes, there is a significant automation process. When a developer requests a resource, automated processes handle provisioning, configuration, access control, and all the other guardrails required by the organization.
  4. Monitoring and logging - The system should keep track of who is using what resources to better identify issues and to be auditable.
  5. Self-management - Developers typically manage their resources, scaling them up or down as needed and de-provisioning them when they're no longer needed.
  6. Documentation and support - These platforms should offer thorough documentation to ensure that everything goes smoothly, and developers should also be able to ask for support when they need it.

Developer self-service challenges

When implementing self-service in your organization, there are many challenges you have to consider:

  • Security concerns - Granting developers more autonomy can potentially increase security risks if not properly managed.
  • Keeping standardization - Ensuring consistency across self-service options can be difficult.
  • Cost control - There are risks of over-provisioning resources, leading to unnecessary costs.
  • Governance and compliance issues - Making sure that all actions comply with the policies inside your organization can be difficult to implement.
  • Maintenance - You will need to maintain your self-service mechanism, and if you build it yourself, this process will be as important as the development itself.

Developer self-service benefits

Despite all the challenges described above, self-service comes with many benefits:

  1. Frees up developers' time to build their applications

Without a self-service model, there would be a lot of back and forth between developers and DevOps engineers, resulting in a lot of time wasted, thus slowing down the overall development process

  1. Reduced bottlenecks

DevOps teams are freed from routine tasks, allowing them to focus on more important initiatives while being sure that everything stays in control

  1. Improved engineers' satisfaction

When you can focus on your job and don't have to go through a million steps just to test something out, frustration is kept to a minimum. Implementing self-service improves the retention process.

  1. Faster time to market

Development cycles are accelerated with a self-service mechanism, allowing engineers to quickly release new tested features.

💡 You might also like:

Developer self-service examples

Let's consider some examples.

Without self-service

  • Developers have to raise a ticket with the DevOps team to get the infrastructure set-up for testing a new feature inside their app. This can take a couple of hours, but it can also take a couple of days, leaving the developers blocked for the time being.
  • Developers rely on the DevOps teams to scale resources or adjust configurations in their testing environments. They need to wait until a DevOps engineer is free and can do this for them.
  • Developers that get frustrated by the processes, may workaround DevOps engineers to build their infrastructure manually, just to be able to test their application. This will lead to unnecessary costs because in most cases, this infrastructure will hang around after the developer finishes his tests.
  • When a new developer joins the team, they have to wait for IT to set up their development environment, install necessary tools, and configure access rights. This process can take days, delaying the onboarding process.
  • When preparing for a demo or prototype, developers have to coordinate with multiple teams to set up a temporary environment, which can delay the process and potentially miss deadlines.

With self-service

  • Developers access a portal, use one of the accepted self-service templates, spin up their infrastructure, and test their applications. This reduces the time from hours/days to minutes or even seconds.
  • With self-service, developers can use approved templates that have scaling enabled and thus can focus on their tests.
  • In a self-service process, this will simply not happen because developers have an easy way to deploy their resources, without needing to do any manual work.
  • New developers can use a self-service portal to automatically provision a pre-configured development environment with all necessary tools and access rights, reducing onboarding time from days to hours.
  • Developers can use self-service tools to quickly spin up and tear down temporary environments as needed, without involving other teams, ensuring demos are done in a timely fashion.

How to implement developer self-service?

To implement developer self-service, as a platform/DevOps engineer, you should follow these steps:

  1. Understand what resources and permissions developers require - In this way, you will know exactly what kind of template you will need to build, what kind of guardrails you should implement, and how flexible these templates should be.
  2. Choose the right tool for the job - You can use a 75hp car in a race, but you will most likely not win it, even though you are by far the best driver. It is the same thing for implementing developer self-service. You need a tool/platform/product that supports self-service capabilities and can accommodate your use cases.
  3. Define guardrails - When you build your self-service templates, ensure you incorporate all the guidelines that ensure security, compliance, and even efficient resource usage. This way, you won't need to bother checking whether developers are using the templates efficiently.
  4. Provide training - Educate developers to understand how to use the templates effectively.
  5. Monitor, adjust, and ask for feedback - Understand if the templates you have provided are indeed offering value to your developers, and act accordingly.

Spacelift self-service

Spacelift is an infrastructure orchestration platform that gives you the ability to implement self-service infrastructure. 

Blueprints are templates for environments that let the administrators configure all defaults, guardrails, and other settings to make it easier for anyone who needs infrastructure to deploy it. 

You don't need deep infrastructure expertise to deploy infrastructure because it is as easy as filling in a form. With Blueprints, you increase developer velocity because they won't need to worry about defining the infrastructure needed to test their application. Because platform teams develop these templates, all the necessary guardrails are in place to ensure control without compromising speed.

spacelift crate stack

For developers that are used to a K8s environment, Spacelift offers its own K8s operator to enable self-service infrastructure. With this operator, you can manage Spacelift resources, directly from your K8s cluster, meaning that you can easily deploy your infrastructure and your application in a single workflow, reducing human errors.

kubectl get run run-sample -w
NAME         STATE   ID
run-sample   READY   01J4P7Q...
run-sample   PREPARING   01J4P7Q...
run-sample   PLANNING    01J4P7Q...
run-sample   UNCONFIRMED   01J4P7Q...
Enter fullscreen mode Exit fullscreen mode

spacelift operator

Key points

Empowering developers to self-serve is one of the best ways to keep them happy and speed up your time to market while not sacrificing control. Implementing your own self-service mechanism can be cumbersome, especially in the infrastructure space, so using a dedicated platform for this will be the best way to go forward. 

Spacelift is one of these platforms that can help with your developer self-service, and with your overall infrastructure orchestration workflows. If you want to learn more about Spacelift, create a free account today or book a demo with one of our engineers.

Written by Flavius Dinu

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .