<p>Mainly DevOps is not a role (when used as such it's more a buzzword than a real role).</p>

<p>DevOps is roughly an organization pattern aiming at breaking the silo between developers and sysadmins.<br>
The main goal is to build teams with devs and sysadmins (along with testers usually) responsible for a product (application) from its definition, architecture decisions up to the maintenance in run of this product.<br>
Each member of the team will be part of the decision on the whole life-cycle of the product, a dev will do some sysadmin tasks in production, and a sysadmin will participate  in the design phase of the product to avoid caveats from the infrastructure perspective for example.</p>

<p>At ideal, a sysadmin would also be part of the development team for the product, in real world sysadmin code more on the configuration around the product and monitoring solutions, but being able to voice concerns to other members of the team avoid a lot of misunderstanding on the deployment process.</p>

CC BY-SA 3.0
2017-04-16T19:22:43.587Z
Some organizations I've worked in have (perhaps more through chance than design) taken this to an extreme: we had no dedicated sysadmins and all the sysadmin work was done by "regular" developers. (In this particular organization many of the developers were very experienced systems administrators so we never felt any need to hire someone who specializes in that.)
cjs
CC BY-SA 3.0
2017-03-04T16:14:09.727Z
So much this... DevOps is **not** a role. You "do" system administration in a different way as "part" of a DevOps culture.
Ken Mugrage
CC BY-SA 4.0
2019-03-01T09:17:22.117Z
"DevOps is roughly an organization pattern", the more enlightening snippet I have read so far.
Diagathe Josué
CC BY-SA 4.0
2019-07-31T07:06:52.337Z
May be you can clarify that DevOps != NoOps
sgargel
CC BY-SA 4.0
2022-06-06T23:43:33.560Z
I would specify "Operations" is a common team deploying software the developers maintain - hence the **Ops** in Dev**Ops**.
Ari
CC BY-SA 3.0
2017-03-01T10:47:01.327Z
2017-03-01T10:47:01.327Z
Tensibai
<p><strong>Sysadmin vs. DevOps (personal view)</strong></p>

<p>Some companies talk about Dev, Ops and Test. If something needs to be tested then they say: "Test should do that". If something needs to be developed, Dev will do that and if software needs to be deployed, Ops will do that.</p>

<p>In my opinion and what I have experienced at several companies is that this results in a "throw it over the wall" mindset that results in friction between people and teams. Personally, I sometimes feel that people work individually and say this is what I did, I have nothing to do instead of working as a team.</p>

<p>According to me DevOps means that everybody in a team is responsible and busy with development, testing and operations. There is no I in a team and no separate departments. Everybody should release. Of course there are specialties, but in my opinion everybody should be able to do at least 25% of some work in every area. E.g. if someone was a Developer back in the day then one should be able to change some configuration management code, e.g. chef and deploy software.</p>

<p><strong>References</strong></p>

<p>Sysadmin</p>

<p>According to <a href="https://en.wikipedia.org/wiki/System_administrator" rel="nofollow noreferrer">Wikipedia</a>:</p>

<blockquote>
  <p>A system administrator, or sysadmin, is a person who is responsible
  for the upkeep, configuration, and reliable operation of computer
  systems; especially multi-user computers, such as servers.</p>
  
  <p>The system administrator seeks to ensure that the uptime, performance,
  resources, and security of the computers he or she manages meet the
  needs of the users, without exceeding the budget.</p>
  
  <p>To meet these needs, a system administrator may acquire, install, or
  upgrade computer components and software; provide routine automation;
  maintain security policies; troubleshoot; train or supervise staff; or
  offer technical support for projects.</p>
</blockquote>

<p>DevOps</p>

<p>According to <a href="https://en.wikipedia.org/wiki/DevOps" rel="nofollow noreferrer">Wikipedia</a>:</p>

<blockquote>
  <p>DevOps (a clipped compound of "development" and "operations") is a
  software development and delivery process that emphasizes
  communication and collaboration between product management, software
  development, and operations professionals. It supports this
  by automating and monitoring the process of software integration,
  testing, deployment, and infrastructure changes by establishing a
  culture and environment where building, testing, and releasing
  software can happen rapidly, frequently, and more reliably.</p>
</blockquote>

<p><a href="https://upload.wikimedia.org/wikipedia/commons/b/b5/Devops.svg" rel="nofollow noreferrer">DevOps</a></p>

<p><a href="https://i.sstatic.net/tdlPb.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/tdlPb.png" alt="enter image description here"></a></p>

<p><a href="https://upload.wikimedia.org/wikipedia/commons/0/05/Devops-toolchain.svg" rel="nofollow noreferrer">DevOps Toolchain</a></p>

<p><a href="https://i.sstatic.net/Lq9Xq.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Lq9Xq.png" alt="enter image description here"></a></p>

CC BY-SA 3.0
2017-07-26T03:11:53.710Z
Only one tiny comment: IMHO as long as the team as a whole has good coverage over each aspect of the dev/ops/test areas and has good communications it's not absolutely necessary that each individual in the team also covers each and every such area. Sure, it's a good thing if that happens, but *requiring* it may get unnecessarily expensive in some cases.
Dan Cornilescu
CC BY-SA 4.0
2017-07-25T22:07:56.623Z
2018-11-02T19:50:59.083Z
2018-11-02T19:50:59.083Z
030
<p>A system administrator is responsible for maintaining and configuring servers and their responsibility is to ensure the user with the performance, uptime and security that they are looking for. Defining the role of a DevOps engineer is a little more difficult since there is no formal career path and DevOps itself can have many forms. </p>

<p>A DevOps engineer can be, for example, a developer who is interested in network and deployment operations or a system administrator who has a passion for coding and scripting. The transition from system administrator to DevOps engineer is not very difficult, in fact, this <a href="https://squadex.com/insights/system-administrator-making-leap-devops/" rel="nofollow noreferrer">article</a> does a very good job describing the process. </p>

<p>Many people would even argue that this transition from system administrator to DevOps engineer is essential since the position of system administrator will become obsolete in the future. Even though there are plenty of legacy servers that need maintenance and system administrators possess a lot of “tribal knowledge” the sysadmin position will become more scarce in the future. </p>

CC BY-SA 3.0
2017-12-26T09:16:52.260Z
2017-12-26T11:35:03.170Z
2017-12-26T11:35:03.170Z
DevOps Jedi
<h2>Short Version</h2>
<p>DevOps a combination of organisational culture, Agile/Lean ways of working and software automation that when applied to Systems Administration and Operations allows these functions to operate with the same level of Agility as Agile or Lean Development Teams.</p>
<h2>Long Version</h2>
<p>The ideas behind DevOps came out of the Systems Administration, Operations and Agile communities, specifically, <a href="https://twitter.com/patrickdebois" rel="noreferrer">Patrick Debois</a> gave a <a href="http://www.jedi.be/presentations/agile-infrastructure-agile-2008.pdf" rel="noreferrer">presentation at Agile2008</a> entitled 'Agile Infrastructure' where he highlighted the disparity between the way the three functions within an organisation operate:</p>
<ol>
<li><strong>Agile Development Teams</strong> - Agile teams writing code.</li>
<li><strong>Systems Administrations Teams</strong> - Building infrastructure to run the software.</li>
<li><strong>Operations Teams</strong> - Supporting applications and infrastructure in Production/Live.</li>
</ol>
<p>Debois' proposal was to unify the three ways of working together, specifically moving Systems Administration teams and Operations teams from a <a href="https://en.wikipedia.org/wiki/Waterfall_model" rel="noreferrer">Waterfall Model</a> to an Agile Model.  To that end, Debois setup <a href="https://legacy.devopsdays.org/events/2009-ghent/" rel="noreferrer">DevOpsDays 2009 in Ghent, Belgium</a> inadvertently coining the phrase <strong>DevOps</strong>.</p>
<p>The idea of DevOps resonated with the Authors of the VisibleOps series of books: Gene Kim, George Spafford and Kevin Behr; who went on to write <a href="https://www.amazon.co.uk/Phoenix-Project-DevOps-Helping-Business-ebook/dp/B00AZRBLHO" rel="noreferrer">The Phoenix Project</a> and <a href="https://www.amazon.co.uk/DevOps-Handbook-World-Class-Reliability-Organizations-ebook/dp/B01M9ASFQ3" rel="noreferrer">The DevOps Handbook</a>. Both books explore how Agile and Lean can positively impact Systems Administration and Operations teams.</p>

CC BY-SA 3.0
2017-08-08T19:06:57.060Z
Excellent summary! Best I've yet seen about the history behind this philosophy and engineering style.
Jesse Adelman
CC BY-SA 4.0
2020-07-27T03:23:47.700Z
And, also, this should be the Accepted answer, IMO. :)
Jesse Adelman
CC BY-SA 4.0
2020-09-25T09:47:41.760Z
Sarcasm version: instead of hiring 1 system admin (100k/year) + 1 senior dev (150k/year) + 1 junior dev (60k/year), let's hire 2 devops engineers can do anything the boss want by 2 x 80k/year
Luke
CC BY-SA 3.0
2017-04-16T20:13:30.983Z
2017-04-16T20:13:30.983Z
2020-06-18T08:28:10.803Z
Richard Slater
<p>As a <em>DevOps</em> Engineer coming from an Operations background, you will have moved from building and deploying servers and software <em>manually</em> to <strong>scripting</strong> the installation of software onto your servers with the likes of BASH, PowerShell, Python etc. After a while, you would realise how cool scripting is and start to explore more sophisticated ways to <strong>automate deployment</strong>. </p>

