TNS
VOXPOP
Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
0%
No: TypeScript remains the best language for structuring large enterprise applications.
0%
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
0%
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
0%
I don’t know and I don’t care.
0%
DevOps / Platform Engineering / Software Development

PlatformCon 2023: Bigger and Even Better

The conference expanded on themes like selling the business value of an internal developer platform, how to treat your platform as a product and more.
Jun 29th, 2023 8:33am by
Featued image for: PlatformCon 2023: Bigger and Even Better

PlatformCon 2023 is the platform engineering event of the summer, and for good reason. With over 22,000 platform practitioners, experts and enthusiasts from around the world tuning in for 169 community-submitted talks over two days, this conference, which was held earlier this month, was one to remember. In case you missed it, here are the highlights.

We’re Here for Community

When the platform engineering community hosted the first PlatformCon in June 2022, we didn’t expect the event to become as big as it did. We were blown away to see over 7,000 platform engineers from around the globe join the live-streamed event, and to watch over 70 talks by thought leaders and practitioners.

This year’s event was even bigger and even better. The Platform Engineering YouTube channel grew from 20 subscribers to over 12,000, the Slack community welcomed 10,000 additional platform enthusiasts, PlatformCon 2023 received nearly five times the number of talk submissions of the previous year and sponsors for the event almost doubled. We couldn’t be more excited to see the community grow and come together to learn, share and connect at this year’s PlatformCon.

Big Trend: Platform Blueprints

PlatformCon 2023 saw a big shift toward discussions about how to create and build internal developer platforms (IDPs) that add value. Nowhere is this more apparent than in the new Blueprints track, where practitioners dove into tried-and-true IDP blueprints and reference architectures.

Streamlining Platform Design with Reference Architectures

The McKinsey team unveiled two new IDP reference architectures based on learnings from hundreds of real-life platform setups that enable organizations to set up a minimum viable product of the platform in one day.

In “Platform as Code: Simplifying Developer Platform Design with Reference Architectures,” McKinsey’s Stephan Schneider and Mike Gatto explained how reducing cognitive load on developers is key to boosting innovation and velocity. Organizations can achieve this through standardization, enabling developer self-service, driving industry best practices and avoiding shadow operation antipatterns.

They then introduced their new reference architecture for IDPs on Amazon Web Services (AWS), which is designed to improve developer experience (DevEx) and the health of the organization’s tech stack. From their research, the team at McKinsey determined that IDPs consist of five architectural planes with unique functionalities. The diagram below is an example of how tools can be clustered into each plane. The combinations of tools in each plane can and should be adapted to the needs of the organization. Furthermore, switching one tool for another shouldn’t require replacing all of the tools in the same plane or the larger IDP.

However, technology is not enough to improve DevEx and productivity at scale. Gatto explained that successful platform organizations must also set a clear direction at the foundation, foster a strong engineering culture, establish governance that enables flow and creates platform pull, and create a platform that developers want to use.

McKinsey’s Marco Marulli’s talk “Streamlining Developer Platform Design with Reference Architectures” presented an IDP reference architecture for Google Cloud Platform (GCP)-based setups based on the same design principles and goals for the organization.

The team at Humanitec created more extensive guides based on McKinsey’s reference architectures for AWS, Azure and GCP setups. The white papers explain how to integrate the architectural planes, provide concrete examples of golden paths, dig into how developers, Ops, and platform engineers benefit from this design and more.

How Much Abstraction Is Too Much?

Finding the right level of abstraction for your platform is notoriously difficult. In his talk “Build Abstractions, Not Illusions,” Gregor Hohpe, author of Cloud Strategy, pulled upon two decades of building distributed systems to explain why hiding more complexity isn’t always useful to developers.

Abstractions, Hohpe explained, remove or generalize details or attributes to focus attention on details of greater importance. Platforms need abstractions because the underlying technologies are very complex. Good abstractions form a cohesive language and useful mental model that help users navigate this complexity. However, when platforms remove or generalize important details, they create misleading illusions and disappointment instead.

Building Scalable Golden Paths

When most organizations first create golden paths, they too often prioritize the simple scaffolding use case of a new service or resource. However, this only covers Day Zero of a service that will be around for hundreds of days. This pitfall was the topic of Kaspar von Grünberg’s talk “Build Golden Paths for Day 50, Not for Day 1.” Von Grünberg, Humanitec’s CEO, defined a golden path as any procedure in the software development life cycle that a user can follow with minimal cognitive load and that drives standardization. The problem with focusing on golden paths for Day 1 tasks is that it ignores the remaining 99% of tasks that occur more frequently across the life cycle of an application. The key is to build an internal developer platform that enforces standardization and security best practices with minimal to no changes to the developer’s workflow.

