This article is more than 1 year old
Become an Andre Previn in your time: DevOps for star conductors
Playing to the full-stack orchestra
When we talk about "full stack" software, we are most commonly talking about the disciplines and elements (and their associated competencies) that span the complete smokestack of software application development as we typically define it.
Laurence Gellert's well-composed piece in 2012 nicely clarified this stack as the strata that run from the server, network and hosting layers onward to modeling, business logic, APIs, user interface and upwards into user experience and ultimately to requirements and business needs.
"To me, a full stack developer is someone with familiarity in each layer, if not mastery in many and a genuine interest in all software technology," writes Gellert.
So can we say the same about DevOps? Is there a DevOps stack and does it play out in the same way in terms of its granular breakdown? If it's not a stack, then could DevOps really just be a pile of IT?
Can we even say DevOps stack?
Yes, there are various component parts to DevOps (task metrics, collaboration elements, conflict management tools and so on), but is it okay to call them a cogently flowing stack in the same sense as software architecture? In other words, are the granular distinctions between DevOps stack levels different in the same way and do they plausibly fit together into a logical progressive stack?
If the DevOps stack isn't really stacked, then should it just be called the DevOps pile? Is DevOps really just a crock-pot mish mash with no recipe for continuity?
Laura Frank, senior software engineer at Codeship, thinks DevOps is indeed a stack, as she is prepared to try and validate the suggestion.
"There's more than just one tool needed for DevOps – your codebase needs version control, continuous delivery and integration, release management, and monitoring. Everything starts with a repository ... and this whole process originates when an engineer pushes his/her code to a repository. So, without any piece of this 'stack,' any attempt at 'doing DevOps' will just fall apart," she says.
Frank explains the point is that these tasks are automated "through the stack." So as an engineer, she might spend time writing code to set up the tasks, but she doesn't have manual involvement in any part other than producing the code. Crucially though, knowing that it's a stack and that all the parts are there is important.
"The DevOps process touches everything from the project repository to the production application. At Codeship, we use containers at different [stack level] points in our own internal DevOps process ... and containers are folded into a lot of the workloads our customers have as well," she says.
Yanking my toolchain?
On the other side is Freeform Dynamics research director and CEO Dale Vile. He doesn't think DevOps is a stack as such, or a pile, but rather a chain – like a toolchain.
If we accept that a software toolchain is a discrete set of application (or data management) software tools that share a link in order to work towards a defined goal, then should that be any different from a stack?
According to Vile, DevOps is about streamlining software delivery from requirements through to operations; "traditional disconnect" between developers and operational staff is addressed along the way. Thus the notion of the chain is enforced – meaning there is key logic behind the way builds move along the pipeline.
It's a short step from here to the idea of continuous delivery, but Vile reckons people often misinterpret what this means: "In a fast-moving DevOps environment (where continuous integration is producing stable builds maybe once or even several times a day), you are clearly not going to promote all builds along the pipeline."
"In practice, builds are selected for promotion out of development according to a schedule, based on achievement of a functional milestone, or on demand, e.g., in response to an urgent need for a new feature or fix," he said.
But there's a lot to think about if you want to automate the flow of releases through your continuous delivery pipeline. In a CA-endorsed paper, Vile has written that as environments "drift" through manual actions, such as fixing or tuning systems, then the answer is a system of automation that can deal with unexpected situations – something that handles fails with an appropriate alert or that presents a fix in line with pre-defined rules.
"This requires a good level of handshaking between the orchestration layer (which is primarily concerned with the movement of application packages) and underlying tools such as Chef and Puppet (which track infrastructure and middleware components)," according to Vale.
Orchestration is what matters
Whether we call DevOps a chain, a pile, a stack or a "manacled sequence of interrelated functional dependencies" (OK, I just made up that one), what appears to be most important is the orchestration factor. You can label the sum of the component parts of DevOps how you want, as long as they work together fluidly for continuous delivery.
Getting DevOps to work right is a process of cultural, process and technical tooling transformation. Whether those tools sit in a pile or a stack is not as important as knowing that there's a whole toolbox to get to grips with. ®