Templatized pipelines have improved efficiency while limitations in code-based development remain
What is our primary use case?
Harness has been implemented in our organization for one of our clients for approximately 8 to 10 months. Harness is particularly utilized for our infrastructure provisioning pipelines and our RITM ServiceNow requests.
With Harness CI/CD, one of our main use cases is using it as an infrastructure-provisioning pipeline. Harness allows us to have an end-to-end infrastructure pipeline, which connects our DevOps and our ServiceNow for governance and our custom portal, which we call an infrastructure-provisioning portal, and a central backend database through which we are able to provide a heterogeneous mixture of different resources including AWS, Databricks, Vault, IDMC, and GitHub repositories. Through this, we use Harness as the main platform where we are able to provision and manage all the pipeline executions as well as our requests that we receive for infrastructure provisioning.
Our team primarily interacts with Harness using their Pipeline Studio. That is one of our finest use cases, and currently, we are also looking forward to integrating Harness or working within Harness so that we can do more pipeline-as-code type development.
What is most valuable?
One of the best features Harness offers is the ability to templatize pipelines. Through template pipelines, we are able to reuse pipelines across different of our internal workstreams, and we are able to utilize various organization-level templates for various common use cases including ServiceNow RITM tickets or infrastructure-provisioning pipelines for Terraform.
Pipeline templatization has been a primary focus of my team, particularly because one of our infrastructure-provisioning requests always has a dependency on Terraform workspaces and GitHub creation. To address that, we resolved the issue by creating an end-to-end child pipeline that is part of our FTP platform. That pipeline is then utilized across all our different workstreams to provision Terraform workspaces and connect with Vault and GitHub IAC, so that we can effectively and reliably create infrastructure as code repositories. That is how we are able to work with templatization.
Harness Pipeline Studio is another feature that stands out. A good visual platform that allows us to see the pipeline end to end in an architectural manner is always helpful.
What needs improvement?
Harness UI can do a lot of good things. Harness's UI should not feel very complicated. At the current stage, it feels very commercialized and compared to other platforms such as Argo CD or Jenkins, which feel much more lively and much more simple. Infrastructure as code or pipeline as code is something that Harness severely lacks. There is not a lot of good support for pipeline as code, and I often find myself not using pipeline as code the way other platforms such as GitHub Actions or Jenkins integrate pipeline as code. Pipeline as code is definitely one of the disadvantages when it comes to Harness. Additionally, the entire platform feels very commercialized, which is something that a lot of developers, especially open-source enthusiasts, might not appreciate even within the organization.
One of the very important key factors I observed was that there is no way to execute nested pipelines, which means that we cannot execute child pipelines within child pipelines and child pipelines even within those child pipelines. There is no way to execute nested pipeline execution, which may or may not be required based on the use case, but it is definitely one of those features that I wish the platform had.
For how long have I used the solution?
Harness has been implemented in our organization for one of our clients for approximately 8 to 10 months.
What do I think about the stability of the solution?
Harness is decently stable. I do feel there has been some downtime, but it may be a problem with our platform or our teams internally. Overall, I feel the platform is stable enough.
What do I think about the scalability of the solution?
Harness scalability is good. It is able to work on our infrastructure side, which is EKS, and we are able to handle our organization growth effectively for an enterprise use case.
How are customer service and support?
Although I have not directly interacted with customer support, we have been receiving incident reports whenever an incident occurs on Harness, and they are usually quick to respond, which is always an advantage.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
In my organization, we were and are still using GitHub Actions. GitHub Actions is the primarily CI/CD tool that we use, particularly because it comes with direct integration with our enterprise GitHub setup, and it is a natural tool that a lot of developers are familiar with in today's time. The reason why we shifted to Harness from GitHub Actions for a few of our edge use cases or newer use cases was because of pipeline templatization, a studio visual code development experience, as well as easy integration with other pipelines and templates that have been developed throughout the organization.
How was the initial setup?
My organization opted for Harness through AWS Marketplace and by reaching out to professionals and support teams at Harness.
What was our ROI?
By adopting templates and various different pipelines across our own IDP platform, we have saved upwards of 30 to 40% of development time and also reduced risks of failures or error rates by upwards of 70%.
What's my experience with pricing, setup cost, and licensing?
From what I understand with respect to Harness, licensing and setup costs were relatively low for an enterprise, and the pricing was more catered toward enterprises who would invest in the technology. The price that they pay extra for that technology compared to what they would have paid for open-source is then offset by the number of projects they are able to onboard.
Which other solutions did I evaluate?
In our organization, the only other option that we really evaluated was Argo CD. We did not go for Argo CD primarily because it was already open-source, and while using it, it felt more catered specifically toward Kubernetes, which was great. Our use cases are varied because we work with different domains such as AI and data engineering. We are dealing with a heterogeneous set of architecture, and while Argo CD did integrate nicely with Kubernetes-based deployments, it lacks severely in those other areas where Harness shines.
What other advice do I have?
For others looking to use Harness, they should first evaluate their own organization to determine if Harness really solves all their use cases. Harness is somewhat use-case dependent, meaning while it definitely lacks in pipeline as code, it is still able to provide a pipeline-based studio, which is something that is unique to the platform itself. It could be a great performance booster for teams that are working heavily with other aspects of the application stack and not focused completely on pipelines. My overall rating of Harness is 6 out of 10.
Which deployment model are you using for this solution?
Public Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)
