What support do developers need at large enterprises to be productive? We often fall into the trap of evaluating coders on output, maybe even innate talent. We think that the best way to build secure and efficient software is to hire 10X developers, and get out of their way. But even if the individuals have massive intellectual firepower, operational work grows like entropy in the system. Developer tools include everything from code editors and IDEs to version control and testing tools, and this massive range of productivity tools functions as an additional productivity problem at a higher level of abstraction.
As more engineering leaders come to view developer productivity as a managerial goal rather than an emergent property, solutions designed to centralize tooling and reduce cognitive load have become increasingly popular. Among them, Internal Developer Platforms, and Internal Developer Portals. However, the lines between these categories are starting to blur, creating more confusion in engineering teams about where to start. While we’d love a clear answer on how each are defined—the truth is that roadmaps for each now criss-cross against “standard” definitions. So let’s take a look at the current state of the world, while we prepare for continued convergence in the coming years.
What’s driving interest in IDPs (either one)
Consider the current software development environment. In the cloud-native era, with the widespread adoption of microservices and Kubernetes, a proliferation of tools and technologies has removed the delineation between developers and operational tasks. Work that Google defines as toil creeps into developers’ daily routines, like barnacles on a speedboat. Devs are balancing multiple tools that lack context on one another, while fighting an endless stream of requests to address issues or improve state as standards evolve or fade away. Companies unwittingly create a high cognitive burden even for a team of high performers, reducing them from 10X performers to single-track administrators.
If this risk emerges with even the most talented and independent developers, you can be sure it applies to the average software development team that is scaling rapidly and hitting triple digits on headcount. Operational data like owners, versions, and language can be housed in a spreadsheet for early-stage startups, but past your 100th component (service, resource, API, etc) Excel documents become stale, and the shared language of software development evaporates. Platforms and Portals replace individual inspiration with process, providing micro solutions to sharing best practice and targets, with the potential to integrate productivity tools across the stack and rationalize the development environment.
Instructing developers means providing back-end support on tools and data, CI/CD pipelines and development standards. Facebook may have had the luxury of moving fast and breaking things before emphasizing building stable infrastructure, but guaranteed consistency and high standards across the codebase are now top priorities for software development. Let’s explore how these operate in practice.
Platforms and Portals
Once it becomes clear that a developer team needs to add structure to operations, the next consideration is what the main pain points are. Are you looking to enable golden paths in development, establishing uniformity in production for certain types of software that encourage best practice? Or are you looking to accelerate infrastructure provisioning, automate CI/CD pipelines, and orchestrate systems across your stack? …Maybe all of the above? Developer Platforms and Portals have been a popular choice to aid in both, and are still distinct enough that it’s worthwhile covering what each offers today, so you can make a decision about where to begin.
Internal Developer Platforms
Internal Developer Platforms primarily focus on orchestration and monitoring of infrastructure. Integration with clusters, image registries, CI pipelines and any other resources that make up the software development stack are all within the remit of Developer Platforms.
At a minimum, Developer Platforms must include:
Visibility: Platforms must provide insight into underlying infrastructure and dependencies.
Self-Service: Platforms must enable users to automate infrastructure provisioning according to agreed-upon best practice.
Extensibility: Platforms must be tooling and system agnostic, with loose coupling to ever-changing infrastructure.
These features abstracts work away from the “build” cycle, while ensuring developers have access to the underlying technology. In this way, Platforms reduce cognitive load and developer toil, while remaining agnostic on tools and approach.
However, these abstractions don’t extend to data dependencies and relationships, meaning developers retain greater manual responsibility for things like operational maturity, always up-to-date alignment to best practice, and versioning.
Ultimately, Platforms alleviate the burden of operating distributed systems in a complex development environment, but the knowledge involved in directing and continuously improving processes remains fragmented.
Internal Developer Portals
The “old” (read: 2022) definition of Platforms and Portals depicted the former as a place to build, and the latter as a layer of abstraction for developer interaction. But Portals like Cortex have begun chipping away at this world-view—with enhancements like task prioritization, software templating, and infrastructure provisioning that bring the Portal closer to the center of Developer operations.
The new standard feature-set for Internal Developer Portals now includes:
System of Record: At minimum, Developer Portals must serve as a system of record for all of engineering. While ITSMs, monitoring tools, and engineering intelligence platforms provide rich insight on service, resource, product, and team metrics, the IDP marries that data with contextual information about how these things are built, by whom, and to what standards of excellence. To achieve this, the IDP needs to have:
More-than-Services Catalog: IDPs must have the ability to catalog services, resources, domains (product or org groupings), and teams in a way that makes ownership, components, language, changes over time, and documentation obvious.
Ecosystem-Spanning Integrations: Catalogs should be fueled by integrations that span your entire developer ecosystem, so that existing data dependencies and relationships can be preserved without needing to rebuild your data model from scratch.
Custom Data: Data from internal systems, home-grown tools, or third-party applications can’t be overlooked when building a central system of record. Portal users must be able to incorporate, and drive action using this data.
Active Improvement: The ability to assess the quality, consistency, or adherence to standards for all contents of your catalogs is now table-stakes for Internal Developer Portals. But the ability to actually drive meaningful action towards improvement, with initiatives, alerts, and custom actions are now in high demand for IDP customers.
Scorecards: Create custom rubrics for any short or long-term use case using data from across your ecosystem. Scorecards can include rules related to maximum allowable vulnerabilities, integration with other security solutions, and minimum code coverage—or can be as simple as requiring Helm charts to be attached to each service as part of a one-time migration to Kubernetes.
Initiatives: Initiatives add a temporal element to your projects, making them increasingly popular with organizations that want to track meaningful progress towards short term initiatives.
Self-Service: Features related to not just improving visibility but actively driving alignment, reducing developer cognitive load, and reducing opportunity for error are increasingly coming into the purview of Developer Portals.
Scaffolding: IDPs now must have the ability to scaffold new services and resources according to defined best practices
Actions & Workflows: IDPs should also enable resource provisioning. Cortex Workflows enable users to send payloads and chain together multiple actions out of the platform for execution elsewhere.
Extensibility: As engineering teams work to blend new tooling into already crowded developer workflows, customization of the data model, UI, and workflows have become a non-negotiable for teams seeking to centralize tooling and activities.
Plugins: Popularized by open source Developer Platforms and since adopted by Developer Portals like Cortex, plugins enable users to inject data from anywhere into their daily workflows.
Customization: As engineering teams work to blend new tooling into already crowded developer workflows, customization of the data model, UI, and workflows have become a non-negotiable for Developer Portals seeking to centralize tooling and activities.
In short, Developer Portals focus on abstraction in day-to-day tasks for developers, increasing the autonomy while simultaneously improving performance through scoring and standardization. This allows high performing developers to focus on adding value doing what they do best, while also helping to set and enforce best practice across the team.
Knowing where to start
While many organizations choose to pair Internal Developer Portals and Platforms, the need to keep these technologies tightly coupled has waned in recent years. Portals now offer a significant share of the benefits of Platforms including infrastructure tracking and paved paths to production, with the added benefit of enabling users to actively improve systems, alleviate prioritization, and improve developer experience. Importantly, Portals also solve for a unified system of record—on which even Platforms must rely for optimum use.
If you'd like to learn more about how Cortex can help you build your Internal Developer Portal program, contact us today.
