Spinnaker Reviews

Spinnaker's main use case is deployment. We use it to create custom pipelines instead of manually deploying our HAN files. This allows us to deploy different services for staging, production, and other environments.

The tool's most valuable feature is its intuitive interface for converting existing Kubernetes specs into working pipelines. It's easy for anyone to deploy anything on any environment when they need to test or deploy for a specific merchant or use case. Instead of going into the specs and changing different variables, they can do it through the UI, which is very useful.

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 have been using the product for more than two years. 

The tool is a stable product; we haven't seen many updates. For our use cases, we don't need updates. We'll probably continue using the current version even if updates are available unless they offer features like maker-checker workflows or pipeline tests.

In our company, everyone on the engineering side actively uses Spinnaker, probably at least once or twice a week. That would be around 600 people.

The deployment and setup are straightforward to do.

The solution is open-source. 

I would recommend the tool to anyone interested in using it for the right reasons. It's very easy and useful, and depending on your use cases, it can save a lot of time.

Regarding integration with other tools in our CI/CD pipeline, we have something to manage ownership control and access control for different pipelines. Spinnaker has integrated, allowing certain user groups access to specific pipelines or groups of pipelines and controlling access to deployment in different environments.

Overall, based on my experience, I would rate Spinnaker nine to ten out of ten.

Spinnaker is used for automating a variety of deployment tasks, infrastructure, provisioning tasks, and all kinds of things. It is also a generalized workflow engine, much like Argo Workflows. Spinnaker is just an older technology and is not a Kubernetes-native tool.

The most valuable feature of the solution is that it is an older workflow engine that has really been around for ten or more years. It came out on Netflix, and they have even stopped supporting it. Our company was among Spinnaker's most active contributors at the time. It does what it does. Okay. It has a nice cloud driver that can be a pluggable cloud driver, such that in the back end, it can plug into various clouds such as AWS, GCP, and Azure. Its cloud driver can also plug into the Kubernetes API server, and that way, you can define workflows or pipelines. I will use the terms pipeline and workflow interchangeably here. You can define pipelines that actually deploy Helm charts into Kubernetes clusters and things of that sort without having to write anything custom.

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.

I have been using Spinnaker for two years. My company is a contributor and consists of Spinnaker end users.

Once you have gone through everything related to the tool, it becomes a fairly stable product for you. It will continue to run, and obviously, we can have all kinds of monitoring 24 hours a day on our entire infrastructure, and even after that, it does continue to run fairly well. Considering what our company has also set up with Kubernetes if anyone experiences any problem, we automatically restart Kubernetes pods. The tool's stability is not too bad.

It is a scalable solution. Scalability-wise, I rate the solution a four out of ten. In terms of scalability, I would rate Argo Workflows or Tekton Pipelines as seven or eight out of ten.

My company doesn't really have the need to engage with Spinnaker's support team since we have our own internal support team.

Spinnaker is an open-source product. The tool is completely free for users.

When it comes to the tool's integration, I would say that it does have an API. My company had to modify the APIs somewhat so that we could pass things that are specific to our processes to it, so it is not too bad. The API itself is decent enough for triggering, getting status, and exposing metrics. Integration hasn't been all that difficult. The actual installing, configuring, running, and keeping it up at scale have been the biggest issues. Integration is not too bad.

I would not recommend the product to others at this point in time. If they plan to use it, I would ask them to be careful and aware of its scalability issues. If you are using Kubernetes as your application and service deployment infrastructure, I suggest you do not use Spinnaker.

Considering the functionality it is supposed to provide as a workflow engine, I would rate the tool a four out of ten.

We use Spinnaker to deploy docker containers or docker images to GKE (Google Kubernetes Engine).

The solution's deployment is pretty easy. If you want to go back to the previous version, the rollback is pretty much easy. Spinnaker makes the developer's life easy with respect to the solution's deployment or integration with Slack or any other channel. Spinnaker's notifications are good, and it is pretty much easy to configure. The base setup is pretty much complicated, but it's very easy to use once the setup is done.

The most valuable feature of Spinnaker is the rollback. With the help of other CICD tools like Jenkins, we have to click on a few more places to roll back to the previous version. With Spinnaker, we can go back to the previous version with just one click.

Spinnaker's configuration setup is too complicated and should be made easy. While configuring Spinnaker, we need to get a CLI tool called Halyard.

I have been using Spinnaker for around one year.

If you want to run Spinnaker, eight other applications are running behind it that you need to manage.

I rate Spinnaker a seven out of ten for stability.

I rate Spinnaker an eight out of ten for scalability.

Since Spinnaker is an open-source solution, we don't get any technical support. If we have any issues, we need to search Google for the solutions.

Spinnaker is a free-to-use, open-source solution. We just need to pay for the servers where it is deployed.

Spinnaker is deployed on-cloud in our organization.

If users want to deploy docker images to the Kubernetes engines, they can choose Spinnaker. The solution's configuration setup is a bit complicated, but it is easy to use once the setup is done. It will be easy for the developers to deploy and manage applications.

Overall, I rate Spinnaker a nine out of ten.

We primarily use the solution for deployment purposes. 

The best feature is that we can link it with GitHub until the deployment and it'll even gel with Jenkins for further implementation, et cetera. We like that Spinnaker can essentially gel with other pipeline products to make the deployment successful.

It is easy to deploy.

There is a good community around the product that makes troubleshooting possible.

The solution can scale. 

It is stable. 

The graphics are okay.

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. 

I've been using the solution for the last two years. 

This is a stable product. It's very reliable. There are no bugs or glitches. It doesn't crash or freeze. 

When it comes to Jenkins CloudBees, it may sometime have an outage due to the resource crunch. Out-of-memory instances may happen. The service which I'm running in the cloud, the particular controller I'm talking about, the Jenkins controller, can go down. If that happens, I have to do the manual restart. That said, it's not happening on the Spinnaker stuff. Coordination-wise, it's very smooth compared to Jenkins. From an enterprise perspective, it can scale quite well. 

We have more than 4,000 developers on staff and at least 3,000 of them use this solution. We have a pretty big organization. 

I haven't really dealt with technical support.

I've been doing the documentation work for each and followed every issue that has been recorded. Each and every issue has already been recorded at some point online, and we refer to how those issues were solved previously. Therefore, there's no need for third-party support. It's completely open source. The community helps troubleshoot, and every issue is publicly documented, down to what happened and how it can be fixed. 

It's a straightforward setup process. Spinnaker can be run in a very lightweight way. For example, the container service I have doesn't require on-premise or dedicated instances or used resources to be there. It's a container service center, and if we find multiple endpoints it's not a problem. Multiple containers can be used with single endpoints also.  

The amount of time the deployment takes depends on the deployment and where we are going to deploy. For example, if you're doing a complete setup of the infra, it's going to read any of the scripts, like Terraform script or Cloud Formation, or any other Pipeline script to build a new infra. Inside the container service, if it's going to deploy particular images, that may take a maximum of ten to 20 minutes. For the complete infra build, that's simple. That's done in less than ten minutes. It won't come more than that.

The solution is open-source and free to use. Everything is available online. 

We do have an enterprise license and we have a separate team that takes care of all the licensing. 

I'm a customer and end-user. 

We have a big environment and enough information online to help us deal with any issue that might arise. It makes for an excellent open-source option. We also have our own reliable in-house experience that has become quite useful over time. 

As developers, we want to deploy our code very fast, and we depend on the cloud, containers, and pipeline to get that done. Automation helps with that. Spinnaker helps with that. It's playing a significant role in making deliverables happen.

I'd rate the solution ten out of ten.