Friday, March 14, 2014

L-Earning Your Way Up the Cloud Learning Curve

Invariably when asked what I lessons I can share in cloud adoption I refer to Jurassic Park.  During the initial tour of the facility, Dr Ian Malcom (Jeff Goldblum) sounds a warning to Jurassic Park entrepreneur John Hammond (Richard Attenborough):

“You read what others had done and took the next step.  You didn’t earn the knowledge for yourselves”

Having spent the majority of my career in emerging technology I have found one immutable truth: you can’t leap and hop your way up the learning curve, you have to earn the knowledge for yourself.  The knowledge you earn provides the critical insights necessary to make course corrections and deliver a solution not only relevant to the existing problem, but one which becomes the foundation for the next solution.

Big public cloud providers like Amazon, Google, and Microsoft earn their knowledge every day delivering solutions to buyers in IT and the business.  In contrast most Fortune 500 companies have chosen to let others earn the knowledge by partnering with private cloud solution providers, who themselves imitate public cloud providers.   Overlooked in the analysis of public or private are the combined powers of expectation and momentum.  What the public cloud delivers today quickly becomes an expectation of the private cloud tomorrow, and momentum is widening the value gap as public cloud product cycles continually contract.  As a result private cloud solution providers are not only well behind on the learning curve, they are falling further and further behind.  This puts IT leaders, who are following the followers, in a difficult position where their only choice is to try and leap up the learning curve on their own.  The results are predictable and all too real: projects fail to meet expectations.  And as the gap grows, pent up demand is beginning to fracture the status-quo dam carefully constructed by IT leaders over the past 40 years.

So what to do?  Realizing CIO's are largely out-manned and out-gunned I figured it's time to put-up or shut-up.  So after years of referring to it in conversations and presentations, I have finally documented “Brian’s Non-Scientific But Anecdotally Accurate Cloud Learning Curve”.  These are the "Ah ha!" moments I've documented in my 10+ year journey through distributed computing in the Fortune 500, from P2P and grid to cloud.

As companies earn their way up the knowledge curve via private cloud, they invariably make the same mistakes at the same points on their journey.  Examples abound, but the most common are: consolidating servers without considering the entire data center, failing to recognize the ‘Gulf of DevOps’ and delivering self-serve portals which fail to engage developers, and struggling to align the infrastructure centric view with the application oriented view of cloud computing.  Today the fast followers are realizing it’s about ‘clouds’, not ‘cloud, and thus are struggling through the ‘Orchestration & Provisioning’ and ‘Brokerage’ steps.  And I expect at some point they’ll realize how important automation (policy, governance, etc.) and autonomics (optimization, continuous availability, etc.) are to their success.  The question is will they learn this BEFORE it becomes an issue?  Or plan for it accordingly and build it into their roadmap regardless of what their private cloud provider says or does.

Cloud Computing has rapidly emerged as the foundation of the Software Defined Enterprise.  Getting to cloud first and fast sounds compelling.  In reality the path to cloud nirvana is littered by the hollowed out shells of failed projects, primarily due to companies trying to jump the learning curve like John Hammond and derive the benefit without earning the knowledge. 

Tuesday, March 4, 2014

SDN and NFV are Crucial to Getting Cloud Right

Go back to 2008 and you'll find the beginnings of an incredible cost savings opportunity in the emerging world of cloud computing.  Built on the back of grid computing, cloud offered to reduce operational costs by 30% just through the application of mass virtualization technologies (virtual machines, server and data center consolidation, etc.).  Over time the return on investment improved, until in 2012 executives started talking about a 70% overall cost reduction versus previous generation approaches.  By contrast SDN became a topic in enterprises in 2012 and yet within one year executives at some of America's largest companies are touting the opportunity to reduce network expenses by 70%.  It's no coincidence.

In the emerging SDN/NFV discussion the eye-opening "Ah ha" moment repeating itself almost daily is the realization that when moving network functions to software the platform answer is cloud.  As I referred to in my August 2010 post Everything Should be Software, the opportunity is tremendous to continue the commoditization of hardware by moving specialization into software.  Cloud is the platform for SDN and NFV which in turn enhances the value propositions of cloud:

  • Improved agility to meet emerging business demands
  • Reduced time to market
  • Greater efficiency
  • On-demand scalability
  • Variable cost

As someone who has advocated for years that cloud is the platform of the future onto which companies will build their eCommerce, Big Data, Mobility and Social/Collaboration solutions; an improved value proposition makes cloud all that more enticing.

Imagine being able to bring the transformation, normalization and aggregation tasks from analytics down into the network.  Establishing secure network tunnels on the fly across wired and wireline networks to connect mobile applications to data sources without the risk of interception by a third party.  SDN and NFV bring the functionality required to realize the new data architecture I advocate.

Of course none of the promise of SDN and NFV comes free.  Limiting the speed of adoption is the same culprit that's been holding cloud back for the past 5+ years: expertise.  We simply don't have enough networking experts with backgrounds in software, just as we don't have enough operations, administration, server architecture, storage architecture and security experts with software backgrounds (equally we have few software people with strong network, infrastructure, and security backgrounds).  We are still hampered by the breadth and depth of knowledge required to get cloud right.  Add to this challenge the cost and complexity of moving networks with 99.999% availability and higher into a new technology architecture and the reality sets in the effort will be herculean.  Luckily we have economics on our side.

Compared to the cost of moving data, everything else is free.  As a result there are few who are not jumping at the opportunity to save serious money in their network.  When executives publicly state they see an opportunity to reduce CapEx dramatically and reduce OpEx by as much as 70%, people take notice.  Those expectations are buying signals which drive entrepreneurs to come up with new ideas, venture capitalists to fund those ideas, and buyers to look for start-ups with promising new capabilities.  As in any new market the risk for buyers is separating the wheat from the chaff.  Will Cisco dominate or go dormant?  Can an early leader like Nicera keep its leadership role having been acquired by a mass virtualization focused company like VMWare?  Can the start-ups survive long enough to bring the market the critical mass required to move us past the point of no return?  Will the big companies invest, partner, and acquire to expand their capabilities or to remove competitors from the market?

Although I cannot pick the winners and losers, I am confident all arrows are pointing in the same direction.  We need to keep the faith and foster the willingness to try, fail, and try again.  As with any technology the road to success will be paved by utter failures, however as long as the direction is toward a software driven world I expect our destination will be well worth the journey.

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? 



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.