Notes from building internal developer platform — Part 3: Managing platform as product
The previous entry of the series ended with a significant insight: the moment we shifted the conversation around the platform from a one and done foundational layer set in stone, to a malleable product that we can iteratively craft to address one pain point after another. At this stage, we are managing infrastructure as a product and applying product thinking can be beneficial in order to maximize the platform’s value for its users. Since the development can go to any direction, it becomes imperative for us, as the builder to think of:
- What are the business outcomes that we want to address?
- What are the pain points that the developers are experiencing?
- How big is the problem?
- Can we validate that we provide the desired solution?
- What to prioritize next?
These are fundamental product management train of thoughts that we can utilize to better direct the overall development of the platform, preventing it from becoming just another developer experiment.
It’s worth to also note that treating infrastructure as a software is technically made possible due to the fact that the underlying layer itself is already taking shape in form of higher level abstraction (e.g. Kubernetes, Istio) over lower level building block (e.g. OS). But exposing bare Kubernetes or Istio to developers isn’t the correct strategy since each has its own complexity and different domain altogether. But they have powerful APIs that the platform builders can utilize to create more valuable abstraction and automation that empowers developers to operate their services.
Now, what about the user side of things? On this point, we’re handling the product as one that’s aimed towards expert users, as opposed to creating one for the common public. This means that feature wise, the product will go deep and focused towards specific domains, and due to its internal nature, it will be highly contextual to how the company is organized and governed. The key here is to identify the current workflow, map it, systemize it via platform and gradually optimize it to better serve the users while keeping aligned with the organization compliance. Past that, it’s up to us on how to provide better UX on each iteration to enable developers in performing their tasks outlined in the developer activity model.
For example, in the first iteration, we may have user story that goes like this
As a developer, I want to be able to deploy my services to our Kubernetes cluster without having to write YAML configuration from scratch, so I can confidently complete it myself
The solution can obviously be implemented in many forms. Say, we decided to go with GitOps flow, and utilize our Git provider’s pipeline capability and match it with a Kubernetes friendly CD provider to automate this activity, so deployment is 1 trigger away. We can provide the template pipeline setting that developers can complete by filling in specific information that only they know.
Over time, we discovered that though the solution works, developers still feel that sometime, they feel they have to do context switching between our platform and our CD provider just to ensure that the deployment is successfully performed. Thus, we can propose another user story to tackle in future iteration that goes as follows
As a developer, I want to be able to check my deployment status straight from the platform, so I can verify without having to do any context switching
The journey of making the platform developer friendly should become clearer over time, even if it involves a lot of moving parts. But we can achieve this only if we can truly care about the platform users. Maintaining a clear communication line, and continuously monitoring its usage, becomes a necessity, so we can listen and formulate what the developers actually need.
Another point that we should touch when we treat infrastructure as a product, is the fact that we also have to consider requirements or objectives from a business perspective. And just like demand from users, these targets will also move over time, even if it’s not that often.
For example, at one point, your goal is clear: to improve developer efficiency. But as we have discussed, this is a very large goal and achieving it is definitely not straightforward. So that goal remains a foundational outcome that doesn’t change much as time goes by. What changes much is the context around it. Perhaps the organization is expecting a lot of recruitments to happen over the next few months, thus the platform’s ability to onboard new joiners to let them contribute sooner, can become a priority. And of course, this also contributes to the overall developer efficiency.
Another probable case is to make the system adhere to regulatory compliance. This way, the platform can act as a means to enforce compliance by embedding it inside the developer’s workflow. In the end, for developers, the ability to complete their tasks, without having to go back and forth to fix compliance related issues, will positively contribute to the overall developer productivity and efficiency.
As you can see, product thinking can go a long way in ensuring that the platform delivers value to its users while keeping the business outcome that benefits stakeholders intact. By treating platform as an evolutionary abstraction, we’re bound to manage it as a product. Approaching this with a product thinking mindset will help the platform builder to iteratively develop it in oder to be able to constantly gives value to the platform users, bearing in mind the dynamic change around the organization.
I hope this series of writing helps you in shedding light on some of the ins and outs of building an internal developer platform.
If you haven’t, do check out other entry in the series to give you broader picture of this issue
