Signs You're Doing Devops Wrong (infoworld.com) 166
snydeq writes: Misconceptions and flawed implementations may have many organizations missing the true upsides of devops, writes Adam Bertram in his article on devops practices gone wrong. "Saying that your company embraces devops and regularly practices devops techniques is popular nowadays, and it can serve as great PR for bringing in great talent to your team. But in truth, many companies — and technical recruiters — that are proclaiming their devotion to devops from the hilltops aren't really devops organizations."
Sign #8 (Score:5, Insightful)
Re: (Score:2, Insightful)
s/devops/scrum/g
Re: (Score:2)
or Kanban
Re: (Score:3)
Re: (Score:2)
> s/devops/scrum/g
Invalid sed expression. Two completely different things.
cat /lost+found/*sarcasm* | sed 's/you/whoosh/g'
Can anyone keep up all these bullshits? (Score:4, Insightful)
I am a developer, I have been a developer for a number of decades, and I run businesses which deal in the tech scene in many location worldwide
I can tell you one thing about these 'devop', 'scrum', 'agile' or whatever the new fuck-of-the-day trend they manage to come up ... PROGRAMMING IS PROGRAMMING and everything else is just addons
I have let some of my branches experiments with some of these bullshit schemes, just for experiment sake - and the result, at least to me, have yet to be impressive
Back when I started we have none of these, and yet we managed to squeeze in almost unimaginable functional stuffs within really ridiculous tiny confines (4K of RAM, 2K or ROM, for example) and today when we have almost unlimited memory space, all these bullshits that have been advertised as 'cure all' has yet to deliver
Perhaps I'm an old timer, perhaps the new hipster culture demand to have all these bullshits before they could even start doing anything, I dunno, but my feeling is, with or without these bullshit the most important factor is the PEOPLE
If you have the right folks with the right mindset, you will get great result
If what you ahve are lousy people with 'duh!' mindeset, no matter which of the new-fangled bullshit you adopt it ain't gonna give you any miracle
Re:Can anyone keep up all these bullshits? (Score:5, Insightful)
I agree. There are so many methodologies out there. I discovered a new one the other day: "kanban". If I were to sum it up myself it would amount to not throwing the baby out with the bathwater and keeping what's good when you go to redevelop a system (at least, that's the impression I got; I'm not wasting valuable hours really delving into yet another methodology).
I had a boss once whom a former colleague told me once had instructed him to "stop planning and start doing". This was because he had put in a week or two writing a Word document explaining the system and not actually writing it. We're not talking about a massive system either, just an in-house web page in ASP to handle something simple. At the time, we laughed and thought the boss was a loon, but almost 20 years later I've come to agree with him. You can actually over-plan something, and by the time you've developed it and the users have made you change it, the plan is no good.
I guess the methodology fanbois would say "agile" is the way to go, and something like it would probably be right. I'm guess I'm an agile developer these days but I don't know a thing about what the methodology actually says. I just get stuck in and "do", and occasionally, if a system is big enough and I'm wary of the users changing their minds all the time, I'll commit the important bits to paper and get them to sign off. Other times, when I know exactly what's needed and we're all on the same page, and the clients don't have that look in their eyes that says they'll be changing their minds a lot, I'll just get stuck in and write the thing without a full-on design beforehand. I find that most designs/plans/whatever are useless by the time the project's over anyway.
The best methodology is a good separation of concerns with plenty of comments. The rest is just all flash and no meaning.
Re: (Score:3, Insightful)
You can go too far in the other direction. Amount of design and planning has to be proportional to the size of the project. Sometimes, yeah, you can just jump in and write the damn thing, but other times you really do need to sit down and think things out at a certain level or you'll get half way though and realize your foundation won't support some major piece of the project.. and then the hacks start.
Also I'm a huge fan of prototypes as part of the design phase. Easiest way to identify design hickups in t
Re: (Score:2)
Not necessarily. A prototype can be a viable implementation if it is done well. Of course, only people really good at this (and hence expensive) can do that.
Re:Can anyone keep up all these bullshits? (Score:5, Insightful)
What is the correct balance between "planning" and "doing" ?
"Doing" works for people with plenty of experience, but they are rare.
"Planning" works when the project is very complex, but it is rare
The correct cursor is something between "a little planning, a little doing, and we see what we reached", which is basically agile's definition.
I'd like to share my experience: I wanted to become an agile coach (yes, shame on me !).
This was because I saw the opportunity to help people become better, but that's not really what agile became nowadays.
And I realized that Agile is not for developers, but for managers.
In other words, it's not designed to help developers, but to make money out of managers.
You have to agree that the vast majority of managers are completely clueless, so they doubt about their own skills.
Agile, or most exactly Scrum and Devops, are designed to tell them: you don't understand software development ? No problem, you'll only have to follow a basic algorithm and we promise you that all your problems will disappear.
I agree that this is quite dishonest, but hey, the goal is to squeeze money out of companies, and managers can use their budget for this !
What is funny is that most agile gurus are not decent developers.
They'll explain that such agile game will help people realize something, but they are quite clueless regarding programming.
Re: (Score:2)
I think it's a little less "wool over their eyes"-y and more about creating a process where the high level stuff managers care about is easier to track and control and giving developers space to do their thing without managers meddling too much. It creates a clear(ish) demarcation point. Managers worry about things at the sprint and maybe story level, developers make it actually happen. Once it's decided that it's happening, developers (in theory) are left alone to actually do it.
Contrast that to "pre-agile
Re: (Score:2)
What agile does for the developer is codifies "I have 2 weeks to code this specific thing, go away and let me do it".
I wanted to agree with you, but you are clearly too much obsessed by Scrum !
Frankly, this "2 weeks-sprint" is probably one of the least agile techniques.
It's like saying: we are in the Titanic, we need 10 miles to turn right. Hey, there is an iceberg in front. No, we need 10 miles, so we'll take 10 miles !
Agile is here to force managers focus on their work, and let the developers focus on their work.
Forget daily scrums, forget sprints, just do it in the agile way: as it comes.
How can I balance between plann
Re: (Score:2)
Well, in scrum specifically that's what all the rebalancing is about. You ask "does this amount of work make sense for the window we've got (2 weeks)" and if the answer is no, you add/subtract stuff as required.
I'm not saying it solves all the problems or has to be rigidly adopted to see any benefit, but I feel like it legitimately does address a lot of very common problems in software dev teams in a reasonably effective way.
Chunking stuff up into managable pieces has always been good practice for schedule
Re: (Score:2)
I maintain that this 2 weeks is completely arbitrary, and leads to unregular velocity during the session.
You'll get most work at the beginning, and the effort disappears at the end of the session.
The worst thing is that some of the nice features get cut in so many parts that we can only implement the least costly ones.
This leaves the whole features unfinished and creates a lack of satisfaction.
Perhaps it works well for new teams, but for experienced teams, this is a serious problem.
Also, an experienced mana
Re: (Score:3)
Contrast that to "pre-agile" style where managers would just poke in and out and ask about whatever random bit of functionality they happened to care about at the moment or re-prioritize stuff because someone send them an email
Um, no. pre-agile we had the Capability Maturity Model, Rational Unified Process (RUP), Adaptive Software Development (ASD), Extreme Programming (XP), and many others [wikipedia.org]. And to do any of these "properly" required spending serious amounts of money on training, consulting, auditing, and oooo... don't forget "certification". Entire mini-industries are spawned to handle each of these, for each new "process". Each of them spawn "experts" or "gurus". Some are even able to make doctoral theses out of it.
Sound fam
Re: (Score:2)
And I realized that Agile is not for developers, but for managers.
In other words, it's not designed to help developers, but to make money out of managers.
Oh, perhaps that's the version of "agile" that your managers pushed on you. Agile as specified by the original gang of four had lots of protections for developers. I can understand why most managers end up throwing all that stuff out.
* Developers are the only ones allowed to estimate the size and dependencies for each task.
* The business side is only represented by the Product Owner, and they're really only allowed to interact with developers during sprint planning and a bit during sprint retrospective.
Re: (Score:2)
I agree... I think scrum works if everyone - especially the manager, is on board. Unfortunately, the reality of the last manager I had was that he pushed us all into scrum after some conference or something... and then would get mad at us for not doing the little side-tasks (favors to other people in the company, mainly) at will because we were in the middle of a sprint.
So, I like it - in theory. It's very hard to get everyone on the same page in practice, though.
Re: (Score:2)
I agree, but as a programmer there's basic aspects that Agile, in theory, is really good at. Using the entire team to break down the project into bite-size chunks and prioritizing them (although, everybody should be doing that anyway), and I also like keeping the client involved because just about every project I've worked on ended up with the client saying "that's not what I wanted," even if they finally admit "OK, that's what I asked for, but it's not what I wanted." Catching things early on helps. I a
Re: (Score:2)
You can actually over-plan something, and by the time you've developed it and the users have made you change it, the plan is no good.
Absolutely.
And quite a few companies these days make people spend a boatload of time reporting on what they're doing rather than actually doing it.
It seems the big thing for the last ten years or so is have everyone do spend work hours doing Weekly Update Reports, Daily Metrics Summaries, Monthly Milestone Wrap Ups, etc etc etc.
And then they wonder "where did the time go" and "why stuff isn't getting done".
Re: (Score:2)
I had already implemented and documented the new variable and which properties file it went in by the time I was told I'd need it. Ditto for things that will
Re: (Score:2)
Unfortunately, how much planning you need to be able to "do" well afterwards depends on the person. I routinely see systems that are completely screwed up because of the lack of planning. They are slow, impossible to maintain, insecure and often do not even fulfill the design requirements. At the same time, they are impossible to replace because there is no specification. Having such systems is worse than having nothing.
Personally, I find that depending on project, I need between 10% and 50% of overall time
Re: (Score:2)
There are so many methodologies out there. I discovered a new one the other day: "kanban".
Sounds like Toyota's manufacturing jargon is making its way into the programming world. Toyota jargon has been popular in manufacturing since The Toyota Way [wikipedia.org] came out. Ever since then, a bunch of Japanese rooted words started flying around manufacturing plants. If they are implemented correctly, many of those techniques are useful and intuitive. However, managers usually don't implement it correctly.
Re: (Score:2)
It's an old story. Good developers on a good team will mix approaches as necessary to get the job done. Managers want to turn it into a procedure that monkeys can use to accomplish the same thing but for pennies on the dollar. It's been 50 years but they still haven't learned two important facts. Pay peanuts, get monkeys and monkeys fling poop.
Re: (Score:3, Insightful)
It depends what is meant by devops.
If it means the sysadmins and developers talk to each other and work together in a healthy relationship to deliver stable, scalable apps with heavy use of automation to cut down scut work and human error from both sides - that meet the goals of the organisation - then you're doing it right.
If it's just a synonym for badly run agile, with devs slapping together whatever to meet arbitrary goals rushed into production with insufficient testing, while sysadmins end up firefigh
Re: (Score:3)
badly run agile,
You repeat yourself ;-)
Re: (Score:2)
As far as I can tell, "devops" means "fire all that sysadmin baggage, and just pile that work on developers with no ops experience - it will be fine".
Re: (Score:2)
Or it means "my sysadmins got bored and learned Python" or "sysadmins doesn't sound as cool as devops".
Re: (Score:2)
It's a sysadmin who can code to a certain extent. Most of the sysadmins that I know are now DevOps Engineers.
DevOps is not supposed to be a job title, it was supposed to be a philosophy for Development and Operations interacting. Which meant that you'd still have Developers and still have System Administrators, they'd just integrate more closely.
Needless to say, it now functionally means a sysadmin who can do light coding (useful for software defined cloud stuff like AWS) and understands certain tools lik
Re: (Score:2)
The company I work at now just makes the developer do the ops stuff too. No, we don't bring any sysadmin experience to the job, but we're quite good at automating that ignorance. It works exactly as well as you might expect. I'm amazed at how often some team's "lessons learned" after some disaster are stuff that any mid-career sysadmin would do religiously without really needing to think about it. I'm not clear what advantage this was ever supposed to bring, but it wouldn't surprise me if we found out w
Re: (Score:2)
Having worked at a place kind of like that, I can tell you that ultimately, they considered the functions of the sysadmins and particularly security, to be "in their way", or they simply didn't understand it.
There were some smart guys who worked there, but they thought that they could automate away the job of Operations. I was impressed by some of the things they achieved with automation, but ultimately they didn't understand operating an application or security. It was probably for the best that their ap
Re: (Score:2)
Sysadmins need to be part coder these days to do their job properly with automation and flexibility; devs need to be part sysadmin so they can factor performance and stability within sane budgets into their designs.
The thing is, a (good) Sysadmin has *always* needed to be part coder. If you weren't comfortable shell scripting, you weren't being a good Sysadmin. And once you're shell scripting, and maybe doing some perl or python, it's really just a matter of syntax and project scope to go from there.
In short, it's easy to take someone with solid Sysadmin skills and experience and teach them more coding. It's a lot harder to take someone with lots of programming skills and teach them systems administration skills that
Re: (Score:2)
This, so much this. "Devops" (which should be "developers who know some sysadmin skills" and "sysadmins with some programming skills", but is usually "developer and sysadmin are the same person") and "Full-Stack Developer" (instead of "developer", you have "developer-DBA-QA-XYZanything else we can make them do") are code for "Let's hire one guy to do 2 or 5 jobs instead of hiring 2 or 5 people like we would do if we were less insane and less cheap." With devops, you get pressure from your lead dev or arch
Re: (Score:2)
I am a developer, I have been a developer for a number of decades, ...
Me too - and I agree. Well, mostly. I think these fads are really just about management trying (and failing) to catch up with what developers are. Agile is really just about trying to formalise what a sensible development team already does: talk to each other, make changes to designs when needed etc. The reason it fails is probably that in formalising the process, they try to introduce yet another one-size-fits-all concept, and developers are just not like that. A sales team perhaps, would like it - sales p
Re: (Score:2)
It doesn't really matter what you call an agile development style or if it's even documented or not (OK, it's good if there's a trail in some way so you can see what has been done or not).
What is really scary is those that tries to impose the waterfall style of development - it's something that only works if you design simple hardware items with few ways it can go wrong. On software it can cause a project to go on for years (Half-Life 3 anyone).
Re: (Score:2)
Half-Life 3, as far as I can tell, is languishing at Valve because no one wants to work on it. My understanding is that the general policy is that Valve employees work on projects that interest them, and a team has not formed that is interested in doing HL3. I do not believe it has much to do with their coding process.
While there may be some collateral they have produced for it, I don't actually believe Valve has ever actually started working on HL3, so it isn't a matter of them being behind schedule.
Oddl
Re: (Score:2)
Agree it's about people and shitty programmers are gonna be shitty regardless of process.
That said, as someone who's seen adoption of agile make a huge (mostly positive) difference, I do think changing methodologies can sometimes be a good idea... if for no other reason than it gets people into a "doing something different" mindset rather than a "business as usual" mindset.
I'll also say that software as a business has changed dramatically. It was never just about programming, but I certainly feel that the c
Re: (Score:2)
I agree that shit programmers are going to be shit programmers no matter what, but another problem is shit managers that use the methodologies of agile/scrum/kanban/whatever to further isolate themselves from accountability by blaming everything on the developers. If you're an MBA who can barely run a toaster, yet you're in charge of directing a software project of significant complexity, the shit rolls downhill until your once-good developers are now burned out husks who are indistinguishable from shit pr
Re: (Score:3)
Re: (Score:3)
Bingo, and very well said.
Add to everything you just said that programming, by and large, is a solitary sport, and a lot of this "management fad of the week" shit comes into sharp focus as nothing more than new and innovative ways to waste everyone's time by talking about what they're doing rather than actually doing it.
Re: (Score:2)
You subscribe to this methodology: http://programming-motherfucke... [programmin...fucker.com]
Re: (Score:2)
You're old. Back then only few people did programming, and those where excellent at their work because it was highly selective and you needed to be passionate. Now, programming is a mainstream job, which means that millions of people will do that as a day job without the ability nor the motivation.
It's one of the side effect of massive growth. The few interesting guys of a specific domain get surrounded by many mediocre guys that just don't give a shit. You can see that pattern in every single domain.
Puttin
The hipsters are the problem (Score:2)
You're not old or wrong. The hipsters just discovered UNIX pipes/sockets and decided that they should give them a trendy name... I shit you not, meet etcd (to be fair, it's pipes with a few extras, but nothing worthy of a name because I guarantee this has been done in the last 40 years once or twice). https://www.youtube.com/watch?... [youtube.com]
This is actually the problem I have with Design Patterns - not them in and of themselves; I don't think they needed names, but I'm okay with them having names. I came to figu
Re: (Score:2)
Indeed. These hypes live on the mistaken belief that you can get great value out of mediocre and relatively cheap people by just using the right magic development process. That does not work and never will. It is just another manifestation of the greed and stupidity so prevalent in society today.
The fascinating thing is that even the Scrum manifesto says "Individuals and interactions over processes and tools" in first place. A warning that this is only a tool and will not magically make people perform much
Re: Can anyone keep up all these bullshits? (Score:2)
Re: (Score:2)
Not so much fashion/fad in management techniques, but you still get plenty of relatively clueless managers, changing scope in the middle of the project, and the occasional fashion/fad in engineering solutions.
Re: Can anyone keep up all these bullshits? (Score:2)
And don't forget that computer folk have specific FLSA exemptions which let management disregard the kind of professional behavior that those in the other disciplines have.
Re: (Score:2)
Software covers too much ground for there to be "one true way", or even really for there to be a need for it.
What is needed is definitions for specific types of software, like mission critical health care systems or airplane software. And to some extent, that already exists. The software in an airplane is not usually going to be buggy and is probably already produced in a manner which rivals the processes that other engineers use for things like building the body of the plane or the wiring.
Re: (Score:2)
Sign you're doing it right : your site is offline 3 or 4 times a week.
Sign #9 (Score:2)
Re:Sign #10 (Score:2)
Thinking that there's a magic methodology that you can follow to the letter without realising that every product, every project and every business is different.
Re: (Score:2)
Re:Sign #9 (Score:5, Insightful)
I'm glad you asked... I could preface this with a long-winded history but I'm going to skip that (this time) for the sake of brevity (really). Well, I'm going to *try* to be articulate.
I started programming because I had a need to. I did this for quite some time along with a Comp Sci grad who was my first employee but he didn't do as much of the programming as one might think -- he had other things to do as we were really pushing the hardware further than it was meant to go. Imagine, if you will, the 1990s and, by the end of the 1990s, we were working with data sets that were nearly a TB in size and spread out over giant disk arrays.
Anyhow, the business grew. This meant that my time was severely constrained. I was putting in 20 hour days, often for weeks at a time, and sleeping in the office. This could not last and eventually I hired competent people who were skilled in the mystical art of programming. They were far more adept than myself and much quicker. They were expensive but worth it. They even went so far as to re-write the entire code base because, "Code comments go in the code, not on a coffee stained index card on your desk, asshole!" (That's pretty close to verbatim.)
Now, we didn't have a name for it and I don't know if there is a name for it. But, I tried micromanaging and I tried to keep up and to keep things directed, I really did. I tried to be involved in every commit and every push to production. I tried to understand the new complexity and the new functions when, really, all I needed to do was help them tweak algorithms and help them learn to automate data manipulation tasks. I was still putting in 20 hour days.
Then, I realized I'd hired them for a reason. I'd hired them because they were the best in their field. I hired them because they knew what they were doing and were better at it than I was (which is not a hard task, let me assure you). I paid them very good salaries and gave them great benefits because they were keeping my company afloat and enabling us to expand exponentially. Yet, I wasn't really letting them do their job to the best of their ability.
See, I learned to shut the hell up and get out of the way. Now, I suspect there's no "Shut the fuck up and listen to smart people" mode of development but I can tell you that it is quite successful. I gave them clear directions. They told me what they needed. They told me when it would be done. I gave them the tools they asked for, not the ones a vendor suggested, and shut the hell up and got out of the damned way.
In the interests of brevity, it worked. I am where I am today because of them and because of my being willing to set my ego aside and accept that I'd hired people for a reason. It was hard, this was my baby. No, seriously, it was damned hard to let go. Now, I don't know what they did internally but it looked like they took directions, planned, and then executed. The difference is, they were given what they said they needed, rewarded for their effort, and had a vested interest in success. They didn't have a leader, a supervisor, or anything like that. They had a goal, picked what they did best, and worked on it until it was done.
I don't know what you call it but, well, hire smart people and pay them well. Let them do what you hired them to do. Give them help when they need it. Give them the tools they ask for. Give them a reason to KNOW that they can screw up. Be willing to screw up and admit your errors and learn from them yourself. Treat them like adults and they'll sort out who does what and when - all on their own and without any input from you beyond giving them direction. If they can't then you hired the wrong people.
So, yeah, thanks for asking. That's what worked best for me. Try it sometime. It means letting go of your ego, it means being willing to admit you're wrong, and it means treating people like adults who deserve to be rewarded for hard effort and earn a decent living. It means being smart enough to know what you don't know and being willing to ask someone who does
Re: (Score:2)
See, I learned to shut the hell up and get out of the way. Now, I suspect there's no "Shut the fuck up and listen to smart people" mode of development but I can tell you that it is quite successful.
In my entire professional life, I've only worked with one boss like that, actually recently. He got a great product, myself and the other devs had a blast and learned a lot, and the code is some of the most maintainable, feature-complete and bug-free code that I've seen outside of popular open-source projects (where code quality matters).
I'd love to work for you.
Re: (Score:3)
I am, quite happily, retired. I sold out about eight years ago and I sometimes miss it but I'm never really unhappy with my choice. The thing is, it doesn't seem like this is a difficult thing to figure out. I mean, hell, I managed it. I'd never taken a single business course in my life. I'm a mathematician, not a manager or a business graduate. The hardest thing was letting go, emotionally, and learning to listen to smart people. I don't know everything. I can't. If I need those skills then I should get th
Re: (Score:2)
The best boss I ever worked for was an ex Israeli commando officer. When I say that to most people, they are often a little frightened. But think about it: 1) A commando officer never sends his people in without making sure everyone has a very, very clear understanding of the objective. 2) A commando officer asks what they need and gets it for them or adjusts the plan. 3) A commando officer asks if they can meet the time frame or adjusts the plan. 4) A commando officer truly cares that all his people are
Re: (Score:2)
That makes perfect sense to me. I paid for my education by way of the Marines and the GI Bill and, then, scholarships and working as much as I could. Life has been much different than what I expected when I was a child. I don't think a day passes where I don't think back and ponder the circumstances that got me here. It's easy to say that there was hard work and intelligence involved but, really, much of it just comes down to dumb luck.
Mostly, I was in the right place, at the right time, and able to take ri
Re: (Score:2)
We tried this but accounting killed it because.. (Score:2)
Janice in accounting don't give a fuck!
What's DevOps? (Score:5, Insightful)
No, I haven't read the latest InfoWorld article submitted by snydeq. But I'm pretty sure that it fails to answer the question, what exactly is DevOps?
buzzword-laden definition: just google devops and you'll find enough
best-guess definition: Development and Operations working together
low-budget definition: Development and Operations being the same person
By picking the right companies (that is to say, low-budget ones) I'm happy to say I've been doing DevOps for over a decade!
Re:What's DevOps? (Score:4, Insightful)
Re: (Score:2)
We have a few "test automation" people floating around, their managers want QA people embedded on their development teams and they only want to do it was to have programming skills as a job requirement. As a bonus it is a developer position/salary.
Re: (Score:2)
This is the correct definition of a DevOp. Developers who have to do Ops, because there are none. Therefore a developer you try to code your way out of the manual slogging that is Operations.
It seems to have evolved to mean operations automation, but generally due to a lack of operations staff.
So tools like Chef, virtualization on an outsourced infrastructure, and heavy API use are not uncommon. Success usually requires folks who have operations experience and code skills. If you do it right, you get to
Re: (Score:2)
PowerShell has been available for 9+ years.
Re: (Score:1)
For Developers: No more: "It works on my machine, It's Operations' problem now".
For SysOps: No more: "I won't automate it because then everyone can do it and I like job protection."
That DevOps-attitude has a goal: Continuous Delivery. Automate your deployments, so you can deploy at any moment. Involve your developers in the monitoring proces, so they can get involved when things go wrong in production.
Infrastructure as development (Score:2)
DevOps is treating infrastructure as development.
You wouldn't let someone write java code without version controlling it - so version control your packer.io scripts and ansible scripts for building infrastructure.
You wouldn't let someone manually compile their java code instead of using maven - so script and automate everything from your OS build, to your middleware install, to your build/deploy, to your testing.
If you're a testing freak, you can add testing in there too - have automated validation of your
Re: (Score:2)
Thanks, that simple description has explained it better than any ambiguous Wikipedia article or newsreel I've seen.
If I have had some mod points left I would have upvoted you instead of replying; this post deserves to be seen.
Devoops (Score:5, Funny)
1. You fired all your operations people and gave developers pagers.
--OR--
1. You fired all your developers and gave your operations people compilers.
Re: (Score:3)
1. You fired all your operations people and gave developers pagers.
--OR--
1. You fired all your developers and gave your operations people compilers.
Bingo. Devops means talking to each other and walking in each others shoes a little. It does NOT mean that either side is dispensable, and it's certainly not a replacement for advanced skill-sets and knowledge in either domain.
It's also not an excuse for not dealing with best practices on both sides. The fact that it compiles and you've successfully shipped a black box Docker that seems to pass the tests doesn't mean the internals have been properly designed and engineered, which means you've made fixing pr
Re: (Score:2)
Re: (Score:2)
I've been to your site before! I recognize it from mousing over the penguin images and they yelled at me. It took me a minute to figure out how the squawking was being initiated the first time I visited. Now I think I know how I got there. I assume that I followed your signature or a link you posted. I might have just been looking for penguins, I guess, but that's unlikely.
No, I have no real point but I do encourage folks to click your link and check out the penguins. I got distracted so I have no idea what
Re: (Score:2)
I got distracted so I have no idea what actually did there but, damn it, penguins!
Penguins will do that to you...
Re: (Score:2)
Hehehehe, nice!
And, after a bit of time you are wondering why both your infrastructure and your new software is getting worse and worse.
Re: (Score:2)
Devops sounds like Special Ops (Score:1)
Elite coders doing tactical shit no one else can.
The name lends itself to good marketing and make belief.
Fad clue #14 (Score:1)
"You are doing it wrong and need expensive consultants to learn to do it right."
So, it is a culture after all (Score:2)
From the article: "Above all, devops is a cultural philosophy".
Looks like it is another buzz word like Agile. Based on my experience, Agile can be "Fragile" when the team is not committed on it. Beyond that, Agile can NOT be applied to a) large projects b) projects with lot of groundwork and c) dev stack that require long compilation/building process. Most Agile/Scrum projects I worked end up falling back to a semi "Waterfall" workflow while still doing some Agile stuff (which I happily coined "ScrumFall" a
Re: (Score:2)
In my work, I'm viewing DevOps as automating the interactions between the Dev and Ops teams. For years the two sides would blame each other for everything and work to prove whatever happened was the other guys fault because they didn't want "root cause" to be assigned to them. With the few projects we have the deployment and configuration tasks completely automated, if an application isn't working then the developers have to own up. If a deployment fails the prerequisites then the ops guys can't hide the fa
Re: (Score:2)
Oh ffs. STOP conflating Scrum with Agile. Anybody that does that gets promoted to become
the overpaid secretary (project manager) play jira as an rts
The wrong way around (Score:2)
"Devops" is what you call developers if you can't afford to have dedicated operational staff.
I just don't see why anybody would actually want a single person to take on conflicting roles.
Re: (Score:2)
Where do you get the idea that DevOps equals to one person being both the developer and doing the operational support?
Because in most companies that's what the pointy haired bosses think.
Incompetent people = Chef, Puppet, CFengine... (Score:1)
From the article:
If your company bought Chef or Puppet as a cure-all for its devops needs, you're doing devops wrong.
The author hit the nail on the head here. Any company which puts in Chef or Puppet thinking this is a Silver bullet which will solve their lack of change management process and the hack-it-'till-it-works mentality is simply the wrong place for anyone with experience to work at, and the managers and the people who work there are clueless. Stay the hell away from such places, or you will regret being woken up at 02:00 in the morning because people hacked on stuff with Chef or Puppet, rather t
Are developers really attracted by buzzwords? (Score:1)
From the summary: "it can serve as great PR for bringing in great talent to your team"
Really? Do you attract good developers by saying that you practice the latest and greatest buzzword? Anyone with half a brain knows to first of all investigate what the company in question _actually does_ before signing on and secondly, I think most people realize that none of these fancy methodologies are a silver bullet for being a great place to work. You need skilled developers and a management that realizes that these
"Agile" development is a trap. (Score:1)
I'm completely convinced the real long-term purpose of the Scrum/Agile methodologies is simply to further weaken any market competition naive enough to adopt it in the first place.
Strikes me as Application Specific (Score:2)
Or at least portions of it. Most of this thread seems to be authored by A.C., so it's hard to get a discussion going...
That said: The one concept in the article about "continuously pushing code to production" sounds great, but I think it has serious limitations. Especially when coupled with the "don't be afraid to fail" concept. Perhaps for news aggregating websites or something that is fine, but you don't want to be developing safety-critical software that way.
The things that are useful, perhaps, are th
Re: (Score:2)
As with most of these things, it's a balance.
Continuous delivery on the home-grown intranet? Sure, go for it. Hell, Facebook do it on their mammoth shitfest.
Continuous delivery to car ECUs? How about continuous delivery to the engine testbed, and keep the fire extinguishers primed.
Even where you're putting a manual authorisation with specific checks and balances in place though, one that authorisation is given the rest should be automated. There's no point having thorough, extensive, durable, repeated and m
The first sign you're doing it wrong --- (Score:2)
disagree with #5 an #6 (Score:2)
Re: #6, sometimes it's right to assign blame. That doesn't mean you rake that person over the coals, but at the very least that person (and whoever has the authority to fire or promote him or her) should understand who is to blame.
Re: (Score:2)
ReRe: #5, but that would mean you have to fire _management_! Because they put somebody into a position where they were in over their head (I see that all the time...) and set them up to fail. Nothing more stupid than doing that. (Of course you need to fire the incompetent developer/tester/etc. as well.)
ReRe: #6, this one is very tricky. Finger pointing usually does not result in any clear picture and quite often the people actually responsible manage to fly under the radar. While not assigning blame is a ba
Re: (Score:2)
I've known some very good managers who explicitly state that they will not ever fire anybody for making a mistake.
Make it twice however..
Even there though, root cause analysis. Is the developer lazy, or is this just within the reasonable bounds of human limitations and best addressed through a change in process, an authorisation, an automated test, additional training?
Are Ops incompetent or making rational decisions that have bad outcomes because there are no good options available, focussing on a different
Natural result of #4 (Score:2)
Number 5 are corollaries to number 4:
At its heart, the agile methodology consists of releasing small changes as often as possible ... It is about defining what is considered "production ready," representing that with a set of automated tests, and trusting that the tests written correctly define what it means for code to be "production ready." ...
For the true devops rock stars, it's also about taking that code and sending it directly to production through continuous deployment. If your company allows developers to check in code that goes through automated pre-check-in tests, gets handed over to another set of tests to ensure that the code is ready for production, then goes live on your production servers if deemed ready automatically, then you know you've achieved devops greatness.
If your organization really believes that automated tests can find all show-stopper bugs, and that absolutely no man-in-the-loop soak testing is needed to find unexpected problems, then you are guaranteed to have these failures in ops rather than dev. At that point, you are either explicitly accept that you are treating your users/customers as alpha testers, or the blame is on whoever adopted that QA policy, not the person who introduced the bug.
What DevOps really means (Score:2)
You can have the Devs do Ops and so you don't need to hire any of those pesky Ops people. At least that is how managers see it. Saves time! Saves money! Agile! Buzzword compliant!
Basically as I read up on DevOps I found I had been using it for years. Except I called it "running a professional software development shop where everyone works together to meet goals". Of course "DevOps" looks better on a book title or as the title of a blog post.
Re: (Score:2)
Except I called it "running a professional software development shop where everyone works together to meet goals"
That'll never work! Why, if it did everybody would be doing it.
To be fair, I'd settle for people even bloody trying..
Where I work (Score:2)
But Isn't It Also True that... (Score:2)
But in truth, many companies — and technical recruiters — that are proclaiming their devotion to [ANYTHING AT ALL] from the hilltops aren't really [ANYTHING AT ALL] organizations."
Sign 1 (Score:2)
You're doing devops.
Re: (Score:2)
Re: (Score:2)
is writing a script in Bash Dev or Ops ? How about tuning an Apache server to optimize your app ?
Those are both Ops definitely. Writing a system that automatically tunes several hundred Apache servers over time as things evolve, that would be DevOps.
Re: (Score:2)
I've read the propaganda, but still I don't see how it departs from simple common sense
That would be the 'trusting automated testing enough to push potentially catastrophic updates straight to production' part. Not assigning blame to the dev's fixing the resulting mess might be a necessary concession to getting the job done, no one accepting responsibility for such a testing failure, not acceptable.
For many organisations giving the end user faster updates most of the time is a small benefit compared to the
Re: (Score:2)
I agree with most of what you said, except that organizationally from a business standpoint, unless there is a group for it, it is not being funded.
Yes, most developers have had to do DevOps at some point.
I've tuned databases, written scripts to automate environments and databases...
It really is a job in itself in any complex environment. It took me out of my comfort zone as I got into managing databases, replications, restores, virtual machines...
There is definitely a need for a develop with operations foc
Re: (Score:2)
Any good software engineer has already helped Ops through automation.
Any good Ops person has already given a developer a raft of suggestions on how the shit they handed over could be improved.
DevOps merely points out that this is actually a good thing, and seek to do it instead of being asked.
No funding required. Just do your job like a professional, not a fuckwit.