The corporate pendulum is in constant swing: Freedom versus standardization. Guard rails versus gates. Development versus operations. Workflow versus flexibility. The automated backbones of DevOps and continuous integration / continuous delivery (CI/CD) systems must always be adjusted to find the right balance between these dichotomies.
“You want freedom but you want freedom within a defined pathway that allows the organization to still be productive on making decisions,” said CircleCI’s vice president of business development Tom Trahan. He says that about seven years ago, the explosion of microservices was backed by a cultural change toward developer-led decision making — a philosophy of using whatever you want. But that snowballed fast.
This is perhaps best illustrated in the absurdly complicated Cloud Native Computing Foundation diagram illustrating the cloud native landscape, which, at the time of this post, boasted just shy of 1,300 tools and platforms dedicated to definition and deployment, orchestration and management, and provisioning. For rapidly growing organizations — which are often also inheriting the stacks from mergers and acquisitions — that’s simply too many choices.
This week, CircleCI launched a new set of packages, called “orbs,” to bring the recommended guardrails and automation to the deployment side of organizations that use its CI/CD software and services.
The orbs come from a number of partnerships in the industry, like the Salesforce orb that allows for testing and deploying Salesforce customizations. There’s also a Google CloudRun orb that allows for CloudRun serverless containers to run in the cloud without concern for the underlying infrastructure. Another popular addition will be Kubernetes orbs, which creates a generic base for organizations running private Kubernetes clusters, deployable to Amazon EKS, Azure Kubernetes Services, Google Kubernetes Engine, and Red Hat OpenShift.
Reusability Cuts Down on Choice
With that pendulum swinging back toward organization-led choices for software development, like all things CI/CD and DevOps, this trend is also reflected in the operations side.
Trahan said, “It’s a relatively recent phenomenon where software development people and operations have been looking to implement the same practices in software delivery.”
First and foremost, the new releases are about automating as much as you can, including automating deployment. This level of automation allows for the creative potential of engineers, with rapid release, alongside less downtime and security risks.
And this trend has carried into creating guard rails that allow for a significantly smaller selection of tools rather than all the possible options. This, in turn, prevents whatever you’d call a distributed version of spaghetti code and allows for teams to reuse, recycle and learn from the work of others.
“And lots of people contribute to the quality of that code,” Trahan said.
With these benefits in mind, over a year ago, CircleCI introduced “orbs.” One orb is a package of configuration — very analogous with the Ruby gem or with the way the NPM library works for Node.JS.
Once an organization has created a certain integrated workflow into an orb, it publishes in a publicly available, fully searchable registry. And once an orb is authored, it guarantees mutability, which means your dependency can’t delete it.
Trahan says this kind of repeatably executed code is common in the development space, but it’s “relatively unique in CI/CD.”
It’s not that organizations want to completely limit engineer choice, they just want to limit selection to the best-of-breed tools out there, like with languages, security, linting, and cloud providers. They want their teams to have the capability to use the right tools, which involves standardizing around one, two or three databases, source control systems and security tooling within a single space.
Trahan continued that, with CircleCI orbs, “You work your way through the ramp-up of the learning curve and decide how you want it to work,” tweaking as needed.
He calls CircleCI orbs “a hub where organizations can bring all those things together in a CI/CD platform with out-of-the-box use cases without the need for complex configuration.”
Deploy as Code
CircleCI right now has more than 115 certified and partner orbs from services like Heroku, Kubernetes, and Helm, with more than 1,200 total orbs listed in the CircleCI orb registry.
The most popular orb use case is for deployment as code. These deployment orbs allow developers to choose where they want to deploy to based on their current setup and workflows, and creates an integration in minutes using a pre-packaged configuration.
Trahan dubs this “deploy-as-code” as “the right way to automate processes to get the level of performance — as much validation in the amount of time that makes sense in your org — so you can take an idea and get it in customer’s hands as quickly as possible.”
“When a new technology comes out — there’s a lot of ramp-up for folks who want to take advantage of it,” Trahan explained.
As we already know, developers spend more time maintaining, testing and securing existing code than they do writing or improving code. Moving to serverless is one of these time-consuming situations where it can take hours or even days to write the integrations needed to deploy the serverless platforms that the CircleCI deployment orbs address.
Orbs become a template to speed up the process with the confidence of shared best practices.
Platform-as a-Service provider Convox already works with Google, Salesforce and VMWare-partnered orbs.
Convox Co-founder Cameron Gray said, “Working with CircleCI to build the Convox orb was so easy and powerful. With the Convox CircleCI orb our customers are able to build an application, run their tests, and deploy to Kubernetes clusters running on multiple clouds all with a single workflow, which will save time for users to do what matters most.”
CircleCI and CNCF are sponsors of The New Stack.
Feature image by CJ from Pixabay.