GitLab
vs
Spinnaker
vs
Decision Kit
Decision Kit
Spinnaker Summary
What is Spinnaker? Spinnaker is an open-source, multi-cloud continuous delivery platform that helps you release software changes. Created at Netflix, it has been battle-tested in production by hundreds of teams over millions of deployments. It combines a powerful and flexible pipeline management system with integrations to the major cloud providers. (source:)
Like Spinnaker, GitLab is also open source and also provides a flexible CD pipeline management system, is able to deploy to major cloud providers, and also offers advanced deployment patterns such as canary and incremental (rolling) deployments. In addition to this, GitLab provides not just the CD portion of the SDLC, but also everything else from planning, to CI, to testing, packaging, monitoring, and security scanning, all in a single application.
Spinnaker provides two core sets of features:
-
Application management: This is primarily to view and control your cloud resources. In Spinnaker an Application is modeled along the lines of Microservices. An application contains clusters, which consists of Server Groups. The Application also models Load Balancers and Firewalls.
-
Application deployment: This construct is used to model and manage continuous delivery workflows. A key element of Application Deployment is the Pipeline. A pipeline consists of a series of actions or stages which can be executed manually or automatically triggered. Parameters can also be passed from one stage to another and used for further actions.
At a macro level Spinnaker provides a normalized taxonomy of artifacts and actions that can apply across cloud providers. Using this normalized taxonomy one can build complex pipelines for a cloud provider or across cloud providers.
Spinnaker was created in the pre-kubernetes era and the code base did not take Kubernetes effet. This could lead to higher Spinnaker deployment and maintenance costs. To manage more complex enterprise environments, Armory.io provides an enterprise distribution for Spinnaker.
Armory.io
Armory.io provides an enterprise distribution of Spinnaker. That a third party company has to provide an enterprise distribution provides sufficient indication on the limitations/challenges of the Spinnaker platform.
Furthermore, Armory.io’s business model is heavily dependent on their services team’s involvement in customer accounts. So it is more services less product. A clear indication of the need for services is the Armory.io pricing page that lists the three enterprise offerings but no pricing on any of them. This is likely due to the unpredictability of the services component within each customer engagement.
Strengths
- Easy application deployment across cloud providers.
- Pre-packaged actions that can be easily applied, without need for lower level understanding of different cloud provider’s concepts.
- Spinnaker is Open Source and has a community of developers contributing to the project.
- Complex, simultaneous deployments as first-class citizens.
Gaps
- Only supports the Continuous Delivery (CD) phase of a DevOps cycle.
- Normalized taxonomy does not apply across cloud providers. For example, an Amazon ECS cluster does not map to any core Spinnaker concept. So these need to be set up separately, thus diminishing the value that Spinnaker can provide.
- Cloud providers differ in how they deploy and manage applications, thus eventually users need to get down to individually understanding each provider.
- Spinnaker does not support OpenStack.
- Only available in Self-hosted and managed option. No Cloud version of Spinnaker.
- Steeper learning curve - Pipeline expression language uses a custom syntax, which entails a learning curve for users. Moreover, some string manipulation and other expression evaluation requires use of java code within the expression language. Nested expressions are not supported in Pipeline expression logic, this can be a limitation in some scenarios.
Resources
Feature Comparison
| FEATURES |
|
|
|---|---|---|
|
Built-in CI/CD
GitLab has built-in Continuous Integration/Continuous Delivery, for free, no need to install it separately. Use it to build, test, and deploy your website (GitLab Pages) or webapp. The job results are displayed on merge requests for easy access. |
|
|
|
Built for using containers and Docker
GitLab ships with its own Container Registry, Docker CI Runner, and is ready for a complete CI/CD container workflow. There is no need to install, configure, or maintain additional plugins. |
|
|
|
Container debugging with an integrated web terminal
Easily debug your containers in any of your environments using the built-in GitLab Web Terminal. GitLab can open a terminal session directly from your environment if your application is deployed on Kubernetes. This is a very powerful feature where you can quickly debug issues without leaving the comfort of your web browser. |
|
|
|
Comprehensive pipeline graphs
Pipelines can be complex structures with many sequential and parallel jobs. To make it a little easier to see what is going on, you can view a graph of a single pipeline and its status. |
|
|
|
Browsable artifacts
With GitLab CI you can upload your job artifacts in GitLab itself without the need of an external service. Because of this, artifacts are also browsable through GitLab’s web interface. |
|
|
|
Latest artifacts locked to prevent deletion
The latest artifact of a successful job and pipeline on any active branch, MR, or tag is automatically locked to prevent being deleted. This makes it possible to set an aggressive expiration policy to clean up older artifacts, reduce disk space consumption, and ensure the latest artifact is always available. This default behavior is configurable at the project level and can be disabled in project settings. |
|
|
|
Scheduled triggering of pipelines
You can make your pipelines run on a schedule in a cron-like environment. |
|
|
|
Multi-project pipeline graphs
With multi-project pipeline graphs you can see how upstream and downstream pipelines are linked together for projects that are linked to others via triggers as part of a more complex design, as it is for micro-services architecture. |
|
|
|
Environments and deployments
GitLab CI is capable of not only testing or building your projects, but also deploying them in your infrastructure, with the added benefit of giving you a way to track your deployments. Environments are like tags for your CI jobs, describing where code gets deployed. |
|
|
|
Auto DevOps
Auto DevOps brings DevOps best practices to your project by automatically configuring software development lifecycles by default. It automatically detects, builds, tests, deploys, and monitors applications. |
|
|
|
Canary Deployments
GitLab Premium can monitor your Canary Deployments when
deploying your applications with Kubernetes. Canary Deployments can be configured directly through |
|
|
|
Complex, simultaneous deployments per environment
Canaries, blue/green deploys, and other simultaneous deployment concepts where an environment, like production, would have multiple deployments running at the same time. GitLab has this information, and can even show canary deployments in the deploy board, but in some other places only shows the most recent deployment. |
|
|
|
Robust deploy and rollback bundle
Encapsulate knowledge of deploying and rolling back into something more than a script, perhaps similar to a k8s operator. Something that knows how to handle failure. e.g. if you’re deploying 7 services and one fails, you can’t just stop, you probably have to rollback the 6 that succeeded, as well as the 7th that failed. (Now, depending on implementation, it still might be a script that triggers some kind of operator). GitLab can deploy and rollback, but only via scripts with limited error handling. |
|
|
|
Auto Rollback in case of failure
If a critical alert is triggered on production, Auto rollback rolls your deployment back to the last successful deployment. |
|
|
|
Pre-written deploy target mechanisms
GitLab Auto DevOps knows how to deploy to Kubernetes. Other vendors have built-in mechanisms to deploy to AWS VMs, Fargate, etc. |
|
|
|
Load balancer management for Blue/Green deployment
Blue/green deployment requires switching traffic from one set of servers to another. With GitLab today, you can manage of your load balancer via scripts, but it’s not built in as a first-class citizen. |
|
|
|
Active confirmation of what is running in production
GitLab knows how to deploy to production (and other environments), but then trusts the result. Other vendors actively query the target environment to know what is running. |
|
|
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license
