<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Engineering and Operations: Bridging the Divide</title>
	<atom:link href="http://daemons.net/~clay/2009/04/02/engineering-and-operations-bridging-the-divide/feed/" rel="self" type="application/rss+xml" />
	<link>http://daemons.net/~clay/2009/04/02/engineering-and-operations-bridging-the-divide/</link>
	<description>merely my musings</description>
	<lastBuildDate>Fri, 12 Mar 2010 15:34:34 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Brian Merritt</title>
		<link>http://daemons.net/~clay/2009/04/02/engineering-and-operations-bridging-the-divide/comment-page-1/#comment-204</link>
		<dc:creator>Brian Merritt</dc:creator>
		<pubDate>Tue, 21 Jul 2009 23:09:00 +0000</pubDate>
		<guid isPermaLink="false">http://daemons.net/~clay/?p=97#comment-204</guid>
		<description>Very nice post Clay. Unfortunately, it has been a rare treat to read something so articulate and thoughtful about our industry.

I agree with much of what you say, but I have a slightly different take, and may share some of John&#039;s reservation. I&#039;ve always been confused by the rich number of silos that exist and are always being created within IT. When I began my Internet life, I was dumped into a shell without much more than a blinking cursor and a pat on the back. I had to figure it out. When I wanted to run a machine that could run the flavor of BSD I preferred, I had to build it. When I wanted a lab to try things out in, I had to learn networking in order to build it. In order to allow me to single-handedly manage a growing userbase, I learned how to write scripts and tools. When my employer wanted to build a national network, I had to learn a lot more.

Once I learned enough about networks to realize the intriguing growth possibilities, I had to improve my programming skills and learn elements of software architecture, so my tools would scale properly. When my attraction to scale took me to a much larger shop, I had to learn about the theory of operations. When I started doing consulting, I had to learn about project management, as well as &quot;the business&quot;. When I joined a VC company, I had to learn how to evaluate things that didn&#039;t exist, and consider the many paths that we might all end up following. When I went to academia, my attraction to scale and complexity took me into high performance computing and cognitive computing, where concepts of parallelism, distribution, and efficient automation and management were not nice to haves, but must haves.

All the while, I never felt that I was changing into a different person. My pursuit of perfection in my work, birthed by access to uptime(1) and a motley community of competitive hackers, never wavered. My interest in understanding how systems worked remained acute, and the more systems the better -- including &#039;soft&#039; systems, like organizations, businesses, economies, brains. I was a hacker, and my primary tools were not shell commands or Linux packages. They were, are, and always will be my curiosity, my intuition, my way of thinking and unpacking problems into constituent parts, my energy, my passion for learning, my willingness to push boundaries, and my fearlessness.

At the time I began, available resources were scarce -- most of the knowledge was locked up in small social circles, traded at conferences and deep within vendor circles and universities. Of course, information quickly exploded, and today the amount of valuable information out there is stunning.

While I am reluctant to call this out as a bad thing, I have noticed the industry change enormously. I did a stint in academia for about 4 or 5 years, and when I came back to the valley, everything had changed. Many of the top engineers I worked with after the hiatus had graduated from CS programs while I was out of the industry. Some of them were born with Linux distros in their laps. Their skillsets were impressive and accomplishments myriad, but it felt like something was missing. The average mentality that I had been exposed to when I came up was like me -- a hacker. Now it seems to have morphed into something else, but I&#039;m not sure what to call it. Computer scientist? Or maybe Capitalist?

I can&#039;t be sure, but I feel that the massive growth in the industry, the amount of money being thrown around, and the ever growing amount of shared knowledge in the cloud is having at least one adverse effect. In my opinion, there is too much specialization, and too much focus around goals that involve more traditional pursuits such as ego, money, and traditional status. I see less focus on knowledge for the pure sake of it, ability for the honor in it, and uptime for the glory.

I dearly miss the old days, but I&#039;m glad that I&#039;m young enough still (31) to be a part of more than one major era in the development of the Internet, and I&#039;m proud to have been raised by hackers who were there at the beginnings. For myself personally, I count 5 eras so far -- pre-Mosaic, pre-Netscape IPO, pre-dotcom crash, web2.0, and now the cloud era. For my 15 or so years in IT, that&#039;s an average of 1 new era every 3 years. It&#039;s incredible when you think about it with some perspective.

