John Allspaw jallspaw

Adrian -

I appreciate that you spent time in writing this post. I know I've been up until 2am writing similarly long ones as well. I will take responsibility for having what is likely an irrational response (I blame Twitter for that) to the term "NoOps", but I invite you to investigate why that might be. I'm certainly not the only one who feels this way, apparently, and thus far have decided this issue is easily the largest distraction in my field I've encountered in recent years. I have had the option to simply ignore my opposition to the term, and just let the chips fall where they may with how popular the term "NoOps" may or may not get. I have obviously not taken that option in the past, but I plan to in the future.

You're not an analyst saying "NoOps". Analysts are easy (for me) to ignore, because they're not practitioners. We have expectations of engineering maturity from practitioners in this field of web engineering, especially those we consider leaders. I don't have any expectations from analysts,

	1. Monolithic applications and architectures can vary in their monolithness. This is an under-specified description.
	2. Microservice applications and architectures can vary in their microness. This is an under-specified description.
	3. Microservices and monolithic architectures have both benefits and disadvantages.
	4. Organizations will exploit those benefits while working around any weaknesses.
	5. Success of the business is a large influence on the exploitation of benefits and implementation and costs of workarounds.
	6. All benefits and work arounds are context-sensitive. Meaning that they are both technically and socially constructed by the organization that navigates them.
	7. Path dependency is a thing. History matters and manifests in these architectural decisions and evolution in an organization.
	8. Patterns exist to inform practice, not dictate it. Zealous adherence to an architectural pattern brings peril when it is to the exclusion of cultural context in actual practice.
	9. Architectural patterns w

	- Metrics collection
	- PaaS/IaaS evaluation/investigation
	- Automation (auto-build, auto-recovery)
	- Fault tolerance
	- Availability
	- Monitoring
	- Performance
	- Capex and Opex forecasting
	- Outage response

	For shits and giggles, I ran (http://code.google.com/p/byte-unixbench/) on a c1.xtralarge EC2 instance:

	BYTE UNIX Benchmarks (Version 5.1.2)

	System: ip-ec2.thing.com: GNU/Linux
	OS: GNU/Linux -- 2.6.21.7-2.ec2.v1.2.fc8xen -- #1 SMP Fri Nov 20 17:48:28 EST 2009
	Machine: x86_64 (x86_64)
	Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
	CPU 0: Intel(R) Xeon(R) CPU E5410 @ 2.33GHz (4669.8 bogomips)
	Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSCALL/SYSRET, Intel virtualization