How Cybersixgill has significantly improved developer efficiency with self-service actions

Cyber security company manages the entire lifecycle of runtime microservices in an internal developer portal, significantly increasing efficiency. 

Summary

‍Cybersixgill transitioned to platform engineering to provide autonomy for developers and reduce the burden on DevOps. The company didn’t want to give developers full access to production because that could be dangerous, but it wanted them to be able to carry out tasks specific to them, without needing knowledge of Kubernetes or ArgoCD. 

‍To realize this ambition, the company required an internal developer portal; after testing out several products, the company selected Port and began by building its software catalog - which has enabled its developers to easily find what they need without having to context-switch. They then worked on simpler self-service actions before tackling the biggest burden on DevOps - building new microservices, which previously took a number of days. The company now uses self-service actions to enable devs to scaffold a new service in minutes. The benefits have been huge, and developers are increasingly looking to the portal as a way to get things done. 

The Challenge

Cybersixgill is a cybersecurity company that looked to transition to platform engineering as a way to provide autonomy for developers and reduce the burden on DevOps.

‍It all started when the DevOps team realized it was inundated with developer requests. They  wanted to carry out tasks such as scaffolding a new service or provisioning a new environment. It became clear to Naveh Katz, director of cloud operations at Cybersixgill, that a change was required.

‍“We wanted to fast track all of the DevOps processes and provide developers with self-service actions. Initially, we tried to make this happen with some internal development to automate one single process that developers requested each day - and we saw how much this could benefit DevOps and the developers,” he said.

‍While this was beneficial, to really scale this up and benefit the engineering organization as a whole, it was clear that the company would require a self-service tool/platform - Katz concluded that an internal developer portal is what they were seeking. 

‍Cybersixgill piloted open source and managed service offerings on the market at the time, but they realized that the commitment required didn’t match the value they would gain. 

‍“For open source portals, the investment required was too high, particularly as we would need a full development team just to maintain the platform,” Katz said.‍

‍The Implementation

Enter: Self-Service Actions with Port 

‍When Katz and Nevo Hazan, DevOps engineer at Cybersixgill, came across Port, they believed it was the right fit for its requirements. 

‍“We were impressed with the possibilities - it was strong at the backend side and we could develop it for our needs easily. It could be exposed to our internal customers through a very intuitive UI and easy-to-use forms, and this is why we selected Port and started to implement it,” said Katz.

Low hanging fruit: the first developer self-service actions

The organization started with simpler self-service actions such as:

• New CD applications
• Updates to the production environment (eg. adding resources to Kubernetes deployment)

This initial choice of self-service actions was mainly because the effort was low but the upside was high; these tasks were both easy to exploit and easy to develop - and the developers gained autonomy without the organization having to be concerned with the risk of letting developers run loose or having to wait long for DevOps to be free. 

Another reason for this choice of self-service actions was that developers had a mixed set of knowledge when it came to Kubernetes and DevOps technologies in general. Creating self-service actions allowed the organization to provide autonomy that would feel intuitive to developers, even if they didn’t know the underlying technologies or tools, all with the right guardrails in place. 

“We didn’t want to give developers access to production itself, because that could be dangerous, but we did want to allow them to do the things that are specific to them, without needing knowledge of Kubernetes or ArgoCD,” said Katz.

Next steps: scaffolding microservices

After creating these simpler self-service actions, the team moved on to the task that had the highest burden on the DevOps team: creating new services. The developers had always wanted to quickly build new services, but each new service required a high level of overheads on management and setup. It could take the team three days to build a single microservice in the past - and sometimes there would be a request for several new microservices during the week. 

To combat this previously, the team had the entire DevOps team working a day or two just to set up new services, while simultaneously streamlining the process to make it easier. But the reality was that the team wanted a way for developers to set up their own services, and reduce the time it takes even further. 

“With Port, the developers can develop a new microservice on their own from the initial design and development of the code all the way to production. They don’t need anyone to do anything technical except for approving at certain stages,” said Katz.

