[untitled]
4 comments
I've seen, in my decade of experience in tech, that a well-worded and keyword-packed marketing ploy is as irresistible as gravity to many. As the seductive promises and successful toy examples accrete around the neutron soup of buzzwords, a marketing mass finally reaches an influential Schwarzschild radius. Businesses that come within this radius are pulled in and obliterated, but they have no knowledge of their destruction. They've passed the event horizon and are now in a place where causality and reason have been up-ended. Their demise would only be detectable outside in the faint Hawking radiation that is drowned out by the background noise of self-congratulatory back-patting.
These pie-in-the-sky companies are necessary in the tech galaxy. Their primary purpose is to weed out those businesses who don't have the wisdom or tenacity to take on the challenges themselves. Their secondary purpose is to teach future tech leaders a hard lesson: there is no silver bullet.
These pie-in-the-sky companies are necessary in the tech galaxy. Their primary purpose is to weed out those businesses who don't have the wisdom or tenacity to take on the challenges themselves. Their secondary purpose is to teach future tech leaders a hard lesson: there is no silver bullet.
One correction... I believe that Forrester "invented" the term NoOps and did so quite a while ago.
cool:)
So let's talk about the marketing term "No-Ops."
In AppFog's attempt to assert a meaning over the marketing term, we're told that it means "developers can code and let a service deploy, manage and scale their code." I have yet to meet a single company facing a sizable technical challenge whose performance and availability needs could be met by a strait-jacket PaaS with an autoscale button. I'm not saying that many smaller companies don't use such services successfully – that's very much true. But let's be clear: the dream of push-button autoscaling while letting "somebody else" handle deployment, monitoring, instrumentation, and anything that may go wrong in the middle of the night is a marketing dream. As engineers, we have a business need and emotional need to own our availability [1]. Placing the sum total of your operations into a PaaS providers hands, biting down hard on that marketing dream of NoOps, and throwing the pager out the window doesn't mean you have nothing to worry about. It just means that you don't care, and can do nothing about it.
But it's not enough to stop there. Instead, the author sees fit to posit his / her marketing term as the continuation of a history in the evolution of web operations, and proclaim that the term is one that "traditional operations" personnel revile. If "No-Ops" is a success of any sort, it's a marketing win, not a technical one – and certainly not an operational one. If you think that you can place every single egg in your company's basket in the hands of PaaS providers and never worry again until you have to twiddle the auto-scale dial after which everything will be fine, you're only fooling yourself.
Who will migrate data on an oversubscribed Postgres shard to two more shards by night by partitions of account IDs? Who will enable dual-writes, run a migration, then cut over reads as we move into Riak? Who will notice a spike in await on the Kafka RAID, recognize the week-over-week trends pointing to your team running out of iops, order, and rack a set of new boxes with SSDs before it's too late? Who's watching the switches and keeping track of which racks have GigE and which have 10GigE uplinks to the next rack to avoid oversubscribing the network?
It's rare in our industry to see a promise so removed from reality. Indeed, if NoOps is a movement at all, it's powered only by the dream of not having to do one's job which is to ensure that a company is able to deliver on their business value. Who among us isn't tempted by such a promise? [2]
[1] http://www.whoownsmyavailability.com/
[2] http://www.youtube.com/watch?v=fM9o8MxLX3Q