You can't DevOps everything, kids. Off the shelf kit especially

Hey, psst. Come over here, I have a secret to tell you. My fellow DevOps hoodwinkers would cement-shoe me for saying so, but you don't always need to do the DevOps. In fact, in many cases, it's likely a waste of effort. Let's start walking this way, briskly, now – I think I see some pink and chromatic blue fade-tipped Thought …

[Anonymous Coward]

Insert buzzword here

Despite what the "gurus" tell you regarding the current "hot" software development methodology or process, there is inherently no silver bulllet.

"Every silver lining has a cloud" and "no good deed goes unpunished".

[yoganmahew]

Re: Insert buzzword here

Indeed. Agile for legacy is a disaster. I haven't worked on updates to modern systems, but I suspect I could broaden it to "agile for an existing system is a disaster". It'll help you push something out the door, but modifying and adding new features to an existing system by agile is going to shorten its life and yours.

[Anonymous Coward]

I'd counterpoint with the idea that there's no such thing as genuine COTS. The boring, pedestrian, essential stuff like ERP, CRM, even foundational stuff like your AD is certainly bought fully functional off the shelf, but we all know the bulk of the cost and the effort is implementing your business logic and your rules and your quirks over the top of it. That's the area where an agile approach yields benefit; responding to change with a lower cycle time actually makes more sense there than almost anywhere else in your business.

[Steve Button]

COTS still needs to be installed and configured.

And to do that install manually could take a long time, and be error prone.

Take something like Documentum which can take around 1 week to install by following a massive Word document which tells you all the step-by-step instructions. Very easy to get wrong and very difficult to automate. You would be much better off choosing a package which can be automatically installed and configured with Chef, Puppet or Ansible. This is still DevOps.

You can forget about Continuous Integration for the COTS aspect, but if you are then further customizing you'll likely need that too.

As for Agile, I think you are conflating two different things here.

In the above scenario it would still make more sense to develop your Config Management scripts using scrum and in sprints, delivering a working solution at the end of each sprint.

Now, when it comes to SaaS your argument probably does make more sense. You aren't going to "do the DevOps" if you are using standard Salesforce.

[Cederic]

Re: COTS still needs to be installed and configured.

Does anybody use the 'standard' Salesforce though?

Salesforce is less a SaaS and seems in many ways far closer to PaaS (Platform...) - and that's before you even start mucking about with force.com and Heroku.

Certainly we don't seem to be able to do anything on Salesforce without needing a raft of developers involved. Even if all they're doing is config, that still goes through dev/test/prod, still needs testing, benefits from automation and should really be recreatable on the fly if you want a new environment setting up. Then there's all the network interconnect, data quality and governance, security overlays, integration...

Similar experiences with ServiceNow too; this SaaS malarkey can be jolly excellent, but that doesn't preclude a DevOps style approach by any means.

[Jason Bloomberg]

DevOps means DevOps

Think DevOps is great? We have a service for that. Our experienced DevOps gurus will tell you exactly why DevOps is great and how to leverage Devops to your advantage. All for a small fee.

Think DevOps is crap? We have a service for that. Our experienced DevOps gurus will tell you exactly why DevOps is not all it's cracked up to be and how you can avoid the pitfalls of DevOps. All for a small fee.

Remember; DevOps. It's win-win all the way to the bank.

[Mark 110]

Re: DevOps means DevOps

I did a DevOps course from the Dev Ops Foundation last week. Just to check I was as up-to-speed as I thought I was. One of the key things highlighted on the course was that a DevOps approach isn't always appropriate and organisations should think about when its appropriate or not.

A 'bi-modal' approach was pretty much recommended.

[Anonymous Coward]

I can't help smiling at all the buzzword and hype used to try and push software sales, DevOps is no different.

We have a couple of engineering manufacturing companies that had a major software update in 1996 and all we have done since then is replace the computer hardware ans cables as they succumb to the environments.

The machine tools have an estimated 50 years life before they need to consider replacements. The software driving those tools will last that long.

There is no need to change that software just for the sake of change, in fact doing so could be counter productive. The only real change in the office is that they have moved to laser printers and we designed new invoices for them.

[Erik4872]

A good idea plagued by buzzword mentality

The higher-ups in our organization are very buzzword driven, and I imagine they collect a lot of free meals, golf trips and other...amenities...from the DevOps consultants. Just like Agile a few years ago, we've been told that we're now "all in" on DevOps.

What will happen in our case is that we'll take the parts of it that make sense and use it in the real world work we do. We'll even take the single-pane-of-glass magic tools the DevOps company of the month sold them and give a half-hearted effort to integrate them. I think that's the key -- if you let your consultants run the show you're going to get an ITIL-style monstrosity that takes more work to care and feed than the actual work you're doing.

We have a lot of "boring, legacy old school" stuff from 2005 (if you can believe it.) We also have a lot of new cool shiny microservicey stuff. Knowing where to apply DevOps techniques, which ones are appropriate for your world, and what to skip is the key to keep DevOps concepts (which for the most part are really good ideas) from being another shelfware that gets abandoned when the next buzzword comes to town.

[Anonymous Coward]

COTS can be a very good solution for many problems. However, COTS solutions also need to be periodically updated and configured and installed.