Things are moving quickly. I don&#039;t know what will come next, but I hope we don&#039;t end up destroying all of the opportunities for young kids like me to be exposed to the broad variety of fascinating and exciting challenges within IT, and within life. I hope that curious young people are given the opportunity to take their time with things, to learn about them more deeply, and to gain wisdom rather than just collections of repeatable skills. The world needs hackers, not just role players.</description>
		<content:encoded><![CDATA[<p>Very nice post Clay. Unfortunately, it has been a rare treat to read something so articulate and thoughtful about our industry.</p>
<p>I agree with much of what you say, but I have a slightly different take, and may share some of John&#8217;s reservation. I&#8217;ve always been confused by the rich number of silos that exist and are always being created within IT. When I began my Internet life, I was dumped into a shell without much more than a blinking cursor and a pat on the back. I had to figure it out. When I wanted to run a machine that could run the flavor of BSD I preferred, I had to build it. When I wanted a lab to try things out in, I had to learn networking in order to build it. In order to allow me to single-handedly manage a growing userbase, I learned how to write scripts and tools. When my employer wanted to build a national network, I had to learn a lot more.</p>
<p>Once I learned enough about networks to realize the intriguing growth possibilities, I had to improve my programming skills and learn elements of software architecture, so my tools would scale properly. When my attraction to scale took me to a much larger shop, I had to learn about the theory of operations. When I started doing consulting, I had to learn about project management, as well as &#8220;the business&#8221;. When I joined a VC company, I had to learn how to evaluate things that didn&#8217;t exist, and consider the many paths that we might all end up following. When I went to academia, my attraction to scale and complexity took me into high performance computing and cognitive computing, where concepts of parallelism, distribution, and efficient automation and management were not nice to haves, but must haves.</p>
<p>All the while, I never felt that I was changing into a different person. My pursuit of perfection in my work, birthed by access to uptime(1) and a motley community of competitive hackers, never wavered. My interest in understanding how systems worked remained acute, and the more systems the better &#8212; including &#8217;soft&#8217; systems, like organizations, businesses, economies, brains. I was a hacker, and my primary tools were not shell commands or Linux packages. They were, are, and always will be my curiosity, my intuition, my way of thinking and unpacking problems into constituent parts, my energy, my passion for learning, my willingness to push boundaries, and my fearlessness.</p>
<p>At the time I began, available resources were scarce &#8212; most of the knowledge was locked up in small social circles, traded at conferences and deep within vendor circles and universities. Of course, information quickly exploded, and today the amount of valuable information out there is stunning.</p>
<p>While I am reluctant to call this out as a bad thing, I have noticed the industry change enormously. I did a stint in academia for about 4 or 5 years, and when I came back to the valley, everything had changed. Many of the top engineers I worked with after the hiatus had graduated from CS programs while I was out of the industry. Some of them were born with Linux distros in their laps. Their skillsets were impressive and accomplishments myriad, but it felt like something was missing. The average mentality that I had been exposed to when I came up was like me &#8212; a hacker. Now it seems to have morphed into something else, but I&#8217;m not sure what to call it. Computer scientist? Or maybe Capitalist?</p>
<p>I can&#8217;t be sure, but I feel that the massive growth in the industry, the amount of money being thrown around, and the ever growing amount of shared knowledge in the cloud is having at least one adverse effect. In my opinion, there is too much specialization, and too much focus around goals that involve more traditional pursuits such as ego, money, and traditional status. I see less focus on knowledge for the pure sake of it, ability for the honor in it, and uptime for the glory.</p>
<p>I dearly miss the old days, but I&#8217;m glad that I&#8217;m young enough still (31) to be a part of more than one major era in the development of the Internet, and I&#8217;m proud to have been raised by hackers who were there at the beginnings. For myself personally, I count 5 eras so far &#8212; pre-Mosaic, pre-Netscape IPO, pre-dotcom crash, web2.0, and now the cloud era. For my 15 or so years in IT, that&#8217;s an average of 1 new era every 3 years. It&#8217;s incredible when you think about it with some perspective.</p>
<p>Things are moving quickly. I don&#8217;t know what will come next, but I hope we don&#8217;t end up destroying all of the opportunities for young kids like me to be exposed to the broad variety of fascinating and exciting challenges within IT, and within life. I hope that curious young people are given the opportunity to take their time with things, to learn about them more deeply, and to gain wisdom rather than just collections of repeatable skills. The world needs hackers, not just role players.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: clay</title>
		<link>http://daemons.net/~clay/2009/04/02/engineering-and-operations-bridging-the-divide/comment-page-1/#comment-164</link>
		<dc:creator>clay</dc:creator>
		<pubDate>Sat, 27 Jun 2009 16:01:05 +0000</pubDate>
		<guid isPermaLink="false">http://daemons.net/~clay/?p=97#comment-164</guid>
		<description>@allspaw: Thanks for your comment. Flickr is a great example of how two teams can amicably and efficiently run a large, dynamic site. It&#039;s interesting to see how different sites approach the SRE position. Google SRE reports into engineering, whereas Facebook SRE reports into operations. The design of the reliability team, and of the software release process, seems to vary with company culture and platform architecture.

At Ning, we don&#039;t have a dedicated SRE team -- instead, we have weekly on-call rotations in eng and ops. I have maybe a somewhat unusual perspective, having been on-call first in ops and then later in eng. Our guiding philosophy is that &quot;operations owns production,&quot; which means the on-call engineer does not have authority to deploy code or restart services. Instead, the on-call engineer can request that the on-call operations person make a certain change. I think this is a common approach in enterprise shops, especially those with SOX or PCI compliance concerns, but I&#039;m not sure it scales for web shops doing multiple deployments a day -- hence my post.

Something about a tripartite organization consisting of specialized infrastructure, feature, and availability teams appeals to me, but I&#039;ve not seen it done this way in practice. The success of Flickr, Facebook, and Google does seem to suggest that a third, top-level SRE team may not be necessary. In Ning&#039;s case, we might be able to increase efficiency and reduce tension if we empowered engineering to deploy code and restated our core philosophy as, &quot;the on-call team owns production.&quot;</description>
		<content:encoded><![CDATA[<p>@allspaw: Thanks for your comment. Flickr is a great example of how two teams can amicably and efficiently run a large, dynamic site. It&#8217;s interesting to see how different sites approach the SRE position. Google SRE reports into engineering, whereas Facebook SRE reports into operations. The design of the reliability team, and of the software release process, seems to vary with company culture and platform architecture.</p>
<p>At Ning, we don&#8217;t have a dedicated SRE team &#8212; instead, we have weekly on-call rotations in eng and ops. I have maybe a somewhat unusual perspective, having been on-call first in ops and then later in eng. Our guiding philosophy is that &#8220;operations owns production,&#8221; which means the on-call engineer does not have authority to deploy code or restart services. Instead, the on-call engineer can request that the on-call operations person make a certain change. I think this is a common approach in enterprise shops, especially those with SOX or PCI compliance concerns, but I&#8217;m not sure it scales for web shops doing multiple deployments a day &#8212; hence my post.</p>
<p>Something about a tripartite organization consisting of specialized infrastructure, feature, and availability teams appeals to me, but I&#8217;ve not seen it done this way in practice. The success of Flickr, Facebook, and Google does seem to suggest that a third, top-level SRE team may not be necessary. In Ning&#8217;s case, we might be able to increase efficiency and reduce tension if we empowered engineering to deploy code and restated our core philosophy as, &#8220;the on-call team owns production.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Allspaw</title>
		<link>http://daemons.net/~clay/2009/04/02/engineering-and-operations-bridging-the-divide/comment-page-1/#comment-162</link>
		<dc:creator>John Allspaw</dc:creator>
		<pubDate>Fri, 26 Jun 2009 23:02:23 +0000</pubDate>
		<guid isPermaLink="false">http://daemons.net/~clay/?p=97#comment-162</guid>
		<description>While I agree with a lot of the points you make, and I see the purpose of the SRE distinction, I can&#039;t help but feel that the &quot;us versus them&quot; divide in perspectives can be bridged without creating a &#039;middle&#039; ground group.

Still thinking on it...</description>
		<content:encoded><![CDATA[<p>While I agree with a lot of the points you make, and I see the purpose of the SRE distinction, I can&#8217;t help but feel that the &#8220;us versus them&#8221; divide in perspectives can be bridged without creating a &#8216;middle&#8217; ground group.</p>
<p>Still thinking on it&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jonathan Aquino</title>
		<link>http://daemons.net/~clay/2009/04/02/engineering-and-operations-bridging-the-divide/comment-page-1/#comment-64</link>
		<dc:creator>Jonathan Aquino</dc:creator>
		<pubDate>Mon, 06 Apr 2009 21:13:47 +0000</pubDate>
		<guid isPermaLink="false">http://daemons.net/~clay/?p=97#comment-64</guid>
		<description>Interesting idea!</description>
		<content:encoded><![CDATA[<p>Interesting idea!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
