How Checkmarx saved hundreds of thousands of dollars on developer environments with Port

‍Port enables Checkmarx to create an end-to-end developer experience for developer environments

Summary

Checkmarx’s DevOps team had to deal with an increasing number of tickets from developers, particularly centered around spinning up new developer environments. This resulted in higher costs and frustration for developers and DevOps. 

The company implemented an internal developer portal using Port, which enabled it to establish an end-to-end experience for creating and managing developer environments. This included using a self-service action for creating environments, seeing all of the relevant information about the environment in the software catalog, being able to request an extension of the TTL (Time-To-Live) using a self-service action, being able to use an automation to destroy the environment when the TTL expires and use a self-service action to delete any environment that is no longer required.

This significantly reduced the workload on DevOps, cut costs from potentially hundreds of thousands to just thousands of dollars, and increased consistency and productivity among developers.

The portal allowed developers to manage their environments autonomously, supported a shift towards a GitOps model, and provided a more user-friendly experience. The high adoption rate of the portal demonstrates its value to the team, improving overall efficiency and reducing dependency on the DevOps team.

The challenge

Checkmarx faced a common challenge that many engineering teams encounter: a bottleneck of tickets created by developers for DevOps to handle. In this case, many tickets were for assistance in spinning up and managing developer environments. This bottleneck slowed down the workflow, and created frustration for developers and DevOps alike.

To make things worse, Checkmarx had five different approaches for creating developer environments to test software. This meant DevOps had to provide support to many different developer teams that were effectively trying to reinvent the wheel without necessarily adding value. Not only was the creation of environments slow, but the variety in types of environments created an operations challenge.

The numerous different approaches meant that developers had to constantly learn new ways of accomplishing the same task. This effectively reduced their autonomy and productivity. Overall, it was time consuming, and as many environments were not deleted after use, it became incredibly expensive.

One of the more popular approaches to creating a new environment had constant issues and required fixing constantly.

“This led to the whole DevOps team having to stop working until somebody can investigate, potentially terminate the environment and go back to the last known working version,” explained Noam Brendel, DevOps team lead at Checkmarx.

"The team lost significant hours each week on this back and forth,” he added. 

Brendel sought a new approach which would provide developers with the autonomy they needed along with the right guardrails in place and unify standards for environments. That’s how he came across internal developer portals.

Spinning up a new developer environment 

After analyzing several options, including Backstage, it was clear to him that Port offered an end-to-end developer experience for spinning up developer environments without the need to scale up resources significantly. 

Checkmarx used the portal to establish self-service actions for creating or destroying a developer environment, providing developers with autonomy, while ensuring that they are following golden paths with the right security and compliance measures in place. 

"If a developer needs a development environment, they simply go to the self-service portal and click 'create'. They then select the AWS account for their team, and the environment is set up with a Time-to-Live (TTL), ensuring it doesn't run indefinitely,” said Brendel. 

Developers can also choose the specific version they need, so that if they want to investigate a bug in a particular version they can do so. 

Brendel believes that the way Port abstracts away complexity is benefitting developers.

‍“I can click and an environment pops up and there’s a whole black box of logic that isn’t exposed to the user,” he said.

Developers can also use self-service actions to extend the TTL, or to take down a developer environment. 

What’s more, Checkmarx has created an automation in Port to terminate ephemeral environments. So when the timer property TTL of a developer environment entity expires, it triggers a GitHub workflow that automatically terminates the environment. 

‍

The combination of self-service actions and automations enable developers to manage developer environments from end-to-end, providing a much better experience.

Saving hundreds of thousands of dollars 

Previously, teams would create environments that were not utilized efficiently, were always-on, and were expensive to maintain. For example, there were environments that would be left on during weekends and holidays, and were only used by a few developers. 

Using Port, developers can implement fully cost-effective end-to-end environments with a single click. This meant instead of having numerous AWS resources (EKS with EC2, RDS, S3, etc) for each environment, they created an environment with k3d (a lightweight wrapper to run k3s) that contained everything bundled inside it. 

With the visibility of costs and a more streamlined approach for creating environments, the engineering team has significantly reduced costs.

“What once cost 30 dollars per hour for an environment can now run as low as 70 cents per hour. This means we’ve reduced costs from potentially hundreds of thousands to just thousands of dollars overall,” said Brendel. 

The team has also standardized the environments so that all developers work within the same setup. This consistency ensures that everyone is on the same page.

Developer environments made easy

Within these environments, developers can easily download the Kubeconfig file and work with it locally in their IDEs. This means they can get the full developer experience in their preferred IDE, and can override the file. This offers a smooth and unified experience, regardless of the environment's location.

Checkmarx also offered an option for developers to add ArgoCD in each personal environment as part of a shift towards a GitOps model. This has allowed them to experiment and learn without needing to fully understand its complexities upfront. This new setup provides a more user-friendly and hands-on approach.

For those who might be less comfortable with the command line interface (CLI), the system offers an intuitive interface through ArgoCD, enabling them to manage and modify their environments easily. This flexibility is a big step forward, as it allows developers to debug and interact with Kubernetes more effectively. Checkmarx intentionally kept the features streamlined and practical, focusing on adding only the most useful tools, rather than overwhelming users with unnecessary options.

The future: software catalog and scorecards

Another self-service action that has enabled standardization is to ‘create a new service’. 

“Up until now, if a developer wanted to create a new service, they were dependent on a lot of other teams, who they had to approach to get this done. We had a few templates but nothing concrete or well-organized. With Port, developers can create a service without being dependent on anybody,” Brendel said.

Meanwhile, the DevOps team has a self-service action for enabling or disabling pipelines, and Checkmarx intends on expanding the number of self-service actions it has going forward.

Brendel explained that his team’s next task is to build a service catalog and his team is in the process of defining what it should look like. 

The main hurdle that his team has to overcome is establishing how they treat new services and old services. This is because for new services, developers are no longer dependent on the DevOps team, when they create a new service such as a Go service, they receive a GitHub repository complete with CircleCI integration, providing everything required for continuous integration, such as Makefiles, Dockerfiles and other configuration files, effectively scaffolding the project. The setup also includes a predefined workflow that incorporates important security and quality measures.

The team needs to find a way to onboard older services into this new standardized process, to ensure consistency across all services within the company. This is something they will plan in the next sprint. 

 Brendel wants to use Port’s software catalog to enable pipeline visibility from code to production. This will mean that developers and DevOps can see where along the pipeline software is at any given time, reducing the need for developers to approach DevOps with questions about statuses. 

Once the software catalog is up and running, the team can begin establishing scorecards. Brendel is keen to drive better standards through scorecards, with one example being to gain more visibility into code coverage and grading different percentages accordingly. 

Internal developer portal is providing value

Brendel is tracking adoption of the internal developer portal using Mixpanel, and he sees consistent usage of people creating services and environments.

“The adoption rate is high, with the majority of our users engaging in some form of activity each day. It’s clear that our users are finding value in it,” he said. 

Conclusion

By implementing an internal developer portal with Port, Checkmarx successfully addressed the inefficiencies and high costs associated with managing developer environments. The portal empowered developers with autonomy, reduced the burden on the DevOps team, and ensured consistency across the board. The self-service capabilities, along with automation for environment management, not only streamlined operations but also significantly cut costs. Additionally, the move towards a GitOps model and the planned enhancements with a software catalog and scorecards highlight Checkmarx's commitment to continuous improvement. The high adoption rate of the portal underscores its effectiveness, making it a valuable asset in enhancing productivity and maintaining high standards within the organization.