121–130 of 139 posts
Earlier quoted context omitted.
Therefore we need a new title to distinguish "Real System Administrators" from server technicians. So, we get "devops" for people who understand both.
Except in reality we get people who are bad at dev and bad at ops pretending they can do both
I am a DevOps Engineer by trade and title. Here is my take on this: It is a role - not something that can be done by OPS or DEV or SEC or what have you. Allow me to explain my 2 cents worth: - With the amounts of tooling (CI/CD pipeline, infrastructure monitoring, infra. provisioning, config. management, etc.), you do not want your DEVs or your full-time admins focusing on this bit at-all. It is good if they have som…
Those engineers might have different focuses; so maybe building a data store, or an api, or a Jenkins system, or an artefact store....
If you leave your cicd tooling and toolchains to a team then you create a dependency, and for me a key part of devops is reducing dependencies.
The suggestion in your post is that by blurring the traditional roles you make those people less productive. And therefore the solution is to create a new role.
That's fine: but that's the old thinking (IMO) hanging around. The original intent of devops would definitely run counter to that :)
Earlier quoted context omitted.
As a relatively old guy, I always thought that DevOps was just the new name for what people have always been doing. It is literally just now that I've realised that other people think it is different :-) Possibly younger people don't understand what system administrators used to do...
DevOps role is different because it assumes full product ownership. Typical system administrators are focused on just the infrastructure portions. In a DevOps role you are more focused on the things running on that infra, as well as the infra. It's a more encompassing role than the traditional 'sysadmin' role.
"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…
It is not the engineers that call themselves 'Devops'. It's the recruiters and managers. Every engineer that I know that holds the 'Devops' title hates it, but has no choice in it.
Thanks to the recruiters and the all-too-common association that "devops = the new ops", the very term has suffered a massive devaluation. I learned this the hard way - I was foolish enough to try to hire DevOps Engineers. That's a two-month span of my life I will never get back. That's why I came up with the idea of renaming it as a search for Infrastructure Engineers.
... only to find out that I wasn't the first one. The signal/noise ratio had obviously been a problem because other companies have used the term before I did, but on the other and, even more companies have joined the crowd since then.
(It was interesting to see this blog post, because it has almost the exact title I have had in mind for my WIP longer post on the same topic.)
"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…
DevOps, is a developer, that do admin stuff, because the development environment became more complex with the introduction of virtualization , cloud technologies and big data Admins who do Dev work should be called OpsDev ... A DevOps, is a Developer , someone who started as a developer and now do extra admin and systems work Not the other way around ..
Eh. Spinning up a new VM is wayyyyy easier than racking a new box. And deploying to an app-running service is generally way easier than managing a bare-metal/load-balancer/etc-interfacing deploy script.
A devops engineer building and maintaining that infrastructure is a split that makes sense to me, but generally doesn't obviate the need for systems/network admins and engineers, as you still have problems and issues with the underlying things often come up (sometimes it's outsourced to a cloud provider, though).
I am a DevOps Engineer by trade and title. Here is my take on this: It is a role - not something that can be done by OPS or DEV or SEC or what have you. Allow me to explain my 2 cents worth: - With the amounts of tooling (CI/CD pipeline, infrastructure monitoring, infra. provisioning, config. management, etc.), you do not want your DEVs or your full-time admins focusing on this bit at-all. It is good if they have som…
Saying you have a DevOps team is like saying you have Lean team, a Theory of Constraints team, or a Just-in-time manufacturing team. DevOps doesn't say that devs shouldn't write code any more then Theory of Constraints says a guy that paints car hoods should be building brake pads. It is about the fact that they should work together to ensure the organization as a whole meets the goals. Not as isolated units that only prioritize their own goals.
I've seen the same flak about Agile and scrum roles for the same reason. People think they can buy the DevOps/Agile/whatever. Only difference with DevOps is rest is that it is getting more noise.
I used to repeat this statement, but a few years of the current pattern, I disagree. (I'm going to generalize for UNIX systems, apologies in advance) Your traditional systems engineers are well versed in the ways of UNIX, but that does not automatically qualify them to wear the DevOps hat. And vice versa. Systems and DevOps are two different sides of the house. There is an entire tooling set that someone with the Dev…
In DevOps there is no "I can't run npm" unless the new guy is building his first personal env. In DevOps ERRNO scrolling down the screen means your kit is broken and you need to rebuild it to a known, working state, yourself (and crap like that certainly wouldn't be making it into production). In DevOps the entire organization is on board. Everyone has a role even if it's just feedback or a ring-ring fielding phone jockey and they'll know why and they'll know it's an important contribution because every lost piece of information affects delivery and quality.
If you're automating, integrating, designing, orchestrating, trouble-shooting or just about any other ing-ing you can think of than you're an engineer and you can front that with whatever you like be it systems, integration, quality-assurance, software, application, automation, monitoring, cloud, reliability, hardware, database, support, etc. etc. and even devops, if you like.
The difference is whether the organization you're doing all of your "engineering" for has accepted and/or is applying the DevOps "method".
I've perused some "DevOps Engineer" postings and a good amount of them look like garbage idolization of this or that toolset combined with looking for someone they can beat on until their infrastructure works like they think they'd like it to.
DevOps ain't infrastructure and it certainly isn't ace dev guy running the prod kit and no, it's not about "enabling" developers either. It's an operation comprising the entire cycle of delivery with expectations and requirements from all members.
Given the case of some new startup and they're on the hunt and poised to ramp then what they're really looking for is a savvy engineer (or 12) that can ing-ing all. day. long.
Sadly, because of business overlays and buzz-wordery and agile styles and .. certain software stacks, a more than fair share of time gets sucked right out of the actual developing and operating parts, especially if there's any palatable resistance to acceptance but, alas, it really is just another thing fronting ing.
I was thinkging about that Mike Dilworth quote: "DevOps is a culture, not a role! The whole company needs to be doing DevOps for it to work." It's one of those kinds of statements that at first glance, looks really insightful and invites the head nodding up & down in agreement. However, thinking about it some more, that type of quote can be applied to anything . "Compliance is a culture not a role. Everyone from the…
If you look at the early conversations, it was a discussion that outlined a management paradigm that borrowed heavily from Theory of Constraints in the manufacturing world. The discussion lead to a consensus among those involved that defined core values of culture, automation, measuring, and sharing (CAMS).
To many people, DevOps means that paradigm. The examples you list (security, marketing, etc) are not paradigms composed of several values. They are business functions as infrastructure automation might be. We don't call the accounting team the "cash-flow" team cause it is a paradigm. Not a function.
While I don't think it is worth falling on your sword over, the fact that folks care about the wording is good. It means they are thinking about more then just the function, but also the underlying paradigms.
Earlier quoted context omitted.
it is definitely possible to have fairly deep level of knowledge at all layers it just takes effort. That said, the larger the project, the more the need for specialization and the less possible it is for someone to keep up with all changes and be a domain expert.
I disagree. Maybe, there's a couple of guys/gals around that can go up and down the software and hardware stack and know where issues may lie when there's a problem, but I doubt there are many. As a someone that's been in the tech industry a very long time, I came to the realization a long time ago that I couldn't be the expert at everything. Can I dabble in Oracle, Windows, Linux? Sure, would I want to bet my job on…
That's what happens when you work at startups, there is no plethora of employees, and a lot of work.
Earlier quoted context omitted.
You are comparing apples to oranges (in my opinion of course). I would say it's often hardly about just "operating" the machine. You need to know how the machine works how it can affect other machines and what can you do if parts of the machine break. Not only that but also how many operators you can find, how many additional modules (libs) are there and how often you need to oil the wheels. Sure the implementation o…
> I would say it's often hardly about just "operating" the machine. You need to know how the machine works how it can affect other machines and what can you do if parts of the machine break. So, in terms from programming analogy, you need how your runtime operates, how it can affect neighbour processes/services, and what can you do when the runtime breaks down. This still does not affect how you structure your code (…
Working with CFEngine's "DSL" v2 was very different from using Puppet mainly due to its limitations and lack of features. This really affects the way you structure your code.
There were / are many nuances in CFEngine that make it different from puppet. And this is also about availability and complexity that is what I meant.