Platform as a Product
Why neither mandatory nor “opt-out” services deliver on the promise of Platform as a Product
Back in 2018, Even Bottcher wrote a great post about Platform as a Product: https://martinfowler.com/articles/talk-about-platforms.html.
Be very careful not to just apply the platform label to the limited virtualised hosting and locked-down centrally-managed tooling that you already have.
Bottcher discusses how important it is that platforms be compelling to use. In particular he states the following qualities of Platform as a Product:
- “you must be willing to trade off strict consistency of implementation against the freedom and responsibilities that you’re handing to the autonomous application teams”
- “self-service for the overwhelming majority of use cases”
- “composable, containing discrete services that can be used independently.”
- “does not force an inflexible way of working upon the delivery team.”
Choices
Platform as a Product is not about making your platform perfect. It’s about giving people choices.
You’ll know you are making a platform better if people opt to use bits of it. This implies that they have the option not to use it. If people can’t escape, there’s no motivation for platform engineers to be user-centric. And that ends up hurting our value chains.
Learning as we go
At Armakuni we believe in continuous learning. That’s why we have non-production cloud accounts available to all our engineers. We use these for training and non-critical internal services.
One example is the GCP serverless function behind our Slack “Gopher” app. It can carry out quick tasks like /randomuser — useful to pick someone at random to chat to.
Various processes and tools help us to make use of these cloud environments.
A global Azure policy
One of these is a policy we set up in Azure. Creating a resource requires specifying tags indicating the owner and purpose. This is to allow us to work out what we still need. A great idea!
But, unfortunately, we found that this policy breaks the use of Azure’s az CLI tool. For some Azure resources, one can’t specify tags at the time of creation via the CLI. Instead, you have to first create the resource, and then assign tags afterwards.
We applied the policy globally, meaning that all our engineers had to comply. This meant that the only way to use the CLI tool was to disable the policy for parts of the system and then re-enable it. Of course, this sort of thing never works and we ended up with the policy turned off for large parts of the learning environment.
A clean up “nuke” script
Another tool we created is an automated “nuke” script. This script has an exclusion list as part of the source code. Every Friday afternoon, the script executes and removes all non-excluded resources. This is a great idea because it cuts down on unnecessary charges, and wasted resource.
The result?
People started using personal accounts for learning and tooling. Our simple change to our platform made people nervous to use the environment. We made using the platform harder by forcing people to remember where and how to keep their work safe.
So, what should we have done?
Our tagging policy made sense. Knowing what resources are for is important. Cleaning up wasted resources is also a great idea — for our finances and our planet. But, we tried to mandate these things rather than helping people to be responsible.
One way we could have handled the tagging policy would have been to replace it with an audit function. Stop mandating people create tags at the moment of resource creation. Instead, audit resource groups which haven’t implemented this policy. If they contain resources missing tags, provide a single click way to add it.
But, let the resource creator choose. They might decide to do it by hand. We can ask why and provide a better alternative.
One option for cleaning up resources is to audit the resources that exist and produce a report on costs. Then provide a one-click way for people to clean up, or to schedule retention.
In conclusion
Give platform users choices. If they don’t choose the service, it’s a signal that your product fit is wrong. If you don’t keep your users in mind, they’ll find a way to bypass you.
