How Xceptor is visualizing Kubernetes and Argo CD with Port
Ready to start?
TL:DR
Xceptor, a data automation provider including for financial services firms, faced challenges in transforming its software development practices, such as siloed operations, limited visibility into ownership and dependencies, and inefficiencies in deployment processes. Port helped overcome these issues providing a UI that abstracts away the complexity of Kubernetes and enables selfâservice actions. It will in due course also offer better visibility into DORA metrics Xceptor is targeting.
This helped to balance engineering and business objectives and enabled developers to deliver changes more efficiently. In addition, project managers and product owners gained improved transparency into ongoing work. As a result, Xceptor saw significant improvements, including estimated cost reduction, more autonomy for engineers and better collaboration across teams.
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.
[Establishing a Kubernetes platform] could have created yet another silo where I take software and deploy things on behalf of others on my platform â and I didnât want that. I wanted complete ignorance from the workloads that run on it, to a certain degree. Port is helping us to break silos â and itâs just the start
Concluding thoughts
Xceptorâs transformation was powered through its move to containerization and orchestration via Kubernetes, and Argo CD enabling the GitOps model. Daniels emphasized that Portâs part in presenting an interface that exposed information to users was critical to the transformationâs success â including a significant estimated increase in deployment frequency and an estimated 46% decrease in running costs per tenant.
âMost of the users of the catalog and selfâservice actions don't know what containers, Kubernetes or GitOps are. So, without Port we'd either have failed to deliver on the selfâservice aspect and ended up interfacing over email or a ticketing system or we'd have been forced to build our own UI which is resourceâintensive and is unlikely to have yielded the same results,â said Daniels.
Daniels says the key values that Port has provided Xceptor include:
- Being able to truly benefit from Kubernetes by providing the UI that abstracts away complexityÂ
- Helping to determine and visualize ownership and dependencies
- Providing autonomy through the catalog and selfâservice actionsÂ
âBuilding a platform has created the foundation for our journey towards realising the outcome where each and every engineer at Xceptor is empowered to confidently deliver highâimpact changes frequently and predictably with minimal toil."