Regarding areas for improvement, one significant issue is the lack of maker-checker flows to ensure that newly created pipelines are accurate and tested. We currently use an in-house abstraction over Spinnaker to verify pipeline specs, environment variables, etc. It would be beneficial if Spinnaker could offer this functionality within their product.
I am not sure if anything can be improved in Spinnaker because it was written and designed before Kubernetes was around. All of its authentication, role-based access control, application definition, and other stuff happen outside of Kubernetes, so Spinnaker is not a Kubernetes-native tool. You have to mimic a lot of the stuff you already have the provisions for in Kubernetes. Kubernetes also has parallels to what it is in Spinnaker. If your deployment infrastructure is Kubernetes, to get it running on Kubernetes takes a lot of customizations that you have to do, and it is something that the company has done. One of the downsides of Spinnaker is its scalability. The amount of data that it stores in each pipeline or from a pipeline context is huge. Every time it goes to run a pipeline, it just generates a lot of data, and its database is not exactly tuned out of the box, meaning it is not tuned for high scalability. You start to run a bunch of pipelines in parallel, and very quickly, within a couple of hundred pipeline runs, you start to run into scalability and performance issues.
Senior DevOps Engineer at a computer software company with 1,001-5,000 employees
Real User
Dec 2, 2022
In some cases, in terms of the Trinity feature, when it tries to communicate with AWS CloudFormation, and we try to deploy the instance or any container service, if any connectivity issues happen, the pipeline can fail. An error appears simply as a Trinity error, or some common error. It never shows exactly why it's failed and where it failed. Sometimes, we have to go and re-trigger or re-run the entire pipeline or reset the particular stage to make the deployment successful. Log-wise, we need to understand why something has failed so that we can understand and try to fix it the moment the issue is reported. The solution could use more robust monitoring. There are many features we can compare with Jenkins. For example, how the plugins are set up and how to customize things. For example, for Kubernetes, we have Grafana, and again, it's a separate tool. We'd like everything to come in a single tool and have the pipeline, its main dashboard, show us everything that needs to be monitored. For example, if you take in Jenkins, there is a feature called Blue Ocean. Over Blue Ocean, instead of console output, we can see how the stage is going. The graphics could always be better.
Release Automation streamlines the process of delivering software updates by automating manual tasks. This can significantly reduce deployment times and increase configuration accuracy.Release Automation allows organizations to automate software deployment processes, reducing error rates and human involvement. It enhances collaboration between development and operations teams, leading to a more efficient workflow. This approach supports continuous delivery and integration practices.What...
Regarding areas for improvement, one significant issue is the lack of maker-checker flows to ensure that newly created pipelines are accurate and tested. We currently use an in-house abstraction over Spinnaker to verify pipeline specs, environment variables, etc. It would be beneficial if Spinnaker could offer this functionality within their product.
I am not sure if anything can be improved in Spinnaker because it was written and designed before Kubernetes was around. All of its authentication, role-based access control, application definition, and other stuff happen outside of Kubernetes, so Spinnaker is not a Kubernetes-native tool. You have to mimic a lot of the stuff you already have the provisions for in Kubernetes. Kubernetes also has parallels to what it is in Spinnaker. If your deployment infrastructure is Kubernetes, to get it running on Kubernetes takes a lot of customizations that you have to do, and it is something that the company has done. One of the downsides of Spinnaker is its scalability. The amount of data that it stores in each pipeline or from a pipeline context is huge. Every time it goes to run a pipeline, it just generates a lot of data, and its database is not exactly tuned out of the box, meaning it is not tuned for high scalability. You start to run a bunch of pipelines in parallel, and very quickly, within a couple of hundred pipeline runs, you start to run into scalability and performance issues.
Spinnaker's configuration setup is too complicated and should be made easy. While configuring Spinnaker, we need to get a CLI tool called Halyard.
In some cases, in terms of the Trinity feature, when it tries to communicate with AWS CloudFormation, and we try to deploy the instance or any container service, if any connectivity issues happen, the pipeline can fail. An error appears simply as a Trinity error, or some common error. It never shows exactly why it's failed and where it failed. Sometimes, we have to go and re-trigger or re-run the entire pipeline or reset the particular stage to make the deployment successful. Log-wise, we need to understand why something has failed so that we can understand and try to fix it the moment the issue is reported. The solution could use more robust monitoring. There are many features we can compare with Jenkins. For example, how the plugins are set up and how to customize things. For example, for Kubernetes, we have Grafana, and again, it's a separate tool. We'd like everything to come in a single tool and have the pipeline, its main dashboard, show us everything that needs to be monitored. For example, if you take in Jenkins, there is a feature called Blue Ocean. Over Blue Ocean, instead of console output, we can see how the stage is going. The graphics could always be better.