Von Grünberg provided an example of a golden path for deploying a workload to a Dev environment, implemented with Score and the Humanitec Platform Orchestrator. The flow of the golden path is pictured above. According to von Grünberg, scalable and sustainable golden paths drive standardization of config and infrastructure management. Within this framework, organizations approach every release as a Day Zero or opportunity to “clean up” and reduce technical debt.

Embracing the Human Side of Platform Engineering

Platform engineering isn’t just about technology. It’s also about creating a culture that enables platforms and their developers to thrive and succeed.

Diving Deeper into Platform as a Product

The platform-as-a-product approach is consistently a topic of conversation in the community. The approach involves conducting user research, creating a product roadmap, soliciting regular feedback, iterating, launching the platform and marketing it internally to the platform’s customers: the developers. The user-centric approach ensures that the platform addresses users’ needs, gains buy-in from stakeholders across the organization and is enthusiastically adopted by developers.

However, despite the buzz, many organizations still struggle to apply the platform-as-a-product approach in practice. This was the topic of one of my favorite PlatformCon 2023 talks. In “Why Is It so Hard to Create a Great Platform as a Product,” OpenCredo CEO and CTO Nicki Watt highlighted some common stumbling blocks organizations encounter when trying to embrace this approach.

For example, many organizations fail to afford the platform the same considerations as an external product. This is because when users are internal, as they are with an IDP, it’s easier to make assumptions about what users know, want and need. However, organizations should strive to treat their internal users with the same care. Another common pitfall Watt shared was organizations mandating platform adoption. Making the platform mandatory closes off the crucial feedback loops platform teams need to gauge the effectiveness of the platform and make continuous improvements.

Where Does Ops Fit into Platform Engineering?

Honeycomb co-founder and CTO Charity Majors joined the PlatformCon 2023 stage to make her case for why “The Future of Ops Is Platform Engineering.” In her talk, she pushed back against the “DevOps is Dead” headline but acknowledged that there was a kernel of truth to the rest of the story.

What struck me most was Majors’s focus on how Ops professionals can find fulfilling work in a rapidly changing job landscape. Operational expertise is more important than ever, she explained, but the titles and expectations for Ops jobs are changing because the level of abstraction engineers need has become much higher. Majors described Ops experts as approaching a fork in the road of their career. For those who love working on infrastructure, she recommended solving a category problem with infrastructure as a service or platform as a service. For those who love operating code, site reliability engineering or platform engineering can be the future.

The Impact of Platforms

Whether your organization is at the start of your platform journey or a platform engineering veteran, it’s crucial to understand the impact your platform has on the business. The Impact track made its debut this year to educate business leaders about the value IDPs add and to teach platform engineers and product owners new ways to gain buy-in from the C-suite.

In his talk “How to Communicate the Business Value of Platform Engineering,” Gartner’s Manjunath Bhat noted that most organizations struggle to explain the value of platform engineering. Yet most are familiar with the struggle to scale DevOps to enable many teams to build, own and operate their products. In this context, platform engineering provides value by delivering a self-service platform supported by a dedicated platform team that helps scale DevOps across teams. However, according to Bhat, this is only part of the story. The key to communicating the business value of platform engineering is understanding how it extends beyond DevOps. Furthermore, different stakeholders have different priorities. Platform engineers need to be aware of how to speak the language of different stakeholder groups.

To this end, Bhat shared Gartner’s Enterprise Value Equation and showed how it could be used in a platform engineering context.

Link: https://www.linkedin.com/posts/activity-7073619577938579456-qPG1/

The process would look something like this:

    1. Assess stakeholder priorities and concerns. Listen to stakeholders and learn what their priorities and concerns are. These will vary depending on the stakeholder group.
    2. Identify and define value enablers. Value enablers are the actions the platform teams take that provide value to stakeholders: developer portals, golden paths, IDPs, etc.
    3. Build a value map to map value enablers to stakeholder impact. A value story is a compelling narrative with supporting metrics that demonstrates how software engineering initiatives generate business values. Well-defined value stories are aligned to business objectives, tailored to stakeholder priorities and easy to communicate. Balance trade-offs where stakeholders have competing interests.
    4. Support the value story through outcome (not output) metrics. Output metrics optimize the flow of work, whereas outcome metrics optimize the flow of value.
    5. Communicate the “why” to incentivize mindset shifts. These mindset shifts drive platform adoption and allow the platform to make an impact on the business.
    6. Communicate the realized value to the organization. This includes improving customer satisfaction, driving revenue growth and reducing time to value.
  • Adjust and iterate.

