Cloud Computing Impacts Technical Agility

The application of Cloud Computing architectural and business concepts to real world business problems allows an increase in technical agility.  According to Wikipedia, Agility is

“...the ability to change the body's position efficiently, and requires the integration of isolated movement skills using a combination of balance, coordination, speed, reflexes, strength,endurance and stamina.”

Technical Agility is the ability of a business to efficiently apply technology to solving business problems.  It requires a combination of knowledge, funding, process, planning, speed, consistency, and purpose.

The application of the business and technology concepts of cloud computing can allow a business to keep up and even be ahead of the curve of what a business needs.  This is especially true because of the decreased need to make massive investments in relatively static technology infrastructures to solve yesterdays problems.

Almost every day I hear that cloud computing is passe or that it is just marketing hype.  To be sure there is no shortage of hype.  But, this particular story definitely has some legs.  Last July Gartner predicted that 2010 IT spending would be, “The market researcher said Thursday it has trimmed its estimate for IT spending for 2010 to $3.35 trillion, a gain of 3.9 percent over last year's $3.23 trillion.”

That is an astounding number!  On Sept. 10 Gartner then stated, “Companies spend around 10.2 percent of their budget for external IT services on cloud computing, according to a new Gartner survey.”

Now, that says that cloud computing efforts might pull in a cool 323 billion dollars in 2010.  That is a LOT of money.  I’d predict that weather that number is or is not accurate that it’s 100% accurate that you will see the real amount of money going to cloud related efforts grow very quickly over the next 3-5 years.

As a result of decades of work in systems automation, grid computing, cluster computing, and virtualization computing technology can now be deployed faster, more accurately, more flexibly, and more cost effectively than ever before.  An individual human being with nothing more than a terminal can control vast compute grids.  Can monitor, update, and scale using nothing more than a 3G connected iPhone if they so choose.  This evolution of technology is helping to drive a revolution in business through a drastic reallocation of human and financial capital.  In times when the cost of financial capital is high, like now, this is a very big deal.  The dearth of micro-funding options to start-ups is a possible indicator here.  The proper application of capital to technology initiatives can make a dramatic difference for any business.  Any business owes it to their bottom line and shareholders to, at the very least, examine the situation with their technology infrastructure management today and make a purposeful decision for their company about how and when they will use cloud computing resources to solve their business problems.

I'm fond of saying that if a company does embrace Cloud Computing that it can be a driver for real innovation.  It can help the company and it’s people better leverage the money they do spend on technology while allowing them to focus more on their true area of expertise.  Employing Cloud Computing techniques and tools is not using technology for technologies sake but for the sake of deploying ideas more quickly than ever before and converting those ideas to revenue.  That is a profound maker of change.

SPOF (Single Point of Failure) Analysis

When planning a system or taking on the analysis of a system that is already in place to begin preparations for scaling there are a few key things one must do.  One of those tasks is to perform a Single Point of Failure (SPOF) analysis.  SPOF’s are the enemy of availability for any system.  This is an exercises done with the input of a cross functional team of key persons from operations, business, and development.  The goal of this analysis is not to actually do the work but to identify the work that needs to be done in the context of the business goals.

Doing this analysis goes through phases similar to many technology projects.  They are usually something such as:

• Define the Goals of the Analysis
• Design the Plan to Achieve the Goals
• Execute the Plan
• Analyze the Data
• Produce Report of Results

These steps may vary a bit depending on the organization size, team, available resources, and the size of the environment.  But, in general, SPOF analysis will follow that pattern.

Some other important points to consider when thinking about SPOFs:

It’s can be better to have SPOF analysis done by a 3rd party who is actually less familiar with the systems but has proper relevant experience.  Those that are very close to a system have a tendancy not to see things because they are too near.

Having SPOF’s does not necessarily mean that someone made a mistake.  It is not a weapon.  If you treat it this way you can be sure people will not report SPOF’s when they find them.  Often times we live with SPOF’s on purpose due to resource limitations or opportunity costs reasons.  If fixing an SPOF problem will cost a million dollars it might be better to accept that potential down time is the better outcome if something goes wrong.  Weather this is or is not true in any given situation is complex business question much more than it is a technical matter.

The report that is produced as the output result of an SPOF audit should be reviewed by the entire technology and business team to determine the potential impact to the business and then entered into whatever passes for a backlog and technology architectural review board so that they can be properly analyzed, ranked, and put in line to be fixed.

SPOF analysis should be done periodically throughout a product/service life cycle.  Things change every single day.  Last years SPOF analysis is probably no longer valid.  Comparing SPOF analysis’ over time can be very enlightening as well toward finding endemic problems that consistently get swept under the rug.

