Delivering Great Developer Experiences with Platform Engineering

Introduction

Companies increasingly turn to platform engineering to help scale their development teams and increase developer experience for engineer efficiency. But how do platforms work? Who should build them? Is platform engineering overly focused on technology, or is it about people? In this virtual panel, we’ll discuss how teams build platforms, set others up for success, work with developers who use their platform, measure their progress, and adapt to new challenges.

We’ll examine platforms from the perspective of developer experience and explore how leading companies are helping their engineers avoid bottlenecks and friction. While there will be many stories of how things went well, expect a few tales of unexpected trouble and bumps in the road, too.

The Panelists

• Aviran Mordo, VP of Engineering @Wix
• Jemma Hussein Allen, Platform Engineering Technical Lead
• Ana Petkovska, Engineering Manager of Developer Experience Group @Nexthink
• Andy Burgin, Principal Platform Engineer @Flutter

InfoQ: When did your organization intentionally start designing and building a platform, and what was the key driver for this?

Aviran Mordo: Back in 2010, when we started to learn how to do CI/CD, we realized that we wanted more than just automation. We wanted to give our developers the best experience we could think of for managing their artifacts.

In 2011, we fully adopted microservices architecture and figured out CI/CD methodology, so we set up to build the first platform and developer’s portal.

A few years later, we looked at our developer’s velocity and took yet another step in Platform Engineering. We took the abstraction to a higher level, from the infrastructure level to the code level, and built Platform as a Runtime, which spans from the code level all the way down the stack to the infrastructure level.

Jemma Hussein Allen: The organizations I have worked in started to build their platforms around 5–10 years ago. Initially, the platforming initiatives started when we migrated workloads from on-premise to virtual machines in the cloud. Once containerized workloads became more widely adopted, we migrated from either on-premise to containerized cloud-based workloads or from virtual machine cloud-based workloads to containerized ones.

The organizational platforms are adapted to accommodate the specific application use cases. The platforms used in the organizations changed to allow for better use of the technologies and integrations that different projects needed.

Andy Burgin: My organization has been around for many years and runs many gambling products, so there never was a point where we decided to "do platform engineering"—it was more of an evolutionary process.

To illustrate with a specific example, in 2016, we wanted a platform that allowed our developers to go fast, removing dependencies and handoffs for developers. The aim was outside of the tribe; there should be no humans involved in the value stream between feature and customer. Based on that definition, we created our first Kubernetes platform, which became a huge success. It was adopted by development teams across the business and continues to deliver value to this day.

Ana Petkovska: We started the first team focused on platform engineering and developer experience in February 2022. At that time, our central DevOps team struggled to scale with the growth of the product engineering organization and the variety of areas it got as ownership over the years. Thus, we formed the Engineering Productivity team (inspired by the so-called teams at Google and GitLab) focused solely on internal tooling. The team started building self-service platforms around the areas where we received the highest number of requests and which could bring the highest productivity gains.

InfoQ: What do you do to engage developers in using the platforms, and how do you support them in their daily work?

Aviran Mordo: Developers usually don’t like too many abstractions, so to gain their trust, we have invested heavily in education, teaching how the platform works behind the scenes. At Wix, we have very strong guilds, so leveraging the guilds as a channel for education really helped.

In addition, we have a very active support channel where developers can ask the platform team anything.

Another thing that helps us is that we treat our platform as an internal open source, so developers can always see what is being developed, request new features, and contribute to the platform.

Jemma Hussein Allen: We found the best way to engage developers is to keep everyone in the loop about the current platform implementation and the future roadmap. Alongside this, a key engagement point is regularly asking for developer feedback and suggestions, especially around any pain points, and ensuring the roadmap incorporates these improvements.

Andy Burgin: We were always a very customer-centric team from the outset of building the Kubernetes cluster. Indeed, the cluster was originally built as a platform for a specific product; therefore, we always had a customer (development team) and created a great working relationship with them. However, as we grew, we realized that what would now be called "DevEx" was an essential part of running the platform, so we created a team specifically to engage with our developers.

We started monthly meetings to foster collaboration and feedback loops. We have a chat-based support function that keeps engineers away from tickets (although the work is logged and recorded into tickets by the chatbot). We have also trained hundreds of engineers with workshops that teach them how to build and run applications on our clusters.

