"A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product" - Evan Bottcher.

"Making the right thing the easiest thing to do" - David Sugden

There have been a few discussions at one of my clients about treating your platform as a product and how to treat your developers as customers.

This reminded me of David Sugden’s talk about providing a platform at scale.

David discussed how a platform needs to be the path of least resistance to gain traction. When an organisation is in startup mode, dev teams try to do everything. Eventually, they have to do more and more: patching, containers, runtime, and K8s. At this point, the organisation may want to start using a platform.

What does this mean:

• Self-service

• Supported

• Compelling

• Voluntary

It’s essential to find the sweet spot between Decentralised — Federated — Centralised

The teams at David’s organisation requested different elements and services via self-service when needed. The platform team did the rest of the scaffolding admin e,g,

• Security

• Patching

• Data backups

• Autoscaling

The platform team provided several different services:

• Github

• Artifactory

• IAM for all services

• Nexus

The only way to access MVN central was via Nexus firewall

The Platform team also provided several integrations, meaning teams got many benefits from using the Platform services rather than rolling their own.

• Service now integration

• JIRA

• Styra integration

The platform team did all the things they could have had to do themselves

The platform team also created golden paths for using their various services. These were Inner-sourced so that if teams wanted to submit changes or adaptations to the golden paths, they could either submit a PR or fork the repo

The platform team were obsessed with self-service - "No one should ask us to do things for them."

The team produced metrics and a dashboard to demonstrate that the teams were using the platform. The key data were also summarised in a monthly service report. The platform team felt that they should "Meet engineers where they are", i.e. platform engineers engaged with customers in their team chat rooms.

The platform group set targets for the adoption of the platform by the dev teams. Their expectations were:

• 70% golden path as is

• 20% needed tweaks / inner source

• 10% sceptics / too niche

One of the platform team's key targets was to move the percentage using the as-is golden path to 80%.

The platform team had a dedicated product manager and a monthly open forum where they discussed the platform with its customers. They also had a suggestion forum and shared the roadmap so the dev team could see what was being worked on. Sharing a roadmap of requested features and which team asked for them is always a good incentive. This shows other teams that the platform is in use and creates competition with other teams to request features and efficiently use the platform.

The platform has to be a compelling product, so you can say, 'It would be better for your team just to use our platform, and then they can focus on delivering value.'

The platform team identified several large business units with a lot of overlap so they could use a common platform and make savings. Senior management then supports promotion. The platform's promotion was more about CTO support than mandating people use it.

Having a Product manager is a handy way to ensure that your platform team treats your dev teams as customers and that they are well-represented. By adding the scaffolding and the ancillary services, they have encouraged their users to choose their services.

The real emphasis on making using their service voluntary rather than mandatory ensured that they could stay customer-focused even though they were global in scale.

'A Platform is a set of tools and services arranged into a compelling product for developers to use."

Andy Burgin of Flutter is also part of a platform group responsible for setting up and onboarding customers to the central Kubernetes cluster. The emphasis at Flutter was on Devex, and the use of the platform relates directly to developer productivity.

Initially, the problem to be solved was using docker containers in production. The K8s cluster has been in use since 2016, and the production use of containers was a scary process back then.

Several integrations, e.g., firewall, DNS, and logging, were implemented, essentially a whole product suite of supporting tolling. After it had been in place for a while with multiple users, the team added RBAC support.

Unfortunately, while the rollout of Kubernetes was effective, several platform engineers were unhappy. This was mainly a case of growing pains. Andy’s talk outlines the next stage of development for the platform.

The platform team responsible split into three subteams:

• The engine team ran the actual cluster at a technical level.

• The capabilities team were responsible for the various integrations and add-ons.

• Andy was a senior member of the customer experience team who looked after the devex side of things.

The team needed to establish a baseline to assess how to improve things, so they surveyed users using principles from Accelerate and produced their own State of Container platform document. The anonymous surveys included usability statements such as “I find it easy to deploy my code via a pipeline.”

The next stage was to determine who their customers were. For this, they used their internal Slack bot, which is used to raise support issues.

They obtained a list of customers raising tickets about the cluster and examined the org chart to determine which teams their users and customers belonged to.

They carried out our open-door meeting once a month, which fed into Capacity and development planning for the teams. The whole meeting was minuted, and actions were followed up on. The meeting notes were logged in the shared wiki, which led to high accountability, as it was open to all staff members.

From these various meetings and surveys, the Platform team was able to develop a set of things to work on and put this in priority order.

To better communicate ownership of the resources in the Kubernetes cluster, the platform team stored details of the owning team in the Kubernetes metadata for the resources.

One of the advantages for teams using the centralised Kubernetes cluster was that the Platform team had set up standards and compliance advice and checked across the whole cluster. This meant that teams could look at the metrics, complicate checks, and see if things were being met - some teams even produced real-time dashboards showing this information.

Another thing the teams were able to surface was capacity usage and costs. Again, dashboards could be produced to show and type these data back to the owning teams. Once these metrics have been created, the monthly planning meeting could be structured around working through all the metrics.AWS cost metrics

The Flutter team worked with the development team to produce a set of golden paths for deploying API actions to the cluster. These were made by developers for developers. The infrastructure team created a set of managed base images as part of the cluster's production. The golden path consisted of standard pipelines, documentation, and instructions for using them. As another incentive to use the centralised cluster and golden paths, they have security to pre-approve your process if you use the framework.

One of Andy's key points is that you should not do the ‘wrong things right’. Ensuring that the proper training is delivered and documentation is provided is essential. It’s critical to speak to people Face to face. Don't create a Slack channel; instead, have regular meetings. Andy said it's important not to be the person who says, ‘People don't know what they want,’ and then produces the solution you think they want. They are fully aware of what they want and need to be given some agency to affect the tools they are working with.

It’s essential to collect good actionable data about who your customers are and to do customer surveys and break customer requirements into different areas so you can see what is still to be worked on

I worked at Flutter during the early part of this process, and I found the inner-sourced golden paths and the willingness of the other teams to be good at sharing info made the platform usable. It was very helpful when Andy asked what we wanted from the system and also to be offered training. Still, while the platform team provided the scaffolding, the golden path and the pre-baked base images completed the circle.

Once you treat your customers as customers, they will also become advocates and help their colleagues use the platform.