SPOF analysis does not just apply to technology.  It also applies toward business organizations.  One of the people that I’ve noted understands this far better than most is Warren Buffet.  I think he had a clearly articulated (albeit secretive) planned succession strategy when I was still in diapers.  Even at Berkshire-Hathaway Warren Buffet himself has made sure that he is not a single point of failure;  a true visionary.

Are you Cloud Computing yet?

I still believe something I said some time ago about Cloud Computing.  In a short post I wrote in March of 2009 I said, “Cloud Computing as a paradigm shift is a significant technological evolution that has the power to drive a revolution for how businesses and technology relate to one another and operate together.”  As the market matures for Cloud Computing it has become more clear what it makes a service a cloud computing service.  There are a few common characteristics of a software, platform, or infrastructure services that have surfaced over time.

On-demand Resources. The concept of using only what you need when you need it.  There is no perfect demand curve.  There is going to be some waste.  But, one should try to minimize over or under provisioning through the use of on-demand deployment techniques.

Pay-Per-Use.  When you provision on demand resources you will pay for those resources at a reasonable granularity relative to the SLA you need.  You should expect to pre-pay longer when you need much stronger SLAs from your provider.  

When you compare public cloud use versus private cloud computing deployments.  What changes is the granularity at which you operate fiscally.  For an off premise public cloud like EC2 you might operate and pay by the hour.  For and Off/On-Premise in a private cloud you might operate by the physical node with much longer deployment times and life-cycles.  But, well managed, it can still be pay per use but at a monthly or even annual granularity.

Elastic.  The ability of a deployed resources to be scaled up and down relative to demand.  This is also related to billing but you may find that for service providers to provide very strong SLA’s you must reserve capacity and be willing to pay for that weather you use it or not.  Examples of this are Amazon EC2 reserved instances and nScaled’s disaster recovery as a service.

Scalable.  This related to elasticity.  It’s the ability of a system to grow in response to demand for more transactions.  People often expect a cloud to be magically scalable and many services unfairly promise this sort of thing.  But, scalability is much deeper than your IaaS providers cloud.  It has to do with how the software you install is written and runs.  See the recent article Building for the Cloud is Building for Scalability for more thoughts on this matter.

Highly Available.  The characteristic of a system that dictates that there are zero single points of failure.  This means that you could pull any one (or sometimes more) components completely out of the system with no notice what-so-ever and it will keep operating in a normal or possibly gracefully degraded state.  One way to do the the process of going over any given deployment and discovering the availability problems I call SPOF (Single Point of Failure) analysis.  This is an architectural excercise done with the operations, business, and development teams that related the services, servers, and software together and identifies any SPOF’s (single points of failure).

Individual components do not necessarily need to automatically recover to achieve high availability. But, at the very least, they should be monitored and people should be notified so that corrective actions can be planned.  More than any other piece actually achieving high availability will provide the best night-time so you can rest medicine.

If the service (either IaaS, PaaS, or SaaS) does not have those three features then it, in and of itself, is not really Cloud Computing.  It may be using or be a component of a cloud computing effort.  It may be on its way to becoming cloud computing.  But, in and of itself, it’s not cloud computing yet.  Let’s discuss an example.

A straight-forward example of this would be launching a single EC2 AMI and asking the following question.  Is using an EC2 AMI to host your website really Cloud Computing?  If you subscribe to the requirements here then no, it is not.  One EC2 AMI, no matter what you say about it, isn’t in and of itself, cloud computing.  It uses cloud computing components but the web site (or SaaS if you prefer) is not cloud capable because if I (or amazon) turns off the EC2 AMI then your website will fail.  But, if you combine it with more EC2 instances, AWS load balancing, good DNS, and the web site application itself can scale over multiple instances without creating more SPOF’s then nice work!  It is rocking the cloud.  Now your cloud computing!  Yes, I verbed the phrase there.  That brought to mind a comic strip I saw some time ago that went like this:

Calvin:	I like to verb words.
Hobbes:	What?
Calvin:	I take nouns and adjectives and use them as verbs. Remember when "access" was a thing? Now, it's something you do. It got verbed. Verbing weirds language.
Hobbes:	Maybe we can eventually make language a complete impediment to understanding

Are you “Cloud Computing” yet?

Accountability vs. Responsibility in the Context of Organizational Scalability

I recently read a phrase in a book that has been clanging around in my head since I read it.  Since it was sticky I thought I would share here.  It said,

"You can delegate anything you would like, but you can never delegate the accountability for results." - Art of Scalability1

In my opinion, this means that with regards to scalability, if you are designing and managing an organization for growth it is crucial that the lines of not only responsibility are clear but also that the lines of accountability are clear.  The phrase, "The buck stops here," springs to mind.  Wherever the buck stops is where the accountability starts; a point often looked over by the delegators of responsibility.

Sources:

1 - "The Art of Scalability", Michael T Fischer