How devops is perceived
Philip J. Hollenback
thoughts:
http://www.hollenback.net/DevopsPerceptions
I'm worried devops being pigeonholed as 'puppet and chef users'.
P.
--
Philip J. Hollenback
www.hollenback.net
@philiph
Joe McDonagh
the article would spell out SCAM. Just sayin'.
--
Joe McDonagh
AIM: YoosingYoonickz Google: Joseph.E.McDonagh
IRC: joe-mac Skype: therealjoemac
Kit Plummer
Matt Ryanczak
> After the 'manage shell scripts' blowup last week I wrote down a few
> thoughts:
>
> http://www.hollenback.net/DevopsPerceptions
I suspect we (this list) have many different views of what devops is.
The shell scripts episode is one example, but there is also the
"Internet operations ISN'T a part of IT?" thread from a few weeks ago
that also hinted at a difference of opinion regarding the scope of
devops. The latter thread was generally civil and I got a lot out of it,
However, one thing I did not get was any better understanding of what
devops means to most people.
It might be useful to define devops more concisely. This wikipedia
article http://en.wikipedia.org/wiki/Devops tries to do that. Does it
succeed though?
fwiw I think the wikipedia article does an OK job, not great. The venn
diagram is probably the best part :) The article hits on better
collaboration between operations and development but reads too
development centric to me. More should be said about automation, change
and configuration management, repeatable processes, instrumentation
(monitoring) and kiss (always relevant to operations imho). I'm an
operations person though so I see it as devOPS rather than DEVops which
is probably my problem ;)
Perhaps devops means many things (gratis / libre)? devops (the
methodology) is more than chef, puppet, salt or any other tool for sure
though.
~Matt
Spike Morelli
I'm worried devops being pigeonholed as 'puppet and chef users'.
Anthony Shortland
Ernest Mueller
>On 28 Mar 2012, at 18:41, Philip J. Hollenback wrote:
>>I'm worried devops being pigeonholed as 'puppet and chef users'.
>
>sad as it is, this is an unfortunate reality or at least a very
>aspects of the movement:
Well, sure. Movements like this don't make people any smarter.
Agile. I see a lot of people implement Scrum blindly with no real
understanding of anything here: http://agilemanifesto.org/, and then
religiously defend Scrum's default implementation regardless of its
suitability to their environment. Although that's better than those
that even half ass it more and just say "we've gone to coding sprints
now, we must be agile, woot!" Of course they didn't set up any of the
guard rails, and use it as an exclude to eliminate architecture,
design, and project planning, and are confused when colossal failure results.
DevOps. "You must use chef or puppet that is DevOps now let's spend
the rest of our time fighting over which is better!" That's really
equivalent to the lowest level of sophistication there in
Agile. It's human nature, there are people that can't/don't want to
engage in higher order thought about problems, they want to grab and
go. I kinda wish we could come up with a little bit more of a
playbook, like Scrum is for Agile, where at least someone who doesn't
like to think will have a little more guidance about what a bundle of
best practices *might* look like, at least it gives hints about what
to do outside the world of yum repos.
My own personal stab at "What is DevOps"
(http://theagileadmin.com/what-is-devops/) tries to divide up
principles, methods, and practices and uses agile as the analogy to
show how you have to treat it. Understand the principles, establish
a method, choose practices. If you start by grabbing a single
practice, it might make something better - but it also might make
something worse.
Back at NI, the UNIX group established cfengine management of our Web
boxes. But they didn't want us to use it, that would be work and a
hassle. But then if we installed software that needed, say, an init
script (or really anything outside of /opt) they would freak out
because their lovely configurations were out of sync and yell at us.
Our response was of course "these servers are here to, you know, run
software, not just happily hum along in silence." Automation tools
can make things much worse, not just better.
At this week's Agile Austin DevOps SIG, we had ~30 folks doing
openspaces, and I saw some of this. "I have this problem." "You can
do that in chef or puppet!" "Really?" "Well... I mean, you could
implement it yourself... Kinda using data bags or something..." "So
when you say I can implement it in chef, you're saying that in the
same sense as 'I could implement it in Java?'" "Uh... yeah." "Thanks
kid you've been a big help."
If someone has a systems problem, and you say that the *answer* to
that problem is "chef" or "puppet," you understand neither the
problem nor the tools. It's "when you have a hammer, everything looks
like a nail - and beyond that, every part of a construction job
should be solved by nailing shit together."
We also do need to circle back up and do a better job of defining
DevOps. We backed off that early on, and as a result we have people
as notable as Adrian Cockroft saying "What's DevOps? I see a bunch
of conflicting blog posts, whatever, I'll coin my own *Ops term."
That's on us for not getting our act together. I have yet to see a
good concise DevOps definition that is unique if you remove the word
DevOps and insert something else ("DevOps helps you bring value to
software! DevOps is about delivering a service to a customer!"
s/DevOps/100 other things/.
Hmmm, that was a quality rant, maybe I'll post it on the blog.
Ernest
Christopher Little
Noah Campbell
Miles Fidelman
> > We also do need to circle back up and do a better job of defining
> DevOps.
For what it's worth, since I'm the guy who kicked off this thread by
commenting (on the lopsa-tech list, as quoted here by Philip Hollenback
) that:
"The devops list is] mostly folks who are users, developers, and fans of
chef, puppet, similar tools. A few folks have a broader sense of
operations. (Call me sensitive, but when I queried about management of
shell scripts, I got jumped on by rabid chef and puppet users.)"
I should emphasize that my comment was about my perception specifically
of this list, and not all the people on this list.
I did not, and do not mean to suggest that my impression of the broader
DevOps community is that it is all about Chef and Puppet. At least in
researching the topic, in places like the devops-toolchain list, in
presentations by folks like Alex Honor, it's always been clear to me
that there is a larger set of perspectives and approaches in the "DevOps
community" focused more on processes as well as tools for continuous
integration.
If there is a broader sense that devops is just about puppet and chef -
as several folks have suggested in this thread (e.g., in reporting
experiences in the hiring process) - that goes beyond the scope of my
specific comment and opinion.
(Note: This is completely separate from the opinions I've been forming
about the degree to which DevOps approaches address the full range of
issues faced by systems administrators, particularly those who are
operating in enterprise environments as distinct from service delivery
environments. For what it's worth, my observation is that DevOps is far
more relevant to those who involved in continuous integration of
software into service provider environments, than those who are managing
slowly changing enterprise environments. But that's me.)
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
Eric Shamow
damone...@gmail.com
John Allspaw
James Turnbull
+2. DevOps is about enabling the business to do business better, faster and cheaper. Who cares how we get there. They don't.
James
Ernest Mueller
"What is DevOps?"
"It's better faster cheaper!"
"Uhhh - OK, lots of things things claim to make
business "better". How's it different from anything else?"
"Culture!"
"So... Specifically..."
I think we all believe DevOps is a real thing
that has a distinct specific value that is
different from most existing processes. Us not
wanting to think hard enough about it to quantify it a little is just lazy.
Ernest
At 06:44 PM 4/1/2012, James Turnbull wrote:
>+2. DevOps is about enabling the business to do
>business better, faster and cheaper. Who cares how we get there. They don't.
>
>James
>On Apr 1, 2012 6:41 PM, "John Allspaw"
><<mailto:all...@gmail.com>all...@gmail.com> wrote:
>I am now erasing a reply draft for the hundredth
>time because Damon said it better than I could.
>Â The community ought to be able handle a
>non-prescriptive and context-influenced definition that is squishy.
>
>+1
>
>
>On Apr 1, 2012, at 7:03 PM,
><mailto:damone...@gmail.com>damone...@gmail.com wrote:
>
>>Maybe I'm in the minority on this… but I feel
>>like the but what is and isn't DevOps?" debate
>>is a giant red herring. Specifically, the
>>desire to define DevOps as tangible thing (e.g.
>>"add sugar, flour, water; bake for 35 minutes
>>at 425 degrees; congrats you have hot a fresh DevOps").
>>
>>In my opinion DevOps is not a thing. DevOps is
>>not an "it". DevOps is a "why". It's something
>>that we've been missing in IT for a long time,
>>a context that inspires us to rethink how we
>>need to fundamentally approach and build the
>>world around us. By definition, there can't be
>>an exact prescription as that context is going
>>to continually evolve and is going to be
>>slightly (or even dramatically) different from
>>company to company. If you get focused on the
>>"it" of DevOps you end up chasing your tail. If
>>you focus on the "why" you get to something
>>meaningful real quick and then can move on to
>>creating value and solving your actual problems.
>>
>>I've been ranting about this from a "it's not a
>>tool" angle since 2010
>>(<http://dev2ops.org/blog/2010/11/7/devops-is-not-a-technology-problem-devops-is-a-business-prob.html>DevOps
>>is not a technology problem, DevOps is a
>>business problem), so I'm not expecting to make any progress on this now. :)
>>
>>The culture of IT just values technical depth
>>and technical specialization way too much to
>>avoid having any conversation, given a long
>>enough time horizon, not end up in a technology
>>discussion or an outright tools debate. We
>>respect (both in terms of street cred and
>>paycheck size) the person that knows the most
>>about a technology we are interested in… Â and
>>just as easily tend to dismiss the value of
>>process andd organization specialists (which is
>>where the real DevOps work needs to happen).
>>
>>
>>On Apr 1, 2012, at 2:19 PM, Christopher Little wrote:
>>
>>> >Â We also do need to circle back up and do a
>>> better job of defining DevOps.
>>>
>>>Can we have a mini-get-together on this in
>>>Austin's DevOps Days. So many deep-dive the
>>>tooling -- admit it, you know who you are --
>>>without getting the importance of the larger
>>>landscape, as to defining DevOps. I mean,
>>>getting to "squishy" or not, some sort of
>>>general thing, a la CAMS, but a little
>>>crisper, that constitutes "what you could say
>>>first when you start talking about what DevOps is"
>>>
>>>Anybody who knows me knows I pop a couple of
>>>bolts when people immediately cough up the
>>>tooling hairball answering the DevOps Q . . .
>>>Â but I also understand that I'm on the far
>>>other end of most of the community
>>>(non-practitioner, came to this as an
>>>corp-manager-type from an old dev background) --Â
>>>
>>>there's got to be some middle ground we can
>>>find that the larger IT world can get,
>>>between, say, me and somebody who says "Puppet/Chef is the DevOps solution"Â
>>>
>>>(that sound was bolt heads hitting the ground)
>>>
>>>
>>>
>>>
>>>On Sat, Mar 31, 2012 at 12:38 PM, Ernest
>>>Mueller <<mailto:ernest....@gmail.com>ernest....@gmail.com> wrote:
>>>At 07:34 AM 3/31/2012, Spike Morelli wrote:
>>>On 28 Mar 2012, at 18:41, Philip J. Hollenback wrote:
>>>I'm worried devops being pigeonholed as 'puppet and chef users'.
>>>
>>>
>>>sad as it is, this is an unfortunate reality
>>>or at least a very widespread phenomenon. Â
>>>Unfortunately it feels like only a very small
>>>minority is focused on the communication and
>>>group dynamic aspects of the movement:
>>>
>>>
>>>Well, sure. Â Movements like this don't make people any smarter.
>>>
>>>Agile. Â I see a lot of people implement Scrum
>>>blindly with no real understanding of anything
>>>here:
>>><http://agilemanifesto.org/>http://agilemanifesto.org/,
>>>and then religiously defend Scrum's default
>>>implementation regardless of its suitability
>>>to their environment. Â Although that's better
>>>than those that even half ass it more and just
>>>say "we've gone to coding sprints now, we must
>>>be agile, woot!" Of course they didn't set up
>>>any of the guard rails, and use it as an
>>>exclude to eliminate architecture, design, and
>>>project planning, and are confused when colossal failure results.
>>>
>>>DevOps. Â "You must use chef or puppet that is
>>>DevOps now let's spend the rest of our time
>>>fighting over which is better!" That's really
>>>equivalent to the lowest level of
>>>sophistication there in Agile. Â It's human
>>>nature, there are people that can't/don't want
>>>to engage in higher order thought about
>>>problems, they want to grab and go. Â I kinda
>>>wish we could come up with a little bit more
>>>of a playbook, like Scrum is for Agile, where
>>>at least someone who doesn't like to think
>>>will have a little more guidance about what a
>>>bundle of best practices *might* look like, at
>>>least it gives hints about what to do outside the world of yum repos.
>>>
>>>My own personal stab at "What is DevOps"
>>>(<http://theagileadmin.com/what-is-devops/>http://theagileadmin.com/what-is-devops/)
>>>tries to divide up principles, methods, and
>>>practices and uses agile as the analogy to
>>>show how you have to treat it. Â Understand
>>>the principles, establish a method, choose
>>>practices. Â If you start by grabbing a single
>>>practice, it might make something better - but
>>>it also might make something worse.
>>>
>>>Back at NI, the UNIX group established
>>>cfengine management of our Web boxes. But they
>>>didn't want us to use it, that would be work
>>>and a hassle. But then if we installed
>>>software that needed, say, an init script (or
>>>really anything outside of /opt) they would
>>>freak out because their lovely configurations
>>>were out of sync and yell at us. Our response
>>>was of course "these servers are here to, you
>>>know, run software, not just happily hum along
>>>in silence." Automation tools can make things much worse, not just better.
>>>
>>>At this week's Agile Austin DevOps SIG, we had
>>>~30 folks doing openspaces, and I saw some of
>>>this. Â "I have this problem." Â "You can do
>>>that in chef or puppet!" "Really?" Â "Well...
>>>I mean, you could implement it yourself...
>>>Kinda using data bags or something..." "So
>>>when you say I can implement it in chef,
>>>you're saying that in the same sense as 'I
>>>could implement it in Java?'" Â "Uh... yeah."
>>>"Thanks kid you've been a big help."
>>>
>>>If someone has a systems problem, and you say
>>>that the *answer* to that problem is "chef" or
>>>"puppet," you understand neither the problem
>>>nor the tools. It's "when you have a hammer,
>>>everything looks like a nail - and beyond
>>>that, every part of a construction job should
>>>be solved by nailing shit together."
>>>
>>>We also do need to circle back up and do a
>>>better job of defining DevOps. Â We backed off
>>>that early on, and as a result we have people
>>>as notable as Adrian Cockroft saying "What's
>>>DevOps? Â I see a bunch of conflicting blog
>>>posts, whatever, I'll coin my own *Ops term."
>>>That's on us for not getting our act together.
>>>I have yet to see a good concise DevOps
>>>definition that is unique if you remove the
>>>word DevOps and insert something else ("DevOps
>>>helps you bring value to software! Â DevOps is
James Turnbull
No its not. That's called a summary (and I am on my phone so its a brief summary). I can draw lines between each of those summary statements and real action teams can take both culturally and with tools to achieve that summary state.
For example, faster deployments == faster speed to market. Faster deployments come from ...
James
Eh, I completely disagree. That's fuzzy across the line to BS.
"What is DevOps?"
"It's better faster cheaper!"
"Uhhh - OK, lots of things things claim to make business "better". How's it different from anything else?"
"Culture!"
"So... Specifically..."
I think we all believe DevOps is a real thing that has a distinct specific value that is different from most existing processes. Us not wanting to think hard enough about it to quantify it a little is just lazy.
Ernest
At 06:44 PM 4/1/2012, James Turnbull wrote:
+2. DevOps is about enabling the business to do business better, faster and cheaper. Who cares how we get there. They don't.
James
James Turnbull
And to be clear, the "who cares how we get there" is about tool selection. I don't care what tools you select or not as long as they achieve the right outcomes.
James
Eh, I completely disagree. That's fuzzy across the line to BS.
"What is DevOps?"
"It's better faster cheaper!"
"Uhhh - OK, lots of things things claim to make business "better". How's it different from anything else?"
"Culture!"
"So... Specifically..."
I think we all believe DevOps is a real thing that has a distinct specific value that is different from most existing processes. Us not wanting to think hard enough about it to quantify it a little is just lazy.
Ernest
At 06:44 PM 4/1/2012, James Turnbull wrote:
+2. DevOps is about enabling the business to do business better, faster and cheaper. Who cares how we get there. They don't.
James
Matt Ryanczak
> Eh, I completely disagree. That's fuzzy across the line to BS.
I agree with your disagree :) As a community we should be able to come
up with some sort of definition that is suitable for text books,
wikipedia and other forms of documentation. Even if that something is
somewhat vague. How else do the initiated learn what devops is? Perhaps
its more of a mission statement than a definition?
"Devops is an evolving methodology for realizing business goals through
operational best practices and tight integration between software
engineering, quality assurance, technical operations and other business
units."
Just to get the fire started...
~Matt
Charles Henrich
Definitely agree here. I've seen far far too much focus on tool x or process y as magic bullets instead of focusing holistically on all the tools and processes that for your organization will improve the business. For me modern day operations (call it whatever you want) is about enabling the business to get from idea to use with limited friction. It's up to the teams to decide what the appropriate levers are to do that in their context. It may be tooling, processes, automation or none of the above and still be the right answer.
There is no spoon.
-Crh
(apologies for being terse, sent from an iPhone)
Paul Graydon
I know that it would fall inside possibly a few of those categories, but
I think it's probably worth specifically mentioning Security. It
frequently seems to be ever the bridesmaid and never the bride, but it's
something that should permeate everything. We keep seeing companies
failing and disasters occurring because it isn't. It gets shunted in to
'other business units' at best, an afterthought rather than
forethought. Proof in case the fun over that ruby on rails 'bug' &
github the other week.
Paul
John Allspaw
I might say that to reach for specificity in the term, there be dragons and a frustrating result, maybe 140 characters at a time.
Continuous deployment may help one org realize business gain, and not another. Giving devs root may help further one org realize business gain, but maybe not others. Same with Chef. Same with A/B testing. Same with embedding developers in operations. Or vice versa. And so forth.
What matters is the extent that different domain expertises are given the charter and culture to amplify and compliment each other's abilities and perspectives, as a means to further the business. Everything else is implementation details that can and will change.
I'm not bold enough to assert that devs without root, waterfall dev cycles, or Netsaint and Sybase on AIX can't achieve a devops environment.
I realize this isn't an easy thing to describe, but I simply can't point to a specific tool, org structure, title, methodology, or process that is a recipe to make such an environment.
I feel confident that I can tell the difference between a "programmer" and an "engineer" without employing specific criteria, and I feel the same way about devops. I personally don't use the term, instead I opt to say "developer and operations cooperation, collaboration, and coordination". If the sentence feels weird with that substitution, I then think that the intention didn't match my expectation.
Instead of a specific "what" definition, instead let me suggest that we as practitioners can offer stories of our success and failure, including implementation details, in support of attempting to build such an environment as I described, and take it from there, with an open mind.
We can't 'git pull devops' no matter how hard we (or others) want to.
(from my iphone)
Eric Shamow
I feel confident that I can tell the difference between a "programmer" and an "engineer" without employing specific criteria, and I feel the same way about devops. I personally don't use the term, instead I opt to say "developer and operations cooperation, collaboration, and coordination". If the sentence feels weird with that substitution, I then think that the intention didn't match my expectation.Instead of a specific "what" definition, instead let me suggest that we as practitioners can offer stories of our success and failure, including implementation details, in support of attempting to build such an environment as I described, and take it from there, with an open mind.We can't 'git pull devops' no matter how hard we (or others) want to.
- Cooperating with other teams in the IT organization to achieve the goals set out by the larger organization as a whole
- Transparency and data sharing both within and between groups
- An emphasis on collaborative, multidisciplinary problem-solving over finger-pointing
- Using the same toolsets across different parts of the organization, mainly in the attempt to achieve the above.
- An individual toolset or set of toolsets
- A job description for a developer who is good at operations, or vice versa
- Agile with scrum taken out and replaced with something else (kanban, etc)
Miles Fidelman
> For what it's worth, and as someone that joined in the pile-on - it
> would be a lot more helpful if you posted conciliatory observations
> about DevOps to the LOPSA list, where most of the actual damage was done.
Absolutely not. What I said on the lopsa list was:
>/ Anyway, when I asked for tool suggestions on one of the devops lists, where I
/>/ kind of figured was the place to ask about tools, about all I got were
/>/ religious pontifications about puppet or chef being the "one true way" -
/>/ which seems a bit out of line with my experience of real-world operations,
/>/ both in the small, and in the large (been around both, though more as an
/>/ architect for large systems than as an operator).
/>/
And later, when I posted a summary of information I was collecting, that included this statement:
/>/ A couple of folks on the devops list pointed me at this:
/>/ https://bdsm.beginrescueend.com/modules/shell
(thank you, by the way)
Someone asked, rather briefly:
> The devops list?
I replied:
> http://groups.google.com/group/devops
> and
> http://groups.google.com/group/devops-toolchain
>
> Mostly folks who are users, developers, and fans of chef, puppet,
> similar tools. A few folks have a broader sense of operations. (Call
> me sensitive, but when I queried about management of shell scripts, I
> got jumped on by rapid chef and puppet users.)
>
And I stick by that characterization of the opinion I formed based on the responses
that I received to what I thought was a perfectly reasonable question.
Miles Fidelman
/
Ricardo Pascal
the IT organization to achieve the goals set out by the larger
organization as a whole"
The idea of "An emphasis on collaborative, multidisciplinary
problem-solving over finger-pointing" sounds a little more like to be
a DevOps to me.
But the other concepts like:
* Produce more metrics
* more automation
* with or without chef
* improve deployment process
All of this always existed as Sysadmin duty, in more or less scale at
different companies.
I have the impression that the Dev in DevOps, should reflect (or at
last was supposed to) someone from Ops, doing a little of Dev.
Like searching at code for possible bottlenecks that some function may
cause on the database server. Then test, fix, and tunne it (both the
code and the server). A DevOps should be writing code with developers,
choosing frameworks, libs, drivers
When people talk about DevOps like producing more concise "cookbooks"
for chef/puppet/salt I got a image of a pig with lipstick. Cause
that's what Ruby/DSL look's like for a regular Op who usually does
stuff with shell script.
--
Ricardo Pascal - Sysadmin and Developer
Twitter/Skype: voorloop
Eric Shamow
But the other concepts like:* Produce more metrics* more automation* with or without chef* improve deployment processAll of this always existed as Sysadmin duty, in more or less scale atdifferent companies.
I have the impression that the Dev in DevOps, should reflect (or atlast was supposed to) someone from Ops, doing a little of Dev.Like searching at code for possible bottlenecks that some function maycause on the database server. Then test, fix, and tunne it (both thecode and the server). A DevOps should be writing code with developers,choosing frameworks, libs, drivers
Ramin K
After the 'manage shell scripts' blowup last week I wrote down a few
thoughts:http://www.hollenback.net/DevopsPerceptions
I'm worried devops being pigeonholed as 'puppet and chef users'.
What if the question had been about building a framework around a bash http server that supports logging, easy to use config files, multithread/child procs, modules, etc? Just use Apache seems like a pretty good answer, doesn't it? Hell the question put in this light appears downright insane. Apache vs node, tornado or something in that vein is more complicated. However the first set of questions are going to center around "do you have needs that $x general httpd server can't meet that more specialized solution $y can? Otherwise use $x."
I propose that the reason "Puppet, Chef, cfengine3, pick one" is thrown out so often is not because we care about the toolset, it's because we *don't* care... as long as it meets a minimum set of capabilities (see Apache, Nginx, IIS pick one). As someone above pointed out if we'd had this conversation ten years ago a different set of tools would be tripping off tongues because those were the minimum set of capabilities at the time. Further most of the us have internalized this logic which means we just throw out the conclusion rather than review the steps that got us here. Fixing that may be worthwhile, rehashing the conclusion I'm not so sure about.
Ramin
damone...@gmail.com
Gildas
Le 2 avr. 2012 08:02, <damone...@gmail.com> a écrit :
> I'm not sure how it will be received, but I'm seriously considering lobbying hard for DevOps Days Mountain View to have no tools talks or panels. People can obviously do what they want in the open space portion of the event… but there are so many great topics (complete with history and academic rigor to boot) to explore without having the 10th retread of a tools panel or another tool talk that you can already find on youtube.
>
No worries, I'll happily second that motion (although I think the time slot during open space for tools-oriented ignite talks worked ok last year).
Gildas
Rob
them from the heavyweights in the field. Back to the original concern
of 'DevOps being pigeonholed' I'd agree with that statement. My
experience has led me to be an extremely pragmatic person, you do what
needs to be done, using the best tools available to you, as
responsibly as you can. Sometimes your tool chain may look like shell
scripts, duct tape and a drinking bird. Other times it may look like
ruby, bamboo, jenkins and chef. I'd like to think that the industry
is relying on this emerging segment of specialized generalists that
can bridge the gap between any and all groups to solve real problems.
Typically the problems we face aren't related to features that
endusers enjoy but are directly responsible for allowing that
enjoyment to occur in the first place. I don't think we can ignore
that people from all disciplines can contribute to DevOps, Development
- Operations collaboration, or what I once heard called 'Doing the
right thing'. I speak from experience, my team is comprised of a
business major, two engineers, a computer scientist and a stellar
sysAdmin. It's our collective thinking and approach that makes us
essential to our organization regardless whether it's Dev, QA, Sales,
IT, or even the exec (who loves metrics) who engages us. It's never
about the tools, they are just a means of accomplishing what we've
been asked to do, or what we'd like to do in our commitment to making
the business better and stronger.
So, I'm sad to see DevOps and Chef/Puppet becoming tightly coupled.
What we can and do contribute is much more than the knowledge of some
specific tools.
Rob
On Apr 2, 1:25 am, Gildas <3ntr0...@gmail.com> wrote:
> Le 2 avr. 2012 08:02, <damonedwa...@gmail.com> a écrit :> I'm not sure how it will be received, but I'm seriously considering
Spike Morelli
I found it quite illuminating to search job postings for the term "devops" on Dice (http://bit.ly/H31bmD - 106 hits) and Monster (http://mnstr.me/Hx1KHe - 66) - also I was told by our Dice sales rep (don't you love them!) that there are more than 80 resumes that contain that keyword. Anyone got broader data on that? We want to know where best to put our recruiting money.
It's a credit to the members of this list that the term has gained such wide coinage, and is still gaining momentum. Makes it a whole lot easier when you talk to contract companies and recruiters and they know what you mean!
That said, it's certainly not clear from scanning these postings that "devops" equates to "Puppet or Chef". In fact you can see calls for a wide-range of skills applicable to service delivery automation in general - both build and deployment and both application and infrastructure provisioning ... that's certainly what we're looking for in a "devops engineer" even if they do specialize in certain tools.
Any help and pointers on how and where to triangulate individuals like that? What works for you?
Mary Carello
Question about part of your post: is the crux of the issue that
recruiters you have come across do not fully understand devops or that
they contact about the wrong type of positions (non-devops when you
want devops)?
>I think the job sites are the last place where to put money, but I have a pretty radical position about recruiting. I strongly believe the recruiting industry, at least for tech, is in dire need of reformation (very much like other aspects of engineering, devops being a champion example of that reformation)
of that reformation you mention above. Agree about the job sites.
>about recruiting strategies, it's an argument dear to me, but off topic for this list I think.
Cheers,
M
Spike Morelli
Question about part of your post: is the crux of the issue that
recruiters you have come across do not fully understand devops or that
they contact about the wrong type of positions (non-devops when you
want devops)?
I think the job sites are the last place where to put money, but I have a pretty radical position about recruiting. I strongly believe the recruiting industry, at least for tech, is in dire need of reformation (very much like other aspects of engineering, devops being a champion example of that reformation)
Am interested in the example of how devops might be a champion example
of that reformation you mention above. Agree about the job sites.
about recruiting strategies, it's an argument dear to me, but off topic for this list I think.
We could start another discussion... or rant ;)