Ana Petkovska: We have several ways to engage with the developers, depending on the purpose of the engagement.

We have weekly meetings called DevEx Connect, where we inform the teams about important changes that our teams are bringing. We have found them particularly useful in periods when we needed adoption of the platforms that our team built: to inform the developers of the progress and important changes, to answer questions, and to get feedback.

For bigger changes, we also organize workshops and trainings for the teams. For any issue during the daily work, we have a dedicated Jira board where the developers can open support tickets for the tools and services that the platform teams own. For simple queries, they can also contact us via a public communication channel.

InfoQ: What was the biggest hurdle with the adoption of your platform?

Aviran Mordo: The platform is highly opinionated about how to do things. For instance, you can only have a single entity in a microservice. Some developers felt that developing within the platform had too many constraints. They were very reluctant at first to use the platform, and we did not force them to. Our mission was to build something good enough that they would want to use it.

To mitigate that, we had to have a very responsive platform team, work together with all the developers, and address their issues, whether by finding workarounds, letting them opt out if necessary or sometimes even changing design decisions.

We always leave spare capacity in the platform team (about 30%) to quickly respond to the product developers' immediate needs. If a developer is stuck on the platform, we treat it like a production incident to get them unstuck as fast as possible.

Jemma Hussein Allen: The biggest hurdles we found were slowed integration due to other business priorities and concerns about losing freedom when moving to a more standardized platform deployment process.

The deployment process varied between the different areas and teams in the business, mainly because different developers preferred different tooling or because the processes had been set up at different times, meaning older processes didn’t implement the latest recommended practices.

We found that developers were happier to onboard after they had spoken with other teams that were already using the platform and could speak from experience about how it helped reduce deployment time and cognitive load. Addressing specific team pain points really helped to increase platform adoption.

Andy Burgin: Many of the development teams hadn’t worked with containers before, so our extensive training workshops were key to setting developers off on the right foot and helping them do the right thing. Within the first hour of the workshop, we’ve already covered twelve-factor app principles. We realized that helping developers "do the right thing" was particularly challenging if no one wrote down what that looked like, so we worked with the development teams to create a list of what "good" looked like; we called these our "best practices" focused around build, deploy, and run.

We soon realized that many of the "run" items could be codified, so we implemented checks on the cluster to measure workloads against those criteria and produced tooling that allowed development teams to view the "compliance" with the best practices.

I’m super keen to ensure that if you are going to "empower" teams, you need to give them tooling to help them understand and act upon them; too many times, I’ve heard "shift left" used as an excuse to reallocate ownership, we didn’t want to be one of those teams.

Ana Petkovska: The hardest part is getting time from the developers to adopt a change. The main focus of the developers is the product that the company sells. Thus, we are competing for time and resources with all the items on the product roadmap that are the highest priority for the product development teams. In these situations, it really helps if the platform's adoption is also supported and recognized as a top priority by the upper management.

We also started building a joint roadmap for product and engineering work. This gives better visibility to all the engineering initiatives that the development teams need to focus on to improve engineering efficiency, as well as the quality, and security of the product.

InfoQ: How do you measure the impact of your platform? Are different approaches required to collect data for developers and executives?

Aviran Mordo: We conduct both quantitative and qualitative surveys of developers and managers. We measure the development velocity to see if we improve it.

And we treat product developers as partners and advisors. For every new feature the platform team releases, they have an advisory board from the product teams to give them feedback on the features and be a design partner. This way, we always know that we develop the right solution to their problems.

Jemma Hussein Allen: We measured the impact of the platform using Dora metrics, mainly deployment frequency and lead time to change, as the platform handled deployments using a blue/green method, so any failed deployments were automatically rolled back without causing any impact to the end user.

Regarding the business, the metrics were gathered at the project management level using reports such as burn-down charts.

Andy Burgin: When we started the DevEx team, the first thing we did was baseline what the development teams thought of our clusters. We surveyed the teams and asked for anonymous feedback on the clusters (we thought we were more likely to get constructive feedback if it were anonymous). We recorded how teams felt about using the platform by assessing usability. To do this, we included nine questions about usability, which proved extremely valuable for measuring sentiment year after year; these quantitative metrics are great for measuring adoption.

