Bunnyshell vs. Backstage for Environment Management

Utilizing Backstage is like using a framework to develop your own Developer Portal. It will be customizable, but with considerable work to be done, both initially and throughout the entire lifecycle of the Developer Portal.

Customizing Backstage is a matter of dealing with plugins: installing, configuring and possibly adapt them.

Either an existing plugin is used, if it suits the job to be done, or a plugin is developed / adapted to fit the need. Building a complex flow using plugins requires several plugins to be used and more often than not this results in a less-than-optimal workflow, due to the design constraints imposed by each plugin.

Tedious dependency management

As some Backstage plugins demonstrate - scaffolder-backend-module-aws actions package, scaffolder-backend-module-azure-pipelines or scaffolder-backend-module-http-request - combining the use of several plugins in a newly-created ecosystem is not always straightforward, and the more plugins are used, the chances of having incompatible plugins / dependencies increase. Work-arounds or code changes will likely be required to solve the situation.

Plugins and internals of underlying systems

Using plugins also creates the need to know the internals of the underlying systems - and also maintain these systems and constantly adapt their interfaces - let’s take for example the AWS authentication:

The integration is not only a matter of generating an IAM user and generating a key pair for it and then using it straightforwardly in the Developer Portal. It also involves modifying some files and managing dependencies.

Integrations outside of what plugins provide require a deep understanding of the system being integrated, as well as its interface (API or CLI, for example). Also, error handling must be performed for the integrated system, along with dispatching notifications, fixing inconsistent resulting states in various scenarios, and a few other concerns as well.

An example of a generic plugin for integrations would be the HTTP one, with which APIs of integrated systems can be called from.

Another possibility to integrate a system is to develop Backstage plugins or Custom Actions, but this leads to full-fledged software development, with all its life cycles for design, development, testing and maintenance.

Although a powerful RBAC system is available for Backstage, the permissions for an action are implemented by each Plugin, so in some cases, granularity may not be as fine as needed.

The pipeline defined in Github will build the container image which will end up deployed in Kubernetes, with the tag = TAG or SHA (depending on what event triggered the pipeline)

The pipeline will release the new application version on Kubernetes by creating a PR in the argo-cd repo, with the newly-created tag updated in the manifests.

Upon merging the argo-cd PR, the app will have deployed the latest version build the environment is not linked with any branch on the repo

In this Backstage configuration, 1 git repository repo = 1 environment, so the latest “built” version will be deployed - this can be the latest commit sha, the latest created PR version, the latest tag etc. This means that for any given feature a new repository will need to be created, and merges will happen across repositories.

Any additional infrastructure/services changes must be made through opening a PR on the crossplane repository, manually. Developers need Crossplane knowledge.

Additional concerns:

Need to define a strategy for the uniqueness of the environment / repository naming and stick to it.

The name given in Backstage is used to replace placeholders when creating the repository and its pipelines / resources etc.

The application links can be accessed from Backstage through 1 or more URLs defined in a YAML file for Backstage (catalog-info.yaml), from the application’s repository.

Need to keep conventions, having customized names will be risky, since the uniqueness is not governed by a central system.

Other information displayed in the environment’s page is also taken from the YAML file for Backstage (catalog-info.yaml) from the application’s repository, such as:

A few points to take into consideration:

The vast majority of the integrations are of a pull type - this helps in having the links in one place, making Backstage more of a catalog than an action-taker.

The heavy-lifting (actually creating, deploying and keeping the environments up-to-date, as well as the cleanup after deletion) will need to be performed in pipelines or other external tools, called via API or CLI tools.

Backstage will only be able to list or offer a view into most of your actions.

Extensive error-handling must be taken care of in these implementations across tools.

Maintenance of these pipelines / API calls / CLI calls must be taken care of as new versions appear and old ones get deprecated.

In conclusion, using Backstage would make up for a great framework on starting to build your own Developer Portal, but it offers little more than a set of rules in the actual work of creating environments.

It provides good enough view/link integrations with commonly-used external tools for logging, monitoring and issue tracking, but you’d either have to settle with the available implementations of the pull type plugins or put in substantial effort to write/adapt your own plugins, and then maintain them as well.

This would require hundreds - maybe even thousands - hours of work to get the Portal up-and-running, and considerable effort in maintaining/improving this Portal on an ongoing basis. A dedicated team would be required to run it and provide maintenance.

The Backstage platform is more geared towards service catalog / discovery than environment management. It can be used for environment management also, but with work-arounds and by having the experience quality suffer.

Bunnyshell is a dedicated environment management platform, with fully-fledged capabilities for production environments, as well as staging and development environments. The environment sits at the core of what Bunnyshell does, and concepts are implemented in a clear and concrete manner, as opposed to being abstracted and generalized. This makes working with Bunnyshell a no-brainer for engineers, who can concentrate on the actual applications instead of having to deal with the low-level implementations, abstractions and constantly connecting the dots.

So:

Using Backstage would make up for a great framework on starting to build your own Developer Portal, but it offers little more than a set of rules in the actual work of creating environments.

It provides good enough view/link integrations with commonly-used external tools for logging, monitoring and issue tracking, but you’d either have to settle with the available implementations for read-only plugins or put in substantial effort to write/adapt your own plugins, and then maintain them as well.

This would require hundreds - maybe even thousands - hours of work to get the Portal up-and-running, and considerable effort in maintaining/improving this Portal on an ongoing basis. A dedicated team would be required to run it and provide maintenance.

The comparison below tackles a few important aspects to take into consideration when deciding for a Developer Portal in a large enterprise.

In addition to these benefits, Bunnyshell also offers seamless integration with existing tools like Docker Compose, Helm Charts, or Kubernetes Manifests, support for preview environments in CI/CD pipelines, vendor-agnostic design, simplified environment management, Terraform support, increased developer productivity, and faster feedback loops.