I identify as a sysadmin.
DevOps is broken
151–160 of 363 posts
Re: DevOps is broken
#152I’ve long held this opinion but I consistently get drowned out. DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways. All “devops” as a job title has done has muddy responsibilities and given many folks the wrong impression of what an operations discipline should be. There is also a lot of rewriting of history that gets…
I'm convinced the use of the term "DevOps" continues only because of its incredible polymorphic vagueness...
Two intelligent, sincere, experienced tech people can discuss devops, in detail, for a good length of time, and still be talking right past each other without really noticing.
Re: DevOps is broken
#153How many companies are there where a Dev team writes code and "throws it over the wall" for Ops to deploy and maintain? I hear people talking about this as an anti-pattern all the time, but I haven't been in enough workplaces to see what this looks like when it happens recently.
We had this pattern in a previous role. Essentially, there was a repo with yaml config files in it. A dev team would write their code they wanted to deploy, configure the yaml files, and infrastructure would be deployed in AWS. That infrastructure was owned by the operations team.
This caused as many disasters as you’d expect. For example, when something breaks (like ECS, or a bad AMI is deployed), the dev team is stuck waiting on the operations team to fix it because the infrastructure is owned by the ops team.
I was part of transitioning to a different model where the same general concept applies; a bunch of yaml leads to infrastructure being deployed. But that infrastructure was fully owned by the dev team that deployed the code.
It only made things generally easier, because then if the deployment code broke (i.e. the code responsible for converting the yaml files to infrastructure, like terraform modules), we’d have to fix it.
Ultimately it was just a fancier and more guided version of Kubernetes.
Re: DevOps is broken
#154> The problem is most engineers don’t want to do operations work. There's your problem. You have people who build stuff without caring where and how it runs. Recipe for disaster.
I don't understand. I want to develop code. I don't want to become an AWS/S3/Github/Jenkins/Action/terraform/etc expert. I know enough of this to be dangerous but not at a level that passes as professional. Yet I am regularly tasked with maintaining the full deployment of code. There's a reason to have a team of people doing this "DevOps" work. Just like we have a team of people who do SRE. It creates a standard and…
> I don't understand. I want to develop code. I don't want to become an AWS/S3/Github/Jenkins/Action/terraform/etc expert.
They’re tools for the job, like your compiler and the language you use to program.
That’s like saying “I like to use Python and couldn’t care less for Java”. It’s fine to disagree with the team’s choice of the tools, but one needs to eventually commit to the choice, even it’s not your preferred one!
There’s an old adage that “if you’re writing clever code then you may not be clever enough to debug it”. It’s true! Operations requires deep understanding of the code running in production, the business rules and the customer. The person who will operate your code will eventually be smart enough to develop it entirely too, eventually cutting out the “dev”. I’ve personally seen this happen over and over.
Re: DevOps is broken
#155I’ve long held this opinion but I consistently get drowned out. DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways. All “devops” as a job title has done has muddy responsibilities and given many folks the wrong impression of what an operations discipline should be. There is also a lot of rewriting of history that gets…
DevOps is part of my job description. I was fuzzy on what it meant before, after reading this article, I have no idea what it means. As a general term, it's far too vague, when in practice it seems to just mean that you'll be splitting your time between writing regular application code and writing infrastructure as code. Oh and you get to be on-call.
Re: DevOps is broken
#156I’ve long held this opinion but I consistently get drowned out. DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways. All “devops” as a job title has done has muddy responsibilities and given many folks the wrong impression of what an operations discipline should be. There is also a lot of rewriting of history that gets…
>>the only alternative is to start making CPUs by hand Agreed. For some applications the cloud difference is significant; for many (most?) others though, "Cloud" is just rebrand of "Hosted". And even for more cloudy offerings, while I'm in a very specific and different part of IBM, some of the old timers/architects/powers-that-be keep trying to explain "We had that in 1969 !!!" :-D Agreed also at rewriting of history…
> My dad has been IT director and he chuckles when I talk to him about "new and exciting paradigms" which he of course sees as turning a circle to what they had in 70's and 80's :)
As someone with 20+ years in IT, I agree - a lot of these "new and exciting paradigms" are not new at all.
My personal favourite is how many large multi-nationals are now building in-house clouds?
WTF is the difference between an "in-house cloud" and a shared-use datacenter from the 1990's?
Re: DevOps is broken
#157I’ve long held this opinion but I consistently get drowned out. DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways. All “devops” as a job title has done has muddy responsibilities and given many folks the wrong impression of what an operations discipline should be. There is also a lot of rewriting of history that gets…
> I don’t hire devops, I hire infra engineers, build engineers, release engineers and: backend engineers. This is a great way to do it. There seems to be a correlation between unnecessary product complexity and unnecessary corporate complexity. Being direct about roles goes a long way towards simplifying corporate complexity.
> There seems to be a correlation between unnecessary product complexity and unnecessary corporate complexity.
That's Conway's law.
"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure."
Re: DevOps is broken
#158I hate devops. We used to have a dedicated systems team. Now programmers are expected to both write code and manage their own cloud infrastructure. These are two entirely different skill sets.
Re: DevOps is broken
#159I’ve long held this opinion but I consistently get drowned out. DevOps has different meaning depending on who you’re talking to, even some definitions that appear similar are different in nuanced but important ways. All “devops” as a job title has done has muddy responsibilities and given many folks the wrong impression of what an operations discipline should be. There is also a lot of rewriting of history that gets…
"Sysadmin" got rebranded as "DevOps", because "techsupport" got rebranded as "sysadmin".
Re: DevOps is broken
#160When I ran a fairly small team of engineers, I created what I called an "Infrastructure Engineer." I staffed it with a fairly junior, but still brilliant, engineer.
He rapidly became the most popular member of my team.
His job was to commoditize configuration management, and strip away as much of the overhead from the coders, as possible. He didn't do release management, and we didn't really work automatic testing into our release workflow. This was because Japan did not trust auto-testing, so each engineer did their own unit and harness testing. Japan also wanted each engineer to make their own "official" release, as opposed to having a CD system spit it out.
There were reasons. I didn't necessarily find them that compelling, but they were the boss, so I gave them what they wanted.
Japan liked him, as it gave them one single person to talk to, and he also helped them to streamline their own infrastructure. In fact, he is the only employee that I ever had (including myself), that traveled to Japan before being there a year.
For myself, I find using things like Fastlane, JIRA, and Jenkins, aren't actually helpful, for a one-man shop. I tend to do a lot of stuff by hand.