Table of Contents
Kubernetes is currently the most powerful tool for orchestrating software containers, but there’s no denying that it’s complicated. Many teams find that adopting Kubernetes means employing an entire team of site reliability engineers (SREs) to babysit their clusters. This is a little better than the old days when systems administrators had to watch over dedicated servers all day. When it comes to team topology, it can feel like we’ve run a long way without having moved very far.
Forward-looking teams have found value in adopting self-service Kubernetes environments, but what exactly does that mean? In this post, we’re going to break down what self-service Kubernetes is, why your team might adopt it, and a couple of key points to keep in mind as you do.
#What Is Self-Service Kubernetes?
Self-service Kubernetes isn’t a technology or a team structure. It’s more of an organizational focus. Adopting self-service Kubernetes doesn’t mean that you abandon your SRE team either. Instead, self-service Kubernetes means adopting technologies and procedures that give your developers the tools they need to work with Kubernetes in every environment. That means your development, testing, and production environments. To a lot of teams, that sounds like an odd choice. But we’ll explore the benefits and some ways to mitigate the downsides by laying out why it might be in your team’s best interest to adopt this mindset too.
#Who Benefits from Self-Service Kubernetes?
Let’s be clear. If you don’t roll out a self-service Kubernetes approach effectively, the answer to this question just might be nobody. That’s obviously not a good outcome. But if you’re willing to put in the time and the work and plan out your approach, the answer to the question of who benefits just might be everyone. Let’s talk about how.
#SRE Teams
The first and most obvious group that a self-service Kubernetes approach benefits is your SRE team. This makes sense, right? By enabling development teams to work with Kubernetes directly, your SRE and platform teams can spend more time focusing on actually building your platform. They can turn around new feature requests more quickly because they’re not spending nearly as much time babysitting your production services. That all by itself is worth it for many teams. If your SRE teams are currently spending a lot of time taking care of your production services, it might be hard to imagine how freeing them up would positively impact your business. The truth is that an SRE team that can focus on pushing your platform forward will lead to big improvements in your system’s reliability, performance, and security.
#Development Teams
The second group that’ll see a big benefit from adopting a self-service Kubernetes approach is your development team. By taking direct control over Kubernetes management for their applications, development teams enjoy much better flexibility in their infrastructure. That kind of flexibility provides teams more leeway to experiment with architecture, which in turn means that they’ll be able to ship features more quickly. It also gives the development team more tools when they’re trying to troubleshoot and remediate production issues. Many development teams find themselves stuck in the mud when trying to fix issues because they don’t have access to critical systems at the most critical time.
#Executive Teams
The final group that gets a big boost from the adoption of a self-service Kubernetes approach is the executive team. The benefits that flow into other teams climb the ladder. When your teams have more room to improve their performance and reliability, and when your development teams turn around features more quickly, your software is going to work better and do more things. In addition, you’ll likely find that your engineers enjoy working in your environment more. The increased flexibility and additional time to tackle technical challenges mean engineers get to spend more time delivering high-value work and less time troubleshooting issues.
#Adopting Self-Service Kubernetes
If you’re thinking about adopting self-service Kubernetes, there are some things you need to keep in mind. Many teams get scared off from adopting a self-service mindset by things like security and complexity for developers who aren’t used to working with Kubernetes. All of those are absolutely valid concerns, but with the right controls in place, it’s possible to mitigate them before they become a problem.
#Role-Based Access Control
It’s reasonable to respond to a self-service Kubernetes system by wondering whether that means developers have access to every resource in your production environment. The answer to this should be no. No employee should ever have access to more resources than they need to do their job. Adopting a role-based access control (RBAC) system can be complicated, but it’s a critical part of your Kubernetes security. This is true whether you’re using a self-service approach or whether you’re using a more traditional SRE team.
With a self-service environment, RBAC is critical. Developers should have access to the systems that they support because that’s where you trust them, and that’s the work that you need them to do. For systems that developers don’t need to use, they should have minimal or no access.
#Quality UI
Another key part of self-service Kubernetes is providing a high-quality user interface for working with your Kubernetes cloud. And you need each of your developers to spend time learning how Kubernetes works and building skills with the tool. Since Kubernetes is complicated, it can require a big investment. With an intuitive UI, you can short-circuit that requirement, boosting your team’s productivity. This is one of the first things you should commit your SRE teams to do if you’re thinking about adopting self-service.
#Training and Support
Even with a high-quality UI, you’ll probably still need to spend time training your developers to work with Kubernetes, and you’ll need to support them. You can’t expect every developer you hire to be a Kubernetes expert, so having good documentation is crucial for productivity. It’s important to remember that this is an ongoing effort. You can’t just do a little bit of documentation and one round of training and expect success.
#Container Image Management
Another key task for your SRE team is adding and maintaining high-quality container images. While individual development teams should have the last word about the software that runs on their service containers, they need good base images to work from. That means secure, stable software packages that are already installed and a reliable system for delivering those images. Once the SRE team provides useful container images, it’s the responsibility of the team to update software packages and security updates for their system’s code.
#Loft Can Help with Self-Service Kubernetes
If you’re thinking about adopting a self-service Kubernetes approach, Loft is ready to help. It provides a high-quality user interface for your Kubernetes operations and built-in RBAC systems to simplify permissions management. Our Kubernetes experts are ready and willing to help patch any holes in your organizational knowledge and provide that critical knowledge and support that your developers need to tackle their own Kubernetes challenges. Loft also integrates with multiple code management systems, unlocking your GitOps approach to simplify container image management.
If self-service Kubernetes seems like a good fit for your team, reach out today and find out how Loft can help with your adoption.
This post was written by Eric Boersma. Eric is a software developer and development manager who’s done everything from IT security in pharmaceuticals to writing intelligence software for the US government to building international development teams for non-profits. He loves to talk about the things he’s learned along the way, and he enjoys listening to and learning from others as well.
