#98: 10 best practices for Platform Engineering

Hey there! Welcome to Platform Weekly, your weekly can of platform engineering beans. Every week, we try and unpack some of the mysteries of the platform engineering universe. We talk about news, events from the community, and most of all learnings and best practices. Let’s get crunchy.

P.S don’t miss the highlights, we’ve got a treat in there??

10 best practices for Platform Engineering

The first-ever official platform engineering fundamentals course has been insane. We’ve covered all the core principles of platform engineering from designing your golden paths, perfecting your abstraction layers, and knowing exactly how to start and how to succeed.

With 8 sessions + 2 guest lectures from Manuel Pais (author of Team Topologies) and Ajay Chankramath (Fmr Head of Platform Engineering at Thoughtworks), and dozens of conversations across the course Slack with all the attendees - I feel like even I’ve 5x’d my knowledge of platform engineering during the run of this course!

We also dove into what is usually the hardest part of platform engineering. Getting buy-in from your management, proving the value of your platform. And actually ensuring your platform gets adopted and succeeds.

There is no way I could summarize 8 weeks of learning and 2 awesome guest lectures into one newsletter!

But let me give you a taste of what we’ve been exploring. As first shared in my Platform as a Product whitepaper. Here are 10 best practices for platform engineering. ________

10 proven best practices

Build vs. buy vs blend?

The market reached a maturity level where it doesn’t make sense anymore to build everything from scratch. You should make a business case and do your ROI calculations as early as possible. According to our DevOps Benchmarking Study 2023, the best-performing platform engineering teams blend OSS with commercial vendor offerings but do not build everything from scratch. Check the platform tooling landscape for inspiration.

Apply well established architecture patterns?

With a three-tier architecture (presentation, application, data): start building from the backend; do not simply put a developer portal as a presentation layer on top of your existing setup and build additional logic into it. Build the house first, then the front door.

Everything as code

Consider code as the single source of truth which helps maintain transparency, increase reliability, and simplify maintenance. An IDP that’s code-first at its core allows for disaster recovery, versioning, and structured product development principles. This does not exclude further interface offerings such as a UI (portal), CLI, or API.

Build golden paths over cages

Creating golden paths that provide best practice guidance and recommended approaches helps lower cognitive load and improve security and standardization. IDPs that apply smartly layered abstractions give developers the choice to follow the golden paths and be free to leave or change lower-level configs if the security posture allows.

Take an 80/20 attitude to platforming

Do not try to please everyone. To adapt to different situations, meet diverse needs, and benefit from evolving technologies, staying open-minded is key. But your platform design should not try to cover every technology on earth or convince every developer in a user base. Do not assume that you will be able to please 100% of developers. Instead, consider achieving 80% a great win.

Leave platform interface choice to the developer

To ensure adoption, give developers the freedom to use the interfaces they’re most comfortable with and that best meet their needs. Provide the option to use an OSS workload

specification like Score, a portal (GUI), CLI, or API.

Security from scratch

To get buy in, implement security best practices from the get-go. If the V1 of your platform doesn’t fulfill security and compliance requirements and if there is no proof that the platform will even support ensuring security and compliance by design, security teams will veto and your platform initiative is dead before it could even properly start.

Measure from the beginning?

Measure success with hard numbers to support informed decisions and generate stakeholder buy-in. Choose metrics wisely, considering both leading (e.g., automation and complexity scores) and lagging indicators (e.g., DORA metrics). Track leading indicators in non-production environments early on. Remember to include NPS scores for developer satisfaction, as well as stability metrics, SLOs, and SLAs.

Gain stakeholder buy-in

Make sure all stakeholders have a seat (besides the developers - your customers). From security to compliance and legal teams, from architects to I&O teams, and important for the funding of your platform engineering initiative: executives. Make sure you build a platform team where important stakeholders are represented by heralds and the team goals are aligned with those of your stakeholders.

Think about adoption from the first day

If the platform is not used, it is dead. This is about internal marketing/evangelism.

Identify the right first team to onboard and make them advocates of your platform They are essential for platform success and developer adoption.

_________

For the second cohort of the fundamentals. We’ll go through all 10 of these points and break down exactly what you need to do to build a winning platform. And more than that - the course is a lot of fun too!

See you there