My favorite quote from the Team Topologies book is from Paul Ingles of uSwitch where he says, “We didn’t change our organization because we wanted to use Kubernetes; we used Kubernetes because we wanted to change our organization.” It is easy to accept the status quo and not reflect on how the tools that we use to craft our products also limit the extent of our solutions. If we want our software engineers to produce more working software we need to remove toil from the process, reduce external dependencies, and abandon old styles and techniques of developing software. My problems are not your problems. Your business will have different constraints than mine. You need to change the habits and behaviors of your staff and the challenges because developing cloud-native software is different.
As you start your journey on an internal developer platform consider these bullets from this article. Focusing on these can help avoid some level of failure. Culture still needs to be taken into account.
- Provide a great developer experience
- Measure engagement and communicate with users
- Measure cost and the performance of the platform
- Improve the platform and the dev experience
- Buying may be cheaper than building
Your north star is improving business outcomes via this platform to enable efficient and effective software development. Due to the power and the flexibility of the Kubernetes platform you could get lost in your journey because of the overwhelming amount of choices and options.
Early on in the research of our Kubernetes platform, I found lots of valuable information to prepare us for our journey to production. From production best practices, security hardening, high-availability, disaster resilience, developer experience, and much much more. Topics that seemed straight forward like whether to have a service mesh and of course we would choose Istio, right? I want to provide a great experience and the draw is that for any of the many opportunities that Kubernetes grants it’s not the best use of my team’s time to solve those issues. The great thing about Kubernetes as a platform is the giant community and new companies solving specific hard problems.
The greatest feedback I heard about this whole endeavor was, “If you can wait six months then do”, looking at you .NET container debugging Bridge to Kubernetes. Kubernetes is a rapidly evolving ecosystem with practices and products that could vanish or disappear or stick around and it’s hard to tell which is which. At some point, we need to accept our decisions and revisit them in the future but most of all we want to make a great experience for our users.
The mortgage broker I work for focuses on two areas: automating the digital mortgage and developing additional revenue channels. To support these two pillars we need an internal developer platform to reduce the friction for teams doing their work but also add friction in our API contract development and other areas. We are content with running our own data centers and dabbling in the public cloud only when it makes sense to do so. To provide the broadest benefit solving the pain points for the 80% of commodity software applications our software engineers create makes the most sense. Those commodity components are APIs, workers, scheduled jobs, and data storage.
When you design your development experience you should think about what challenges your developers/QA face, what their skill sets are, and what you can remove that can help them achieve their jobs easier. In the case of automating a digital mortgage, the challenge is an endless amount of automation around todo lists, documents, and data that needs to go everywhere. We’re primarily .NET C# and we are turning our backs on Windows servers and IIS. We only have 100+ software engineers and our problems and leverage is different than much larger enterprises. For us, handing over kubectl would be a disservice. In the far future if knowledge and understanding of Kubernetes is desirable we will reevaluate if it makes sense to provide a more expert level product offering.
A powerful characteristic of Kubernetes is the ability to have more than one of anything especially platform abstractions.
- Dive.co - Dive is a platform reliability dashboard for Kubernetes.
- Rancher’s Rio - Rio is an Application Deployment Engine for Kubernetes
- Cloud Foundry’s cf-for-k8s - The classic cloud foundry command line experience
- Loft Virtual Clusters a Kubernetes focused approach to enabling safe developer access
- Platform Pronto - an internal developer platform focused on four essential project types for developers
Focus on serving your team and get them a product they can start using as soon as possible. Unfortunately, platforms require a lot of basic features to be usable but do not develop your platform in a vacuum thinking you understand the experience better than your users do. Understand that even if you try to over-abstract everything that might be a disservice to your software engineers when they need to dig in and debug how things work in this new environment. Your experience might not match mine and different audiences might need more or less direct control. Buying and installing a tool does not make people act or work differently. When you bring in a tool like Kubernetes expect that cultural and behavioral changes may be equal or harder than the technological challenges.
- Get training for your staff and be prepared to overcommunicate the required changes and knowledge
- Provide a great experience and measure those improvements while obtaining continual feedback
- Buy solutions as much as possible because the breadth of opportunities in the new environment is endless and likely your company is not best suited to solve those problems