Announced this week at its online OPEN CORE SUMMIT, the framework has already been employed to create 15 plugins for Spinnaker, including an observability tool from Armory and a provisioning tool from Pulumi. The plugin framework creates extension points that provide standardized interfaces for creating plugins that invoke various microservice within the Spinnaker CD platform.
Armory CTO Isaac Mosquera said the goal is to make a Spinnaker platform now being developed under the auspices of the Continuous Delivery (CD) Foundation more easily extensible. The relationship between the frameworks and Spinnaker is naturally symbiotic; more extensions are needed to increase the appeal of the platform. Organizations are unlikely to build those extensions unless Spinnaker achieves a critical mass of adoption.
Originally developed by Netflix, Spinnaker is being advanced by CD Foundation, along with the Jenkins and Jenkins X continuous integration/continuous delivery (CI/CD) platforms. Organizations will employ different platforms under different circumstances, but the Spinnaker platform does enjoy the capability of being integrated with multiple CI platforms that DevOps teams already have in place, noted Mosquera.
That ability to mix and match DevOps platforms is becoming more critical as IT environments become more hybrid, he said. The expectation is support for Tekton pipelines, which were originally developed by Google and now are part of the CD Foundation portfolio, will be added to various CI/CD platforms to make it easier to integrate DevOps pipelines.
In the meantime, a debate surrounding how to implement best GitOps practices is starting to swirl. Thanks to the rise of Kubernetes, it is becoming easier to employ GitOps processes to automate the pulling of code from a Git repository onto any platform. In some cases, that approach might reduce or eliminate the need to rely on a dedicated CI/CD platform to manage that process. Conversely, Mosquera noted CD platforms such as Spinnaker also provide a range of capabilities that span everything from automating audit process to rolling back application code in event of a major deployment issue.
In the meantime, the amount of code moving through DevOps pipelines continues to increase. Simultaneously, the code is arriving in form of microservices that, although are comparatively easier to build, are often more challenging to deploy, update and manage.
It’s not clear how many organizations might be looking to replace existing DevOps platforms to manage those processes more effectively. However, more organizations are embracing DevOps processes more widely to deal with an ever-increasing volume of code. As such, the number of organizations adopting open source DevOps platforms in one form or another will continue to rise. Most of those organizations, however, are unlikely to want to download on their own the raw bits that make up those projects.