For the sake of developer productivity, don’t start your platform journey with IDPs or genAI
Aug 1, 2024
As a platform engineer, it’s often not clear where you should start your platform journey.
And the stakes are high. Choosing the wrong first initiative to focus too much on an all-encompassing solution risks your project grinding to a halt, your platform team not becoming a lauded engine of growth for your organization, or in the worst-case scenario, you find yourself on the CFO’s future rounds of budget cuts chopping block. So choosing a platform initiative that demonstrates very clear ROI, in a short timeframe, is critical.
From speaking to many platform engineers, we commonly hear about generative AI and internal developer portals at the top of the ‘platform initiatives’ lists. While both can have high impact, they’re far more complex than they appear. In this article, we’ll talk about why that is, what you should do to avoid these pitfalls, and how to maximize your ability to improve developer productivity as a platform engineer.
Internal developer portals
IDPs connect all tools, documentation, and team information in one central catalog. They are especially helpful for large teams with complex infrastructure but can be equally beneficial for smaller teams who are looking for a unified interface where developers can access resources.
According to Gartner, they were cited as the most frequently piloted technology between 2022-2024. Gartner also cited that ‘IDPs demand ongoing investment and should not be considered a one-and-done activity’. IDPs must continually evolve to cope with changing development, software architecture, infrastructure, and operational needs’. This is in line with the experiences we’ve heard from the many platform engineers we’ve spoken to and why adoption rates are stuck at 10%.
What developers portals do well
Portals are most helpful when it comes to visibility. Here are a few of their common use cases:
Centralized visibility: Portals are a central catalog that includes assigning ownership, surfacing quality and security metrics, facilitating template provisioning, documentation, and self-serve actions.
Managing service ownership: They keep track of service owners, making it easier to map your architecture and find the right person for help with mitigating incidents and creating new functionality.
Where do IDPs fall short?
Adoption challenges: Portals are a broad tool that solves many different sub-problems. As with any platform initiative, without a strong enough pain to address or organizational priority, adoption often stalls. Additionally, introducing new interfaces like a UI portal to developers can take significant time to enact behavioral change.
Limited scope: Portals commonly focus on the discovery of resources, which usually appeals more to leadership than developers. This focus is also more relevant to the scaffolding and launching of new services, at the start of the development lifecycle, leaving day 2 concerns like updates, patching, and maintenance to still be considered.
Only a user interface: Backstage critically describes itself as a ‘framework for building developer portals on’. Backstage is not an out-of-the-box solution. It even mentions they are ‘not the source of truth’ for your platform. All your backend infrastructure must be created, in addition to the React and TypeScript components created for the UI. Skills that are uncommon in early platform teams.
Finally, because of their adoption challenges and limited scope, portals are not sufficient in improving developer productivity when deployed on their own. They require too much ongoing maintenance and don’t touch enough of developers’ inner loops to be effective.
Generative AI
We can all agree that genAI is revolutionizing how developers write, document, and test code. By leveraging LLMs, these tools generate code snippets, suggest improvements, and even identify potential bugs. GenAI shines when it comes to automating repetitive tasks and providing intelligent insights during development. However, rolling out code assistants in a large organization poses operational and security risks.
Where does genAI fall short?
Accuracy and reliability: Many off-the-shelf coding assistants are trained on publicly available code, making them respond with ‘student answers’ to ‘leetcode’ problems that are normally incorrect for professional contexts.
Governance applications: With the explosion of coding assistants available, organizations often end up with ‘shadow co-pilots’ running wild with their developers. These are genAI instances that are not approved by your organization, and don’t follow your security or compliance policies.
Security vulnerabilities: Code assistants read and train their models on your private source code. To prevent this, you’ll want to self-host your own models.
Measuring return on investment: Understanding if genAI is worth the resources is challenging. Organizations are asking unanswered questions about ‘who is getting value?’, ‘how much value?’, ‘how much faster are we going?’.
Limited scope: Similar to portals, genAI only supports a short part of the development lifecycle. While it can improve productivity related to writing boilerplate code, it relies on developers to be able to set up their environment and integrate these tools appropriately.
*And don’t forget, this means you’ll likely require hosting your own GPU infrastructure!
Your secure distribution method for IDPs,
genAI and more
Cloud development environments are standardized and automated development environments pre-configured with all tools, dependencies, and packages required to write code. For developers, CDEs provide the freedom to use all of their favorite tooling without the overhead of setting up a development environment. For platform teams, CDEs provide a centralized place to standardize and automate everything related to the setup, maintenance, access provisioning, and troubleshooting of development environments.
In the context of portals and genAI, CDEs are your best alternative for an immediate ROI solution.
Don’t take it from me, hear it from other platform engineers. In recently reading ‘so you want to hire for developer tooling’, by the Infrastructure Witch of Hachyderm (Hazel Weakly), she talks about the common misconceptions companies have when kicking off internal enablement teams like platform engineering or developer experience:
“The below list of projects is something that is pretty much guaranteed to be positive ROI, I haven’t gone wrong from picking something off of this list and rolling with it if I didn’t have a more compelling first option: fully automated developer onboarding and local developer environments.”
Hazel highlights the commonly overlooked area for platform engineers: the place developers spend most of their time, their environments.
This is exactly what CDEs address. They automate and secure development environments, all while acting as a distribution platform for platform tooling and standards. Instead of developers adopting ‘shadow IT’ coding assistants, sending source code and IP outside of your company, platform teams can configure exactly which tools developers can use and automate any authentication and configurations, removing reliance on developers to install anything. Now every tool a developer uses is not only approved by your business for security and compliance, it’s delivered to developers directly without them doing anything.
Ultimately, CDEs enable platform teams to shift their influence to the inner loop of the software development life cycle. This allows them to unblock core developers’ productivity issues, and show immediate impact.
Download this whitepaper to learn more about the ROI of standardized and automated development environments specific to platform teams.
Last updated
Aug 1, 2024