Integrating Instapaper with TTYtter

If you're using TTYtter as a command line twitter client in a shell environment and you want /url to add the link in a tweet to your Instapaper account, the following entry in .ttytterrc will accomplish this:

urlopen=curl -s -d username="USERNAME" -d password="PW" -d url=%U https://www.instapaper.com/api/add

Not This Leg Either

Late in Season 1 of House MD, House discloses the story behind his limp and his addiction to painkillers... he was diagnosed with a blood clot in his leg, and rather than follow the doctor's advice to amputate the leg, he demanded a different, more risky procedure that involved circumventing the clot with a vein.  House cited an "irrational attachment" to his leg for this illogical stance.

As he was preparing for the surgery, he wrote on his bad leg... "Not This Leg Either."

Two things stood out in this episode to me.  First off, I understand a common caution given to medical students (and doctors, for that matter) is to not self-diagnose nor self-treat whatever affliction you think you have.

Very sage advice, since when you are personally involved, it prejudices your thinking.  Why is it then, that so many IT professionals try to self diagnose when it comes to their environments?  In many cases, those people either caused or contributed to the issues in the environment they are supporting!  As Einstein said, We can't solve problems by using the same kind of thinking we used when we created them.”

Too often I've seen people attack recommendations for rational, low risk improvements simply because they had too much emotional investment in the current design to realize that the suggestions are for the best.  When you're too close to an issue, it becomes easy to fall into "ditch digger's syndrome."

The second thing that resonated with me in that episode was House's admittance that his decision not to amputate was irrational and due to his attachment to his leg.  How many irrational beliefs are holding IT organizations back today?

• Server Huggers (i.e. "You Can't Virtualize Exchange/SAP/etc") - Actually, quite often, you can.
• Conversely, Virtualization Huggers (i.e. "You must virtualize everything!") - Ultimately, technical decisions have to come down to what provides the best return to the business on the investment.  Many times, that may be virtualization... but not every time.  Are you sure that your virtualized environments are saving you money?
• We absolutely need five 9s of availability - Have you actually determined whether or not all systems can justify the infrastructure and cost that five 9s requires?

IT people shouldn't be primarily technology advocates... they should be business advocates that understand how technology can be used to increase the profitability and ability for their business to deliver.  Otherwise, they are just trumpeting whatever the current buzzword that vendors are hyping as the current cure for all the issues in their environment.

CIO Cloud Initiatives

With VMworld just around the corner, I've been reflecting on EMC World's focus of "the journey to the private cloud." Even today, some of the statements made during the opening keynote by Joe Tucci still don't sit well with me.

In the keynote, Joe showed a slide that had a list of ten top CIO initiatives for 2010.  The third initiative was Cloud Computing, followed closely by Storage Virtualization.  People can argue endlessly on how accurate surveys such as this one are, but from a hype standpoint, Cloud Computing is definitely up there.

I question how many of those CIOs have an accurate understanding on the nature and skills of their IT organization and how that impacts the feasibility of internally implementing a private cloud... successfully at least.  I've always pictured the "journey to the private cloud" as a model similar to Maslow's hierarchy of needs.

On the lowest level, you have the technical competence of staff.  Is your organization properly staffed with the right type of IT people to architect, implement, and administer a private cloud?  Or are there a substantial number of fiefdoms staffed by "next-next-finish" administrators?  Any gaps here would need to be resolved before a private cloud could be successfully implemented.  The resulting architecture is going to be most likely more complex and automated than the current environment, and this will amplify any skills gaps.

The next level is the maturity of workflows and processes.  Are the steps for implementing new IT systems well defined?  Is there a good understanding on where time is being spent for new system implementations?  More importantly, are the processes relevant and actually followed, with appropriate budget and technical approval in place to ensure that new systems are properly financed and designed?  How is chargeback handled?  Without good processes and workflows, all private cloud provides is the automation of broken processes and a further lack of fiscal responsibility.

The third level is the organization's current state of virtualization.  What is the current percentage of systems virtualized?  What barriers exist to increase this percentage?  Is the environment stable, performant, and well managed?  If your organization is bad at virtualization, it will be terrible at private cloud.

If the organization is successful on those three levels, then the private cloud is likely the next step to take to further increase the business value of IT.  In fact, organizations in that state will gradually adopt a private cloud model without any external influence as they continue to automate and consolidate the routine architectures and implementations.  

However, many organizations aren't there yet... at least, not enough to make Cloud Computing the third most popular CIO initiative.  I'd argue that many times when CIOs say that Cloud Computing is important, what they're really saying is that their current IT infrastructure is painful to work with, expensive, and slow to change.  The hope is that once this new buzzword architecture is implemented, their IT will suck less.

In a way, this is similar to the "server consolidation" CIO initiatives during the infancy of virtualization.  Lots of organizations had initiatives to reduce the server footprint.  The resultant architecture ended up being Windows VMs running on VMware GSX Server running on Windows 2000/2003 (since, after all, the current footprint was primarily Windows so those departments were assigned this initiative).  While meeting the "requirement" of server consolidation, these implementations resulted in little to negative business benefit.

Lets make sure today's private cloud implementations don't end up the same way.