Wednesday, December 4, 2013

A Rational Approach to Cloud Adoption

Today is the day.  You've built the mass virtualized infrastructure.  You have the buy-in from leadership across the business and IT.  You've included all the constituent teams from development and QA to audit and help desk.  It's time to flip the switch, move the cloud, do things better, cheaper and faster.  Ready, set.

STOP!!!  What about the applications?

What about the applications?  They're locked and loaded and ready to GO!

Yes, but are they the right applications? 

Huh?

Ugh...

It's a great day when the internal private cloud is ready to go with real applications doing real work, demonstrating real value.  There is good reason to be proud and get excited.  However, too often the one question not asked is which applications will be migrated to the cloud?  That simple question needs to be answerd BEFORE cloudification begins.

As I've said for several years now, every good cloud strategy begins with a rationalization project.  Application rationalization is the eye opener which sets the strategic foundation for cloud adoption.  Just because an application can be moved to the cloud, or people want it moved to the cloud, is not enough of a justification.  There is only one chance to make a first impression.  Therefore we need to make sure we hit the cloud running which means we're already sure of the direction, tempo, and weather conditions.  Nothing sells a new technology like relevance and nothing kills a new technology like irrelevance.  Good, bad or indifferent it's the business who gets to decide which is the future of cloud.

Often the discussion on migrating applications to the private cloud starts rightfully with focusing on the low hanging fruit.  However how can one know what the low hanging fruit is when many organizations do not have a consolidated list of their applications, their dependencies, their costs, their users, nor their technology stacks?  The decisions are often made on cursory, incomplete knowledge based on the prior experience of team members and their friends.  I personally believe this single factor is a significant reason why so many initial private clouds failed to meet the expectations of executives; they were built to support and undefined set of applications that did not match the reality of the company.  There's nothing like setting out on a journey of a thousand miles with no more than a vague idea of where you want to end up.

Application Rationalization is a discipline within Application Portfolio Management (APM) which provides a company with a 360 degree view of their application inventory.  It's surprising how many organizations, large and small, do not maintain accurate inventories as part of their APM strategy.  Done properly, an application rationalization effort provides an invaluable set of application metadata and drives strategic decisions to answer questions such as:
  • what applications are used, why, and by whom?
  • which applications have similar or overlapping functions?
  • which applications are strategic, tactical, or end of life?
  • what are an application's dependencies including its underlying infrastructure?
  • where does the application sit and what does it consume?
Of course I'm assuming the proper time and effort are expended so the metadata collected is robust and not superficial.  In such a case, mining the application inventory can provide tremendous information for planning cloud adoption, especially when the inventory can be queried to provide killer reports such as strategic applications with cloud compatible dependencies.  The mining can help identify architectural requirements pre-implementation, shape the adoption roadmap, and establish baseline budget numbers for each adoption phase. 

"Moving to the cloud" is the new war cry of CIO's big and small, however like most things it's a combination of efforts which make cloud adoption successful.  Having a strong handle on the application landscape is the key to success because in the end cloud is about applications.  Adopting cloud as an infrastructure first strategy is akin to driving away for vacation and hoping you end up somewhere relaxing.

Tuesday, November 19, 2013

The Holy Trinity of Enterprise Public Cloud

It's only fair to use a religious reference when writing about the religious war public cloud computing is often subjected to in discourse.  Over the past five years we have established several immutable facts.  First, public cloud is cheaper than internal IT, period.  Second, the vast majority of security concerns surrounding public cloud are in fact nothing more than fear, uncertainty and doubt.  Third, companies cannot invest and innovate at the rate of cloud entrepreneurs and thus the gap between public and private cloud capabilities is widening at an increasing rate.  As a result the number of CIO's interested in adopting public cloud as part of their enterprise compute strategy is beginning to grow, particularly in the Fortune 1000.  It appears at this point we are down to three issues: noisy neighbor, guaranteed availability, and Internet security.

Noisy neighbors are just what you think; those neighbors who fill the air with sound disturbing the tranquility of shared spaces.  When people think of public cloud they think multi-tenant, often to the exclusion of any dedicated model.  I've heard speakers at conferences say it isn't cloud if it's not public, and it's not public cloud if it's not multi-tenant.  Such thinking created an impasse for many years as enterprise CIO's could not take the risk of having a noisy neighbor consume all the computing resources available on a given server starving out their virtual machines.  However the barriers are dropping as cloud providers are addressing the noisy neighbor concern.  Amazon AWS and Verizon Terremark for example allow users to provision environments with dedicated servers.  Of course no multi-tenancy means a higher cost, but only marginally higher and the value outweighs the increase.  As subscriptions to a dedicated model increase so will competition as others join the fray.

Guaranteed availability is a difficult requirement to address.  Enterprise CIO's are concerned that at some point when a new VM is needed the provider won't have any more space available.  It's an interesting theoretical possibility, yet like many theories it has not been proven in practice (which is why it remains a theory rather than a law).  Public cloud providers have stayed well ahead of the demand curve ensuring a steady supply of VM's available even during the incredible growth rate in cloud over the past several years.  Combine this track record with the best practice that software should be cloud agnostic capable of running on any cloud, the unlikeliness of a scenario where all providers are starved of capacity, and the availability of dedicated servers; and a starkly different reality emerges.  Done correctly, cloud guarantees greater availability than ANY company can achieve inside its four walls.

