Scripts Are The New Technical Debt
In the world of open source, it’s easy to get lost in the endless possibility of what could be. You can scale just about any application from end to end with the right combination of tools, all without being tied into a single vendor.
Sounds great right?
Your intelligent and experienced DevOps team set out to assemble a toolset that is well supported, secured and accomplishes the goals for your DevOps organization in a streamlined and repeatable manner.
You spend months learning Domain Specific Languages (DSL) for each (Groovy, YAML, HCL, CloudFormation, Dockerfiles, etc) and writing automation and test scripts for building and deploying and testing and IT ALL WORKS. Your DevOps pipeline is a work of art your team can use and be proud of.
Job done. Wipe hands and walk away, except….
Who Maintains Your Bespoke DevOps Tooling Stack?
Here’s the problem that organizations start realizing on day 2 operations. These solutions are advancing faster than anything we’ve seen. Kubernetes itself has a minor release every 3 months. So how do you keep up with these constantly evolving programs?
A typical DevOps tooling stack based on open source software may look something like this:
Each one of these comes with it’s own patch and release schedule. Not only do they all have their planned major release versions, but also any critical vulnerability patches. Kubernetes alone has had 3 major releases and numerous CVE fixes. And a plugin heavy Jenkins deployment is a nightmare to keep updated.
Tooling upgrades are just the beginning.
Next, how do you maintain, adapt to new best practices, refactor the automation scripts for more efficiency and security, and keep the pipeline updated and modern. It is unlikely that most organizations can afford to have a team dedicated to this task, but rather the team who built it and is responsible for maintaining it also develops and runs the applications and infrastructure for your core business on a day to day basis as well.
Don’t just avoid vendor lock-in, avoid developer lock-in too.
The image below represents the current “CNCF Landscape”.
Also, if you are interested, check out the interactive version of the CNCF Landscap here.
These days everyone talks about “vendor lock-in”, but what about “developer lock-in” and “developer burn-out”.
Asking teams to efficiently manage this in addition to their other tasks may push your teams to their limits. In the unfortunate event that team members leave, are others able to quickly pick up where the previous “owner” of the automation left off?
The questions that organizations are constantly having to ask themselves today are:
- How do we bring this open source solution into our infrastructure safely, without breaking anything.
- How do you choose what single solution would be the best option for your organization, nevertheless picking an entire stack.
- What team members have the skill sets to take on this “transformation”
- What if those key team members leave the organization.
So What Are We To Do?
Luckily, there are tools and practices that your organization can leverage to ease this process.
Some tips to help keep the update process easier:
- Create reusable modules for many of your common tasks
- Develop upstream shared libraries that numerous services can leverage and automatically be patched when the upstream is updated.
- Loosely couple the components in such a way that individual component updates do not affect other services
We are typically skeptical of external tooling because we want to avoid vendor lock-in and keep using the open-source tools we know and love. With Agile Stacks, that isn’t an issue. Agile stacks outputs the configuration in the native language of the tool you want to use (Terraform HCL, Jenkins Groovy, etc) and saves to a completely accessible Git repo. The code is yours to do with what you like.
The beauty comes from the SuperHub automation portal that keeps track of what is deployed and automatically provides version and code updates to your chosen stack components as they are released. Removing this burden lets your team focus on other areas of the development lifecycle and look ahead to future improvements.
The AlphaBravo team is committed to aiding in the acceleration and adoption of modern open source technology. Reach out to us if you are planning to build your CI/CD pipeline or are looking for automated ways to keep your current stack updated and efficient.