It’s rather more nuanced to collect qualitative metrics as differing perspectives are needed to gauge if DevEx is delivering value. Having metrics and feedback openly was one way we could look at what was a seemingly great overall "score" but understand that the qualitative feedback indicated that the reach of the effort and the value it was returning wasn’t sustainable, so we stopped it as a role and moved those responsibilities back into the engineering teams as business as usual function.

Ana Petkovska: In order to have the full picture, we try to get both quantitative and qualitative metrics.

For quantitative metrics, we are mostly focused on tracking the adoption metrics to understand at what stage of adoption different teams are, how often they are using the base feature of the platform, and how it improves the state in our organization compared to legacy tooling.

Depending on the project, we run surveys or ask for direct feedback for qualitative metrics. For now, we do not have to collect different data for developers and executives.

InfoQ: If you could time travel and start your platform building again, what’s the one thing you would change?

Aviran Mordo: Since Wix started very early, we had to build our own solutions for the platform (there were no commercial or open-source products). Thus we ended up actually building two platforms, one for the backend engineers and one for the frontend engineers. In reality, these are similar platforms, but we ended up with different platforms that don’t have feature parity and without a holistic view of our system. If I had changed something, I probably should have insisted on building just one unified system for all developers.

Jemma Hussein Allen: If I could change one thing, it would be to implement a more component-based adoption of platform tooling where teams can onboard individual platform components at the best time for the team and project. This would speed up the adoption of platform tools and make it easier for developers to familiarize themselves with each component.

Andy Burgin: I think we did some great work given the Kubernetes ecosystem at the time; in hindsight, we should have been more involved with the developer toolchain. But at the time, we never saw that as a function of the platform team in the early days, as the development team owned their SDLC and tooling. That led to some fragmentation and duplication of Kubernetes tooling; however, over time, that consolidated into a golden path framework originally built by one of the development teams.

I’d have liked the platform team to have helped encourage the adoption of the golden path framework by more development teams. But I still think that it was right that developers built it for developers. I believe it’s been much more widely embraced than if we, as a platform team, had mandated such a solution.

Ana Petkovska: The one thing I would change is to prepare better for mandatory adoption. For platforms, it is best to make them part of the golden path and avoid enforcing adoption. However, sometimes, we have to set strict deadlines for adoption.

One typical case, for example, is when we want to deprecate an existing tooling (in order to decrease the cost of maintenance or to avoid extending a contract with a vendor). If you are not well-prepared for such mass adoption, you might put a lot of load on the platform team for support.

We started taking the following actions to prepare better for such moments.

1. Announcing the deadline early enough and sending reminders so the developer teams can plan time to execute the adoption.
2. Having a variety of use cases as early adopters of the platform to cover different needs.
3. Setting gradual milestones for adoption to avoid everyone waiting for the last day.

Conclusions

Platforms offer more than just automation; they support developer experience. They make it easier to use new technologies and provide integrations. They can also remove dependencies and handoffs for developers, which can lead to productivity gains.

Platforms also help scale organizations by providing uniformity in development methodologies, toolsets, processes, and best practices as they are codified into the platform.

Organizations engage their developers in platform development through education, for instance, by teaching how the platform works behind the scenes. They involve developers using internal open-source approaches and guilds. Support channels and chat-based support are provided for platform usage. Frequent meetings can be used to foster collaboration. Make sure you are getting feedback from developers to enhance the platform.

Loss of freedom for developers and business priorities are some of the main hurdles in platform adoption. Don’t force developers into using a platform; instead, work closely with them to build something good enough that they will want to use it.

Quantitative and qualitative surveys of developers and managers can be used to measure the impact of their platforms. Companies also use adoption metrics and measure the development velocity to see if it improved, and metrics from Dora like deployment frequency and lead time to change.

For effective platform implementation, consider building one unified platform over multiple platforms for the front and back end. The component-based adoption of platform tooling can support teams in onboarding individual platform components at the best time for the team and project. Involve yourself in the developer toolchain to reduce tool duplication and establish a golden path framework.