<p>Eventually, you would have settled on a <em>Chef, Puppet, Ansible</em> or other <strong>configuration management</strong> tool to help manage the state of your fleet of systems. As your skills with the automation of application deployment and system management matured, along with your tools, you have more recently moved into the realm of '<strong>Infrastructure as Code</strong>' and use it to not only automate the deployment of software but the infrastructure and environments required to drive the software during the business's shift to the Cloud.</p>

<p>Now you are cooking with gas. Over time you have been introduced to the benefits of using developer centric tooling such as <strong>source control</strong> to manage the modules, recipes and templates that make up your arsenal of deployment and management tools.</p>

<p>When you shifted into the <em>DevOps</em> team you were exposed to the software development life cycle and the concept of <strong>continuous integration</strong>. Boy those developers were releasing changes quickly and to keep up you found yourself working more closely with the devs! You experienced the urgency placed on the development team to change things ALL-THE-TIME which grates against the old operational paradigm of "<em>if it ain't broke, don't fix it</em>". No more bragging about system uptime anymore, you are into <em>disposable</em> infrastructure.</p>

<p>You noticed that the move to <em>DevOps</em> was more than working with the <em>devs</em>, or using <em>new tools</em> and <em>techniques</em>, but there was a distinct <strong>cultural</strong> shift in the team, one that permeated through the organisation at large. You were working as a close-knit team with <em>shared responsibilities</em>, <em>shared tooling</em> and <em>shared goals</em>. </p>

