The RackN team has been working on making DevOps more portable for over five years. Portable between vendors, sites, tools and operating systems means that our automation needs be to hybrid in multiple dimensions by design.
Why drive for hybrid? It’s about giving users control.
I believe that application should drive the infrastructure, not the reverse. I’ve heard may times that the “infrastructure should be invisible to the user.” Unfortunately, lack of abstraction and composibility make it difficult to code across platforms. I like the term “fidelity gap” to describe the cost of these differences.
What keeps DevOps from going hybrid? Shortcuts related to platform entangled configuration management.
Everyone wants to get stuff done quickly; however, we make the same hard-coded ops choices over and over again. Big bang configuration automation that embeds sequence assumptions into the script is not just technical debt, it’s fragile and difficult to upgrade or maintain. The problem is not configuration management (that’s a critical component!), it’s the lack of system level tooling that forces us to overload the configuration tools.
What is system level tooling? It’s integrating automation that expands beyond configuration into managing sequence (aka orchestration), service orientation, script modularity (aka composibility) and multi-platform abstraction (aka hybrid).
My ops automation experience says that these four factors must be solved together because they are interconnected.
What would a platform that embraced all these ideas look like? Here is what we’ve been working towards with Digital Rebar at RackN:
| Mono-Infrastructure IT | “Hybrid DevOps” |
| Locked into a single platform | Portable between sites and infrastructures with layered ops abstractions. |
| Limited interop between tools | Adaptive to mix and match best-for-job tools. Use the right scripting for the job at hand and never force migrate working automation. |
| Ad hoc security based on site specifics | Secure using repeatable automated processes. We fail at security when things get too complex change and adapt. |
| Difficult to reuse ops tools | Composable Modules enable Ops Pipelines. We have to be able to interchange parts of our deployments for collaboration and upgrades. |
| Fragile Configuration Management | Service Oriented simplifies API integration. The number of APIs and services is increasing. Configuration management is not sufficient. |
| Big bang: configure then deploy scripting | Orchestrated action is critical because sequence matters. Building a cluster requires sequential (often iterative) operations between nodes in the system. We cannot build robust deployments without ongoing control over order of operations. |
Should we call this “Hybrid Devops?” That sounds so buzz-wordy!
I’ve come to believe that Hybrid DevOps is the right name. More technical descriptions like “composable ops” or “service oriented devops” or “cross-platform orchestration” just don’t capture the real value. All these names fail to capture the portability and multi-system flavor that drives the need for user control of hybrid in multiple dimensions.
Simply put, we need devops without borders!
What do you think? Do you have a better term?
