Are you a Salesforce or an Uber? Choose wisely, devs

There’s no one-size-fits-all when it comes to DevOps. In small operations DevOps will likely mean very little as developers will probably already be managing production environments in addition to the deployment of applications. At the other end of the scale, in very large organisations - where there are well-defined lines …

[Electron Shepherd]

DevOps is like the fire safety procedures in any office. You won't need a fire extinguisher or an evacuation plan every day but they are there because when there is a fire having them is incredibly helpful

An interesting analogy, since the key point of an evacuation plan is to get everyone out of the way, and let the professionals, who are trained to deal with the emergency situation, come in and work unimpeded.

Every office I know has a policy of "if there's a fire, hit the fire alarm button and get out. Don't try to tackle the fire yourself". Partly that's the lawyers and health and safety getting involved, but partly it's because unless you know what you're doing, an amateur tackling a fire can make things worse (there's certain types of extinguisher for certain types of fire - get it wrong and you make matters worse).

[Steve Davies 3]

The Water on a Chip Pan effect

Which is why in a couple of jobs I've had in the past we all had mandatory fire safety training including how to tackle small fires. Jet-A can get a tad nasty at times.

To be honest, if the instructions are to 'Get the hell out' why do we have to have effing fire extinguishers all over the place? The Fire Brigade will bring their own.

Back on topic.

Salesforce or Uber?

How about neither and no I won't be drinking the DevOps koolaid.

time to stop flogging a dead horse perhaps?

[Lysenko]

Not quite...

Fire extinguishers exist for a reason. Tools that ordinary workers can deploy in an emergency situation but which absolutely MUST NOT be played around with in the course of normal operations because of the huge amount of collateral damage the are likely to cause.

On this basis, I'm on board with DevOps.

[Spoonguard]

hUBERis

[gumbril]

Don't get this.

DevOps is an example of one of many processes that can be applied in the event of a fire, if it happens to be the way your work, but how does that make DevOps different, special, unique?

As much as I dislike twitter, they are as much as part of the same process, communicate is pretty important to.. during the event (and actually if your doing it right - before - "Hey Customer, When/if this happens, don't panic, this is what's we're going to be doing.. and this is how long it will take, and this is when you get an update and this is the role that will be doing the update, so communicate that to your management and give them the impression you are in control.")

I mean having an up to date out of office telephone list of your IT department is probably more important.

And, in any 'Fire' the biggest uncertainty is finding out what happened. If your doing it right you don't need to find out "Hey Bob, what happened?" - "I dunno, we failed over to our other location, we'll get someone looking at it now, it's still a P2 as we've lost some redundancy" If you're not, then you need to get on that phone list and start calling, to get the people to figure it out what to fix, and if it's code, what's that -10% of the time, then you need to get them to figure a fix - and then, finally you call upon automated delivery. Whoopee, so if at that point they say - it'll take 3 days to release - cause it's not DevOps? Not likely.

Frankly, spontaneous code issues, that cause a fire, are relatively rare. Unless we're talking releases. And that's should be covered by engineers pre-booked, and rollback procedures.

TL;DR If DevOps is core in your 'fire' safety procedure, you're more Dev than Ops, and you certainly don't know enough to plan tackling it.

[Snipp]

The most import feature of a good DevOps team is answering the phone at 3AM because your app is crashing.

[Anonymous Coward]

SFDC not moving to CD?

I would like to correct your comment regarding SFDC and continuous deployment not being a fit:

I am a San Francisco DevOps/SRE contractor who is heavily involved in cloud migrations from data centers, and Agile/CD transitions. As such I have been approached by SFDC for my expertise (I have not been available) to assist in a high priority transition to do exactly what you stated is not appropriate for them. Any large customer facing organization has some services that change slowly, and others that must do so to retain market differentiation. Adapt or Die. You confuse SFDC the organization with that dichotomy.

SDFC is indeed undergoing a HUGE initiative to move much of their operations into the cloud SPECIFICALLY to support an ongoing transition to Agile development, refactoring to services/microservices, and (where appropriate) very frequent CD. They see their periodic & infrequent release strategy across the board as being a MAJOR impediment to competing effectively against various competitors and not-yet-competitors in their space. Further that strategy has exacerbated an SDDC tendency to continue to deploy large-ish monolithic applications, and do so on dedicated hardware in high cost data centers, which then require massive regression testing to QA.

So if any thing, SFDC IS a "poster child" for an organization that gets the need for Agility, microservices (containerized of course ;{), in a cloud environment. Adapt or die.