Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-04-16T19:22:43.587Z
Answers: 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.)
Answers: cjs
Answers: CC BY-SA 3.0
Answers: 2017-03-04T16:14:09.727Z
Answers: So much this... DevOps is **not** a role. You "do" system administration in a different way as "part" of a DevOps culture.
Answers: Ken Mugrage
Answers: CC BY-SA 4.0
Answers: 2019-03-01T09:17:22.117Z
Answers: "DevOps is roughly an organization pattern", the more enlightening snippet I have read so far.
Answers: Diagathe Josué
Answers: CC BY-SA 4.0
Answers: 2019-07-31T07:06:52.337Z
Answers: May be you can clarify that DevOps != NoOps
Answers: sgargel
Answers: CC BY-SA 4.0
Answers: 2022-06-06T23:43:33.560Z
Answers: I would specify "Operations" is a common team deploying software the developers maintain - hence the **Ops** in Dev**Ops**.
Answers: Ari
Answers: CC BY-SA 3.0
Answers: 2017-03-01T10:47:01.327Z
Answers: 2017-03-01T10:47:01.327Z
Answers: Tensibai
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-07-26T03:11:53.710Z
Answers: 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.
Answers: Dan Cornilescu
Answers: CC BY-SA 4.0
Answers: 2017-07-25T22:07:56.623Z
Answers: 2018-11-02T19:50:59.083Z
Answers: 2018-11-02T19:50:59.083Z
Answers: 030
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-12-26T09:16:52.260Z
Answers: 2017-12-26T11:35:03.170Z
Answers: 2017-12-26T11:35:03.170Z
Answers: DevOps Jedi
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2017-08-08T19:06:57.060Z
Answers: Excellent summary! Best I've yet seen about the history behind this philosophy and engineering style.
Answers: Jesse Adelman
Answers: CC BY-SA 4.0
Answers: 2020-07-27T03:23:47.700Z
Answers: And, also, this should be the Accepted answer, IMO. :)
Answers: Jesse Adelman
Answers: CC BY-SA 4.0
Answers: 2020-09-25T09:47:41.760Z
Answers: 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
Answers: Luke
Answers: CC BY-SA 3.0
Answers: 2017-04-16T20:13:30.983Z
Answers: 2017-04-16T20:13:30.983Z
Answers: 2020-06-18T08:28:10.803Z
Answers: Richard Slater
Answers: <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>
  
Answers: CC BY-SA 3.0
Answers: 2018-01-18T06:31:36.433Z
Answers: 2018-01-18T09:07:44.380Z
Answers: 2018-01-18T09:07:44.380Z
Answers: rdp-cloud
Answers: <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>
  
Answers: CC BY-SA 4.0
Answers: 2018-11-06T22:19:15.680Z
Answers: Do not re add name calling in your answer, keep it in line with the question, again I recommend you read [answer] for guidance.
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2022-01-10T15:10:14.430Z
Answers: 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?
Answers: djboris
Answers: CC BY-SA 4.0
Answers: 2018-11-06T05:20:27.167Z
Answers: 2018-11-06T22:14:34.247Z
Answers: 2018-11-06T22:14:34.247Z
Answers: hakkican
Body: <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>
  
Comments: CC BY-SA 3.0
Comments: 2017-05-19T16:25:13.637Z
Comments: @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.
Comments: James Shewey
Comments: CC BY-SA 3.0
Comments: 2017-12-30T08:40:54.677Z
Comments: 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) :-)
Comments: setevoy
Comments: CC BY-SA 3.0
Comments: 2017-03-01T11:03:15.127Z
Comments: Related: [What is the difference between SRE and DevOps?](http://devops.stackexchange.com/questions/86/what-is-the-difference-between-sre-and-devops)
Comments: Sathyajith Bhat
Comments: CC BY-SA 3.0
Comments: 2017-03-01T17:16:29.250Z
Comments: 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)
Comments: Woodland
Comments: CC BY-SA 3.0
Comments: 2017-03-01T17:17:20.517Z
Comments: SRE and sysadmin terms are different.
Comments: kenorb
Comments: CC BY-SA 3.0
Comments: 2017-03-01T19:45:27.970Z
Comments: 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.
Comments: Evgeny Zislis
Comments: CC BY-SA 3.0
Comments: 2017-03-01T19:47:44.427Z
Comments: @Evgeny Tell that to recruitment agencies.
Comments: kenorb
Tags: <terminology>
Title: What is the difference between Sysadmin and DevOps Engineer?
UserDisplayName: kenorb
ThreadText: # 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 [username_14 Engineer](https://stackoverflow.com/jobs?sort=i&q=username_14).
  
  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 username_14?](http://username_14.stackexchange.com/questions/86/what-is-the-difference-between-sre-and-username_14)  
  > **username_4**: Possible duplicate of [What is the difference between SRE and username_14?](http://username_14.stackexchange.com/questions/86/what-is-the-difference-between-sre-and-username_14)  
  > **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 username_14. I personally think that username_14 is not even a role ... so I would have some say on the matter.  
  > **username_0**: @username_5 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 username_14 conference, there was the same question, and the reporter's answer was a joke, obviously, but with with a downhill of the truth: "username_14 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 username_14 is not a role (when used as such it's more a buzzword than a real role).
  
  username_14 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... username_14 is **not** a role. You "do" system administration in a different way as "part" of a username_14 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**: "username_14 is roughly an organization pattern", the more enlightening snippet I have read so far.  
  > **username_10**: May be you can clarify that username_14 != 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
  
  username_14 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 username_14 came out of the Systems Administration, Operations and Agile communities, specifically, [Patrick Debois](https://twitter.com/patrickdebois) gave a [presentation at Agile2008](http://www.username_14.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 **username_14**.
  
  The idea of username_14 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-username_14-Helping-Business-ebook/dp/B00AZRBLHO) and [The username_14 Handbook](https://www.amazon.co.uk/username_14-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 username_14 engineers can do anything the boss want by 2 x 80k/year  
  
  ---
  
  ### Answer by username_18 on 2018-01-18. Score: 13
  
  As a *username_14* 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 *username_14* 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 *username_14* 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. username_14 (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 username_14 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.
  
  username_14
  
  According to [Wikipedia](https://en.wikipedia.org/wiki/username_14):
  
  > username_14 (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.
  
  [username_14](https://upload.wikimedia.org/wikipedia/commons/b/b5/username_14.svg)
  
  [![enter image description here](https://i.sstatic.net/tdlPb.png)](https://i.sstatic.net/tdlPb.png)
  
  [username_14 Toolchain](https://upload.wikimedia.org/wikipedia/commons/0/05/username_14-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 username_14 engineer is a little more difficult since there is no formal career path and username_14 itself can have many forms.
  
  A username_14 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 username_14 engineer is not very difficult, in fact, this [article](https://squadex.com/insights/system-administrator-making-leap-username_14/) does a very good job describing the process.
  
  Many people would even argue that this transition from system administrator to username_14 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, username_14 (or OpsDev) grow horizontal. You can see the same pattern how microservices evolved from monoliths. I would rather choose username_14 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 username_14/OpsDev).
  
  ---
  
  I wonder why it is called username_14 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, username_14 (or OpsDev) grow horizontal"? If you mean the application scalability, that has nothing to do with either SysAdmin or username_14, 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 username_14?  
  
  ---
  
  