Deploying Your Own Kubernetes Cluster in the Enterprise Is Anti-DevOps – InApps Technology 2022

You’re fast-tracking a project and moving at the speed of light, so having a developer deploy another Kubernetes cluster just makes sense, right? After all, speed is everything in today’s enterprises, as they compete to bring new products and applications to market. No one wants to slow down developers. Deploying another K8s cluster and having multiple DevOps teams across the enterprise create and maintain their own infrastructure may put you ahead in the race for this project, but you’re rushing headlong towards a cliff when it comes time to scale DevOps later. And if the enterprise can’t scale beyond a handful of teams, it’s going to lose speed — while competitors that can scale will easily outpace it.

Any business that is growing fast or has reached enterprise size faces this dilemma. No one wants to return to a strict centralized IT practice, where application delivery teams feel disempowered and must wait for an understaffed IT team to fulfill all their infrastructure requests. Yet the practice of everyone building and maintaining their own infrastructure eats away at quality, compliance and governance.

Cue Platform Teams…

To address this, companies have instituted platform teams — dedicated, cross-functional subject matter experts that build, govern and maintain these self-service platforms for internal development teams. These platforms are built as customer-centric products to help solve end users’ problems in the most effective, enterprise-approved way, while still offering an open source mindset that lets developers have a say in what they need in order to do their best work.

Platform teams are not new; in fact, Gartner put out a great piece on how to make these work well a couple years ago. At Puppet, we work closely with enterprises to help platform teams build the API-led solutions they need to succeed.

I’ve found that developers have mixed emotions when it comes to platform teams and how well they actually work. There are good reasons for this. Developers often worry that being forced to use infrastructure provided by central IT will result in less freedom over their creativity and unnecessarily slow them down. Indeed, platform teams that are funded as a one-time project may work well initially, but without ongoing investment the platform will stop evolving to meet user demands — which will create frustration on all sides. End users end up creating work-arounds, building their own infrastructure, and returning to the bad old days of shadow IT.

It is a developer’s job to innovate, build and iterate as fast as possible. Doing it on their own is often the fastest route to success for an individual project, but it may not be a sustainable approach overall.

But without a platform team, are you really practicing DevOps? 

You may be missing the forest for the trees. Zoom out and look at the enterprise as a whole: if everyone used a different OS, you end up with chaos because the lack of standardization inhibits overall optimization. If everyone creates their own little infrastructures, how will you scale when you have dozens, if not hundreds, of developers? Platform teams, when built with the user in mind, give you a common toolset that minimizes the cost of quality, compliance and security, and enables faster value stream delivery. A developer’s job should get easier if the platform team is doing its job well.

What It Takes for the Platform Team to Succeed 

1. Support a systems-thinking approach. This is a key tenet of DevOps. Systems thinking requires that you look at the enterprise as a whole, and see every DevOps team member as part of that whole. Imagine the enterprise as a giant spider web. Every time someone moves at any place on the web, the entire web feels the effect — even if you don’t think your new K8s cluster has any real impact. There are externalities that come into play for every action. What’s the impact? Will a developer’s actions contribute to the ability to scale, or inhibit it? What is the responsible way to contribute to the org? What’s the sustainable way? Is how you are doing DevOps today supporting the teams of developers that will be working at your enterprise five years from now?
2. Invest long-term in platform teams. Platform teams need funding that increases over time, as they build multiple platforms and expand their impact across the enterprise. This is not a short-term project. Platform teams should be considered a permanent part of the organization, as crucial to innovation and revenue as the product development team. They are, after all, building the internal products that developers will use to create products for your external customers.
3. Choose a diverse mix of experts. For platform teams to work well, they need a diverse mix of cross-functional subject matter experts who share the ability to code. They need to understand how developers inherently work and what will best solve the bigger issues at hand. They need a customer-centric mindset that continually seeks to create solutions that work. Building a platform as a product requires as much skill and expertise as building your external products — and these team members need to feel the support and validation of the enterprise leadership behind them.
4. Appoint a platform product manager. The team needs leadership — someone who decides what the platform will do, not how to do it. This person needs to have a product mindset, focusing on the market of users, discovering their problems, and building self-service solutions that genuinely address these needs. With competing demands and needs across the enterprise, the product manager needs to prioritize new solutions, deprecate those that aren’t meeting user needs, and ensure that strong feedback loops exist between the users and the platform team.
5. Build with API-first, modular, composable solutions. End users must be able to take the solutions and recompose them in ways that work for them. Focus on providing solutions via easy-to-consume and easy-to-combine APIs that can be triggered from scripts, automation tools and CI/CD systems. Make the code behind these solutions visible internally and ensure internal contributions from your users are possible with an “inner-source” model.
6. Evangelize the platform internally as well as you market your products externally. You can build a platform and have a team, but if it just exists and no one really knows about it, it won’t succeed. Run internal marketing campaigns and get users involved in contributing to ideas. Put that DevOps feedback loop in place, so the platform becomes a continually improving core essence of how developers get work done.

With a well-run platform team delivering composable and modular self-service solutions, developers can operate with a high degree of freedom — relying upon standardized dependency layers that ensure compliance and scalability for the rest of the enterprise. Doing this well requires continuous investment in people, processes and tools; but it will also generate continuously increasing returns, as long as it’s not treated as a one-time investment.

Feature image via Pixabay.