Finally we have the security concerns stemming from the use of the Internet to access public clouds.  What was true in 2010 is not true in 2013.  First we have providers such as Amazon AWS who support dedicated connections.  Although simple to understand on the surface, once the engineering is done to remove any single point of failure the implementation is quite complex.  Enter a much more sophisticated solution with AT&T NetBond, currently connecting clients via their private networks to IBM, Microsoft and CSC clouds.  NetBond eliminates the uncertainty of the Internet, connecting cloud provisioned resources seamlessly into the compute fabric of the enterprise.

Where do we stand today?  Although the market has addressed each of the individual issues of the trinity, we currently lack maturity and widespread adoption.  Few cloud providers deliver solutions to all three challenges.  Some of these solutions are new to the market with less than a year of experience under their belt.  However the change is real and we are now at the point where its time for customers to start voting with their checkbook.  In order to reach the ubiquitous cloud nirvana desired by all, the Enterprise CIO's need to start paying for all the things they've said they need in order to use public cloud.  It's time to put up and the next 24mo will determine the fate of cloud in the enterprise.  Will public cloud bring an economic argument unhinging businesses from the pace and skillset of their internal IT department?  Or will the market find new concerns to thwart progress and push the promise of public cloud further into the future?  From where I sit the die is cast.  Enterprises will find ways to adopt public cloud, and those who do so first will gain the greatest first mover advantage in the history of technology adoption.

Wednesday, July 24, 2013

Cloud vs Telecom

My current role has brought what I call the Achilles Heal of cloud into full view.  Experts agree telecom's should own the cloud outright.  After all a cloud is predicated on bandwidth, latency and security so having the keys to the kingdom the telecoms are in the best position to take the throne.  However to date no carrier has established a significant footprint let alone a dominant one.  When people talk about cloud invariably they do not talk about AT&T, Verizon or CenturyLink despite each having multiple cloud solutions, many recognized by Gartner as Magic Quadrant leaders.  I believe the primary issue is a lack of understanding in the market of the differences between mass virtualization and cloud.  Mass virtualization in the form of servers and storage are of no threat to telecoms.  Use fewer physical boxes, shift to virtual machines, buy capacity on demand.  All of those are complimentary to the underlying business of a telecom: selling bandwidth.  Cloud however is a threat because it's all about the applications and data, and the carriers want to provide the bandwidth to move and protect the data.  Today at telecom's cloud is little more than a functionary to serve the sale of bandwidth to customers focused on mass virtualization and nobody has stepped out of line to focus on cloud.  However we are on the brink of a tremendous shift in the bandwidth world with the advent of Software Defined Networks (SDN), and I'm beginning to believe its the game changer that telecoms wish they could avoid.

SDN virtualizes the network in a matter similar to server and storage virtualization.  The goal is to ensure only as much bandwidth as needed is purchased and it can be controlled via automation.  CIO's expect SDN will not only transform their data centers but transform their Wide Area Networks (WAN) as well.  Through the tried and true mechanism of competition telecom's will be incented to provide SDN like features enabling companies to dynamically scale their network up and down and thus their ultimate bill.  Will this generate the 70% savings common in the world of server virtualization?  I don't think so, because most companies have already done the leg work to consolidate their telecom spend so there aren't circuits that are 5-7% utilized like we had with servers.  In some situations companies are kidding themselves thinking they'll be able to save reams of money yet they are saturating their existing bandwidth and demanding more.

However there is a dark side here that either the telecoms don't see OR they see all too well.  Once SDN penetrates the market the pieces will be in place to engender a completely new architecture.  Combine the fault tolerance of cloud based applications designed to provide reliability on unreliable infrastructure with the cheap bandwidth of Cable, DSL, and other last mile technologies and you have a compelling option versus expensive telecom bandwidth.  Instead of purchasing a 1Gbps ethernet connection why not purchase 20 x 50Mbps connections at a significantly lower cost.  Yes you give up the robust management tools, reliability, and SLA's of the enterprise quality connectivity.  You give up some ground in security.  However with applications that assume the infrastructure isn't reliable, running on a distributed infrastructure, and leveraging encryption both at rest and in transit, what is the real downside?  In fact there should be a benefit to having a more distributed network environment and as cloud adoption increases I, like many, expect there to be fewer and fewer large scale data centers and an increasing number of highly distributed micro-data centers.  Owing to the adage "compared to the cost of moving data everything else is free" companies are incented to find new solutions to reduce the cost of bandwidth.

There are situations, such as high-speed trading and national intelligence, where such an approach doesn't make sense (at least not yet).  However there are also numerous situations where such an approach makes more sense than shelling out the money for bandwidth of a higher quality and resiliency than is required..  If SDN makes using cheaper alternatives easier why would a telecom be interested in adopting SDN?  Of course we know by the hundreds of examples the worst strategy is to fight change.  Therefore at least one proactive option for mitigating the loss of revenue is to move up from mass virtualization to real cloud; focusing on the applications and data.  Large carriers can build capabilities into their network to facilitate the collection, analysis and distribution of data at the point of collection, near the point of collection, or in a central repository.  If carriers built solutions which automatically determined where an application should run, where the data should be collected and distributed, and did so in a secure manner I believe it would make a very compelling argument for their more expensive but more capable bandwidth.

Today the telecoms are going down a road of providing increasingly undifferentiated network services which puts them squarely in the dreaded commodity bucket.  I don't see how the market doesn't find a way to negate the need for quality and reliability.  It's simple economics at play and economics always wins!