The Ops Identity Crisis
This was a good read. As a DevOps Engineer at a company that does not have a distinct Ops department, who&#x27;s also a Tech Lead, I have some thoughts I&#x27;d like to share.<p>First, while the ultimate goal of any engineer (even not among the Ops disciplines) should be to automate yourself out of a job, we have seen time and again that it is impossible to do so, as any good engineer will continue to advance the state of the art. Conclusively, there is no &quot;finish line&quot; for operations that will not be obsolete within 3 years. The concern that you&#x27;ll just have to migrate across organizations, reaching the &quot;finish line,&quot; rinsing and repeating is a non-issue. The notion of a finish line is really sugarcoated FUD. (The author&#x27;s interesting thought experiment alludes to this and does refute the argument, so hopefully my statements simply complement the article in that regard. I call it a thought experiment because we will never arrive at this &quot;you automated everything&quot; goal.)<p>I absolutely agree with the author that we <i>do not really need ops engineers.</i> We <i>do</i>, however, need <i>specific disciplines of software engineering</i>. Specifically, I recommend The Systems Engineering Side of Site Reliability Engineering[1] (as well as the book), Site Reliability Engineering[2] from Google. The usenix article in particular describes three distinct disciplines of software development: systems engineering, site reliability engineering and software engineering. The <i>individuals</i> behind the roles have little to do with the roles themselves (rather, the causal chain is the other way around); it&#x27;s often misunderstood, for whatever reason, that software engineers and operations engineers have different skillsets because of who they are. This is true, but it does not mean that a software engineer cannot, in short order relative to individuals with no software background whatsoever, transition into an operations role, or vice-versa. Orthogonally, identifying individuals with the skills in any of these three disciplines is critical to placing them in work that is personally and professionally rewarding, as well as more valuable to the organization than if they were placed in some other discipline. And sometimes, individuals do not even know of these disciplines or, for whatever reason, think they are suited for a discipline that they are not actually best at. I was one of these people (a software engineer before moving into operations). In essence, what I&#x27;m trying to demonstrate here is that these disciplines of software development are permanent (or have generations-length longevity) and we should not be concerned with being replaced or becoming obsolete. Indeed, it is the <i>specific tasks</i> that will change over time. Consider, for example, electrical engineers. We do not anticipate that EE&#x27;s will be replaced by robots. Despite robots automating the process of manufacturing circuits, EE&#x27;s will always be invaluable and irreplaceable. However, their specific responsibilities will change over time. This is why I said before, advancing the state of the art results in new work (or even types of work) to exist. Finally -- and this is just a bonus -- any experience acquired by, say, an EE will be useful even if he or she transitions to a new discipline of engineering. In my experience, the best software engineers I ever known have understood in remarkable depth CPU architecture, memory models, networking protocols, configuration management, etc.<p>&gt; there is practically no difference between a software engineer and an operations engineer - they both build and run their own systems - other than the domain: the software engineer builds and runs the top-level applications, while the (ex-)operations engineer builds and runs the infrastructure and tooling underneath the applications.<p>The above statement from the article&#x27;s thought experiment vaguely describes two (of the three) software engineering disciplines that Hixson[1] talks about. Operations engineers and software engineers alike are, in this thought experiment, responsible for leveraging their expertise and talent (understand that I use the word talent according to the definition described by Hixson) at maximum efficiency. The manifestation of these disciplines is reflected in their <i>domain</i>, but the individual tasks themselves are only relevant today and will change tomorrow. The third discipline not described here (systems engineering) is very much relevant and deals specifically with the interactions among systems, which neither operations nor software engineers will focus on (or necessarily have significant talent in). Later in the article, the author sort of blends SRE (site reliability engineers) and SE (systems engineers) together. The distinction isn&#x27;t important for the author to make her point, but I wanted to highlight it a little bit.<p>Second, I think the author describes an environment that strongly reflects the ideals of the DevOps movement. From my reading, I&#x27;m inferring that the author is aligned with these ideals. I consider this a big selling point if I ever wanted to consider Uber as a place of employment. As some other comments here on HN have noted: it is extremely rare and difficult to find an organization that has embraced DevOps principles with such purity. I&#x27;m fortunate to be employed at one of them (not Uber), and it sounds like Uber has made some good decisions as an organization in this regard. (Hopefully this paragraph can be to the benefit of any employment-seeking operations engineers. The statements in the article reflect positively on Uber, particularly if you are trying to move from a traditional operations role to a DevOps&#x2F;SE&#x2F;SRE role.)<p>Third, the article does a great job refuting the 3 identified arguments. In general, I can&#x27;t agree more! The author takes the time to consider the merit of each argument and qualify the conditions under which they are true before refuting them, which makes it much easier to read coming from a more traditional organization. From my biased perspective, I don&#x27;t even give these arguments the light of day and refute them without thinking twice about the qualifications that can alter their accuracy; so, one takeaway for me from the article has been to <i>not</i> make the assumption that these arguments are being made by like-minded individuals. It&#x27;s quite likely that I&#x27;m too hard on people for bringing up concerns like these and, as a result, not open to new (old) ideas.<p>My final thought on the article is that, while it&#x27;s not really news in most of the social circles I spend my time with (as a byproduct of having learned much of what I know from a stellar colleagues in a great work environment -- not because of any personal accomplishment), I really appreciate that the author took the time to write out these thoughts and publish them so that the broader software community can grow and adopt ideals that move our industry forward in a very positive, very significant way. So thanks to the author, and to aberoham who posted the link here on HN!<p>[1] <a href="https:&#x2F;&#x2F;www.usenix.org&#x2F;publications&#x2F;login&#x2F;june15&#x2F;hixson" rel="nofollow">https:&#x2F;&#x2F;www.usenix.org&#x2F;publications&#x2F;login&#x2F;june15&#x2F;hixson</a><p>[2] <a href="https:&#x2F;&#x2F;landing.google.com&#x2F;sre&#x2F;book.html" rel="nofollow">https:&#x2F;&#x2F;landing.google.com&#x2F;sre&#x2F;book.html</a>