With all the gradations of DEVOPS I do not think it is easy to give one verdict about them.

[foxyshadis]

This is unnecessarily harsh

I'm pretty sure DevOps still includes the Ops part, and while a lot of "DevOps" kiddies I've met are basically hotshot programmers who've learned a couple of tricks about deploying and debugging the OS and slap the hot title du jour on themselves, there will always be room for operators who intimately know their software and hardware, even if they didn't develop it themselves. A big part of the value proposition of DevOps is that we can be fairly seamlessly pulled off of a development project to manage an operations project.

With any luck, we can leverage their development background to make something better than the usual Perl monstrosities that function as glue code. At its best, it's not just that we fuse the roles, it's that we can step into whatever role we're needed in and do better.

On the other hand, consultants are consultants, and any buzzword you hear is no better than any other buzzword. Any business hoodwinked by that deserves their fate.

Honestly, if a business wants to grab an ERP and try to shoehorn it in on the cheap, more power to them. When they need to go beyond the basic COTS customization capabilities, hopefully they'll call or hire someone capable.

[Anonymous Coward]

The only thing I have got out of DevOps, when distilling the buzzword bingo is....

It's a good idea to have your Devs and Ops collaborate over the lifetime of a piece of software..

That's probably where this started, and all it was meant to be, then some people decided, let make this a thing..

Why does the modern world have to turn a small sensible idea into a weird worldwide cult? It's not just DevOps, it's anything in the modern world, oh my god, this is the nest big thing you must be doing...

It's a marketing wet dream living in this new world and I hate it..

[Lotaresco]

Same old, same very old

"It's a good idea to have your Devs and Ops collaborate over the lifetime of a piece of software.."

I started my career in the pharmaceutical industry, in the 1970s. Big Pharma has always been a consumer of Big IT and spends a lot on IT projects. In the 1980s it became obvious to us that something was badly broken because no matter whether we talked about R&D in the sense of "new product" or D in terms of "new/improved IT systems" often what was delivered to operations wasn't fit for purpose. We used to refer to it as "over the wall" rather than "DevOps" but the problem we tried to shift was that there was a wall between development and operations and every so often development would run up to the wall, throw something over it with a note pinned to it saying "This is what you asked for."

By the 1990s we had fixed it for all aspects of business delivery by doing the logical thing of having operations included in all phases of development. It worked, no need for "a method" or shiny suits or six figure salaries.

When I emerged from that environment to more mainstream IT I was horrified that the old crap way of doing things has survived. Now I'm horrified that smoke and mirrors has been applied to "leverage" <retch> huge salaries for stating the bleeding obvious.

I agree with you that it's a marketing wet dream but it's not selling much of value. Since my thing these days is security, I'm really ticked off that in most DevOps projects security isn't thought of at all. It seems to be common that they think "Just get it working, we'll keep security happy by throwing some in at the last minute[1]."

[1] That is, if they bother at all. Just look at the DevOps approach leading to Internet of Tat. Not a pretty sight.

[Dagg]

COTS does work

The problem I have found is that every business thinks that its process and procedures are special and the software need to be adjusted to those process and procedures.

But when it comes down to it a bit of process re-engineering and guess what, the business can use the COTS with none or minimal changes.

A retail store is a retail store is a retail store.... Same for a bank, insurance company etc.

Within a business there are standard processes HR, CRM, Supply chain etc that all work the same across different businesses and industries. But some companies must have there own version. From a customer development point of view this is a gold mine.

[Anonymous Coward]

Agile doesn't cut it.

>> Waterfall will serve you well if the requirements for your software never change, and are fixed. It's like making a circle of salt around your house: it'll keep the trolls out, for sure, but that's a lot of salt to blow if it turns out that trolls, actually, don't exist.

Total BS, try using agile on a very large fixed price, fixed function, fixed delivery date project and you are toast.

Little things like the software must be fully functional and deployed to all stores country wide before the xmas sales season starts and you have provided a fixed price quote and there are penalties nasty ones if you don't meet the deadlines.

Lawyers and 20 paces anyone....

[Mike Timbers]

Re: Agile doesn't cut it.

>>Total BS, try using agile on a very large fixed price, fixed function, fixed delivery date project and you are toast.

No, sorry but that's simply wrong. Large projects can be delivered with an agile method. Done it on multiple ecommerce projects (£10m big enough for you?) where launch dates are fixed because TV advertising's been bought, budgets are fixed because I was an SI and functionality was written up in epics and wireframes. Fortnightly sprints, automated builds and testing, CI/CD. All the things you say can't work at scale. They can and they do.

[Anonymous Coward]

Re: Agile doesn't cut it.

Nobody develops using pure waterfall so that is a strawman comparison. Perhaps agile has delivered some large complex projects on time and with the required features but I haven't seen it.

I just reviewed an agile project 2 years past due (was 1 year), 4 times over budget, massively reduced functionality (substantially less than the minimum core functionality defined) and still not usable. Clearly from this alone agile projects can go just as horribly wrong as anything else. In this case I think agile contributed to the project not being stopped and actions taken until such a ludicrously late stage.

There are some good things in agile but there is no magic bullet and agile assumed to be a pancea is very dangerous.