As an Ops person I think containerization/Docker is the best thing that happen since sliced bread. With nifty containers that the Dev's are responsible for putting together we move some of the Ops responsibility from us to THEM. We know who to point the finger and blame then a fuck up happens. ;-)
DevOps: The spotty faced yoof waiting to blossom
DevOps is a concept that we've all started coming across more and more in the last few months. Critically it's taken a bit of a leap just lately because people have started to: (a) define it formally and (b) actually agree to a decent extent on what the definition is. So, for what its worth, Wikipedia talks of DevOps as: “A …
COMMENTS
-
-
Thursday 7th July 2016 08:50 GMT kmac499
As an DEV person I think containerization/Docker is the best thing that happen since sliced bread. With nifty containers that the OPS are responsible for JUST HOSTING we REmove some of the Ops INTERFERENCE. We know who to point the finger and blame when a fuck up happens. ;-)
Because at long last the old cry of well it worked on my machine is easier to prove.
All true but does tend to go against the spirit of DevOps or as we greybeards called it; good ole' fashioned all working for the same team approach.
On a slightly different note I have heard of some financial institutions having a complete change freeze until they figure out wht the hell The Brexit vote means for them..
-
-
Thursday 7th July 2016 08:53 GMT fruitoftheloon
Which is usually called...
Teamwork, or even better! Talking to and listening to each other, across team boundaries.
I mean cluck a duck, people talking about what they need to do, how to do it and working out potential problems in advance? Which could lead to better outcomes, WOW!!!
Jeez that's an awesome concept.....
/rant
-
Thursday 7th July 2016 09:45 GMT Anonymous Coward
Re: Which is usually called...
Unfortunately your cynical, albeit completely correct view doesn't sell tickets to seminars or pay "journalists" to write crap pie in the sky articles about stuff that the rest of us have been doing for decades long careers in IT.
Whoever wrote the Wiki entry for DevOps is clueless about the real world of IT.
-
Thursday 7th July 2016 11:00 GMT fruitoftheloon
@AC: Re: Which is usually called...
Dear AC,
Actually it isn't cynical at all! A little while ago I used help 'fix' troubled £xxxm programmes, funnily enough I have never encountered a cattle-tracked programme that needed to change to the latest whizz-bang methodology.
But I did encounter quite a few where:
- the client didn't know what they needed/wanted (which rarely actually matched)
- the sales numpties' primary focus was their commision, as opposed to selling something that would be viable/functional/add some value
- senior Directors/programme managers who would have 0% probability getting hired for the job they held if they were an 'outsider', due to them being f'ing idiots
- for some inexplicable reason, the client thought that hiring consultants/outsourcers to fix what was actually a cultural (not technical) issue would dramatically improve their organisations over a year or so....
Cheers!
Jay
-
-
-
Thursday 7th July 2016 08:58 GMT Anonymous Coward
Do I detect a little common sense at last? I've read enough about Devops and been continually frustrated by much of it. The focus of anything in IT must be the business case, this means proper costing and evaluation of the benefits. Unfortunately this can be difficult and often IT offloads this responsibility to the business managers and then whines about it afterwards.
In my experience, cost everything, down to the number of paper clips needed. Where you can only estimate, do so and say so. Detail everything, send it to the business with caveats, if they sign off then it is down to them.
If they cut support or training or resource and it all turns into a giant mess then you have your piece of paper witch says "I told you so".
-
Thursday 7th July 2016 09:50 GMT OzBob
Devops is not about Development personnel!
its about Development processes (building updates into versions and releases, and deploying them). I am fighting a semantic battle with senior manglement at a customer site on this, and pointing out that Operations is also the process. I have been a Developer for my sins, and know how badly this will end if they are the sole driver of this.
And the automation is used for deployment of the versions and releases, to allow both the conventional and Agile methodology to be relatively painless.
-
Thursday 7th July 2016 10:49 GMT Peter Gathercole
Automation
The automation part of the Wikipedia article is there to suggest that in order to be able to do rapid development and deployment (which is really an agile concept, not necessarily a DevOps one), it is necessary to be able to do rapid and consistent regression and functional testing and deployment with minimal effort.
Unfortunately, automated regression and acceptance testing is good at finding the problems you've seen before. It's not so good at finding new problems. That requires time and rigor in the testing processes.
So, by reducing the testing effort to enable rapid deployment of new code, you're actually exposing yourself to unexpected problems closer to the live environment. To my mind, this is the single biggest issue with agile development, and by extension DevOps. IMHO, large organizations that have a critical reliance on their IT systems will remain with their traditional testing regimes, which will make DevOps difficult to integrate into their working practices. It's a Risk thing.
It's interesting that in several organizations I've worked at over the 35+ years I've been working in IT, Operations team members have been present during all phases of projects, and on the distribution and approval lists of the change processes, so communication isn't a new thing. It just seems to have dropped out of favor a bit in recent decades as IT has become more silo'd.
-
Thursday 7th July 2016 11:00 GMT EC
OK so one thing that's always missing with this is doing DevOps across company boundaries. Whilst internal or cloud based software is great, some of us still ship installers and scripts to clients who install on their servers; and no doubt some of you receive and deal with our .msi and .sql deliveries . Does anyone have experience of DevOps with a product?
-
Tuesday 12th July 2016 08:18 GMT Lusty
@EC yes, the idea is that you move to a SaaS model and stop sending software. You can either do this in the cloud (easy) or on prem by pushing to your VMs on their platform. The MSI and sql deploy is quite old fashioned and will be a chain around your neck, especially if an agile startup does SaaS to replace you!
-
-
-
-
Friday 8th July 2016 06:57 GMT Anonymous Coward
Re: Limited sample volume..
I was on a Microsoft day recently and they titled it
Application Lifecycle Management and DevOps with Visual Studio
and the day was very useful on the new ALM stuff in Visula Studio. I went along for that, but was hoping as a side benefit to get some non-bs clarity on exactly what DevOps was.
On the day DevOps was mentioned precisely once, in the introduction.
So basically, like all the DevOps noise on El Reg, it was just there as a buzzword to hook people in.
-
-
Thursday 7th July 2016 14:57 GMT Erik4872
So much is coming together all at once...
DevOps is smack in the middle of a bunch of huge changes happening in corporate IT. One of the biggest problems is that so many "new" things are all coming out at the same time. Public cloud replacing onsite systems, new cloud-enabled applications replacing traditional client/server applications, automation tools allowing fewer sysadmins managing more servers, microservices, containers -- and it's all happening at the same time. Now, like the article states, this new world needs more flexible IT staff which is what DevOps proposes to solve.
The problem is that DevOps is like Agile, a good idea on paper that is often horribly misapplied. DevOps can migrate to NoOps very quickly in a startup-style environment, especially with all the pushbutton deployment tools being developed. Same way an Agile project can morph from "fast feature driven development" to "no architecture, make up the design as we go."
Is DevOps a mindset, a magic dashboard sold to PHBs, or a religion peddled by DevOps consultants? Right now it's all of them -- I'm hoping it shakes out into a sane blend of these.
-
Thursday 7th July 2016 21:04 GMT John 104
Okay, all well and good. But is it actually a proper thing or is it just a relatively young term that inept managers throw about without either understanding it or meaning it?
FTFY
Well, first of all I'll start by saying that I don't really like the second half of Wikipedia's definition: I fail to see what specific relationship DevOps has with automation. I do, however, get a warm feeling from the fact that both these definitions (which happened to be the first two I picked at random) both include the words communication and collaboration. So perhaps there's something in the concept
You must be lucky. What most people think of Dev Ops is Agile process coupled with the latest version of Chef or Puppet, with the goal of automating the operations team out of the picture so that the latest version can be shipped. There, we met our goal. Don't know what Operations problem is...
-
Friday 8th July 2016 16:05 GMT wheelybird
The article explains what DevOps ought to be
but the reality is that DevOps has been confused with CI/CD by almost all agencies/employers now.
I'm currently looking for a contract - my expertise is Linux infrastructure/operations. Those contracts don't exist any more. Go to a job site of your choice now and search using the keyword 'Linux'. A year or more ago that would have given you mixed results; Linux support, Linux Admin, Operations, Engineers etc.
These days over 90% of the results are 'DevOps Engineer'.
Look at the spec for a DevOps engineer and it'll vary, but it's typically Puppet/Chef/Ansible, Python/Ruby, AWS, Jenkins/Travis etc. The role is generally "Manage the CI/CD toolset, package up the software for deployment, write the deployment scripts, do the deployments."
So DevOps is actually "that bit where dev and ops overlap which no-one else wants to do."
The issue with this is that it doesn't solve the problems that the real DevOps aims to solve. Instead of separate dev and ops silos, you now have dev, ops and devops silos.
The "DevOps" roles also put a lot of emphasis on the candidate being able code (and that's code, not script), so evidently this favours developers that, for reasons either good or bad, have moved from their development career into DevOps. They'll tend not to have (and the employers aren't looking for) deep or broad experience in ops, and therefore won't be aware of the niceties of how to properly apply the stuff they're doing in dev environments to production.
Oh, and for extra hoots, in the past week I've also come across adverts for TechOps, WebOps and NetOps. The future's looking bright!