Hi. DevOps person here. Was doing DevOps for about 15 years before the word was even coined. (I did my first "devops" kind of work professionally in 1995.)
DevOps isn't a tool. It isn't a team, or a person. It isn't even a culture. It's a way, for lack of a better word. Like the way of the Tao. The DevOps that can be named is not the true DevOps. Everyone is doing DevOps, and no one is doing DevOps. That doesn't mean some aren't doing it better than others.
Some years ago, I attended the first DevOps Enterprise conference, and there was a phrase everyone was using... "We're not unicorns, we're horses". The point being, your company doesn't need to be a Netflix or a Google to do DevOps successfully. Elements of transformation can be adopted by anyone. Then again, as I said on Twitter at some point, "Some companies are unicorns, some are just horses, some are just donkeys, some are just stick horses, and some are just sticks". To go on another wild analogy, DevOps transformation is kind of like alcoholism. First, you have to admit you have a problem.
The next thing is, because DevOps is basically a Taoist problem... well, you can't buy the Tao. You can't hire the Tao. So companies that try to "buy the DevOps", thinking a tool will save them, or try to "hire the DevOps", thinking a consultant will save them, are doomed to failure. This isn't to say you shouldn't go out and try to hire experienced DevOps engineers, or that they can't help you, but the reality is much more broad than a single hire. Getting a good engineer is only as good as that engineer's freedom to act.
And tools do not DevOps. They only make the DevOps easier. You can DevOps even with antique tools. Back before some of you were born, I was doing distributed deployments with version control and A/B testing with shell scripts and a SQL database. It worked.
Wow, I can rant a lot about this. But what really matters? Commitment to becoming better. Actions, not words. Automating what can be automated. Recognizing that speed reduces rather than increases risk. Remembering that it's a process, not a goal. Being patient with slow beginnings. Measuring things. Remembering that not everything that is valuable can be easily measured.
I tend to think it is a culture that recognizes and seeks after the tao. I've been part of cultures that think IaaS, CI/CD etc are varying levels of important. Some are zealots about CI/CD but then don't care at all about IaaS (they provision everything manually). I've also been part of cultures that won't do anything manually. So maybe it isn't a culture in itself, but it's definitely related to and enabled by a culture at the least.
> Getting a good engineer is only as good as that engineer's freedom to act.
That made me cheer in my brain. Absolutely true :clap:
Yes, it's a culture. And it's not a culture. It's also a toolset, and not a toolset. So I see "culture" on the same spectrum as "tools". Which is more Taoism, I suppose.
If you're doing DevOps right, you'll have good culture and good tools, for sure.
I tend to favor automated, or at least scripted provisioning... if it can be exercised quickly and easily, it's more likely to be exercised more often, meaning one can be more trusting.
This sounds nice. The reality of "DevOps" in many companies is this, right or wrong: we'll make the development team do operations / infrastructure tasks, and save on hiring real, seasoned ops folks.
The problem is the team building your product often doesn't want to do that work, even if they can...
I don't think the reason companies are moving to devops is to save on ops costs. At most companies their ops guys are cheaper than their devs. They're doing it because there was an unexploited gap between development and ops that has a lot of potential.
I've interviewed many developers and operations folks. The cheap ops folks are cheap for a reason: they can't code and therefore aren't going to be automating much of anything without a lot of effort. The good ones are just as expensive as developers, because that's what they actually are...
Well, even worse, a lot of companies I've been to, are hiring "devops team", that does nothing else rather than involuntary creating yet another bottleneck, it was supposed to eradicate at first place.
That falls under my "hire the devops" criticism. A "devops team" is a bad idea. This is a blurry line, because it's also a good idea - that is, hiring someone (or a team of someones) whose job it is to think about, plan, and implement the devopsy things. But it too often comes with an attitude that development doesn't need to change, and ops doesn't need to change, and can't you just build something to make the stupid stop hurting? And then you spend your day either fighting fires in the build system or surfing Facebook and wondering where you went wrong with your career... but I digress.
My biggest niggle, is it doesn't have to be "perfect"... just good enough.
* Do you need it now?
* Is there a simpler solution that gives most of what you want?
* IS there an iterative approach you can start with?
As much as I've appreciated being on projects with CI/CD all the way to production, etc... there's something to be said for... does it run locally? can you containerize adjacent local services (db, api, etc)? can you containerize your build and local deploy? Do you have a CI/CD pipeline for pull requests? master? Integration tests?
It doesn't all have to be done at once, it can definitely be ad-hoc and can grow as your application(s) grow. Don't start with k8s when dokku will work. Don't force everything to be ready before any features can be built.
See also “The Tao of Hashicorp” (makers of Terraform, etc.) for examples of the types of meaningful ‘under the hood’ thinking changes needed to really bake ops thinking into dev.
Nah, that's just marketing bullshit targeted at people who are allured by mysticism. (If I were to reductive generalize: west cost liberals who are attracted to the idea of eastern spirituality, but never actually looked into it.)
For Hashicorp to claim the tao like that, is the admission that they do not know it.
For the record, I've seen a number of attempts to "devops" that were the functional equivalent of saying "We're doing agile now, it just has to fit in the Gantt chart". Heck, I've been Gantted on devops transformation work.
While I tend to agree, I think on a practical level it IS a culture, if culture is defined as the way a company operates and a set of principles around that. In essence the culture becomes the way, and so it's a very useful abstraction for thinking about how to influence or lead a movement towards the ways of DevOps.
Was doing DevOps for about 15 years before the word was even coined.
True story, my title was Dev Ops Manager long before the word was coined because I knew a lot about both and kept bringing both groups to the table to solve problems so they made a position for me.
It would be years before I heard the term DevOps again.
> Everyone is doing DevOps, and no one is doing DevOps.
I agree with this. Most times I've been interviewing for "devops" roles what the employer was looking for was, actually, a sysadmin to babysit the devleopers (in terms of being a "dedicate resource").
These roles have been historically disastrous for me with no exception because they shared common problems that kept me from doing my job:
1. All talk and no support for automation. I want to be rich, handsome, and well-liked too but none of that happens without a lot of serious work if I’m just a pretty face with a horrible personality and refuse to admit that’s a big problem
2. Reactionary (vs responsive) culture - all the bad, none of the good of what allows agility. If there was vision and a real need to deploy more often, that would have been solved as a priority to help speed. Instead, all had been around for 5+ years cobbling together bad processes, tribal knowledge first, and burn-out of engineers related to the failing processes was the rule not exception.
3. Lack of understanding of how to grow beyond a certain engineering maturity level - ceremonies over results and design is common as a reaction. A lot of companies do “Agilefall” for example and watch quality and throughout drop like a rock. I’m not sure if there’s an equivalent portmanteau for “Devops tools and processes with none of the benefits of automation and all of the drawbacks of code”
DevOps isn't a tool. It isn't a team, or a person. It isn't even a culture. It's a way, for lack of a better word. Like the way of the Tao. The DevOps that can be named is not the true DevOps. Everyone is doing DevOps, and no one is doing DevOps. That doesn't mean some aren't doing it better than others.
Some years ago, I attended the first DevOps Enterprise conference, and there was a phrase everyone was using... "We're not unicorns, we're horses". The point being, your company doesn't need to be a Netflix or a Google to do DevOps successfully. Elements of transformation can be adopted by anyone. Then again, as I said on Twitter at some point, "Some companies are unicorns, some are just horses, some are just donkeys, some are just stick horses, and some are just sticks". To go on another wild analogy, DevOps transformation is kind of like alcoholism. First, you have to admit you have a problem.
The next thing is, because DevOps is basically a Taoist problem... well, you can't buy the Tao. You can't hire the Tao. So companies that try to "buy the DevOps", thinking a tool will save them, or try to "hire the DevOps", thinking a consultant will save them, are doomed to failure. This isn't to say you shouldn't go out and try to hire experienced DevOps engineers, or that they can't help you, but the reality is much more broad than a single hire. Getting a good engineer is only as good as that engineer's freedom to act.
And tools do not DevOps. They only make the DevOps easier. You can DevOps even with antique tools. Back before some of you were born, I was doing distributed deployments with version control and A/B testing with shell scripts and a SQL database. It worked.
Wow, I can rant a lot about this. But what really matters? Commitment to becoming better. Actions, not words. Automating what can be automated. Recognizing that speed reduces rather than increases risk. Remembering that it's a process, not a goal. Being patient with slow beginnings. Measuring things. Remembering that not everything that is valuable can be easily measured.