CloudBees Continuous Delivery vs. Spinnaker

Spinnaker suits well for applications which are stateless and can adapt to an immutable architecture of deployment. But for applications which are stateful and cannot afford to spin up new servers for every deployment doesn't go well with Spinnaker. It can handle only deployments which are VM based and cannot support deployments to serverless architecture like AWS Lambda etc.

Incentivized

• Fast deployments.
• Can be integrated with a good variety of other products.
• Also provides some insights from your environment.

Incentivized

• It does NOT support CFN based deployments
• Windows based systems finds it difficult to onboard to Spinnaker.
• Pipeline level access authorisation is not there.
• Support for EBS volume encryption is probably missing.
• Attach/detach EBS volumes during deployments is difficult.
• No support to deploy the artifacts without re-creating the servers. Only pure immutable deployment are allowed.
• Open-source - so good and bad!
• Spinnaker on its own has 10 underlying micro services. Managing Spinnaker needs a focussed platform approach.
• User authentication is easy but authorisation management is not straight forward.

Incentivized

• Pipeline Expressiveness • Self-Service/Override • Visibility of Client Teams • Operability of Client Teams - • High-Quality Integrations (AWS, IHP, Google) • Extensibility – (Ability to add code) • The maturity of Deployment Process • Speed/Ease of Onboarding

Incentivized

• By using Spinnaker we are able to deploy new versions of our product quickly.
• A deployment takes in average 2 minutes.
• Our investment on Spinnaker was just time learning it.

Incentivized