What exactly is “DevOps”?

642 views

I don’t quite understand how devops is different from software development. They’re closely related, but I’m just kinda stupid. Please explain it to me

In: Engineering

6 Answers

Anonymous 0 Comments

It’s about writing software that helps to manage other pieces of software. So like in the web development world it has to do with writing scripts which assist with the deployment of code changes to the live site, running backups, etc.

Anonymous 0 Comments

If “Development” is the process of writing or changing code, then “DevOps” is the process of getting that change from the developer to the end product.

Anonymous 0 Comments

Software engineering is at the core of a Devops engineer’s responsibilities but are not limited to strictly pushing code and innovating / releasing products, although this is typically viewed as the highest revenue generating function.

DevOps engineers work on code with developer team, oversee tests / releases and manages the deployment and operation processes across production. Often Devops engineers even manage and integrating security into the development lifecycle and become DevSecOps engineers.

In theory a Devops engineer would be leading the software development program as a core responsibility, but in a smaller organization they likely also are managing their cloud deployment, security and compliance controls, owning access / admin rights for automation tools, monitoring site reliability with SRE, and ultimately working to improve a frictionless development process.

Anonymous 0 Comments

A developer writes the code for an application. Their responsibilities include:
– writing optimal code
– good algorithms
– good data structures
– writing correct code
– meets the business needs
– does not explode when it runs
– maintaining code
– fixing bugs
– taking feature requests
– building new features

Operations runs that code in production. They aren’t talked about as much but their responsibilities might include:
– compiling optimal code
– testing optimal code
– unit testing
– integration testing
– e2e testing
– rolling out code
– blue/green deployments
– rolling deployments
– rollbacks
– migrations
– keeping code running
– live site
– incident management
– security
– logging & metrics

There’s a _lot_ of overlap between these two and depending on who you ask the responsibilities might vary – testing & compiling is often the developer’s responsibility or the partial responsibility of a third group (test), operations might be involved with any new feature requests, etc.

There’s also a _lot_ of places where you can be more productive by knowing “both sides” of the coin – if you write unit tests when you write code, it’s much faster; you can better deal with incidents if you know the code underneath; creating rolling deployment capable applications requires you to understand both sides; etc.

“DevOps” refers to the practice of mixing these two roles to get these benefits. Your developers understand operations; your operations team understands development. They might work in the same room, be the same people, or report to the same manager. You might loop developers in to on call rotations or ask operations to deal with bug fixes.

Compare with the “traditional” model, which saw these as two separate teams – developers would hand finished applications over to operations, who would deploy them to production & manage them once live.

Anonymous 0 Comments

Traditionally, an IT company had two fully separate departments and processes. Development, and operations. Dev was responsible for writing, testing, debugging and maintaining the software. Dev was staffed by programmers and software engineers. Ops, in turn, was responsible for taking Dev’s finished product, the completed software, and setting it up on servers to run it. They would take care of the server’s operating system, and any networking services it depends on, and they would be responsible for stuff like capacity and load management. Ops was mostly staffed by sysadmins and networking/infrastructure engineers.

This way of doing things worked well for a long time because these were quite different problem domains requiring different expertise. The role divisions were clean: Dev produces the software, Ops runs it. If a bug in the software was found in production, Ops would report it back to Dev and they would address the bug in their next version release, which Ops would then install.

But nowadays, the stuff which Ops engineers are responsible for, has started to look more and more like what the Dev engineers work with. Instead of physical servers, they’re dealing with virtual machines. And starting/stopping those virtual machines is done using automated, programmed API calls. And the code to do all that stuff is increasingly being treated just like the software that Dev is writing. The connectivity between servers and their storage backends is no longer described by a wiring diagram, but by a structured document which *tells* the VM host how to hook it up. They call this type of thing ‘infrastructure as code’.

So: Devops. It’s a management and workflow philosophy in IT where ‘ops’, the process of getting the software hosted and running on a server, or a cluster of servers with load balancing or whatever, is treated as continuous with the software development process, instead of distinct from it.

Anonymous 0 Comments

It’s applying traditionally DEVelopment practices and technologies to software or business OPerationS — which increasingly rely on technology and benefit from development practices.