How Xceptor is visualizing Kubernetes and Argo CD with Port

The challenge

Xceptor’s head of platform engineering, James Daniels, had an ambition for the company to change how it develops software by enabling engineers to become experts at running their own software. Xceptor had always tested its software to a high standard, but as a predominantly self—hosted vendor they weren’t aware of exactly how it operated. To do that, they needed a better understanding of how their customers were using the software.

“Our self—hosted (on—premises) customers can take a very long time to take an upgrade, however we saw this same trend arise for our hosted customers, meaning that new product value developed and released could take just as long to deliver to those end users.” Daniels said.

Xceptor wanted a service they had more control over, enabling them to push changes to customers to their benefit. It was at this point that the likes of Kubernetes, GitOps and technologies like Argo CD and Flux became apparent — all of which could help to provide the capabilities to enable Xceptor to do just that at scale.

This opened the door to the cloud native ecosystem and the platform engineering movement. Daniels came across an open source internal developer portal that held some promise but did not live up to expectation.

“We tried building this portal, but it failed for two reasons. The first is that it was taking far too long to build, and the second was that by default the API was unauthenticated and the documentation and support to solve the problem just didn’t work for us , we felt a bit stuck” Daniels said.

After looking for alternatives that could provide the UI he was looking for, along with being hosted on the public cloud and being authenticated, he found an open internal developer portal, Port.

“Port was configuration—driven and flexible. You could in theory model anything. It also did not need access to anything private. I liked the model of pushing data to Port rather than Port pulling data with privileged credentials,” he said.

The portal in action

Abstracting away complexity of Kubernetes

As part of the organization’s shift to being able to push changes on customers, Daniels’ team began switching from a large batch—oriented change delivery to a smaller batch change delivery. This was to improve the cadence of changes and the size of changes that they can make. He sees Port as an enabler, ensuring we have tools to keep the lid on the growing complexity of the systems.

“We’ve been able to invert the control so developers can push code, the GitOps approach means we’re ‘pulling stuff’ not ‘pushing stuff’. As we’ve abstracted the infrastructure using Port, we’ve been able to craft how users can spin up something new.”

Previously, the team would have to use a full—stack approach of spinning up new Azure resources.

Now, they can render YAML into a repo and the various Kubernetes controllers do the rest; but most importantly, it is abstracted for any user which Daniels says has enabled real agility.

In fact, the abstraction has meant that some senior engineers who don’t know about Kubernetes have even thought that everything was run on Port.

“I can see why they thought this because Port has become the face of the platform, and it means that the abstractions have worked maybe too well!” he said.

Aligning DORA metrics with business goals with Port

One of the benefits of using Port was to gain more visibility into DORA metrics.

“We wanted to get some objective metrics around DORA, so we could balance increasing our cadence but still keeping quality high.”

For example, one of Xceptor’s key business objectives was to expand the adoption of its platform. Meanwhile, the engineering team was focused on improving development efficiency, including meeting a certain DORA score. They aimed to deploy on demand and reduce lead time to just two or three days in specific areas.

These objectives are linked; onboarding more customers would affect the team’s ability to optimize engineering performance.

“The engineering team had to explain that if we iterate better, we’ll build better software and ultimately become a higher-performing organization. Port can help make these dynamics more visible to both engineering and the wider business,” said Daniels.

Cataloging agents and visualizing observability data in one place

Another pain point for the engineering team was the limited number of agents available in Azure DevOps, which meant engineers had to wait a long time to build. The organization used a Grafana dashboard to visualize build queues and wait times to see if there was an improvement.

Using Port, Xceptor was able to catalog their various agent pools and extract the statistics from Azure DevOps into a Grafana dashboard as a iFrame tab embedded in Port. This meant the team could easily access the dashboard without having to switch context between multiple tools.

“This was useful because it created a reason to access Port which held information not easily discoverable elsewhere. We were able to use Port as our shop window to broadcast improvements being made to build wait times. This integration showed us that an observability tool could be a good companion to Port as otherwise this data is hidden away somewhere that no one knows about apart from the authors of the dashboards themselves,” he said.

Boosting autonomy with self—service actions

The first self—service action that Xceptor built in Port was for creating new repositories, using Azure DevOps in the backend. This enabled engineers to provide some out—of—the—box scaffolding to a new repo along with default pull request policies that are often forgotten about.

The second was for scaffolding an Xceptor Connector, which is the primary extension mechanism for Xceptor to integrate with input and output data sources. This reimagined how they created extensions into something that was more like a marketplace.

“There were going to be hundreds of these extensions, and so it made sense to make a self—service form and get the team that are designing the architecture to own this, so we ended up with a repeatable day 1 setup"

“It was a good collaboration because while I didn’t build the template for what a connector (extension) looks like, I did provide them with the mechanism to make it a self—service action, enabling them to copy the recipe for creating a new repository,” Daniels said. 

Xceptor also created a self—service action for tenant creation using Port, which had previously been semi—automated. This resulted in a drastic decrease in the time it took to create a new tenant or deployment instance from one business day to just a few minutes. 

Next, Xceptor plans to create an action for scaffolding a new microservice architecture as part of the organization’s pivot from its monolith.

“I’m very excited for what that brings, such as enabling us to see who’s on call for a particular component, what the error rates are today, and whether it’s compliant by using Port’s scorecard functionality,”

Daniels said.

The autonomy that self—service has provided has been a pleasant surprise for many on the team.

The team has established 3 core self—service actions so far, and have performed 70 actions in the past 90 days.

How they will use Port in the future

Daniels’ vision for the portal is to create “an operations portal for everything: a silo breaker” used by anyone in security, developers, platform engineers, SREs, and more, showing each persona the things that are relevant for their particular role.

Daniels has some more specific ideas around how Xceptor will use Port in the future.

After researching vulnerability management to improve security, Daniels found that a number of vulnerability management tools write resources to Kubernetes, which effectively act like reports. Daniels wants to use Port to expose this information.

“We could export that information to gain visibility, and link this to the relevant components and then suddenly you can create scorecards which can determine whether anything — a service or connector — is ready or not, based on the report data it’s got. And then you could drive automations from that to enact change,” said Daniels. 

He wants anyone in Xceptor’s tech team to be able to use Port to extract the information they need.

“For example, if we take our Argo CD —deployment system (rollout) — if that can look at the scorecard result of a particular component and see that it’s got too many failings, we could then halt any further rollout until the team have reacted to that — which would protect our reputation and quality standards,” he said.