IT, Complexity, and Clouds Redux

Update:

I listed to Dr. Paul Borrill’s (exSun DE, VP, Veritas CTO) talk at Stanford on itunes the other day. I loved it. My favorite statement was on TIME = CHANGE. It’s exactly in line with much of my thinking and observations after life in IT for 15+ years. I and some other smart people at Sun (now Oracle) put some of this to “code” with DSC – dynamic service containers awhile back. But listening to his talk inspired me to do some more thinking in this space. I’m reposting this here. It was on my other blog a couple years ago or so.

I also read Lori MacVittie’s post on Apathy vs Architecture — it highlights some other aspects of why we are here and why we must work harder to solve the hard problems.

More to come but here’s some background…

I’ve been doing some thinking lately around the cloud model and how enterprises might adopt it. Enterprises are challenged with a conflict — between giving their developers control and choices, and maintaining operational control. Case in point — the ownership around SLAs if often with the operations/adminsitration org — not the developer. The developer in many cases is hoping that most of the “systemic qualities” will appear within the platform and not necessarily require lots of development time. An interesting example of improvement in this space is the SHOAL project around Glassfish.

One of my employees is working on some modeling projects — trying to model the data center “as is” vs deriving the model from a “perfect” state where choices are somewhat removed from the scenario. I mean the data center is architected in specific ways that allow or disallow some functionality — you see this in very large sites, like Google and Yahoo. They have several major architecture patterns where many or most services confirm to those patterns. You want to deploy? You conform.

This battle is often up hill. The last 20% of a solution is the area that you spend the most time on, convincing others of the design or that “good enough” will trump perfect. But I think we need to get over that — we can’t afford not to.

Graffiti is a good example. Hand writing recognition was very hard, companies failed trying to figure this out. Did they constrain the problem (thus the solution) enough to progress to something that works without a whole bunch of “change?” Jeff got it right — fix the few letters that cause the problem (i vs L) and constrain the problem. He found a solution. We’ve gotten a bit more flexible today but its still the core thinking in the industry.

What problems can we solve today if we limit the choices, give a way a little control, and are able to take technology to the next level?

UPDATE: Forgot the Jason Corollary: “Impossible” exists only because we haven’t stated or re-factored the problem so it is “possible.”

Advertisements

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: