A Terraform-first Approach to Internal Developer Portals

Introduction

‍

Port provides a platform for building internal developer portals. Building and managing an internal developer portal can be a challenging task, even for experienced platform engineers. They need to ensure that the developers get a great self-service experience that makes sense, and that the portal is built in a way that maximizes its benefits. They also need to make many design choices about how to model their software catalog, when to apply workflow automation and the extent of self-service they want to provide developers. 

‍

To make it easy for platform engineers, we chose to make Port both API and Terraform first, so that everything can be configurable using Terraform. In this post we’ll explain why.

‍

What about No-code?

Port is a no-code internal developer portal platform. We plan to keep it this way. Using Port’s UI, exporters, connectors, blueprints and RBAC modules, you can indeed set up an internal developer portal without coding. You’ll get the ability to model your services, CI/CD and cloud resources and to deliver a great UI for developers, all without coding.

‍

But that doesn’t mean that no-code is all there is. We also made Port API-first, so that platform engineers can interact with anything in Port using the API. We know that this is what DevOps prefer, and it works well in many cases involving automations in Port. But the more we thought about it, we understood that Port also needs to be Terraform-first.

‍

Platform engineers want to use Terraform

Platform engineers are usually familiar with Terraform and use it to manage infrastructure as code. This solves version control, automation, and repeatability for them. So, it's natural for platform engineers to prefer using Terraform to configure the developer portal rather than using a user interface.

Internal developer portals are part of the infrastructure

At Port, we see the developer portal as part of the infrastructure. It then follows that platform engineers should manage the IDP as code. By managing the developer portal as code, platform engineers can automate configuration and apply version control, just like they do with other infrastructure components. This approach ensures consistency across the infrastructure and the developer portal.

‍

{{cta_4}}

Managing different experiences for different developers

Internal developer portals are made to offer different experiences for different developers. This can be a result of the team they are in, role-based access control policies, as well as developer proficiency in different aspects CI/CD, Kubernetes, etc. Similarly, developers will get access to different types of developer self-service actions, with different TTLs etc. 

‍

Manually managing all these configurations can be a daunting task. Using Terraform, platform engineers can automate the configuration process and ensure that the portal is configured according to the policies they’ve set.

Internal developer portals are infrastructure and changes should be treated as such 

The developer portal is the product that platform engineers provide to their customers, the developers, so it's crucial to ensure that it's thoroughly tested and validated before deploying to production - as with any other product.

‍

With Terraform, platform engineers can define the developer portal for both test and production environments in code and then easily apply it to the corresponding environments. Terraform's ability to create resources in a consistent and repeatable way ensures that the test and production environments are identical, minimizing the risk of issues arising in production due to environmental differences.

‍

Moreover, Terraform's state management system ensures that changes made to the infrastructure in one environment are recorded and can be quickly replicated to another environment, reducing the risk of human errors when moving changes between environments.

‍

Conclusion

While it’s super important to be API-first and provide a no-code platform for developer portals, we believe that many platform engineers will prefer to interact with Port through Terraform. By using Terraform to configure the developer portal, platform engineers can leverage their existing skills, manage the portal as part of the infrastructure, and provide a customized experience for developers. Most importantly, they get to interact with the IDP through the tool they know and love.

Assuming platform engineers have many additional favorite IaC tools, we’re working on adding them. Soon, we hope to have the option to set up the developer portal using Pulumi (thank you Engin!) and Crossplane. This will give our users even more flexibility and choice in how they manage their developer portal infrastructure.