Manuel Pais talked at QCon London [slides] about how team interactions are vital to reduce cognitive load in order to successfully adopt Kubernetes. Pais recommends having a team dedicated to building a digital platform on top of Kubernetes for development teams to use. Other key takeaways included that organizations can get started by assessing the team's cognitive load, defining a digital platform, and setting clear team interactions.
Kubernetes helps development teams to work with the complexity of distributed systems, and it offers abstractions to run and deploy services. However, there are non-functional requirements that organizations also need to consider, such as capacity planning, upgrades, patches, and security practices. Moreover, the Kubernetes learning curve is high, and often development teams struggle to adopt this technology. Therefore, Pais recommends having an internal team dedicated to building a digital platform in order to reduce cognitive load for development teams in regards to knowledge and support. For instance, companies like Airbnb and Uswitch enable developers with self-service capabilities to reduce cognitive load.
If organizations want to start with a team-focus approach for Kubernetes adoption, Pais gave three recommendations. First, asses the cognitive load in the team by exploring how well they understand the Kubernetes abstractions they'll use regularly. Second, define what the platform is responsible for by documenting how the platform team will provide on-call support, communication mechanisms, and recommended practices. And third, clarify team interactions to define who's responsible for what, who's impacted, and how collaboration is going to be in the new internal digital platform with self-service capabilities.
InfoQ interviewed Manuel Pais, co-author of the Team Topologies book, to learn more about his recommendations for adopting Kubernetes in an organization.
InfoQ: Kubernetes is a complex distributed system, and the learning curve is high. What do you think makes Kubernetes special in being the foundation for changing the organization?
Manuel Pais: Focus on the platform; don't focus on the technology too much. You can look at this talk, and you could replace Kubernetes with OpenShift or whatever. I talked about Kubernetes because I see that's what many organizations are embarking on without understanding "why" or "how" is it going to help the life of the development team.
The key point is to focus on the platform and the interface with the development teams. Whatever is underneath might be Kubernetes because it's pretty solid, has a lot of functionality, but might be something else. I was talking with a friend who works at a large bank. And for them, it doesn't really make sense to use Kubernetes, at least now, because it will require all this learning, even if you have a platform team. What they have now works for them. They might have some gaps that they can address without actually taking this radical move to Kubernetes.
InfoQ: Some people are advocating for not using Kubernetes because of its complexity. But that could happen with other technology as well. Would you say instead that the key should instead be to focus on reducing cognitive load?
Pais: I mentioned in the talk that these platforms are contextual, in the sense that it has to make sense for your organization. We can't just take it as a kind of face value that, "Well, Kubernetes is good because everyone's using it."
But, what is the platform that makes sense for your organization? It could be "OK, Kubernetes is the right choice because I have sufficient knowledge and maturity to use it. And it's going to fit with my model." This was the case for Uswitch. They had a pretty advanced engineering team, so they knew Kubernetes was complicated, but it wasn't an issue for them. Or, in the case of the large bank I mentioned earlier, for them it would be a radical change to move everything to Kubernetes, and that is fine because in their context, it's not worthwhile.
Focus on your development teams to reduce their cognitive load with the platform. Technology is not a minor thing, but it becomes the second line of thought. It would help if you first look at the problems that most teams are having to be able to deliver and run their services.
InfoQ: How would you recommend a company begins their journey when wanting to adopt Kubernetes or any new new technology?
Pais: Start looking at your end customer product adoption. How do you measure what your service or product brings you in terms of revenue? How do you measure adoption? Because, hopefully, you're not just churning out features if you don't see adoption from your customer base. So, it's the same for a platform. How do we make this something that can be easily adopted, and teams engage with? I talked about the platform as a product. So that should be the starting point.
Then in terms of the complexity of technology, don't make early decisions based on what everyone else is doing. Make decisions based on what you need now. This goes together with the focus on adoption by your internal users. It takes small steps. Look at platform engagement and adoption. Sometimes different services in the platform might have different adoption patterns. You can use that to your benefit and understand why it was effortless for some teams to use a service and not so easy for other teams. Maybe this new service was not really adopted because technology is making it complicated, and you need something more straightforward. Focus on the platform adoption.
