11–20 of 139 posts
Essentially it boils down to semantics. Often DevOps engineers are one part evangelist and one part automation engineer. The software industry has just chosen to call those people "DevOps".
Earlier quoted context omitted.
> But again we are facing this dilemma when there are literally thousands of different tools and ecosystems and you just simply cannot be an EXPERT or even ADVANCED in most of them. Though there are only a handful of ideas and principles, and all of these thousands of different tools are just reimplementations of some of them, and usually not too fancy at that.
That's correct but you can't learn all the nuances and specifics of every tool there is.
The original thought was beautiful but the way I see it: DevOps is a branch where you specialise. After school people might learn front/back/db stuff and then specialise to "DevOps stuff" -- or then you have more sysops kind of people who start to venture in the land of automating their work. Both are needed imho.
In 2017, there's literally _no_ difference between the outcomes expected from a "Systems Engineer" and a "DevOps Engineer" - both are expected to produce HA, Automated, Well Documented Infrastructure, to allow developers to run their code. Anyone not doing that is just a _bad_ "Systems Engineer"
Developers don't call themselves "Agile Developers" because they started using agile methodologies or "CI Developers" with the boom of CI, but for some reason Ops guys want to call themselves "DevOps Engineers" because they read The Phoenix Project.
People talk about automation as if automation = DevOps, but I believe automation is a side-effect of the shared empathy which DevOps fosters. Because you have that empathy with your devs, you realize that their main goal is to be able to get their code in front of users _as fast as possible_. Automation is the answer to that.
Yes yes, we get it, it's a mindset not a role. Now could we hire a DevOps guy to setup that CI/CD pipeline, ChatOps stuff, Kubernetes and dev/staging/prod flow so the coders can ship. ;) The original thought was beautiful but the way I see it: DevOps is a branch where you specialise. After school people might learn front/back/db stuff and then specialise to "DevOps stuff" -- or then you have more sysops kind of peopl…
That is so 2013! I think you meant SlackOps. ;)
"DevOps Engineer" is simply just title inflation. In 2017, there's literally _no_ difference between the outcomes expected from a "Systems Engineer" and a "DevOps Engineer" - both are expected to produce HA, Automated, Well Documented Infrastructure, to allow developers to run their code. Anyone not doing that is just a _bad_ "Systems Engineer" Developers don't call themselves "Agile Developers" because they started…
I'm not sure what it's like over the pond, but here in London I sit round tables with a bunch of "(security, system, application, cloud) architects" with less than a couple of years experience in the industry (or sometimes 10 years of one years experience) who think they have a remit to define how things work. In a silly bureaucracy, you have to play the game or you won't have a seat at the table.
I do wish it wasn't so, but also having the title doesn't prohibit you from actually doing devops either.
Earlier quoted context omitted.
That's correct but you can't learn all the nuances and specifics of every tool there is.
Of course you don't, but those nuances and specifics are usually superficial and don't change how you approach your environment. You think there is that much of a difference between running Puppet, CFEngine, or Chef?
"DevOps Engineer" is simply just title inflation. In 2017, there's literally _no_ difference between the outcomes expected from a "Systems Engineer" and a "DevOps Engineer" - both are expected to produce HA, Automated, Well Documented Infrastructure, to allow developers to run their code. Anyone not doing that is just a _bad_ "Systems Engineer" Developers don't call themselves "Agile Developers" because they started…
Earlier quoted context omitted.
Of course you don't, but those nuances and specifics are usually superficial and don't change how you approach your environment. You think there is that much of a difference between running Puppet, CFEngine, or Chef?
They are not superficial and they definitely change how you approach your environment. I have worked extensively with both CFEngine and Puppet and I can assure you that they have enough differences especially when you consider large heterogenous environments that in no way you can consider using one as a substitute for the other.
Like what?
Having worked on over 100 DevOps initiatives, I'm inclined to disagree. 8 years into DevOps, automation, cloud computing etc, it's time to accept that DevOps is a specialism and a function that companies - especially big ones - need to put into place in order to adopt the principles. See here for further thoughts - https://devops.com/im-happy-devops-engineer-job-title/
I disagree with your disagreement. There's nothing we do under the umbrella of "DevOps" that wasn't part of competent service ownership twenty years ago. I read your article and the point that stood out for me was the notion that the skills to drive tools like chef, puppet are somehow new and different. But I know better, because although I use those tools today, back in the day we used cfengine and a bunch of declar…