The platform engineering team also made sure to abstract the process for developers:

“This was one of our achievements in creating a new microservice in Port; it’s very intuitive and you don’t have to know what’s running, whether it’s running on Kubernetes or what’s on the backend,” said Katz.

‍When a user triggers a self-service action in the developer portal UI that matches the scaffolding logic, a payload that includes the user inputs and relevant action metadata is sent to the desired CI workflow. A job is triggered and the user gets continuous indication about its progress, with full view of all of the created resources in one place in the context of the related application. 

‍The developer simply has to click on ‘scaffold a new application’, provide the relevant inputs in a customized form, and watch as the action initiatives and the scaffolding process is reflected in Port, including its status and logs. Once the application is scaffolded, the developer can see it reflected in the service catalog, connected to the relevant related resources.  

‍“You just need to know what is relevant to the developer like the resources that each instance of your code will need or the run file, or how you want to monitor a deployment - and we just went through all the values that a new microservice can have - which are hundreds- and from there we just wrapped it up and made it as intuitive as possible, by showing developers only the relevant details they need to deploy,” Katz explained. 

‍Using a checkbox in the self-service form, the team enabled those developers that did have more knowledge in DevOps to customize each of the values, so they could configure the services further if required.

Today, developers can scaffold a new microservice in two to five minutes. 

‍The team used the self-service forms to provide guardrails, for monitoring and identity and access management (IAM). This meant that for services in production, users have to select which level of monitoring they require (they can’t pick ‘none’), whereas for non-production services, the monitoring may be optional or they may not be asked about monitoring at all. Meanwhile, IAM roles are enforced for access - if this isn’t selected in the form then they’re automatically not able to access any of the resources.

Meanwhile, self-service also helps with resource changes.

‍“We had to do the entire CI/CD cycle for resource changes as the developer would have to go and open a ticket, update the source code with the new values and go through the entire process of approvals and deployment, and development in the backend. By using the portal’s self-service, this has reduced the time it takes to do this from 30 minutes to 30 seconds - and it ensures there are no errors,”

‍These huge differences in efficiency and experience have subsequently led to a wider adoption of the internal developer portal.

A software catalog that does more, with less

‍One of the other big drivers of adoption was the portal’s software catalog.  

‍Katz explained that previously, with their service catalog in a wiki, developers had trouble with getting all of the data they needed for developing a new service, for example the different services they would need to interact with, how to check their availability and so on. These data sources included Kubernetes, Bitbucket, ArgoCD, Kafka, Terraform, and Jira integrations. 

‍“We used to manage it manually, running a script every few months to update it but if someone added a new service and forgot to update it in the service catalog we didn’t know - but now it’s all dynamic, it’s all automatic, so it’s very easy for them to look for a specific service,” he said. 

‍The previous service catalog was time-consuming to use, because users would have to keep context switching, but now they can get all of the up-to-date data from all of the relevant sources in the portal, in one place. 

Involving developers early to ensure their needs are met

‍One of the keys to a more impactful internal developer portal is to ensure the platform engineering team uses a product mindset when developing the portal. This means including developers in the conversation from the outset, to ensure that their needs are being met.

‍Cybersixgill included the developers as part of the process, and ensured that they got feedback from developers throughout. Some of the developers didn’t fully understand the idea behind the portal as they believed some of the functions of the portal should be the DevOps teams’ responsibility. But after experiencing how the portal streamlined their routines, they better understood the impact the portal would have on their own experience and productivity.

‍The team also ensures that it does not deploy anything without proving it first - for instance, they will liaise with the key developers to ensure a new self-service action works without any bugs before the DevOps team stops supporting the equivalent request. Then, the team decommissions the old script or automation.

‍Hazan has since set up a regular survey with the developers to get an idea of what features should be prioritized. They will use the responses along with their own objectives and the overall business’ goals to prioritize the most beneficial portal features to add for the entire company.