As organizations adapt to long-term all-remote work, enabling developer self-service is critical to removing friction in the development process and allowing teams to work as quickly as possible. Yet there are valid reasons why some organizations may restrict developers’ ability to self-serve: Done incorrectly, it can become very expensive, lead to security vulnerabilities and increase complexity so much that the system becomes challenging to operate. 

Using Kubernetes virtual clusters is one way to give developers the ability to self-serve without giving them the ability to control all the configurations and the responsibility to set up and manage everything correctly. Here’s what organizations need to know about self-service and how to set it up securely. 

The risks of self-service

Developers want to move fast. Allowing them to self-serve removes friction in the workflow, but with the ability to spin up clusters also comes the responsibility to do so correctly. Without automation tools, standing up a cluster and proactively ensuring that all the configurations are set correctly can be complex and time-consuming. Given that developers ultimately are trying to move fast, the temptation to cut corners is high, and many developers end up doing so unconsciously. 

Even if every developer in the organization follows a cluster creation checklist and never makes an error, having individual developers setting up their own cluster is often expensive. Each cluster needs to have at least three nodes for resiliency reasons, but many apps don’t actually need the capacity of those three nodes, leading to over-provisioning. 

In addition, developers are just trying to get their application to work correctly. They won’t always know what ramifications a cluster configuration change might have, whether it impacts someone else’s application, or the security or cost impacts to the entire system. A system that allows developers to self-serve without guardrails risks complete mayhem as each developer makes changes and sets up new clusters without fully understanding who and what might be impacted. 

Approaches to developer self-service

There are two main ways we see organizations approaching the challenges of developers self-service for Kubernetes. One is to give developers or teams of developers the ability to create entire physical clusters, and giving them the ability to do whatever they want with that cluster. Usually each application will have a cluster and the team working on that app will have access. This approach still requires individuals or teams to take responsibility for setting up monitoring and security tools and ensuring configurations are correct. 

Another approach is to use virtual clusters, which involves creating one large physical cluster and carving out isolated slices  for each application team. This usually results in better resource utilization and makes it easier for the central team to control configurations with guardrails as well as to ensure that all the shared monitoring and other operational tools are installed. 

Misconceptions about virtual clusters

Setting up the kind of isolation and multi-tenancy that allows developer teams to share physical clusters without interfering with each other or creating additional security risks would be challenging to do manually. But with automation tools like the Kyverno policy engine, the process can be automated, allowing teams to get the cost-savings and centralized control of using virtual clusters for developer self-service without compromising on the isolation and cross-cluster security. 

As the tools evolve, setting up virtual clusters and managing them has become easier, reducing the engineering overhead and making them a good option for any company who wants to allow developers to self-serve without worrying about configuration mistakes or giving up central control. 

No one-size-fits-all

Perhaps the most dangerous myth about everything related to the cloud journey is that there is a one-size-fits-all best practice — if you can just find the right path, you can follow it blindly. That’s not the case. Each company will be starting from a different place, using a different workflow and with a different business logic. Not everyone’s business goals are the same, just as no two companies have precisely the same technology stack or organizational culture. 

As organizations think about setting up developers self-service and using virtual clusters, they need to start by creating a plan, understanding both their technical and business goals and then determining how cloud native technology fits into those goals in general as well as how specific technologies like virtual clusters can facilitate goals like enabling developer self-service. 

With Nirmata, it’s easy for organizations to use virtual clusters to facilitate developer self-service. Central teams have a single pane of glass to manage all the physical service and to set up multi-tenancy; developers experience is the same as if they were setting up physical clusters except that they have more guardrails in place to prevent them from making configuration mistakes. Request a demo now to see how it works.