What is an Internal Developer Platform and Building One Successfully

What is an Internal Developer Platform and Building One Successfully

What is an Internal Developer Platform and Building One Successfully

with Jesse Adametz, Director of Engineering, Infrastructure from Twilio Segment

with Jesse Adametz, Director of Engineering, Infrastructure from Twilio Segment

with Jesse Adametz, Director of Engineering, Infrastructure from Twilio Segment

author image

Yena Oh

Yena Oh

GTM

GTM

Oct 14, 2024

Oct 14, 2024

5 min

5 min

With over 20 years of experience in platform, reliability, and infrastructure, Jesse Adametz is a seasoned expert in navigating the ever-evolving developer landscape. As one of Tempest’s key advisors, Jesse brings deep expertise in building and scaling effective engineering teams and offers invaluable insights into driving performance and efficiency across organizations.

We sat back down with Jesse to learn about how he thinks organizations should approach building a platform. He stresses the importance of starting with basics like automated builds and testing, but emphasizes that timing depends on challenges like configuration drift or onboarding. Success, he said, hinges on readiness for standardization and executive support.

Thanks for joining us again! Obviously, you have a ton of experience building both platforms and portals at your various professional experiences. Could you share your perspective on the difference between an Internal Developer Portal and an Internal Developer Platform? If you have one, do you have the other?

Great question, because I see people using these words interchangeably and I believe there’s a distinction that changes what gets built.

Internal Developer Portals are the central interface that provides developers with access to a wide range of resources, tools, documentation, etc. It’s primarily user-facing and focused on improving the developer experience by making it easy to discover and interact with available internal resources.

Internal Developer Platforms provide the infrastructure and tools necessary for developers to build, deploy, and run applications. It’s more focused on the technical backend and operational aspects of development, such as CI/CD pipelines, automation, cloud environments, and infrastructure provisioning. The platform is more about building and running applications.

Despite calling out their key differences, there’s plenty of complementary overlap. In practice, I think having both yields the best results. The portal serving as the gateway to the platform, making it easier for developers to access the capabilities of the platform without needing deep infrastructure knowledge. For example, a developer might use the portal to request a new environment or service, which the platform automatically provisions and manages in the background.

At what point should an organization start considering building a platform? Is this need driven more by company size, business strategy, or other factors?

When I think about what platforms do for engineers, the first thing that comes to mind is efficiency and developer velocity. All businesses need that, and these days, it’s never too early. But teams do need to first understand what problems they truly have so they build the right Platform.

That said, I think there are some day 1 must-haves:

  • Automated builds, somewhere other than the developers laptop

  • Automated testing and a practice of Continuous Integration

  • An automated deploy process

From there, like with any good product, it’s about understanding the needs of the org:

  • Are teams continuously re-inventing Infrastructure provisioning?

  • Is there a rising number of incidents due to configuration drift or inconsistent tooling?

  • Are new hires finding it difficult to onboard and get up to speed because of diverse tools or environment setup?

While these pain points typically crop up for organizations around 50-100 engineers, as the number of services outpace headcount, or with increasing coordination overhead between multiple teams; hopefully you can also see that challenges are truly unique to each business. The need for a platform approach could be before or after any one of these individual signals.

Regardless, any company looking to start this journey should verify two things to be true:

  1. Readiness for Standardization: A developer platform requires a culture shift toward shared standards and practices. If the organization’s culture embraces cross-team collaboration and standardization, it’s a good time to start considering a platform.

  2. Executive Sponsorship: Building a platform is a long-term investment that requires buy-in from leadership. If there is alignment at the executive level about the importance of investing in developer experience and operational excellence, it’s more likely that the platform will succeed.

How do you see enterprises balancing the adoption of open-source software with the need for stability and long-term support in their developer platforms?

In my experience, I like to buy over build as much as possible. So I'm a big fan and supporter of OSS. When deploying that within enterprises, there are a few strategies you can mix and choose from.

  • Many opt for commercially supported OSS (e.g. Grafana Labs), which gives them the flexibility of open-source with the peace of mind that comes from having vendor support.

  • Building a familiarity and some level of expertise is also a good practice, alleviating a complete reliance on any one vendor and knowing how to troubleshoot critical pieces you introduce into your environment.

  • Putting internal rules/governance in place, like keeping an approved list of open-source software to make sure the tools in use are secure and compliant. You’ll often see companies using Software Composition Analysis (SCA) to track OSS dependencies, monitor vulnerabilities, and ensure things like libraries remain updated.

