Two Weeks or Four: A Cautionary Tale
November 23rd, 2007 by Lou
I stumbled across more detail from Rich Manalang regarding the Oracle Mix deployment on JRuby and the Oracle Application Server. I orginally wrote a post about this after meeting Rich and Jake at Oracle World last week.
Its more than a little interesting, but not surprising or atypical, that finding production hardware consumed so much of the team’s attention.
How many enterprises can deploy any useful, inovative, inexpensive, rapidly developed application in less than several months, much less in weeks? What happens in a year or so when there are hundreds of these completed applications in backlog, waiting for a home, rather than one or two?
The Ruby on Rails phenomenon is part of the modern equivalent of the IBM PC that killed the mainframe glass-house operation. Enterprise IT organizations ignore this fact at their peril. An IT operation that can’t deploy new applications, without procurement cycles, in minutes rather than months is doomed far sooner than we may think.
deployment, jruby, rails, ror
“An IT operation that can’t deploy new applications, without procurement cycles, in minutes rather than months is doomed far sooner than we may think.”
Ah, yes, procurement. This is the reason that the last two shops I’ve worked at switched off of Sun hardware. We couldn’t get the beautiful hardware fast enough.
Think what you like about Dell (and I don’t say much good about them), when you call your account rep and say, “I need 25 more servers”, they ask, “Would you like those shipped tomorrow?”
Procuring hardware from Sun, to my dismay, requires too much effort. I want to call someone and say, “Send me another 20 x4600s. I want them by Friday.” For whatever reason, that doesn’t ever seem possible.
As much great stuff Sun has been doing lately — and it’s a lot of neat things — procurement is horribly broken, and it’s leaving a bad taste in the mouths of a lot of people.
I’m sorry to hear of your difficulties and have forwarded your comment to someone who I hope will help. I hope the difference in delivery times is no more than a week or so and is worth the difference in capability.
To clarify, my post was not only about the vendor portion of the procurement cycle. Procurement and provisioning is time consuming and expensive in the most efficient organization, and the vendor portion of the time line is not generally where the greatest challenges are, despite the fact this piece is almost always on the critical path. That is, its best to avoid procurement cycles, period, whatever the vendor delivery capability.
For the general purpose IT shop, providing services to multiple business units for multiple applications, the current prevailing architecture and service models *compel* hardware procurement, even when ample excess capacity is available. This is primarily due to one machine one application deployments, inefficient business models and the lack of homogeneity and consistency in the service stack. There is no architectural or business governance or strategy to support higher utilization rates.
Of course, the general purpose IT shop is the modern equivalent of the mainframe glass house operation. It will give way to SaaS subscriptions following a pattern of anti-adoption where the heterogeneity of service stacks and business led infrastructure deployments are viewed as entrenched legacy to be contained lest growth and margins shrink.
2-3 years ago Sun escaped the containment list in these general purpose shops only to find itself sent to the containment lists at certain SaaS providers. Performance and innovation delivered Sun from the former containment lists. The operational course corrections required to escape the latter ought to be easy by comparison.