Bhat’s approach to this topic is helpful for folks who need high-level concepts translated into a list of action items. By using this framework, platform engineers can better understand the value they’re delivering to the business beyond their developers.

Platform Stories

There’s nothing quite like hearing from trailblazing platform teams about the highs and lows of their platform engineering journeys. The Stories track was designed to showcase practitioners and their processes from initial steps to building and rolling out the platform across the entire organization.

Lessons Learned Building a Platform for 5,000 Developers

In “Adobe’s Journey into Building an Internal Developer Platform,” product manager Rohan Kapoor shared how Adobe’s platform team built an IDP for over 5,000 developers. He explained how Ethos, Adobe’s cloud platform, was crucial to providing resiliency, reliability and robust CI/CD capabilities to product teams. From this foundation, Kapoor’s team hopes to expand into a companywide IDP to streamline security, infrastructure provisioning, monitoring, diagnostics and so on.

Kapoor also shared key learnings from their platform journey so far, including:

  • Treat internal developers like customers. This principle was a common theme, but it’s always worth repeating. Kapoor expounded on the need to focus on developer productivity in training, prepare for the platform’s go-to market and maintain constant communication with users.
  • Establish a baseline for success early. Set realistic goals for the platform team and follow through on them. This can be done through objectives and key results, performance on metrics, features, tech docs or surveys.
  • Recalibration may be needed to make an impact. Just as flexibility and adaptability are important for an IDP, they’re also important for the platform team developing it. Kapoor explained why strategic trade-offs can be necessary and how teams can embrace change.
  • Without adoption, there is no platform. Proving the value of an IDP is an ongoing process. Platform teams should continue to prioritize features that encourage adoption.

Legal Perspectives on Open Source Use

In “A Lawyer and an Engineer Walk into a Bar and Talk Open Source,” Ravi Devineni and Shantanu Singh, senior director of engineering and assistant general counsel, respectively, at Northwestern Mutual Life Insurance, dug into the benefits and drawbacks associated with using open source at their organization. They also discussed the lessons they learned from the process.

Benefits Drawbacks
Legal Perspective
First principle. Open source technology is born out of the spirit of community development and matures through a culture of collaboration. Rights are either there or not, and they usually can’t be bought. Furthermore, an open source project’s focus on what rights are needed primarily drives what’s in the bundle, not commercial incentives.
Client experience over the financial product. Consumer demand for a compelling digital experience can be met with open source technology.
Licensing rights are property rights. Open source stands out because it starts from a principle of inclusion rather than exclusion.
Engineering Perspective
Faster time to market Security threats
Cost effectiveness Trustworthiness
Transparency Complexity of dependencies, updates and patching
Power of the community Support
Recruitment and building a talent pipeline Is it really free?

According to Devineni and Singh, the solution to navigating these trade-offs is to create a line of sight into what open source is being used and where. This enables organizations to understand the impact radius for open source vulnerabilities if and when they arise. Then organizations can obtain a software bill of materials. They can also embed security scanning of software dependencies into the CI/CD pipeline or create a block list to minimize risk. The key is to understand the open source product being used and the license, together. With this understanding, platform teams can better understand the risk a given business capability poses to the organization.

They also shared some tips for lawyers. Devineni and Singh recommended moving away from written legal analysis and toward translating legal requirements into product features. For example, lawyers can consider their company’s risk tolerance for open source use and translate associated risks as detection variables to flag with scanning tools, whether for license risk or vulnerability detection.

The key takeaways from their experience are that enterprise policy for open source is a must, organizations should create a strong open source governance program and strive to automate mundane tasks, and law should be part of DevOps. This talk is a must-see for platform engineers in highly regulated industries such as financial services, insurance and health care.

What Comes Next?

PlatformCon 2023 connected a global community to some of the most game-changing platform engineering leaders and insights. The conference expanded on familiar conversations like how to sell the business value of an IDP and how to successfully treat your platform as a product. It also debuted some much-needed IDP reference architectures. The numbers speak for themselves: Platform engineering is the future.

If you missed this year’s festivities, don’t sweat it. All PlatformCon 2023 talks are available on the Platform Engineering YouTube channel. Use this highlight reel as your guide, dive into one of our curated tracks or forge your own path. Wherever you go, we’re happy to have you as part of the community.

Group Created with Sketch.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.