What is our primary use case?
We don't know the customer's end goal, but we are developing a cloud-agnostic platform based on their wishes. That's why we moved almost all our architecture to Kubernetes. For our development pipeline, which is cloud-agnostic, we also put all our CI/CD pipelines on Kubernetes. We decided to use Tekton because it's Kubernetes-native for CI/CD. Currently, it works on Kubernetes in the GCP and Azure. So we use Azure Kubernetes Services and GCP.
What is most valuable?
The first functional requirement we wanted from Tekton or any other CI/CD pipeline was to be cloud-agnostic. We met this requirement with Tekton. One of our main goals was to improve the development experience. We wanted a narrow branch approach so developers could easily create isolated environments for feature branches. In this environment, it's good to have independent assets like the build system. For example, if a developer wants to develop and use microservices, they can create a feature branch, and Tekton and any build assets are isolated to this branch. Tekton allows this because it is a native Kubernetes build system and works with Kubernetes namespaces as an isolation strategy. You can isolate most Tekton assets in the Kubernetes namespace for your feature branch. This allows you to freely change Tekton assets and objects to adapt to your feature branch and requirements. Additionally, when you remove a namespace, all Tekton assets are removed with it, so you don't need to clean up build assets manually.
What needs improvement?
Based on the event triggers, we found a workaround proposed by the Tekton team. This involves trigger groups. However, I'm a bit worried about scaling Tekton from the point of view of big CI/CD processes. As you know, Tekton uses a Kubernetes native approach with a controller feature. The controller is a service that controls every aspect of Tekton's work in the cluster. The problem is that this controller works in a single zone. You can configure the number of replicas for this controller for high availability, but the controller doesn't allow a sharding strategy. For example, you can't set up the controller to process only a subset of the Tekton objects in your cluster. This singleton approach could lead to performance problems in the future. Currently, our production controller takes around 500 megabytes of RAM. If our environment grows, it might take one or two gigabytes. It would be better to have a sharding or partition strategy to distribute the load from the single controller to multiple ones.
For how long have I used the solution?
I have been using Tekton for the past six months actively, but extensively I started exploring it two months ago.
What do I think about the stability of the solution?
Tekton is convenient because, previously, I had experience with GCP Cloud Builds. The good thing about Tekton is that it works well with autoscale in Kubernetes. You can set up zero nodes, and when you run your Tekton CI/CD pipeline, the number of nodes will grow automatically. This allows for cost efficiency from a build point of view because you won't need to have pre-existing nodes for your workloads.
What do I think about the scalability of the solution?
My organization is promising to move all our builds to Tekton. Of course, we have some concerns about scalability, but for now, it works okay.
How are customer service and support?
We found the solutions faster than the technical team answered us. They have a standard GitHub community forum or issues list where you can ask questions and create issues. But I think their response is not so fast. It took around maybe one week to get an answer from them. But, of course, it's understandable because this is open source and not a paid project for them.
How was the initial setup?
The process of installation has worked smoothly. You just run a couple of commands, and Tekton is installed in your Kubernetes cluster. There are no problems here at all. We did meet some issues with the default configuration of Tekton because, by default, Tekton uses the Affinity feature, some kind of PostgreSQL feature. This feature, when enabled, prevented better scaling. We turned it off, and everything worked as we expected. By default, this feature is turned on, and we met some scalability issues. This feature allows assigning different pods for the same pipeline to the same node. But if you set up different requests and limits for different stages of your pipeline, assigning them to the same node prevents scaling up the node pool. That's why we turned this feature off. Now everything works okay. So maybe the default configuration of Tekton is not perfect, at least for our scenario.
Initially, our project was located in the GCP, but our customer wanted to make it cloud-agnostic. They wanted to move it to Azure and maybe on-premises afterwards.
What other advice do I have?
Based on our requirements, the main need was for a cloud-agnostic platform, which is why we chose to run everything in Kubernetes, and Tekton fits this task easily. If you're familiar with other CI/CD pipelines like GitHub Actions or GitLab CI and they meet all your requirements, it might be good to stick with them. They are quite similar in functionality. Tekton stands out because it provides supply chain security out of the box with Tekton Chains, which we use. It includes built-in tools to sign and verify images. GitHub Actions and GitLab CI don't have this feature out of the box, so you'd need to implement it yourself. For better security, Tekton might be a better fit.
Tekton is easy for beginners to use. The documentation is clear and straightforward. However, the terminology can be a bit complicated with terms like pipeline run, task run, and different Tekton steps. Despite this, you can understand the process quickly. In two or three days, you can set up a basic CI/CD pipeline, maybe even faster.
I would rate Tekton a nine out of ten.
*Disclosure: I am a real user, and this review is based on my own experience and opinions.