For many companies, they decide on the platform approach to facilitate this, building a hybrid model with OSS and proprietary software. For example:

  • Core Infrastructure with OSS, differentiation with proprietary tools: Many enterprises will use OSS for core infrastructure elements like databases, message brokers, and orchestration (e.g., PostgreSQL, Kafka, Kubernetes). They then build proprietary layers on top of these components to create unique capabilities, custom integrations, or enhanced user experiences. This allows them to control critical aspects while benefiting from the ecosystem.

  • Using Cloud-Native Services that Integrate with OSS: Building on the last point, many cloud providers offer managed versions of popular OSS (e.g. Amazon RDS for PostgreSQL, Google Kubernetes Engine). This approach allows enterprises to benefit from the open-source ecosystem while offloading some of the operational overhead to the cloud provider.

  • Selective contribution back to OSS: When adopting OSS, some enterprises contribute back to projects they rely on, especially if those projects are critical to their infrastructure. This helps ensure that the features or fixes they need are incorporated into the mainline codebase, improving the stability and sustainability of those tools.

One challenge we've heard from organizations of all sizes and industries is how difficult it is to get platform adoption from developers. What do you think gets in the way of developers adopting new platforms?

For platform adoption to be successful, there has to be sizable return on investment for engineers. They have to want to use it. If it comes through mandate alone, the organization is likely falling victim to at least one of the following struggles:

  • Lack of alignment with developer needs: If the platform doesn’t address the actual pain points or workflows of the developers, they may see it as more of a burden than a benefit. Developers are more likely to adopt tools that streamline their work rather than add complexity.

  • Limited or lacking enablement: Without clear documentation, guides, and examples, developers likely struggle to understand how to use the new platform effectively. A lack of training or onboarding resources can also create a knowledge gap, making it harder for developers to get started.

  • Missing communication strategy: Platform teams often don't have product managers to help with outbound communication. This results in potential mismatches between what’s delivered and what’s needed, or releases that go unused. Teams then risk a loss of trust, where ultimately, if developers don’t feel heard during the platform’s development, they’re less likely to buy in.

Do you think developer enablement efforts, like developer platforms, replace jobs? What about buying a platform rather than building from the ground up?

Absolutely not. In the last article we talked a bit about DevOps, and the increased burden it has put on every software engineer. There are simply more expectations than ever to keep software reliable, secure, compliant, innovative, etc.

Developer enablement and platforms aid in that, controlling the chaos. All of that work would exist with or without platforms. But with platforms, teams are able to more predictably innovate and ultimately drive better results for the business, in turn, hopefully creating more jobs!

Buying a platform is a great solution, because like it or not (I’ve seen this first-hand), most modern SaaS companies today have almost identical infrastructure/platform roadmaps. Hosted solutions are a shortcut — skipping years of building the undifferentiated stuff — leaving teams to build the business specific value.

Many organizations spend years building and delivering a platform. When do you think this journey considered "done," and how can they determine if they've been successful?

Lately I’ve been thinking a lot about the (potential) correlation between platform complexity and the complexity of the businesses they support. For example, I think if you’re building a food recipe app for the App Store, your problems are significantly different compared to say, processing a trillion events per month that power near real-time communication.

Now, while that may seem obvious, I think it shows a pretty clear difference in complexity that often gets glossed over. While we (as an industry) love to look to the top companies for inspiration, people should realize that they often have very, very different problems compared to Netflix, Google, or Microsoft.

So, rather than setting the platform finish line identical to Netflix, leaders should get crystal clear on the problems their platform needs to solve. They’ll never be done. But they’ll be wildly successful in providing value to the organization throughout their journey and platform evolution.

Ready to kick off your developer platform? Sign up to see a demo of Tempest and see how our platform can transform your engineering workflows today.

Build a world-class developer platform.

Build a world-class developer platform.

Book a demo and get free beta access to Tempest.

Book a demo and get free beta access to Tempest.

Book a Demo