<p>You took your skills in automated deployment and massaged them into the "<strong>CICD</strong>" pipeline being orchestrated by a "<strong>continuous integration server</strong>" like <em>Jenkins</em>, <em>Bamboo</em> or <em>Code Pipeline</em>. Now, when the developers push new code, your scripts, tools and templates stand up new environments on demand, trigger testing frameworks to do their thing and tear down the pre-production environments after the green lights are lit on the release, adhering to the ideas of "<strong>continuous delivery</strong>".</p>

<p>As the new code snakes its way through the CICD stages, you, the developers and the business gain confidence that the update will not break when released to production. There is some way to go before the team gets to "<strong>continuous deployment</strong>", you still need to settle on the finer points of automating the <strong>blue/green</strong> deployment capability, and the decision is mostly a business one. For the time being you are content that the number of calls at 3am have subsided and the sev-1's and sev-2's dwindle.</p>

<p>Even if you do get a sev-1, you are not pulling all-nighters any longer with the managers breathing down your back - you can easily release the previous version through the CICD pipeline and get the system online again in short order. The business has noticed that the <strong>stability</strong> of the IT systems has improved despite the <em>velocity of changes</em>.</p>

<p>You marvel at the way you manage the resources needed to drive the software in your business, especially when you think back to how it used to be and amount of blood you left behind on rails in the datacenter...</p>

