3 Ways an Internal Developer Portal Boosts Developer Productivity
Consolidating all your company’s resources and knowledge in a single place can eliminate stress and improve velocity.
Developer productivity measures a team’s ability to quickly and efficiently write and operate high-quality software that performs well and is easy to maintain. So, it’s not a stretch to say that anything that improves developer productivity isn’t a nice-to-have, it’s a requirement, an ongoing task you have to focus on in order to succeed.
Many products, such as integrated development environments (IDEs), frameworks, testing tools and development methodologies claim to improve or contribute to developer productivity. But few things can add to the developer’s bottom line as quickly and effectively as a well-built internal developer portal (IDP). These tools improve your ability to deliver high-quality code faster and with fewer resources by consolidating your company’s resources and knowledge into a single place. So, your engineers can find what they’re looking for when they need it.
Let’s examine the ways that access to an IDP contributes to developer productivity. We’ll start by looking at how a lack of a developer portal hurts productivity, then we’ll see how a portal addresses these problems.
Supporting a large-scale system without access to an IDP is difficult. Developers spend too much time chasing information, stressing out over a part of the job that should be easy.
When your developers and support staff can’t get a comprehensive view of the services they’re responsible for, they’ll try to build one. They’ll cram a set of tools together on a single screen in an effort to build the proverbial “single pane of glass” that gives them the view they need. They keep a browser open with dozens of tabs logged into myriad tools and cloud accounts to try and organize the information they need at their fingertips.
The number of different tools this requires a developer to be an expert in, plus all of the different rabbit holes they have to go down along the way, make debugging or even simple monitoring needlessly difficult. And this is “state of the art” compared to teams that rely on stale spreadsheets and static wikis!
It’s 3 a.m. and one of your engineers woke up to a call to fix a broken service. But, they can’t find any documentation, don’t know if there’s a runbook nor who owns it, and aren’t sure where to find key metrics inside various tools. They can’t even monitor the service, let alone fix it.
It’s 4:45 p.m. on a Friday in August. Your on-call engineer has a change ticket to release code for a service they’re not familiar with. They ran the deploy, and a related service failed. They can’t find any documentation, up-to-date dependency information, key information about those downstream services, and the ticket requester is gone for the weekend. It’s time to risk a rollback and hope that it addresses the issue.
An IDP alleviates one of the biggest pain points that’s emerged from distributed cloud architecture patterns. Documentation for systems based on microservices and serverless functions tends to fragment when your services are built by different teams that are often dispersed across different offices and time zones. Information also tends to get isolated across cloud accounts.
One of the key advantages of microservices and functions is they make it possible for individual teams to focus on solving their specific problems. But this can be a problem too, since it often leaves your support staff without a “knowledge map” of the entire organization.
Now, let’s look at each one of these problems in more detail. How does an IDP help developers and engineers address these situations?
What your staff needs is a universal catalog of services that makes it easy to see the services and resources they care about and stays in sync with what’s really out there.
When they have this, your staff’s lives don’t just get easier. Their entire way of working changes. Instead of keeping browser tabs open, they simply open their IDP. The portal gives them the answers they need to all kinds of important questions, such as:
A complete IDP has detailed information about each service in your organization. So, your teams can quickly learn:
Your IDP not only contains this information, but has tools for creating and tracking incidents without leaving the portal.
As we’ve already covered, the IDP has source control, release and dependency information for all your services. So any developer or engineer can get the data they need to manage a deployment or arrange for a rollback. They can annotate and log information from services by collecting data from version control, build systems and more, so they’re never deploying in the dark.
Developer productivity is one of the most important strategic and tactical elements that you, as a high-functioning technology organization, can focus on. Especially when you’re keeping an eye on costs. If your developers can’t get to the knowledge they need, no amount of additional headcount or flashy tools will help them deliver high-quality software better or faster.
configure8.io is architected around a universal catalog. It organizes your entire software development operation — all your applications, services, environments, and infrastructure, and key data about them — in a single place. It’s all there, and it’s up to date.
With its comprehensive data set, configure8 users can quickly locate an item — it enables deep links into the right place in the right cloud account or tool when a user needs to drill into detail. Robust analytics can answer powerful questions, and you can use it to organize initiatives that help your team improve.
An IDP will alleviate stress, increase deployment confidence and collapse those dozens of browser tabs into one. And that’s really just the beginning! We encourage you to pilot a solution today and see how an internal developer portal will boost your developer productivity.
Post by Eric Goebelbecker, who has worked in the financial markets in New York City for 25 years developing infrastructure for market data and financial information exchange (FIX) protocol networks. He loves to talk about what makes teams effective (or not so effective).