Ugh.
I loved the concept of DevOps and talked it up in the companies I was associated with. Within a database DevOps had a long history as both database products, database ETL facilities, and end-user applications became more dev-operable. The idea that infrastructure had to become code has been a part of the best DBA’s mantra for years.
The cool thing is that you could walk into a first-rate shop and tell that DevOps was part of the infrastructure. You could see it work. If there were two database systems running side-by-side you could determine which system had DevOps components built in.
But somehow the DevOps concept has become a process rather than an outcome. DevOps is no longer an infrastructure as code… it has become a development process, a method, that has qualities like “empathy”. It is “a software development method that stresses communication, collaboration (information sharing and web service usage), integration, automation and measurement between software developers and Information Technology (IT) professionals”. It is a “culture”… that requires corporate management buy-in.
Ugh.
IMO DevOps is a set of software features that provide resiliency. These features are coded specifically for applications… or they are applications architected to be restartable within some larger, software-based infrastructure. Software defined machines (virtual machines), software defined networks, software defined storage sub-systems are all examples of infrastructure that could be coded to provide a self-healing business application. It is these features that we see when we recognize DevOps at work.
It may be true that there is a method that best supports the development of these features… but the evolution of the word “DevOps” from a set of engineered features to a method that focusses on people is not a positive development.
I would suggest that every DBA think about how to add DevOps capabilities to the processes that support your business applications. I suppose that these DBAs should also be empathetic and collaborate with the application developers… but empathy and collaboration are not the measure of a system that is built on the principles of DevOps.
References:
- Wikipedia: DevOps
- O’Reilly Radar: What is DevOps?
- O’Reilly Radar: Revisiting What is DevOps…
Well, as software architects, we’ve done a really crappy job of describing and generalizing the functions of DevOps into a set of tangible things. Examples include: start, stop, add node, drop node, quiesce, cluster operations, log snooping, state information requests, and CRUD for any privileged resource or object. When was the last time you actually thought about how to upgrade and rollback software components in a never go down architecture?
Yes, there are different flavors of applications which make some methods true and others needed in any / or no context… we can’t describe them all. But it doesn’t seem we even try to bridge the gap by treating the Administrative Functions required to operate an application as a first class application requirement with real stub outs. Bottom line is we’re not going to get better at this until how we operate things is at the top of the requirements list of every application.
I agree that there are DevOps requirements, Michael… Probably driven by SLAs… And further i agree that these are “technical” requirements… Not requirements for business functionality per se. But we deal with other technical requirements, like those describing performance, without requiring a new methodology injecting “cultural” changes and/or empathetic collaboration with the business users as a mandatory step. Let me say again… DevOps describes for me a set of features that i can see in a system… Not a cultural shift prescribed in yet another methodology.