CC BY-SA 3.0
2018-01-18T06:31:36.433Z
2018-01-18T09:07:44.380Z
2018-01-18T09:07:44.380Z
rdp-cloud
<p>There is going to be servers which you do not hear running in data centers. Everything is going to be software. Storage, network, systems, security, data centers; SDN, firewalls, NFV, storage, servers, etc. Sysadmins without a software development background, SDLC experience (I don't even mean scripting Perl, Powershell, etc) will probably vanish. Distributed, scalable and virtualized environments, which is mostly cloud, grow horizontal not vertically.</p>

<hr>

<p>I dare to say Sysadmins grow vertical, DevOps (or OpsDev) grow horizontal. You can see the same pattern how microservices evolved from monoliths. I would rather choose DevOps engineer from software team not from operations/system team. </p>

<p>Because operations/system team just runs what software team builds.</p>

<ul>
<li>Sysadmins do not build/compile Linux/FreeBSD/windows kernel etc. just as software engineers build/compile applications.</li>
<li>Sysadmins do not go through the software development life cycle (SDLC).</li>
<li>Sysadmins are not part of the production pipeline (CI/CD process).</li>
<li><p>Sysadmin start working after CI/Continuous Delivery/Deployment ends.</p>

<p>And if you break and assign Deployment/Delivery, it could be a broken pipeline<br>
the software team is the creator system/operations team are the runners/caretakers mostly.</p></li>
</ul>

<p>It sounds like there is no server/system to administer, no sysadmin need.</p>

<p>Serverless computing is a cloud-computing execution model in which the cloud provider acts as the server, dynamically managing the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity
<a href="https://en.wikipedia.org/wiki/Serverless_computing" rel="nofollow noreferrer">Serverless computing</a></p>

<p>Someone from the software team already knows how to build, maintain even how to code (SRE vs DevOps/OpsDev).</p>

<hr>

<p>I wonder why it is called DevOps but not OpsDev? is it related to the direction between the two? </p>

<p><strong>*In the middle of nowhere, I did not start writing about software-defined storage, this is in reaction to a now deleted comment about it *</strong></p>

<h3>About software-defined storage</h3>

<ul>
<li><p>Software-defined storage (SDS) is a marketing term for computer data storage software for policy-based provisioning and management of data storage independent of the underlying hardware.
<a href="https://en.wikipedia.org/wiki/Software-defined_storage" rel="nofollow noreferrer">Software-defined storage</a></p></li>
<li><p>EMC announced its first ever open source product: Project CoprHD. CoprHD is a Software Defined Storage automation and management controller, and EMC’s recent decision to open source it is at the crux of our strategy for delivering greater value to global businesses as we enter into an area of growth and extreme change.
<a href="https://www.emc.com/microsites/sds/articles/leading-the-way-software-defined-storage.htm" rel="nofollow noreferrer">As the world’s leader in storage and information management, it behooves EMC to lead the way on Software Defined Storage (SDS)</a>.</p></li>
<li><p>CoprHD is an open source software-defined storage controller and API platform. It enables policy-based management and cloud automation of storage resources for the block, object and file storage providers
<a href="https://coprhd.github.io/" rel="nofollow noreferrer">CoprHD</a></p></li>
</ul>

CC BY-SA 4.0
2018-11-06T22:19:15.680Z
Do not re add name calling in your answer, keep it in line with the question, again I recommend you read [answer] for guidance.
Tensibai
CC BY-SA 4.0
2022-01-10T15:10:14.430Z
Why are you replying to a comment to your answer? You should be answering the main question. You are so much off-topic, and what is on-topic is very unprecise or unclear. What do you mean by "Sysadmins grow vertical, DevOps (or OpsDev) grow horizontal"? If you mean the application scalability, that has nothing to do with either SysAdmin or DevOps, but by the application architecture. Nobody can effectively scale a monolith horizontally. Also, most of the SysAdmins today use IaC and config management tools. Why OpsDev when literally everyone uses DevOps?
djboris
CC BY-SA 4.0
2018-11-06T05:20:27.167Z
2018-11-06T22:14:34.247Z
2018-11-06T22:14:34.247Z
hakkican
<p>When applying for a job, usually you can find two types of similar jobs: <a href="https://stackoverflow.com/jobs?sort=i&amp;q=SysAdmin">Sysadmin Engineer</a> and <a href="https://stackoverflow.com/jobs?sort=i&amp;q=DevOps">DevOps Engineer</a>.</p>

<p>Both of them deal with server configuration and ensure the reliable operation of computer systems. It can be hard to tell the difference between the two. What are the main differences between them?</p>

CC BY-SA 3.0
2017-05-19T16:25:13.637Z
@kenorb - I notice you work a lot more with the tech Q&A sites, but my experience is with more general, subjective and open-ended questions (like those at the not tech Q&As), it is often better to determine if a Q is a dup based on the *answers* it will generate. If you ask two wildly different questions, but I can simply copy and paste an answer (possibly with minimal edits), then they should be marked as duplicates.
James Shewey
CC BY-SA 3.0
2017-12-30T08:40:54.677Z
In Kiev, Ukraine on some DevOps conference, there was the same question, and the reporter's answer was a joke, obviously, but with with a downhill of the truth: "DevOps is a Sysadmin, who receives his salary in USD" (c) :-)
setevoy
CC BY-SA 3.0
2017-03-01T11:03:15.127Z
Related: [What is the difference between SRE and DevOps?](http://devops.stackexchange.com/questions/86/what-is-the-difference-between-sre-and-devops)
Sathyajith Bhat
CC BY-SA 3.0
2017-03-01T17:16:29.250Z
Possible duplicate of [What is the difference between SRE and DevOps?](http://devops.stackexchange.com/questions/86/what-is-the-difference-between-sre-and-devops)
Woodland
CC BY-SA 3.0
2017-03-01T17:17:20.517Z
SRE and sysadmin terms are different.
kenorb
CC BY-SA 3.0
2017-03-01T19:45:27.970Z
I suggest you include a definition for sysadmin, and allow for answers who can compare that to role of DevOps. I personally think that DevOps is not even a role ... so I would have some say on the matter.
Evgeny Zislis
CC BY-SA 3.0
2017-03-01T19:47:44.427Z
@Evgeny Tell that to recruitment agencies.
kenorb
<terminology>
What is the difference between Sysadmin and DevOps Engineer?
kenorb
# What is the difference between Sysadmin and DevOps Engineer?

(Asked by: username_0 on 2017-03-01)

When applying for a job, usually you can find two types of similar jobs: [Sysadmin Engineer](https://stackoverflow.com/jobs?sort=i&q=SysAdmin) and [DevOps Engineer](https://stackoverflow.com/jobs?sort=i&q=DevOps).

Both of them deal with server configuration and ensure the reliable operation of computer systems. It can be hard to tell the difference between the two. What are the main differences between them?

**Tags:** terminology

> **Comments:**
> **username_3**: Related: [What is the difference between SRE and DevOps?](http://devops.stackexchange.com/questions/86/what-is-the-difference-between-sre-and-devops)  
> **username_4**: Possible duplicate of [What is the difference between SRE and DevOps?](http://devops.stackexchange.com/questions/86/what-is-the-difference-between-sre-and-devops)  
> **username_0**: SRE and sysadmin terms are different.  
> **username_5**: I suggest you include a definition for sysadmin, and allow for answers who can compare that to role of DevOps. I personally think that DevOps is not even a role ... so I would have some say on the matter.  
> **username_0**: @Evgeny Tell that to recruitment agencies.  
> **username_1**: @username_0 - I notice you work a lot more with the tech Q&A sites, but my experience is with more general, subjective and open-ended questions (like those at the not tech Q&As), it is often better to determine if a Q is a dup based on the *answers* it will generate. If you ask two wildly different questions, but I can simply copy and paste an answer (possibly with minimal edits), then they should be marked as duplicates.  
> **username_2**: In Kiev, Ukraine on some DevOps conference, there was the same question, and the reporter's answer was a joke, obviously, but with with a downhill of the truth: "DevOps is a Sysadmin, who receives his salary in USD" (c) :-)  

---

## 6 answers

### Answer by username_6 on 2017-03-01. Score: 66 | Accepted answer

Mainly DevOps is not a role (when used as such it's more a buzzword than a real role).

DevOps is roughly an organization pattern aiming at breaking the silo between developers and sysadmins.  
The main goal is to build teams with devs and sysadmins (along with testers usually) responsible for a product (application) from its definition, architecture decisions up to the maintenance in run of this product.  
Each member of the team will be part of the decision on the whole life-cycle of the product, a dev will do some sysadmin tasks in production, and a sysadmin will participate in the design phase of the product to avoid caveats from the infrastructure perspective for example.

At ideal, a sysadmin would also be part of the development team for the product, in real world sysadmin code more on the configuration around the product and monitoring solutions, but being able to voice concerns to other members of the team avoid a lot of misunderstanding on the deployment process.

> **Comments:**
> **username_8**: So much this... DevOps is **not** a role. You "do" system administration in a different way as "part" of a DevOps culture.  
> **username_7**: Some organizations I've worked in have (perhaps more through chance than design) taken this to an extreme: we had no dedicated sysadmins and all the sysadmin work was done by "regular" developers. (In this particular organization many of the developers were very experienced systems administrators so we never felt any need to hire someone who specializes in that.)  
> **username_9**: "DevOps is roughly an organization pattern", the more enlightening snippet I have read so far.  
> **username_10**: May be you can clarify that DevOps != NoOps  
> **username_11**: I would specify "Operations" is a common team deploying software the developers maintain - hence the **Ops** in Dev**Ops**.  

---

### Answer by username_15 on 2017-04-16. Score: 23

## Short Version

DevOps a combination of organisational culture, Agile/Lean ways of working and software automation that when applied to Systems Administration and Operations allows these functions to operate with the same level of Agility as Agile or Lean Development Teams.

## Long Version

The ideas behind DevOps came out of the Systems Administration, Operations and Agile communities, specifically, [Patrick Debois](https://twitter.com/patrickdebois) gave a [presentation at Agile2008](http://www.jedi.be/presentations/agile-infrastructure-agile-2008.pdf) entitled 'Agile Infrastructure' where he highlighted the disparity between the way the three functions within an organisation operate:

1. **Agile Development Teams** - Agile teams writing code.
2. **Systems Administrations Teams** - Building infrastructure to run the software.
3. **Operations Teams** - Supporting applications and infrastructure in Production/Live.

Debois' proposal was to unify the three ways of working together, specifically moving Systems Administration teams and Operations teams from a [Waterfall Model](https://en.wikipedia.org/wiki/Waterfall_model) to an Agile Model. To that end, Debois setup [DevOpsDays 2009 in Ghent, Belgium](https://legacy.devopsdays.org/events/2009-ghent/) inadvertently coining the phrase **DevOps**.

The idea of DevOps resonated with the Authors of the VisibleOps series of books: Gene Kim, George Spafford and Kevin Behr; who went on to write [The Phoenix Project](https://www.amazon.co.uk/Phoenix-Project-DevOps-Helping-Business-ebook/dp/B00AZRBLHO) and [The DevOps Handbook](https://www.amazon.co.uk/DevOps-Handbook-World-Class-Reliability-Organizations-ebook/dp/B01M9ASFQ3). Both books explore how Agile and Lean can positively impact Systems Administration and Operations teams.

> **Comments:**
> **username_16**: Excellent summary! Best I've yet seen about the history behind this philosophy and engineering style.  
> **username_16**: And, also, this should be the Accepted answer, IMO. :)  
> **username_17**: Sarcasm version: instead of hiring 1 system admin (100k/year) + 1 senior dev (150k/year) + 1 junior dev (60k/year), let's hire 2 devops engineers can do anything the boss want by 2 x 80k/year  

---

### Answer by username_18 on 2018-01-18. Score: 13

As a *DevOps* Engineer coming from an Operations background, you will have moved from building and deploying servers and software *manually* to **scripting** the installation of software onto your servers with the likes of BASH, PowerShell, Python etc. After a while, you would realise how cool scripting is and start to explore more sophisticated ways to **automate deployment**.

Eventually, you would have settled on a *Chef, Puppet, Ansible* or other **configuration management** tool to help manage the state of your fleet of systems. As your skills with the automation of application deployment and system management matured, along with your tools, you have more recently moved into the realm of '**Infrastructure as Code**' and use it to not only automate the deployment of software but the infrastructure and environments required to drive the software during the business's shift to the Cloud.

Now you are cooking with gas. Over time you have been introduced to the benefits of using developer centric tooling such as **source control** to manage the modules, recipes and templates that make up your arsenal of deployment and management tools.

When you shifted into the *DevOps* team you were exposed to the software development life cycle and the concept of **continuous integration**. Boy those developers were releasing changes quickly and to keep up you found yourself working more closely with the devs! You experienced the urgency placed on the development team to change things ALL-THE-TIME which grates against the old operational paradigm of "*if it ain't broke, don't fix it*". No more bragging about system uptime anymore, you are into *disposable* infrastructure.

You noticed that the move to *DevOps* was more than working with the *devs*, or using *new tools* and *techniques*, but there was a distinct **cultural** shift in the team, one that permeated through the organisation at large. You were working as a close-knit team with *shared responsibilities*, *shared tooling* and *shared goals*.

You took your skills in automated deployment and massaged them into the "**CICD**" pipeline being orchestrated by a "**continuous integration server**" like *Jenkins*, *Bamboo* or *Code Pipeline*. Now, when the developers push new code, your scripts, tools and templates stand up new environments on demand, trigger testing frameworks to do their thing and tear down the pre-production environments after the green lights are lit on the release, adhering to the ideas of "**continuous delivery**".

As the new code snakes its way through the CICD stages, you, the developers and the business gain confidence that the update will not break when released to production. There is some way to go before the team gets to "**continuous deployment**", you still need to settle on the finer points of automating the **blue/green** deployment capability, and the decision is mostly a business one. For the time being you are content that the number of calls at 3am have subsided and the sev-1's and sev-2's dwindle.

Even if you do get a sev-1, you are not pulling all-nighters any longer with the managers breathing down your back - you can easily release the previous version through the CICD pipeline and get the system online again in short order. The business has noticed that the **stability** of the IT systems has improved despite the *velocity of changes*.

You marvel at the way you manage the resources needed to drive the software in your business, especially when you think back to how it used to be and amount of blood you left behind on rails in the datacenter...


---

### Answer by username_12 on 2017-07-25. Score: 6

**Sysadmin vs. DevOps (personal view)**

Some companies talk about Dev, Ops and Test. If something needs to be tested then they say: "Test should do that". If something needs to be developed, Dev will do that and if software needs to be deployed, Ops will do that.

In my opinion and what I have experienced at several companies is that this results in a "throw it over the wall" mindset that results in friction between people and teams. Personally, I sometimes feel that people work individually and say this is what I did, I have nothing to do instead of working as a team.

According to me DevOps means that everybody in a team is responsible and busy with development, testing and operations. There is no I in a team and no separate departments. Everybody should release. Of course there are specialties, but in my opinion everybody should be able to do at least 25% of some work in every area. E.g. if someone was a Developer back in the day then one should be able to change some configuration management code, e.g. chef and deploy software.

**References**

Sysadmin

According to [Wikipedia](https://en.wikipedia.org/wiki/System_administrator):

> A system administrator, or sysadmin, is a person who is responsible
> for the upkeep, configuration, and reliable operation of computer
> systems; especially multi-user computers, such as servers.
>
> The system administrator seeks to ensure that the uptime, performance,
> resources, and security of the computers he or she manages meet the
> needs of the users, without exceeding the budget.
>
> To meet these needs, a system administrator may acquire, install, or
> upgrade computer components and software; provide routine automation;
> maintain security policies; troubleshoot; train or supervise staff; or
> offer technical support for projects.

DevOps

According to [Wikipedia](https://en.wikipedia.org/wiki/DevOps):

> DevOps (a clipped compound of "development" and "operations") is a
> software development and delivery process that emphasizes
> communication and collaboration between product management, software
> development, and operations professionals. It supports this
> by automating and monitoring the process of software integration,
> testing, deployment, and infrastructure changes by establishing a
> culture and environment where building, testing, and releasing
> software can happen rapidly, frequently, and more reliably.

[DevOps](https://upload.wikimedia.org/wikipedia/commons/b/b5/Devops.svg)

[![enter image description here](https://i.sstatic.net/tdlPb.png)](https://i.sstatic.net/tdlPb.png)

[DevOps Toolchain](https://upload.wikimedia.org/wikipedia/commons/0/05/Devops-toolchain.svg)

[![enter image description here](https://i.sstatic.net/Lq9Xq.png)](https://i.sstatic.net/Lq9Xq.png)

> **Comments:**
> **username_13**: Only one tiny comment: IMHO as long as the team as a whole has good coverage over each aspect of the dev/ops/test areas and has good communications it's not absolutely necessary that each individual in the team also covers each and every such area. Sure, it's a good thing if that happens, but *requiring* it may get unnecessarily expensive in some cases.  

---

### Answer by username_14 on 2017-12-26. Score: 2

A system administrator is responsible for maintaining and configuring servers and their responsibility is to ensure the user with the performance, uptime and security that they are looking for. Defining the role of a DevOps engineer is a little more difficult since there is no formal career path and DevOps itself can have many forms.

A DevOps engineer can be, for example, a developer who is interested in network and deployment operations or a system administrator who has a passion for coding and scripting. The transition from system administrator to DevOps engineer is not very difficult, in fact, this [article](https://squadex.com/insights/system-administrator-making-leap-devops/) does a very good job describing the process.

Many people would even argue that this transition from system administrator to DevOps engineer is essential since the position of system administrator will become obsolete in the future. Even though there are plenty of legacy servers that need maintenance and system administrators possess a lot of “tribal knowledge” the sysadmin position will become more scarce in the future.


---

### Answer by username_19 on 2018-11-06. Score: -1

There is going to be servers which you do not hear running in data centers. Everything is going to be software. Storage, network, systems, security, data centers; SDN, firewalls, NFV, storage, servers, etc. Sysadmins without a software development background, SDLC experience (I don't even mean scripting Perl, Powershell, etc) will probably vanish. Distributed, scalable and virtualized environments, which is mostly cloud, grow horizontal not vertically.

---

I dare to say Sysadmins grow vertical, DevOps (or OpsDev) grow horizontal. You can see the same pattern how microservices evolved from monoliths. I would rather choose DevOps engineer from software team not from operations/system team.

Because operations/system team just runs what software team builds.

* Sysadmins do not build/compile Linux/FreeBSD/windows kernel etc. just as software engineers build/compile applications.
* Sysadmins do not go through the software development life cycle (SDLC).
* Sysadmins are not part of the production pipeline (CI/CD process).
* Sysadmin start working after CI/Continuous Delivery/Deployment ends.

  And if you break and assign Deployment/Delivery, it could be a broken pipeline  
  the software team is the creator system/operations team are the runners/caretakers mostly.

It sounds like there is no server/system to administer, no sysadmin need.

Serverless computing is a cloud-computing execution model in which the cloud provider acts as the server, dynamically managing the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity
[Serverless computing](https://en.wikipedia.org/wiki/Serverless_computing)

Someone from the software team already knows how to build, maintain even how to code (SRE vs DevOps/OpsDev).

---

I wonder why it is called DevOps but not OpsDev? is it related to the direction between the two?

**\*In the middle of nowhere, I did not start writing about software-defined storage, this is in reaction to a now deleted comment about it \***

### About software-defined storage

* Software-defined storage (SDS) is a marketing term for computer data storage software for policy-based provisioning and management of data storage independent of the underlying hardware.
  [Software-defined storage](https://en.wikipedia.org/wiki/Software-defined_storage)
* EMC announced its first ever open source product: Project CoprHD. CoprHD is a Software Defined Storage automation and management controller, and EMC’s recent decision to open source it is at the crux of our strategy for delivering greater value to global businesses as we enter into an area of growth and extreme change.
  [As the world’s leader in storage and information management, it behooves EMC to lead the way on Software Defined Storage (SDS)](https://www.emc.com/microsites/sds/articles/leading-the-way-software-defined-storage.htm).
* CoprHD is an open source software-defined storage controller and API platform. It enables policy-based management and cloud automation of storage resources for the block, object and file storage providers
  [CoprHD](https://coprhd.github.io/)

> **Comments:**
> **username_6**: Do not re add name calling in your answer, keep it in line with the question, again I recommend you read [answer] for guidance.  
> **username_20**: Why are you replying to a comment to your answer? You should be answering the main question. You are so much off-topic, and what is on-topic is very unprecise or unclear. What do you mean by "Sysadmins grow vertical, DevOps (or OpsDev) grow horizontal"? If you mean the application scalability, that has nothing to do with either SysAdmin or DevOps, but by the application architecture. Nobody can effectively scale a monolith horizontally. Also, most of the SysAdmins today use IaC and config management tools. Why OpsDev when literally everyone uses DevOps?  

---

