• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

DevOps is in all the job description. But what is it ?

 
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are so many different definitions/implementations of devOps around. What does devOps mean for you ?
Also, anybody knows how does it relate with the Software Reliability Engineer figure created by Google ?
 
Saloon Keeper
Posts: 21133
134
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, at its most cynical, DevOps is cover for management's ongoing effort to downsize the entire IT department into one overworked, underpaid individual.

But there's a practical reason for the term as well.

Back when I started in the profession, the IT department had basically 3 groups: Applications people (programmers and analysts), Computer operations, and Technical Support. At the time "technical support" wasn't clueless people with bad accents, it was the group responsible for the OS, whatever passed for databases, security, general OS-level infrastructure, and in the shop I spent most of my time in, the parts of the applications system that absolutely positively could not be allowed to fail.

The ladder for aspiring IT people back then was typically operations, applications, then tech support, with significant pay improvements as you went up. Often, however, the operations staff had no idea what the software was doing and the software people were clueless about what the hardware was doing to run their software. Tech support had a more direct interaction with the hardware - we could generally walk into the computer room at any time we pleased - but we were software people, so we understood what was going on.

That concept of "tech support" went out as PCs came in and the PC owner was frequently operator, programmer, and OS support person. That's OK as long as you're looking at simple, self-contained systems, but as the PC architecture grew up into server systems, the complexity of a lot of different types of interacting hardware and software made this idea pretty hard to do. To say nothing of the need to keep enterprise-level data backups and security. So the next stage often was applications and operations, with no one formally standing between the two groups. Some of us (like myself) stood there informally, but our hardware/OS expertise wasn't valued in its own right.

Things got more complicated and The Cloud came along. When you outsource your IT to an external service, you no longer need hardware support as such, but on the other hand, it becomes a lot more apparent that a bunch of people "out there somewhere" may be able to keep the CPUs running and the disks spinning, but they don't have any idea of how to make those assets work for your business in a cost-effective way. This was one of the roots of the DevOps person - someone who knew the business and the apps, but also knew how to link the various and ever-expanding set of components, both proprietary and third-party.

I've also seen DevOps promoted as an integral part of Agile. This is a bit of a stretch, perhaps, but it's true that Agile requires more frequent software releases. So someone needs to be handling whatever contiguous integration systems your shop is using, someone needs to ensure that provisioning is handled, and someone needs to ensure that any infrastructure changes mandated by said changes are handled.

So DevOps covers a multitude of sins. At one extreme, it's simply that a member of the application team works closely with the infrastructure. At the other, you could end up with someone like my old mainframe tech support department. When I described my job as "You don't know what the programs I work with do, but I wasn't keeping them working, then the programs that make you money would all stop working".
 
Luca Ali
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim and really thanks for your answer.
With devops it is really difficult to understand where the responsibility of a developer starts and finishes. In my workplace we are responsible of discussing the user story, writing the test, developing the story, manually test that everything went fine, shipping in production and monitor it.

I understand all the advantages of this approach but It looks like we are spreading a bit to thin.
 
Tim Holloway
Saloon Keeper
Posts: 21133
134
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You sound like you're working more on a "waterfall" basis, possibly even as an outfit that produces packaged releases for other customers. DevOps isn't really about software as a manufactured product, since that product is going to be running other places where you usually don't have an on-site presence anyway. DevOps is more for in-house apps.

One of the biggest differences - realistically - between Agile and Waterfall on in-house applications is simply whether or not your software releases are often and scheduled or infrequent and project-oriented. If you are of the latter persuasion then obviously the need for a lot of interaction between development and support is going to be reduced. You may not be using a master provisioning system or even a simple packaging system, because you're not doing it often enough to need them simply to save time (I tend to consider such amenities as also aids to disaster recovery/business continuity, but I differ with a lot of people).

Still, a really critical app being run in-house would still benefit from monitoring and tuning. While you might be able use generic tools and operations staff, if things go pear-shaped, there's a certain advantage to having an application expert in the loop.

It's kind of like the Fire Department. You may grumble about paying to have them sit around doing nothing all day with a bunch of expensive toys, but things look different when you actually need to have them at work ASAP and with no distractions.
 
Author
Posts: 13
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In some organizations - e.g. Google - developers are responsible for their component - its correctness and its meeting its SLAs. There is another group (SET in Google) who are system testers. They are responsible for overall system health - latency, etc. These are the things that are not strictly associated with a single component. Interpreting monitoring information relative to system performance (not single component performance) is their responsibility.

 
You ought to ventilate your mind and let the cobwebs out of it. Use this cup to catch the tiny ads:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!