Contributed by Shaleen Swatantra, OpsMx (CDF Member)
Every company is trying to deliver software faster. One of the most critical decisions for setting up the organization for success is the Continuous Delivery (CD) platform. Sometimes the shiny object is not the right solution.
Responding quickly to customer needs is the new key to long-term success for many companies. Since software applications are now central to so many customer interactions, speed in delivering software is a key IT competency. That is why CD is gaining such a broad following now.
Choosing a Continuous Delivery platform is not simple. The number of integrations required, the process change that CD causes, and the impact of a poor choice all demand thoughtful consideration of all the factors involved in a good decision.
Engineering and IT architects, managers, and leaders need to grapple with requirements and tradeoffs to make decisions on which Continuous Delivery platform to choose. Rather than focus on features or technical details, this blog highlights three strategic dimensions company leaders should consider in their CD selection process.
1. Extensibility – Ensuring the Capability to Meet Future Needs
Initial deployment of CD platforms can provide a complete solution—for your initial applications or targets. Organizations of all sizes change their CD requirements over time, and these changes typically lead to the need for different capabilities in the platform.
Moving forward, teams need to accommodate new scenarios that arise as more services are added to the CD process, more DevOps tools are added to the toolchain, and more corner cases appear in your environments. These extensions could happen weekly, monthly, or even a year from now, but they will happen.
When the situation arises, an update to the CD platform is simply a requirement— without the change, that service is not able to be deployed with the required speed. But with proprietary solutions, the wait time is long. You can’t simply make this change yours. First, you need to request an update from the vendor, hope that your standing is high enough to generate attention, convince other customers to lobby for the feature with you, or compete with other customers for the vendor’s limited bandwidth. Finally, if the change request is accepted, you must wait until a request is implemented, tested, and delivered.
On the other hand, Spinnaker enables you to accommodate extensions quickly.
Extensible: Spinnaker has extensibility built-in. At its core, Spinnaker provides extensibility that allows us to bypass the traditional challenges associated with adaptability and change. You can leverage the extensible framework of Spinnaker to deliver new integrations without having to wait for a corresponding software release from a proprietary software vendor. For example, you can add integrations to new or legacy tools in the CI/CD toolchain that might be implemented or acquired after the CD platform has been deployed.
Flexible: Spinnaker provides flexibility to be able to work with:
- Both traditional and modern applications
- Extensible pipelines
- Extensible stages without needing code changes
- Custom deployment strategies
Open source: Because Spinnaker is open source and the Spinnaker community is large and vibrant, you can work with other companies or on your own to implement changes and add them to Spinnaker.
For example, someone can easily implement a new scenario by constructing a pipeline to fetch a version/package list from a repository like Artifactory/Git, allowing the user to select/search from the list and deploy to one or more targets.
Every software product has defects from time to time. If a proprietary product has a significant bug, you are again forced to work with the software vendor to prioritize and resolve the issue. With Spinnaker, you can make the updates yourself until the change is implemented in the main branch of Spinnaker. This can be a lifesaver when the problem you’ve encountered is crucial to you but not necessarily to many other organizations. This was precisely the case that Cisco encountered – more than once – when modernizing their CD solution.
2. Cost & Risk Mitigation
Cost: Although up-front cost is not an immediate concern for most organizations, it tends to become a concern at scale and over time. Customers who have moved away from proprietary solutions to Spinnaker have told us that proprietary solutions tend to be 300% more expensive, and costs are unpredictable in the long-term as unforeseen charges arise.
Risk Mitigation: As IT organizations adopt continuous delivery practices to accelerate features to the market, management of risk becomes increasingly important. Risk comes in many forms. Spinnaker is designed to reduce release and deployment risks by supporting advanced deployment strategies out of the box. No scripting necessary. Supporting blue/green, canary, and other deployment strategies, Spinnaker can provide multiple ways to quickly and safely deploy software. The O’Reilly book “Continuous Delivery with Spinnaker” goes into detail on implementing advanced deployment strategies to reduce the risk of failed releases.
3. Culture Fit – Key to Innovation
Several leaders have told me that they consider a team’s culture to be a significant factor in the innovation and scalability of their business. I do agree with them that culture influences direction and success for the team.
Teams that actively embrace open source solutions tend to have higher flexibility, a more collaborative culture, and a general willingness to do “whatever it takes” to get the job done. We’ve seen that teams with DevOps cultures or cultures focused on best-in-class toolchains tend to prefer Spinnaker due to its ability to be extensible and flexible, thus minimizing friction to innovation.
Community is another important aspect of your culture. The Spinnaker community is growing and has more than 10,000 people actively working to innovate in Continuous Delivery. Of course, breakthroughs can come from anywhere, and having 10,000 people working on a project provides a much higher chance of delivering new features or finding help when you need to solve a pressing question on the platform.
The Spinnaker Community provides access to best practices from other companies that are facing similar issues. It does not rely on a single vendor being the arbitrator of the best practices or features.
I wanted to share these thoughts as I sincerely believe your choice of CD solution will impact your software delivery’s success.
