8 Things IT Ops Hates—And What Devs Can Do to Help [Part 2]

[ibimage==48370==Original==none==self==ibimage_align-center]

By Al Sargent

This is part 2 of a 2-part series on the things that make your IT ops team members cry into their pillows at night—and how we can all help relieve their pain.

In my previous post I discussed the first four things can make life miserable for your IT ops team: having to wrangle too many new developer technologies; dealing with lots of legacy code; cleaning up after devs who fail to thoroughly test their new apps; and being constantly in the hot seat for problems they didn’t create.

But those aren’t the only headaches that ops experiences! Read on to learn four more:

5. Ops, Interrupted

Everybody is busy these days, but ops folks hate having their personal lives continually interrupted by outages and alerts when they are on call. Being on call sucks—and ops teams get no appreciation for giving up their personal time to deal with emergencies that usually aren’t their fault.

What devs can do to help:

Be explicit with your code and comments. Imagine being the operator looking at errors for a non-performing custom app that they’ve never seen before. Now imagine it’s 2 a.m. and there’s nobody else to ask. How do you make things as easy as possible for them? In other words, how explicit can you make things?

For example, some observers think that Go’s explicit syntax, while more work to write, is easier to read than Scala. And since code is read more often than it is written, it’s important to optimize for the read use case, not the write use case.

In addition, Go doesn’t need a separate JVM to maintain the way Scala does. Yes, a JVM is easy to set up today, but how about 10, 20, or 30 years from now? Put another way, how good is your Perl these days?

6. Chao is too often the order of the day.

IT ops craves order but they very rarely get to experience it. With all the moving parts surrounding hundreds of apps, along with clueless contractors, constant turnover, and multiple tools, the typical daily environment for far too many ops teams is often chaos. Glitches and problems in other parts of the process all come home to roost on ops’ doorstep. Ops wants predictability and hates surprises, so devs, in particular, need to understand that when they miss a deadline or fail to properly test a new build, it’s ops that has to pick up the slack to keep things on schedule.

What devs can do to help:

Use simple, standardized stacks. The more idiot-proof an architecture, the less likely someone with little experience will mess it up.

7. Automation isn't as predictable as promised.

Ops automation, including Puppet and Chef, promise to help ops deal more efficiently with hundreds of constantly changing apps. Unfortunately, it doesn’t always work out that way in the real world.

You can write a program to perform a deployment, for example, but you shouldn’t be surprised that the script may not work perfectly every time. What works fine on version x.1 may not work at all on version x.3, and ops has to deal with a long tail of apps and tools that dev may have already forgotten about.

What devs can do to help:

Encourage ops to use a synthetic testing tool (such as New Relic Synthetics) to check Web applications before, during, and after deployments. Run these tests as frequently as every 60 seconds so that if a problem has been introduced, you find it before your customers do.

The best deployment validation checks go beyond simple URL pings, and run checks that deeply exercise a Web app, especially those areas of functionality with recently modified code. Dev can tell ops where these areas are and suggest ways to exercise them.

8. DevOps, agile development, and continuous deployment don't always focus on ops’ needs. 

For developers, the shift from waterfall development to Agile is great, since it allows dev to more quickly fix their mistakes. But for ops, deployments are some of the most stressful times in their day, and development practices like Agile mean continuous cleanup. It’s bad enough having a root canal once year—now imagine getting one on a daily basis. It’s not that ops folks hate new technology—they work in technology, after all—but ops need to be shown that DevOps, Agile, and continuous deployment isn’t just a stealth scheme to ruin their lives and keep them on a treadmill 24/7.

What devs can do to help:

• Devs can work with ops to remove as many potential problems as possible. Dockerize. Again, here’s a free download of the first three chapters of Docker Up & Running.
• Have dev be on call during deployments.
• Deploy during the day when everyone is on hand, in the office, and awake.
• Use a Platform as a Service (PaaS) with blue/green deployments (such as Cloud Foundry), a methodology that lets you easily roll back a deployment that has failed. And using a PaaS means you are using deployment code that is probably more battle-hardened than the Puppet or Chef scripts someone wrote on their own. (Full disclosure: I previously worked on the Cloud Foundry team at Pivotal and own Pivotal stock.)

Conclusion

Hopefully this post helps a bit in terms of developers understanding the challenges ops faces, and how they can help. To paraphrase a famous former president: Tear down this wall … and let the revolution of increased dev and ops collaboration begin!

About the Author

Al Sargent is senior director of product marketing at New Relic. He's proud to lead an outstanding team of product marketing professionals who are responsible for go-to-market activities for New Relic's software analytics suite. View posts by Al Sargent.