> It isn't even a culture.
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:
If you're doing DevOps right, you'll have good culture and good tools, for sure.
The problem is the team building your product often doesn't want to do that work, even if they can...
* 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?
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.
https://www.hashicorp.com/tao-of-hashicorp
- Workflows, not technologies
- Simple, Modular, Composable
- Communicating Sequential Processes
- Immutability
- Versioning through Codification
- Automation through Codification
- Resilient Systems
- PragmatismFor Hashicorp to claim the tao like that, is the admission that they do not know it.
Would be very interested in your feedback on an article I wrote recently dealing with this issue: https://calebfornari.com/2019/05/31/leading-a-devops-movemen...
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.
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").
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.