Slashdot Mirror
How 'DevOps' Is Killing the Developer
An anonymous reader writes "Python guru Jeff Knupp writes about his frustration with the so-called 'DevOps' movement, an effort to blend development jobs with operations positions. It's an artifact of startup culture, and while it might make sense when you only have a few employees and a focus on simply getting it running rather than getting it running right, Knupp feels it has no place in bigger, more established companies. He says, 'Somewhere along the way, however, we tricked ourselves into thinking that because, at any one time, a start-up developer had to take on different roles he or she should actually be all those things at once. If such people even existed, "full-stack" developers still wouldn't be used as they should. Rather than temporarily taking on a single role for a short period of time, then transitioning into the next role, they are meant to be performing all the roles, all the time. And here's what really sucks: most good developers can almost pull this off.' Knupp adds, 'The effect of all of this is to destroy the role of "developer" and replace it with a sort of "technology utility-player". Every developer I know got into programming because they actually enjoyed doing it (at one point). You do a disservice to everyone involved when you force your brightest people to take on additional roles.'"
Python guru Jeff Knupp should go find a job where he can program, and not worry about ops. Simple solution.
"First they came for the slanderers and i said nothing."
This sysadmin/scripter/system architect/DBA role exists in virtually every company that has a core business other than IT or software development. Even in a very large multinational, there's more utility in having one "Mr Wizard" in each business unit than there is in having a room full of software developers somewhere far away from the rest of the business.
It really is a support role and it's more an outgrowth of system administration than it is saddling your brightest software guy with managing the mail server. Of course, it's possible to get stuck in that role because there's nowhere to go from there, but it's a niche that suits some people. If it doesn't suit you, then move.
It's also a distinct role from the "do everything guy" at a startup, because at a startup everyone is multitasking and as the startup expands, new people are hired to take on some of these roles. DevOps is a role in itself.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
Seen this many many times before. Cheap companies that have lots of developers and are too cheap to hire experienced admins... or an IT shop that thinks they can have the IT guys program instead of hiring proper developers. "hey, you work with computers, you guys can all do the same stuff, right?" Wrong.
While I have known developers that can sysadmin, and admins that can program... they are the exception not the rule. Quality suffers when you force people into jobs they are not qualified for. Companies know this, and they simply don't care as long as the managers think they are saving money.
I'm a good cook. I'm a fantastic eater. - Steven Brust
Full-stack developer generally refers to a developer who can code the full software stack - UI, middleware, and backend. Also lots of QA people can code - automated testing is mostly coding - and lots of developers can't test at all. Author needs a bit more real-world experience.
but hey, free project management? Sign me up!
Seriously though, I am seeing more and more companies pushing to get more productivity out of their work force in an effort to keep the stock price where they need it....
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
All those configuration management scripts and orchestration tools are insanely helpful in development and testing and it's almost a bonus that you can use them in production deployment. Aside from that, nothing will help when you have bad human management. You still need sysadmins and especially DevOps sysadmins with programming chops that can fill in the production side of the picture.
If people realized the cost of context switching on doing development, I suspect they would be much more loathe to require such context switching for Ops, and possibly not even for being a "full stack" developer.
You don't force your brightest people to take on additional roles - that is the whole point of a devops team in the first place. Making developers argue about deployments and sending builds to QA and managing your GIT server and development and QA databases and managing your bug tracker is exactly what your developers should *not* be doing, especially if those scripts necessarily have to be in a different language than your application. Sure, your lead developers and architects work with the devops team to support them so they can in turn support you, but that's as far as the relationship goes.
The way we used to do it, where every senior architect is also responsible for all of those other functions (and has to take the time from his team members below him to help build all that out), is exactly how you stop architecting your software: your leads spend so much time trying to automate the drudgery they aren't improving the app.
They aren't improving the app because all of their brainpower is no longer focused on the *customers'* problems, but rather their own and their teams. That isn't a good use of their time. Hiring smart people who need to understand the application and its environment, but are good at scripting these other languages of automation, frees up your team leads to doing what they did before and do best: focus on the application and getting the team to produce the code that serves the customers' needs.
"But remember, most lynch mobs aren't this nice." (H.Simpson)
-- Joe
There's definitely truth to what he's saying but it cuts the other direction as well. Having your lead guru developer swapping disk drives on a machine isn't the best use of his time. However, I've also seen environments where the developers can't/won't/aren't allow to do the system admin tasks and wind up waiting around or being frustrated when their development systems have a problem. Likewise, with QA - I've seen developers that will just toss any old crap over the wall and expect QA to catch all of their bugs. And, developing tests is often software engineering, often complex software engineering that needs an experienced developer to establish at least the outline of how everything works.
Personally, I expect any developers I'm working with to have at least basic sys admin abilities and know how to setup/fix any other part of the stack they might touch. Those skills should be used when working with the dev systems and in establishing the base line for production. I would then expect that someone who is more specialized in those other roles to actually setup and run production and also be available when the developers get in over their heads on system admin, hardware troubleshooting, etc. In the same way I would expect a systems admin to at least be able to write a script to automate something and not go running to the developers for everything.
For test development, I always like to set groups against each other and develop the test suite for each other's code. Most people are a lot more comfortable and eager to break someone else's code than they are their own.
I had a job where I did everything once, wrote a full-blown ERP system for hundreds of users, all by myself. Everything. Though I was salaried, sometimes I worked whole weekends, or to 2 in the morning - not because I had to, but because I wanted to. No politics, no being just a cog in a machine, no project management, no BS. Just me and code, giving people what they needed and making their jobs easier. It was my dream job, my first and best job, and I've never had anything like it since.
This DevOps movement the author speaks of... I've never seen it, not in all the years I've looked to find it again. He may complain that it's bad, bad for the industry, but I would take it in a heartbeat.
Is that what I was, a DevOp? I miss it so much I can taste it.
I am primarily a developer but I also like to understand the big picture, including software design and UX but also system administration, infrastructure, hardware architectures, and everything else that *directly affects the software I develop*.
Deep understanding of the big picture is key to developing quality software, IMO. You need to understand what comes ahead of you (requirements, business needs, etc) and where your work is headed afterwards... The best way to understand it is to wear these hats from time to time or have previous work experience in those fields. When recommending candidate for developer positions, someone who has system administration experience is a bonus.
Yes, many days I need to take on multiple hats and switch gears as shit comes up in prod and I need to fix a config on production servers or assist whoever has the hands but lack the knowledge. That's the start-up culture I guess, even though I work for an established 100+ year old company.
The point of devops is not to take jobs away from developers. The point of devops is to provide an interface between system administration and development. Development and system administration have always been at odds with each other - system administrators not really understanding or caring how the application works, and developers treating the systems as an infinite resource pool with no real rules or resources past "does my code run?"
The sole purpose of devops is to ensure efficient operation of the infrastructure in a way that allows for repeatable deployments and controlled versioning, and that also includes system software such as operating systems (sysadmins benefit too because they no longer have to do one off deployments of OSes).
This criticism strikes me as woefully underinformed as to what devops actually does, and I'm wondering if the author of this is a developer who is upset because devops is forcing them to actually use the software lifecycle properly rather than just doing cowboy deployments and hoping they work.
For linux tips: http://www.linuxtipsblog.com
The best developer is one who puts stuff together that 'ops' people (users, admins, etc.) can work with. And the best way to get such developers trained is to give them some experience on the other side of the fence. Yes, in a large organization there is going to be less crossover. But its still a good idea. Some people won't like being admins. Some will really take to it. Its up to management to properly allocate resources and keep their people trained and familiar with adjoining organizations needs.
If you absolutely don't want to do any administration tasks, that's fine. But its a rare developer who doesn't throw a fit when management takes their admin/root privileges away on their own workstation.
Have gnu, will travel.
Yeah, you put a coherent thought together and actually contributed to the discussion.
Keep that up and you'll have no street cred on Slashdot at all!
For linux tips: http://www.linuxtipsblog.com
Most developer's I've met have little interest in being Sys Admins, and even fewer of them had the background to administer a large complex site. (Not that they couldn't learn.) In a similar fashion not many Sys Admins are software engineers even if they are capable, even accomplished coders. They are different skill sets even if there is some overlap, and definitely a significant difference in emphasis. Temporary substitutes for each other at best.
much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
A problem I have run consistently around is that developers rarely understand system administration, and operations in general. It makes their software suck a lot more. This is even more true with the Java-crowd, many of which cannot even use a commandline. The more this gets fragmented, the more people get specialized, the more problems arise in architecture, design and implementation, up to and including software that cannot even be deployed because of misconceptions on the developer's side.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Well, at least someone's finally admitting what it's all about.
I essentially have this kind of role within my organization. I design, develop, deploy, and support small to mid-tier systems (e.g., the planning system for a $XXXmio/yr global department, with 300+ direct users) while being one of my own customers, as I am actually a business planner (by role) as opposed to developer. I develop systems as a way to do my "day job" much more effectively. Typical tech stack would be Excel UIs, PostgreSQL data store, and whatever else I need in the middle (e.g., nodejs, tomcat, redis, whatever).
What I've found is that, in general, doing the right thing the "right way" is not worth the cost compared to doing the right thing the "wrong way". By definition, in either scenario, the right things is getting done. What most pure developers utterly fail to understand is that in trying to do the former, there is an overwhelming tendency to do the wrong thing the right way instead.
This is because, as Fred Brooks pointed out long ago--and as the "lean startup" movement is re-discovering today--for any non-trivial novel problem you cannot know in advance what the "right thing" is until you've actually tried to implement a solution. Brooks stated this understanding as the need to throw away the first try, and the lean startup movement is essentially defined by a corollary--you have to figure out how to try cheaply enough that you can afford to throw it away and try again (and again, and again if necessary), while progressively elaborating a robust definition of what the "right thing" looks like by using those iterations as experiments to test hypotheses about what the "right thing" is. Doing things the "right way" usually costs so much in time if not capital that you simply can't afford to throw away the first try and start over, or you cannot complete enough iterations to learn enough about the problem.
Now, I'm not saying that you should be totally ignorant of software engineering best practices, design patterns, etc. What I am saying is that there is a limit to how effective you can be in reality if you live purely within the development silo. Having a "DevOps" role (granted, self-imposed in my case) has been one of the best things that's ever happened to me as far as making me a better developer, right up there with the standard oldies like writing your own recursive descent parser and compiler.
In short, it is commonly-accepted wisdom among programmers (for good reason!) that you are more effective if you actually understand the technology stack down to the bare metal or as close to it as you can manage (even if only in abstract-but-helpfully-illustrative examples like Knuth's MMIX VM), and that this understanding can only be gained via practice. It should be obvious that the same is true in the other conceptual direction through deployment and end use.
Yet another buzzword invented by some CIO/CTO somewhere in an effort to consolidate multiple job roles and eliminate warm chairs. No surprise that its genesis seems to be in the startup world.
"DevOps" is a fucked up amalgam of the developers, the DBAs, the system admins, the mail admins, the storage and backup admins, and sometimes the field techs... All to extract more work from fewer people for less money.
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
That's what I do... Just get it runnning... then later, someone can fix it... Or not... And it can run until it crashes and burns...
:)
Unless, you're doing something really important "running it right" is often overkill
The basic problem is developers are incapable and do not want to produce software that actually works and expect "lower level" people to fix their work.
.
Operations people work in a timeframe of minutes to days
Developers work in a timeframe of weeks to months
Researchers work in a timeframe of years to decades
When you take a developer, who thinks in terms of months, and task that person to think in terms of minutes and hours, you are wasting a resource.
When you make someone respond to an overly wide range of timeframe-based events, the short term events always crowd out the longer term events.
Have you ever noticed that companies locate their research divisions away from the day-to-day operations divisions? It is to keep the timeframes separate.
Exactly. Most developers are incapable of producing code that anyone would ever want to use.
In multiple companies for which I have worked, it was known who was capable of producing code that could actually be shipped and who could not. Management highly valued those who were capable of producing shippable problem free code.
In SO MANY cases, especially in big companies as the OP has alluded to, there is a huge bottleneck in communication between developer and operations - resulting in submitting tickets, waiting in queues, eventually getting operations-related work done so they can unblock their development progress. Solution? Give them the power to make changes themselves. Result? DevOps. OP is just a whiner because he doesn't like what so many demand. Great. Many companies don't even know what devops is, let alone strive to implement it - join one and shut up, nobody gives a shit if you don't like how your organisation is changing your position to one where your existing role is sent to an offsite backup warehouse to die.
Anyone else remember a day when this function was split? Back in the early days, we had Systems Analysts, kept in a separate room to the programmers.
... well, Michaelangelo was a sculptor who was asked to paint. And I have some of his sonnets, somewhere.
DevOps,,. we've seen this sort of thing before. End result is that we get less specialists, and things become harder to fix when they break. But, multi-skilled people are the way things are going. And have been since
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
Developers too often seem to think they know everything, when (esp on large teams) often they have zero idea what it takes to bring their ideas to the real world. It takes serious designers to develop a scalable app, even if lots of people think they know how. I work in production support of multiple websites, meaning I have to clean up after the mistakes developers make on a daily basis. The support folks who have to write patches for our products often grieve over the situations the original developer placed them in. It often takes a major rewrite to fix many performance issues, because the original programmer never imagined all the different situations their code would be used. Prod support is where the real issues are discovered and solved. Accept it and move on.
Read the book The Disney Way.. it doesn't matter if you are the CEO or there to paint the fence. If you see garbage, you pick it up. It's about everyone pitching in to make a company awesome. (said in a Disney Princess voice)... but seriously... Of course everything is a balance, I think the operative word is "occasional" ops.. it doesn't take much time out of dev schedule to manage a web server or VM so your product just keeps working, especially when it is a new product and the production ops are still being figured out.
The permutation of so-called devops that works best for me (and successful start-ups IMHO) is where the developers are also management(being the owner is the cherry on top), of course it only really works in a software company...
You'd be amazed at how much more accountable(function) non-devops managers are when they know then can't pass the buck the developers(threaten outsourcing, etc.). Think Bill, Woz, Sergey & Larry etc...
The problem that others are having with DevOps is that they seem to be defining it differently than you are.
It's like agile... when it became hip to be agile, some people started reading thick books about it - at which point - the point is missed :)
DevOps is possible because you can rely on hosted services, like github, travis-ci, heroku (the whole push-to-deploy movement), EC2, AWS S3, Azure table Storage, and various other vendors like CloudAMQP, Heroku hosted postgres, etc...
All of these hosted services means that there is much less administration and maintenance, plus, these services can be provisioned with the push of a button, rather than filing a bug with IT and waiting 3 months for a result.
The problem is that some people misunderstand DevOps, and miss the point just like some people did with agile development.
Also just like agile development, DevOps isn't the right tool for everything.
So, nothing new...
Devops is not killing off developers. What it is doing is combining the jobs of a traditional Release Engineer and a traditional Linux System Administrator. It's right up my alley, actually, so I am looking to move on for exactly such a position.
The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
DevOps is not a developer role. http://www.dropfolder.org/?p=6...
What I have seen when interviewing at tech startups in the bay area (and I've interviewed with a lot) is that devops roles are primarily operations roles, with an added emphasis on working with developers to get code out quickly. Simple as that. Companies still expect the devops guys to do all the sysadminy stuff, and respond to alerts and put out fires.
"Somewhere along the way, however, we tricked ourselves into thinking..."
So: when a good idea is implemented poorly, then bad things happen. Why is this news?
'DevOps' isn't killing the developer; people who are abusing developers are killing developers and using [place idea here] as an excuse. If you focus on 'DevOps', then you're going to throw out an idea and do nothing to prevent people abusing developers and using [idea n+1] as an excuse.
I worked for over a decade in embedded stuff, mostly Linux kernel development. I didn't do a smidge of database coding the whole time. It just wasn't a factor. On the other hand, I did learn assembly language for five different architectures, found locking bugs in glibc, binary-patched the running kernel for a production fix because the client didn't want to take a new release, and a bunch of other interesting stuff.
And now I'm working on a different project that uses databases heavily, so I'm picking it up as I go.
New code is not perfect on creation and developers need to be prepared to swing the axe, scrap stuff that doesn't work and start off different approaches.
However in production it's better to make very gentle changes to a unstable house of cards even if it is utter shit held together by chewing gum and string.
To work in both you need to be able to switch between mindsets because they are really very different jobs. Someone working in both is not ideal. Even if you are very good at both there is a strong temptation to make radical changes, make incremental changes an place them in production and thus limit options in development or to develop something new that incorporates the flaws of something in production. An ideal is good communication between people in both roles.
"Switching hats" can result in too many compromises and being either too conservative or too radical for the project. If you are stuck in that situation external input from testers or somewhere is vital as a sanity check.
You do a disservice to everyone involved when you force your brightest people to take on additional roles.
This sounds as if the author is saying developers are brighter than other people. Well a few may be, but when you look at most of the dumbass bugs that appear (not to mention the spelling mistakes, tortured logic, crappy coding styles, and mistaken ideas of what constitutes "good") I really can't see that being the general case.
As it is, I feel that it does developers GOOD to get them into a position where they see apps and O/S's from the other side. After all, these were developed, too. So all you're asking the developers to do is see what the results of software development looks like. Rather than allowing them to live in an ivory-tower, isolated development world and then tossing their deliverables over a wall for other people to munge into something workable. If they don't like that, then maybe the problem is with their own craft: producing bad products, than with the operational work.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
To the general public (and unfortunately, most management), people who "do computers" are presumed to be interchangeable jack-of-all-trades miracle workers.
I don't know how many times I've told bosses I don't do networking, I don't do hardware, I can't repair their laptop, and so on.
I do not fail; I succeed at finding out what does not work.
In essence DevOps is an approach to not only allow continuous integration, but go further and allow "continuous deployment". This is necessary to allow software to follow user needs more quickly. Nowadays in many large companies there is some software governed by the IT department and many small tools are ungoverned derivatives of other tools implemented by some management person in Excel. A lot of company knowledge resides in these software pieces. And companies rely on such tools. However, those tools are inherently dangerous, as you do not really know if they work properly and in all cases they are used. Nor is known what the local version actually is capable of, as there are so many different versions available.
Therefore, research wants is to get rid of the need for non IT personnel to come up with "clever" hacks and allow for fast development times. DevOps targets exactly this issue.
Would agree but I don't. Primarily, to design en develop systems well you should have a full view of all its influences across your organisation. A well designed system should intentionally consider all aspects well, against the business strategy.
Having worked for huge organisations, I must say systems are rarely designed well. Their influences across all disciplines are hardly ever fully considered. From one side I agree that one should avoid paralysis through analysis and that eventually some programming must commence. On the other hand, the badly designed systems come in large packs. As a consequence, putting stress and strain on the organisation and eventually affecting the bottom line.
A good op's input will inevitably be of great value to system designers, as the latter usually have no hands-on experience in the concepts they studied. Indeed, input from all affected disciplines is valuable. Until utopia (CMM level 5) is reached.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
In a past life, I worked for a company that developed control hardware. I loved designing hardware and software, and I could focus on it. When the time came to build prototypes and manage BOMs and shop vendors for parts and all the niggly crap that surrounds actually building something, there were people who did that.
One day, all of those people were laid off, and we engineers had to start doing all of that work ourselves. Suddenly I was spending 20% of my time doing my job, and 80% on my time doing the jobs of all of the support people who got canned.
I didn't stay too long after that, and neither did any other engineer who was good enough to get a job during a recession.
Happy workers are good workers, but proud employees are bad employees.
-1 Uncomfortable Truth
There are extraordinairly few developers that have a decent understanding of security principles, networking, or any one of a thousand things that the sysadmin does every day. The mistakes I've seen well educated developers make.
load "$",8,1
While I'd argue that any good developer should have more than a passing understanding and empathy for operations, what is being described here is not DevOps. Let's steal a definition from Wikipedia: DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) operations professionals. DevOps is a response to the interdependence of software development and IT operations. It aims to help an organization rapidly produce software products and services.
DevOps is NOT A ROLE. DevOps is a methodology concerning increased communications between development and operations. For example, DevOps tools may help coordinate software releases across environments -- e.g., helping to ensure that the same software is deployed in the same way in Dev, QA and Production, thereby avoiding potential issues created due to different configurations or dependency combinations. Going the other way, a system monitoring tool which collects information on software failures may be augmented so that IT can choose to collect more detailed information (e.g. stack traces or memory dumps) and have all of that data attached to a bug report published into the developers' bug tracking system. Analytics are a growing area of interest in DevOps, facilitating the collection and consolidation of product and feature usage, making that available in a consumable format for business analysts.
That's what DevOps is in an established organization. It's a Really Good Thing, and once you've experienced it, it's hard to work anywhere that doesn't take DevOps seriously.
Yes, it's true. This man has no dick.
One of my old companies had an actual name for those of us in that DevOps role. It was called the swat team. We were the ones called in when it absolutely had to be done yesterday. Did it suck? Sometimes, but when we said something needed done, management actually would listen instead of blowing it off.
We need *more* of these kind of positions, not less. Pure developers generally don't understand, and often don't even care, what happens to their code after it's gone through their build cycle.
There are way too many products out there, especially those in the 'enterprise' category, that are absolutely ridiculous to install, maintain, or both. They let security concerns fly out the window because having some random port open is more convenient to them, and hell with the risks. Developers should be *required* to spend time learning about and maintaining infrastructure on a regular basis so that they understand how their code impacts said infrastructure.
Yes. In some organizations developers develop the applications, sysadmins administer the systems, and a dedicated devops team figures out automating deployment of the systems configurations and the applications. This allows the people who aren't cross-disciplinary to focus on their strengths. The devops team will often do some limited development, but it's not development of the application.
DevOps builds tools to enhance system administration and application management like monitoring plugins, configuration management rules, plugin libraries for the configuration management system (like Puppet or Chef), any customizations to service startup and shutdown scripts, and templates for the service configuration files. We build middleware systems and the management and failover setup so that sysadmin can focus lower down the hardware/software spectrum and the application developers don't have to code for which database server is their primary and which is their failover at the application level.
Sysadmins are the ones on call that handle the hardware, the capacity planning, the spin-up of systems, and the troubleshooting of the OS, hardware, and system services like database or mail servers. Application developers design and implement the application. DevOps make sure the deployment and management of the service configurations, system user accounts, config files, the application, and all the supporting software required from upstream by all of those things is repeatable, centrally managed, and documented.
The phrase "technology utility player" almost perfectly describes my current role. My official job title is "Principal Software Engineer". However, I spend less than half of my time doing actual software development. I am also responsible for maintaining the Linux side of our infrastructure (it is a mixed Windows/Linux environment and IT only manages the Windows side); occasionally get pressed into service debugging low-level hardware issues in prototypes of custom boards and cables; and until fairly recently was being shipped all over the country on short notice to support product demos.
TBH I actually enjoy this kind of role, except for one aspect: I don't think management understands that everything takes longer because I am juggling so many different things. All they really see is that Project X, which was supposed to take 80 hours, takes a month or more of calendar time. Or that infrastructure issue Y goes unresolved for weeks because it isn't an emergency (yet) and never floats to the top of the priority list.
There used to be two of us "utility player" software guys here. The other one quit a few months ago, and we were not able to find a replacement with the same mix of skills. This has definitely lengthened the list of things I need to juggle.
I'm not sure that's accurate. Programming skills are pretty important today and most people, including myself, learn to code so that their current skill set (and market value) can be enhanced. It used to be that if you need an application, you'd have to buy one or hire a contractor to build one. So, this route has some problems associated with it besides cost. For example, if what you buy breaks, it's harder to fix without calling the company that made it. If you work in telecom and need a call center wallboard, you can either buy one or make one. I chose to write my own with Debian, PHP, and Apache. And it works just the way we like it, we have full documentation on how to rebuild it if needed, it's an inhouse solution that was built by "DevOps". There was a steep learning curve to develop the skill set to do this - it took a few months of hard work and learning. But it was totally worth it.
If anything, the existance of DevOps is totally natural and was born from necessity. If I were a full time programmer, would I be bothered by this trend? Maybe.
Several problems with the original article. Jeff makes the assumption that Developers are at the top of a totem pole and all others are below this developer hierarchy. This is the problem with a lot of younger developers, most who are jumping into development with no structural background in the operating system or real production operations. This premise leads developers to think they are superior to everyone, rather than focusing on building applications that must run in an operational context of being well-behaved in the environment they run, and allow for maintenance work of the operations environment. This is why you see anecdotal articles coming out that talk about the frustration and friction between developers and operations people. The truth is, most developers will be better developers if they learn a little more about how their app will work in a production environment. They will build better applications because they understand the environment better. Your architecture should be loosely coupled, that is, it should not stack up on a single server but rather be broken up into smaller components that can be built for scale across multiple machines and be able to fail over to redundant systems. Ops people will be more than happy to help get you there, but you need to think about how your app will fail as much as how it will work properly. The developer also needs to stay away from dictating specific languages -must- be used to run operations. Rather, they need to understand that operations is best suited to a polyglot of different kinds of tools and languages, using the right tools and wares for the job, not being dictated in some kind of nanny state that says you must use this language or that for operations and all others are to be thrown out. All too frequently startups get hung up on dictating operations people must use Python or Ruby or the ops dude is a total loser. This is the kind of arrogance that shows how little most developers really know about operations. Any of the more popular tools should be available to the DevOps person so they can get things done, and developers should stay away from being nannies. In classic UNIX operating environments the system administrator is/was god, followed by an allowance to use the system granted to developers, database admins, etc. Applications have always been guests inside most Linux/UNUX-based systems, even Windows treats applications for what they are, programs that run inside the operating system. This has always been the premise of modern UNIX-based and even Windows-based environments. Ops people follow this naturally, but typically run into developers that don't want to follow the rules. Ops people expect you to write a well-behaved application. Developers expect an operations environment that runs their application without getting in the way. These two goals can be easily met if both sides work together and allow each side to exploit the system, but everybody has to allow the freedom to make things work best for the goal of building better systems.
Tim
Integrator/Architect here... I travel all over the country (USA) for $CFGMGMT software company doing implementations and training in said package. Further, I do professional services engagements to implement and deploy devops workflows and integration paths for both operational and development workflows. I can say with great confidence that after reading the 150-ish comments here that I've only seen one or two commenters that come close to "getting" modern devops.
As for the RTFA implications, many people saw right through his silliness. Developer in an ivory tower thinking his world is grand and majestic and lauded above all other disciplines. I guess that explains some of the crap in Python (but I digress).
I've been in this business since before the bubble. I have done systems work dating all the way back to the 80's. At that time there were many silos with few bridges between. The first iteration of "devops" I remember seeing can be quantified as developers seeking root access. Even to this day, the answer is continually a resounding "no". Why? Are devs automatically rejected due to what specific tower they are residing in? Are they rejected because of the "separation of powers" or because of "politics"? Are ops folks just dicks with a chip on their shoulder?
I think a number of things have happened and if you'll indulge me, perhaps we can break this conversation out more to see what's going on today.
Back in the day, we had an operations team, systems team, qa team, and dev team. Loosely defined, these were the folks in the NOC monitoring everything and pushing ticket events to the right teams via triage, doing prints and getting them ready for the requestor, managing backups and access to the computer room, etc... general "operational" tasks. Day to day "operations" of the center of computing for your facility. At some point, this title got applied to anything that smacked of someone whose fingers touched anything made of metal. When this seemed to change? Late 90's-ish. I don't have specifics, but that's my recollection. Remember also that different sections of the country progress at different rates, so YMMV.
Then there was the "systems team". Different sites had different monikers for this team from "engineering" (which PEs got pissed about) to "architecture" to "Systems Admins" to... well, whatever title HR thought was appropriate and met their organizational/talent distribution goals, but the work was generally the same. Storage, systems (mid range, intel, mainframe, etc.), capacity planning, backup systems and strategies, disaster recovery, and a myriad of other specializations within systems work. This is the specific "field" of systems work that breeds organizations like SAGE/LOPSA, etc. Those in these organizations dig into the very nuts and bolts of admin as a career and a field of expertise, following current research and methodologies and bettering themselves each and every day. I would offer that while dev folks can be quite competent in various systems tasks, they're just not a sysadmin (much less an engineer or architect). They really have no place in this area REGARDLESS of their quality at it.
Many times I've heard dev get bent out of shape because "ops is being a blocker" or "we can't get anything done because ops is saying 'no'". It's unfortunate to be that myopic and that selfish. What many devs don't understand is the ops person they're dealing with is supporting sometimes as many as 10 different DEV teams operating on the exact same hosts or clusters of hosts and one or two of those environments is the pet project of VP #13 that agreed to a bunch of junk on the golf course that isn't in the statement of work, but is being offered "on the sly". They don't understand that dev #22, who has relationship with VP #11 and can essentially get what they want has forced you to introduce "whiz bang package or library 1.2.3.4" while the safe, researched, CERT recommended package is 1.2.2.2 (and, incidentally is the one all the other dev teams are u
#!/Jerald
I'm a senior mobile dev. at a ~30 person startup who's recently been asked to step into a "DevOps" role. It's being represented as a promotion, since in theory the role will involve more responsibility than my current "pure development" role. Its been pitched as a part-time thing with 30-50% of my time staying devoted to mobile development. At this particular company the DevOps role is seen as being responsible for deployment, but also the build environment and some internal productivity and monitoring tools that require some development effort but aren't part of the company's core product. We'll see how it goes.
Horrible assumption that you think developers are top-dogs, Jeff. I've seen many cases were DevOps role FAILED for competent developers because, in the cases I've seen, this is true:
* Your smartest developer may be just that when it comes to language, software architecture and platform development, but their operating system, networking, hardware infrastructure knowledge + background is not even hobby-shop at best.
* They've always had an ops or engineering crew to throw their code at, figure out how to integrate it, and NEVER had to support it.
* Ego problems thinking they are 'above' remedial automation --- which most of the time doesn't involve a real development language, just scripting.
Out of those two things alone, I've always heard the: "Well we need a sys-admin/engineer now because we are spending more time trying to manage systems, not really sure how or what to automate, and it's really taking time away from me getting back to the kind of development I, as the developer want to do." Which is the polar opposite of the two points I mentioned above.
A working DevOps group should be an amalgamation of the Dev team and Ops teams.
Trying to forge one team where everyone knows everything simply sets a level of mediocrity; you can research so far down an avenue in a given time, and get only so good at it.
I've learned from the ground up (i.e. electronics, basics of VLSI, board design, basic OS design, all layers of the stack programming), and went from there on to system admin. Then did a stint as a developer using the knowledge that I had from my earlier history, and found that the sysop area of my knowledge atrophied in the detail (and the devil is _always_ in the detail) the more I concentrated on being a better dev.
Went back to more of the operator/business side of things, and lo and behold, the more I go into systems and how to put together a proper reliable, recoverable infrastructure, the more my dev is atrophying. I'm half management these days, which means the ops side _and_ the dev side are both atrophying. The guys that do it in a dedicated fashion are more familiar with the latest tech than I am..
You can be a jack of all trades.. But I seriously hope a company doesn't rely on you to get them out of trouble when the fecal matter hits the fan.. If you've been spending most of your time developing, with the nod to tuning the servers so your app runs better, you're not likely to have been able to put the time in to develop the wider infrastructure to support things going fubar, or had the time and concentration to really work out what is likely to get you.
Having a few people marked as DevOps would be useful when you need to populate a middle ground.. They can work with both dedicated ops, and dedicated dev to ensure that scalability is baked in, and resilience is baked in to the apps. When it comes to ensuring the boxes are kept in tidy order for everyone, and get to be able to recover from the smoking ruins.. That's where the dedicated ops shine. When you really want that app to do something really slick, that's when a dedicated dev shines.
Small scale, a DevOps person would work. The larger you scale, the less appropriate it becomes (as the only solution; a big company with the techs being solely a DevOps team would scare me).
Ah yes, the articles about a popular myth. It is (has been, is, and will always be) possible to wear multiple hats and get things done right. This sounds like another FUD article written by someone with a chip on their shoulder.
I pretty quickly came to see the devops movement as a pretty blatant way for management to give a promotion to sysops, and a demotion to programmers. Beyond that, in a medium or large organization, devops runs counter to economic theory: I have a comparative advantage in writing code, which means that the organization should optimize that benefit by having me do that a lot, rather than being a mediocre admin (which I am -- I really suck at it). But there are guys who just love the operating system stuff, and have a real comparative advantage at managing systems. So they should do that as much as possible. But that's not to say that an administrator shouldn't program when needed or when they want to, and I shouldn't install stuff on systems when needed or when I want to. Barring personal interest and ambition, specialization is actually a basic economic premise, and devops taken at face value runs counter to that.
Do I get this wrong:
DevOps is a new term invented by people that don't really understand tech people to cover everything so they don't have to decide who does what and can bundle everyone with the same title and have them solve whatever tech problems might pop up?