April 1, 2024 By Josh Knarr 4 min read

Even the best organizations face challenges about the scale and scope of governance and efficient streamlining of their resources across the enterprise. These challenges can lead to a frustrating, fragmented and disjointed developer experience.

Meanwhile, different groups of developers within the organization inevitably bring different views about what one centralized code-base and tooling set should look like. It is crucial to align these different, well-meaning standards, while enabling our developers to cross silos and organizational boundaries to gain efficiencies. A developer portal like Backstage can help. 

The power of a developer portal

The power of Backstage lies in the organization that it can bring to your software development lifecycle. It acts as an abstraction layer to the complexity of provisioning and deploying microservices that are both consistent and compliant. From specifying business units, domains, teams and other information about your developer landscape, Backstage can start associating those resources together. Those associations happen regardless of where the code might live. Different repositories? No problem. Different EMUs? No big deal. If you can express the structure of your organization to Backstage using its easy-to-learn taxonomy, Backstage will help you tame complexity, bringing organization to your developer teams.

Organizational boundaries between developer teams might make dependencies seem opaque, but because Backstage expresses those relationships automatically inside its system, there’s no more worrying about loose ends. Backstage will map out the picture for you in an intuitive way. Infrastructure teams no longer need to lose time to constant custom provisioning requests from disparate groups; the menu is right in front of everyone.

The reasons for adopting a developer portal include:

  • Centralized tooling by providing one spot to access and use tooling.
  • Improved collaboration with a shared environment for accessing, sharing and managing software components.
  • Enhanced discoverability of components and resources for reuse, reducing duplication of work and creating more consistent practices.
  • Standardization by providing templates and best practices for service creation.
  • Automation and integration  for routine tasks through integration with various CI/CD and monitoring tools, including through a growing community of plug-ins.
  • Visibility and governance into the software development lifecycle through insight to project status, dependencies and more.
  • Developer experience through simplification in project management, collaboration with team members and access to tooling that promotes higher productivity and job satisfaction.

GitOps for repo data

Backstage allows developers and teams to express the metadata about their projects from yaml files. Those yaml files are written to look like Kubernetes resources, so developers can quickly and easily create them. Since the yaml files are versioned(because they’re in Git), this also means they always should express the most current information about your repos. Now, imagine the scenario where a project is consolidated into another project. For Backstage, this is no problem. Because the Backstage yaml files (which have the information about the project) become part of the normal release cycle, as your code is updated, so is Backstage.

By putting our Backstage configuration into the repository and making it a normal part of the release cycle, updates to Backstage happen almost automatically. This automation of  updating documentation and advertising  gives time back to the developers. This leads to increased developer productivity and seamless organizational communications.

Backstage as a proxy

Another great feature is how Backstage manages microservices. Instead of consuming existing APIs, Backstage can act as an API proxy .

Backstage’s API functionality helps bridge the gap between microservices. Imagine that an application is made of five different microservices. Backstage can put all those behind an API proxy, which will help present them as a single microservice. This is like APIGEE or APIM, but “in-house.” Rather than paying a cloud to host that proxy for you, you can move that proxy into Backstage and present it as a single product.

This also helps with microservices that are spread across two different clouds. Instead of maintaining two sets of routable endpoints to compose one application, Backstage will help present a “single pane of glass” to people who want to use your services.

The gain here is that Backstage now smooths over the presentation of the proxy. Have you ever sat and waited for a firewall ticket to be opened, or a service account to be created? Or have you had your services broken because one of the many APIs it depends on changed versions? Hosting an API proxy in Backstage will solve these issues for you, letting you focus more on development.

The benefits of templates

Backstage also offers templates that help accelerate development. Not only do templates advertise best practices and standards that your org has adopted, but Backstage also helps developers get started by creating repositories for them. Templates can also codify workflows.

If your organization has a workflow where developers can create new Kubernetes clusters in the “Dev Project,” Backstage will empower developers to build their environments without having to learn about Terraform. Templates can also be used to interface with workflows because templates are written in Typescript. Complex workflows can be captured in templates, such as requiring a Service Now ticket to be in an approved state before allowing the deployment.

Instead of having a developer perform hours of rework because the project did not meet organizational standards, the template functionality in Backstage can ensure the repository is created correctly. Backstage templates also save developer time by decomposing changes and workflows into easy-to-consume forms.

Why care about developer efficiency?

While this post discusses just a handful of practical examples of how IBM® can drive efficiency gains in your enterprise through internal developer portals like Backstage, it’s hard to question the impact developers can have on a business: 

  • Developers have the potential to raise global GDP by USD 3 trillion over the next decade. This potential stems from their role as force-multipliers in the technology sector, emphasizing the importance of leveraging existing software engineering talent effectively to spur economic growth and innovation.
  • Access to skilled developers is increasingly seen as a constraint to company growth, more so than access to capital. Among over 1,000 C-level executives surveyed, 55% cited access to talent as a constraint, with software engineers (53%) mentioned more often than access to capital (52%).
  • On average, developers spend 13.5 hours of their 41.1-hour work week addressing technical debt and an additional 3.8 hours fixing bad code. This results in a significant productivity loss, with nearly $85 billion wasted annually worldwide due to the time spent on bad code and maintenance issues.

With IBM, you can empower your developers and bring standardization and efficiency to your software development lifecycle.

Reach out to IBM today to discuss the organizational power of Backstage
Was this article helpful?
YesNo

More from Automation

Deployable architecture on IBM Cloud: Simplifying system deployment

3 min read - Deployable architecture (DA) refers to a specific design pattern or approach that allows an application or system to be easily deployed and managed across various environments. A deployable architecture involves components, modules and dependencies in a way that allows for seamless deployment and makes it easy for developers and operations teams to quickly deploy new features and updates to the system, without requiring extensive manual intervention. There are several key characteristics of a deployable architecture, which include: Automation: Deployable architecture…

Understanding glue records and Dedicated DNS

3 min read - Domain name system (DNS) resolution is an iterative process where a recursive resolver attempts to look up a domain name using a hierarchical resolution chain. First, the recursive resolver queries the root (.), which provides the nameservers for the top-level domain(TLD), e.g.com. Next, it queries the TLD nameservers, which provide the domain’s authoritative nameservers. Finally, the recursive resolver  queries those authoritative nameservers.   In many cases, we see domains delegated to nameservers inside their own domain, for instance, “example.com.” is delegated…

Using dig +trace to understand DNS resolution from start to finish

2 min read - The dig command is a powerful tool for troubleshooting queries and responses received from the Domain Name Service (DNS). It is installed by default on many operating systems, including Linux® and Mac OS X. It can be installed on Microsoft Windows as part of Cygwin.  One of the many things dig can do is to perform recursive DNS resolution and display all of the steps that it took in your terminal. This is extremely useful for understanding not only how the DNS…

IBM Newsletters

Get our newsletters and topic updates that deliver the latest thought leadership and insights on emerging trends.
Subscribe now More newsletters