The internal developer portal can help serve the needs of numerous user personas, and can even be configured to meet the requirements for multiple persona use cases.
Portal for Personas
The clue is in the name - an internal developer portal is for developers, right?
That’s true, but developer portals aren’t only for developers. In fact, portals can benefit a number of other personas including product owners, managers, SRE teams, DevOps, and more.
Actually, if you take a product mindset when defining what to include in the portal, you can serve each one of the personas described above. This means engaging with all of the personas and determining the best way to provide them what they need in a portal and platform. The portal can then help to deliver solutions for these pain points by abstracting away complexity and providing meaningful visualizations for each persona.
This would truly make the portal the central point of reference for anything platform engineering in your organization, maximizing your investment into the approach. In turn, you would reduce cognitive load as well as simplifying and standardizing the SDLC for everyone, from code to production, regardless of their role in the organization.
Using Portal capabilities to create user-centric views and actions
Incorporating a persona-based approach in a developer portal involves tailoring the experience to meet the specific needs of different user types or 'personas'.
Port offers three building blocks aiming to create a personalized experience. The trick is to think about each persona and their needs, using the portal-as-product approach.
Personalization in Port is about taking the enormous amount of data coming from the engineering organization and making it usable and accessible to different users, with the ambition of providing a smooth, product-like experience that anticipates their needs and doesn’t burden them with the information they don’t need.
Personalized dashboards and homepages
By allowing each user type to have dashboards that reflect their specific needs and priorities, the portal provides meaningful insights and quick access to necessary information. These dashboards can be configured to show relevant metrics, scorecard statuses, open initiatives, or operational alerts, depending on the role and interests of the persona.
Personalized self-service actions
Port allows you to create the right self-service actions for each persona, controlling form elements, manual approvals,the data shown to the user and more. This means that you can define different golden paths, inputs, levels of abstractions and more for different self-service actions for different users.
Folders
Rather than having to trawl through large numbers of pages within the software catalog, Port enables admins to curate portal pages into folders for specific use cases or teams. This means that the information aligns with the specific workflows of each persona. As a result, each persona has their own customized space within the portal with their specific dashboard pages, catalogs, etc.
You can arrange folders by teams, use cases (e.g. cost management), roles and more.
Role-Based Access Control (RBAC)
Port supports no-code RBAC that lets you define access permissions based on user roles, and ensures that each persona sees only the information relevant to their responsibilities.
A DevOps engineer will want to see ample K8s data, for instance, while a developer will need that data to be abstracted for them, to avoid cognitive load. Indeed, as Viktor Farcic mentions in “mistakes when building internal developer platforms” one of the primary roles of platform engineering is not to consolidate all the data and toss it at developers, but rather to carefully consider how to abstract the data, making it both accessible and meaningful, within the role of the specific user.
Taking the portal-as-product approach to determine what personas need
One of our favorite answers for ‘how to customize the portal for personas?’ can be established using a portal-as-product approach, taking the “jobs to be done” framework as in:
“As [role] I would like to [do something]”.
So, for instance, an engineering director may want to see a scorecard status of all services and all teams, while an engineering manager would want to see scorecards of each service, and a backend engineer will want to see scorecards for their services.
It’s important to keep the different jobs each role is trying to fulfill in mind when defining the structure of the portal.
But what does that actually mean for all of the different personas? What are the use cases for them to get the most out of an Internal Developer Portal? Here are some examples we’ve seen from Port customers:
*Note that some of the use cases may apply to multiple personas, and the Portal can be configured to meet the requirements for multiple persona use cases*
Managers
Cost Management
Cost tracking is a notoriously difficult problem since while companies do track cost data, it is almost impossible to show that data within the context required by both managers and developers - for a specific service, in a specific environment or context.
Using Port, managers can:
- Integrate with FinOps tools or use cost data to get a view of the organization’s cloud computing infrastructure and costs as they relate to services, environments and more.
- Get a real time snapshot of all the costs within the engineering environment and attribute the cost to the right microservice and developer based on the definitions you’ve set in your data model.
- Create scorecards so that they can track costs in context: by developer, team, service and environment. They can set budgets for teams and services, get alerts for cost overruns and get a grasp of the costs and headcount associated with service migrations between teams. That same information can also be presented to developers - setting goals for cost reduction and making them aware of the cost implications of their actions.
Improve Production Readiness, Code Quality
Engineering organizations are always looking for ways they can establish clear standards of quality and maturity to drive alignment across teams. This is exactly what scorecards - benchmarks for each element in the software catalog - are made for.
Using Port, managers can:
- Use scorecards to define and measure metrics for quality, production readiness, and developer productivity.
- Compile scorecard data that is persona or use-case specific into dashboards that show what’s going on and allow for drill down when needed.
- Use scorecards to support initiatives and campaigns - set by managers - to improve production readiness or quality testing practices. This enables managers to clearly communicate standards, drive compliance, trigger actions when a scorecard is degraded such as freezing a deployment and track DORA metrics, ownership and documentation.
Drive Security & Compliance
The portal consolidates and showcases vulnerabilities and misconfigurations across various tools and stages in the development life cycle, all in one place, becoming a centralized hub for security information.
Using Port, managers can:
- Gain a holistic view of potential risks, enabling them to understand the security state of a resource or microservice within a certain context and then be able to address vulnerabilities and misconfigurations proactively, using developer self-service actions.
SRE teams
Single Source Of Truth
While SRE teams have a different toolkit to developers and DevOps, they too can have issues with tool sprawl and getting the desired information that they need.
SREs need numerous tools in their armory - from APMs, incident management and observability tools.
Using Port, SREs can:
- integrate the portal with these core SRE tools, making it easier for SREs to find the information they need with the additional context necessary to investigate incidents.
Keeping Track of Standards
SREs rely on metrics that reflect an application’s performance or system health.
Using Port, SREs can:
- Use scorecards to gain access to metrics such as mean time to resolution, which can support their efforts in ensuring that services are meeting standards.
- Aggregate information from multiple tools in one scorecard.
- Define actions and establish standards for developers.
- Manage timelines for company initiatives such as migrations, from the portal.
DevSecOps
AppSec Posture Management
Managing security vulnerabilities is a continuous task; it shouldn’t be left to DevSecOps to manually check for vulnerabilities in the various stages of the software lifecycle.
Using Port, DevSecOps can:
- Use the software catalog and visualization capabilities to locate and visualize what CVEs are in production and where as they integrate data from multiple sources. This means they can retrieve answers in seconds for questions such as ‘is Log4J in production and where?’ and ‘who is the owner of this specific CVE?’.
- Visualize IaC misconfigurations in production. Having all of this information easily viewable means AppSec developers can better prioritize which CVEs and misconfigurations they need to attend to.
Developers
Perform Actions Without Assistance or Tickets
Developers are often left having to fill out tickets to get the information or access that they need. This slows down the entire development process.
By using Port, developers can:
- Automate dev to production workflows as Self Service:
Scaffold a new service with all of its CI and tests in a single request, deploy a resource or spin up a developer environment. Gain autonomy and be more productive. - Gain temporary permissions to databases, repos, Kubernetes namespaces, environments, cloud
- Use IaC without needing the in-depth domain knowledge
Deploy resources to the cloud with a developer self-service interface with IaC under the hood, so you don’t need the in-depth domain knowledge usually required to interact with IaC. Instead, you just fill in a self-service form to inject the right data to IaC. Port abstracts all the rest and then injects the relevant inputs into the IaC file and git commits. Devs can then create resources as a self-service, deploy a new wordpress site to the cloud in a single request and spin up resources. - Maintain enhanced security, as self- service actions are defined using the RBAC mechanism. This also streamlines the user experience, preventing information overload and creating golden paths.
Manage Alerts and Incidents
It’s common for developers to receive an increasing number of alerts from dozens of tools. It’s therefore difficult to understand the level of risk if something were to fail, so that certain alerts are prioritized and can be reacted to swiftly.
Using a portal, engineers can describe the entities they want in the software catalog, and can include alerts as part of it.
Using Port, developers can:
- Get a single pane of glass for all things alerts, in-context within the relevant software catalog entity and with all the relevant information required, such as the service, logs, or resource owner.
- Get the information they need to investigate and understand which alerts to prioritize.
- Easily track the status, health and KPIs of their services using dashboards which present alerts from a number of applications and systems so they don’t have to move between different systems.
- Be selected as on-call rather than being alerted through a broader alert channel. They can then use self-service actions - actions that don’t rely on tickets or assistance - to act on the alert and remediate issues.
- Benefit from pre-defined on-call developer self-service responses, so they can act against production environments quickly.
See Services in K8s Context
The rise of cloud native and kubernetes created an increase in the complexity that developers need to be aware of in their ordinary flow of work. This presents more tasks and cognitive load, affecting productivity, and also making it difficult for developers to understand where their apps are running, what is deployed where and whether any changes are required for services to run as they should. (The same could be said for DevOps engineers).
Using Port, developers can:
- Gain visibility and understanding of what is actually going on in K8s. See who owns a service, where it’s deployed and also understand quality and standards with regards to K8s.
- Use self-service actions so they can work independently and stop using email or slack messages to request DevOps support.
- Find the Kubernetes resources they need and better understand where services run, explore issues and troubleshoot, view K8S usage and details such as the cloud or domain they’re in, and get K8S metrics.
Manage Your Internal APIs
With the rise of microservices comes the rise of APIs. But it can be difficult for developers to find the information about APIs that they need - and this can negatively impact their productivity.
Using Port, developers can:
- Use an API catalog which has been integrated into a software catalog to help developers answer questions about any API such as: What is the average response time of this API? What was the last response time for this API? How stable is this API?
- See APIs of every published application (preventing them from redeveloping an endpoint that already exists), visualize service interdependency (both downstream and upstream) and understand how a misbehaving API affects services.
- Use scorecards to keep track of organizational standards and best practices, and ensure the various APIs in the organization adhere to them.
- Gain additional context into the APIs provided and consumed by services through the software catalog.
Product Manager
Manage Feature Flags
Feature flags can help deliver new functionality to users quickly and safely but they’re complex to manage.
Using Port, product managers can:
- simplify feature flag management in a number of ways such as: using feature-to-service in production as a self-service, tracking feature flags in production, approving flags, managing flag triggers
Understand and Manage APIs
Keeping track of the huge number of APIs can make it harder for product managers that want to test a product’s capabilities or implement a new feature.
Using Port, product managers can:
- Use the API catalog to better understand internal APIs and access API documentation and specifications. This can help them when testing current product capabilities or when planning to implement a new feature.
Provisioning Environments to Test New Features
From time to time, product managers want access to features that are currently in development. This way they can test the feature or showcase the feature to a prospective customer.
Using Port, product managers can:
- Provision a new environment based on a specific development branch of the new feature, so that they can test it or demo the product
Check out Port's pre-populated demo and see what it's all about.
No email required
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Check out Port's pre-populated demo and see what it's all about.
(no email required)
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Book a demo right now to check out Port's developer portal yourself
Apply to join the Beta for Port's new Backstage plugin
It's a Trap - Jenkins as Self service UI
Further reading:
Example JSON block
Order Domain
Cart System
Products System
Cart Resource
Cart API
Core Kafka Library
Core Payment Library
Cart Service JSON
Products Service JSON
Component Blueprint
Resource Blueprint
API Blueprint
Domain Blueprint
System Blueprint
Microservices SDLC
Scaffold a new microservice
Deploy (canary or blue-green)
Feature flagging
Revert
Lock deployments
Add Secret
Force merge pull request (skip tests on crises)
Add environment variable to service
Add IaC to the service
Upgrade package version
Development environments
Spin up a developer environment for 5 days
ETL mock data to environment
Invite developer to the environment
Extend TTL by 3 days
Cloud resources
Provision a cloud resource
Modify a cloud resource
Get permissions to access cloud resource
SRE actions
Update pod count
Update auto-scaling group
Execute incident response runbook automation
Data Engineering
Add / Remove / Update Column to table
Run Airflow DAG
Duplicate table
Backoffice
Change customer configuration
Update customer software version
Upgrade - Downgrade plan tier
Create - Delete customer
Machine learning actions
Train model
Pre-process dataset
Deploy
A/B testing traffic route
Revert
Spin up remote Jupyter notebook
Engineering tools
Observability
Tasks management
CI/CD
On-Call management
Troubleshooting tools
DevSecOps
Runbooks
Infrastructure
Cloud Resources
K8S
Containers & Serverless
IaC
Databases
Environments
Regions
Software and more
Microservices
Docker Images
Docs
APIs
3rd parties
Runbooks
Cron jobs