Platform engineering is becoming a core focus, tasked with ensuring a good developer experience to grow productivity and retention. To do this, internal developer portals have become a basic requirement.

To learn more, VMblog reached out to industry expert, Zohar Einy, Co-founder and CEO of Port.

VMblog:  How do you explain the recent rise of platform engineering?

Zohar Einy:  Everyone says DevOps is dead. Platform engineering is the natural evolution of all the great things DevOps are working on day to day. What platform engineering is about is taking the work of DevOps and making sure it blends elegantly with engineering work.

Let's first explain what platform engineering is and why people say that it's what will replace devops. Broadly speaking, devops is very reactive today, providing service to developers and taking care of and setting up infrastructure. As engineering organizations move to the cloud, and microservices architectures proliferate, this creates a lot of sprawl. Developers need to do much more than coding. Writing IaC files, Kubernetes manifests, being familiar with the cloud environments, and more make it hard for developers to roam freely while delivering software. This also makes it difficult for devops, since the more cognitive load for developers, the more tickets devops get.

Platform engineering is about solving this problem by creating visibility and automations over which there exists a productized interface for developers. Devops invest once in enabling an action - from provisioning an S3 bucket to scaffolding a microservice - and provide a user interface for developers to perform these actions. The frontend is decoupled from the actual tools and automations, meaning devops also retain the freedom to change tools and approaches (without having to educate the entire org as a result). Good platform engineering reduces cognitive load for developers, but also makes devops lives better and reduces friction. Another result is a software catalog that is updated at all times, showing everything in the engineering org - from cloud resources to services, deployments, and CI/CD flows - a single pane of glass that's useful for everyone.

Einy:  Internal developer portals play a pivotal role in the platform engineering world. The internal developer portal is the front end of the devops automations created by devops, providing a product-like experience for developer self-service. Internal developer portals also form the software catalog that is the basis for all of the benefits we mentioned above -  becoming a single source of truth and the go-to place to understand the state of engineering.

Internal developer portals contain much more over time. They are the central place where various indicators are tracked, from DORA metrics to software maturity and operational readiness - and can also be used by automated CI/CD pipelines as part of processes ascertaining whether services are locked or have a limited TTL.

VMblog:  Isn't the software catalog the main benefit?

Einy:  As I mentioned above, the software catalog is a central part of the internal developer portal, but the self-service part - creating those reusable elements that reduce developer self-service and reduce tickets - is in many ways the focus of a successful internal developer portal. Self-service means that developers don't need to interact with many devops tools but can rather just access all they need through one frontend interface.

VMblog:  You've said that IDPs can interact with machines, can you explain how?

Einy:  We've just written a blog about that :).

VMblog:  What are the pros and cons of using Spotify's backstage as an open-source developer portal?

Einy:  Basically, this is a build vs buy decision. Backstage involves quite a lot of building, while "buy" means choosing the right product, balancing the need to customize, the product quality and how it will serve you over time.

Backstage is really the main engine that got platform engineering rolling, and the ecosystem owes Spotify a lot of credit for making platform engineering a solution and driving its adoption across organizations big and small. Personally, I like their approach to modeling the environment, the plugins they support and the approach in general. What doesn't work for a lot of companies is the work involved in setting up backstage. It requires coding - the good internal developer portals are almost no-code - as well as design resources, product management and more. In short, all the resources you were hoping to deploy elsewhere as a result of a good developer portal implementation go into setting it up and maintaining it. That's why companies like us offer a product - which is much simpler to set up and provides the same value.

Einy:  There are endless use cases.

From the software catalog, developers can get answers to questions like

• What's the current running version in production for a given service?
• Who owns this microservice and where can I find API docs?
• Which kubernetes clusters exist in which cloud environment?
• Why did this deploy fail
• Is this version production-ready? What are the DORA metrics for a given team, service or developer and more.
  

Developers can also:

• Add a secret to a service
• Deploy a service to an environment
• Create a cloud resource in a region
• Add an environment variable to service/environment
• Provision a developer environment for 5 days

Einy:  Because those automations still require developers to know they exist, they may mix devops fields with what developers need to do, may require too broad permissions and mostly, create cognitive load by the fact they exist. A developer needs to know they exist - with an internal developer portal, all the developer needs to do is access the portal. All the rest is easy.

##