Private, Public, Hybrid Cloud ... Whatever.

Just read a good article this morning penned by Joe McKendrick - an independent researcher, speaker and author - on the subject of a recent study by Cloud Connect and Everest Group.  The study polled 213 Executives who could really care less whether their critical business applications are kept inside or outside the firewall.  They simply want the apps running on the "best and most cost-effective sources - whether from inside the data center or from outside providers."

Execs are increasingly indifferent as to where the apps reside, as long as it meets the business need, is cost-effective, and is safe.

The study goes on to dispel five myths about Cloud Computing:

1. Companies are still just testing out this "Cloud" thing.  Not true.  Whether building an internal private cloud or starting to leverage public cloud for DRaaS (Disaster Recovery), DaaS (Desktop as a Service), or traditional uses such as simple seasonal bursting or dev/test use cases,  enterprises are making the transition to cloud right now in droves.  I'm seeing it daily.
2. CIOs won't be needed anymore. I think CIOs will agree that they're sick of vendors telling them that the CIO role is going away, or that their jobs are at risk.  Again, not true.  Will they need to transition and adjust for this new cloud-centric, business-focused era?  Absolutely.  But the CIO role is secure.
3. Cloud is just for IT, not the business.  Quite the opposite, actually.  Cloud will help an IT organization transform from a builder to a Broker of IT services.  Translated, IT will become a competitive differentiator for the business, helping them to leapfrog the competition, creating newfound business agility.
4. Security is no longer a concern.  Security will always be a concern, but their is certainly less concern about public cloud security as there was in its infancy.  Hybrid will be the go forward strategy with security continuing to contribute to decisions on an app by app basis.
5. Deploying a Hybrid Cloud is a piece of cake.  Maybe not that simple.  There is a concern that current staff may not have the experience to get from here to there.  And this is a legitimate concern.  Best to leverage experts on the journey.

Hybrid Cloud Automation Solutions: Flexibility, But at What Cost?

There are many vendors whose Cloud Automation solutions are "little more than a basic service catalog backed by a general purpose automation engine."  Deploying these solutions is both expensive and risky and results in implementations that are very specific to the needs of one type of business.  They aren't generally customizable for the needs of other types of businesses, or easily upgradable to newer versions without considerably more cost and effort.  

Below is another blog entry from Rich Bourdeau, Hybrid Cloud Automation expert, looking at the challenges of deploying these types of solutions. 

Selecting a Cloud Automation Solution:  
Flexibility, But at What Cost?

Many cloud automation solutions available in the market today are little more than a basic service catalog connected to a general purpose automation toolkit.

This is similar to the build it yourself model (discussed in our Build vs Buy post), but at least you are starting with some building blocks and a general purpose automation engine.  The advantage is, you get exactly what you want but at what risk and cost?  Before you start down this path, here are some things you should consider.

The Hidden Costs of Automation Toolkits

There are multiple hidden costs associated with deploying a custom cloud automation solution.  Here are some factors that should be considered when selecting a cloud automation solution:

1. Service costs typically far outweigh software costs.  Some vendors that have cloud automation solutions that are based on a run-book automation tool kit provide a very basic cloud management framework and then a set of process automation tools that allow a custom solution to be developed.  These solutions tend to require lengthy and expensive custom services projects where services typically cost three times as much as the software.

2.  Customized solutions are not easily adapted to other business.  In addition to the higher upfront costs, cloud automation solutions built with an automation toolkit tend to be built specific for the needs of a single business.  When companies try to expand the use of highly customized solutions, they either have further customization costs or suffer from limited adoption across the enterprise.

3.  Customized solutions make upgrades to newer releases difficult.  Many cloud automation customizations strand the implementation at a specific release making upgrades to newer versions difficult and costly.  This may be fine, as long as you are not planning on new features in your vendor’s roadmap. 

4.  Maintenance of this custom solution is FOREVER!  Getting custom cloud services running the first time is one thing.  However, plan on keeping that skill in-house as you will likely need to continue to make changes or maintain your custom cloud solution.  You will likely need someone with very specific skills in whatever tool you choose as well as your custom application.  How easy will it be able to find new people with the appropriate skills if you need to replace your resident expert?  

Hopefully you now have a better understanding of some of the hidden cost of deploying and maintaining custom cloud automation solutions.  In our next blog post we will explore how to identify the perfect mix of time to value and flexibility that will simplify and accelerate your cloud automation deployment.

Rich Bourdeau is Group Marketing Manager at VMware and has over 20 years of experience in developing, managing and marketing IT infrastructure management solutions for enterprises. Rich has spent the last five years helping companies deploy and manage their private and hybrid cloud infrastructures. He has authored papers on Must Have Cloud Management Capabilities as well as Building the Business Case for Private Cloud.

Hybrid Cloud Utopia? You May Want to Dig Deeper.

Yesterday, Chris Wolf (formerly Research VP at Gartner, now CTO at VMware) penned, "Debunking Cloud IaaS Mobility Myths" in response to the fluff being spread by overzealous marketing departments within both open source and OEM software vendor organizations.  Unfortunately, no vendor in this Cloud Play vertical is innocent when it comes to this "silver bullet" talk.

Chris points out that many of the comparisons made between offerings are made on a simple, two-dimensional basis.  The checkbox approach makes it seem that a long list of vendors can "do it", but you have no context as to "how" or "how painfully" or "how costly" until you dig deeper.

He makes a few recommendations that you should employ when evaluating any vendor (including VMware) making claims of some extraordinary utopia:

• Integrations with 3rd parties.  How ... specifically?  Not just that it is supported, but how is it supported?
• 3rd party software licensing.  Does the license follow the VM?  
• Support for preferred vendors.  Are all of your preferred vendors supported?  How well?  How easy is this?  Is there a single solution exchange where you can get the latest and greatest?
• APIs.  How are they accessed?  Native?  Proprietary?  How easy/difficult is it to create or recreate an API?
• Common management solutions.  Same management tools across internal DC and public?  Is this seamless?  What if you change public providers?  Will you need new management toolsets?
• Security policies.  Consistent across the hybrid cloud?
• Network, storage and identity management.  Are there persistent settings, policies, functions, APIs, etc.?
• Logging/Auditing.  Can you tell who did what, when, why?  Does this log data integrate with management toolsets?
• DR.  How quick to recover?  What about configuration drift?

So much more to consider.  When determining reality and - more importantly - true Total Cost of Ownership (TCO), there is simply a lot to think through.  Back to a recommendation that you lean on a trusted vendor and/or partner who has "been there, done that" many, many times.  There are few that can claim this with a straight face.  

In summary:  Push back the "silver bullet" statements, peel back more layers of the onion ... save yourself a lot of time, cost and headache.

Build your Private Cloud Like AWS, and They Will Come

A recent TIP from SearchDataCenter on TechTarget, written by John Treadway of Cloud Technology Partners caught my attention.  The article, entitled "How to Build an Enterprise Private Cloud That is Better Than AWS", provided five excellent pieces of advice in building a Private Cloud (a.k.a. a cloud with your own stuff, in your own DC) that I believe you should heed (I've paraphrased John's words):

1. You have got to spend the money.  Period.  You're not going to get there with your current toolsets.  That isn't to say your current toolsets are a waste or that you should rip them out.  You just need better frosting on your cake, so to speak.  And, in John's words, "... you can't get there with a $1 million investment in half-baked vendor products.  At a minimum, you're going to need to budget $15 to $20 million to implement the base capability."  Of course, the returns will be there in spades, but you've got to spend to save.
2. Prepare to re-org to fit the new cloud model.  People simply won't be doing the same things as they were before the "reveal".  If they are, you've just wasted $15-$20 million.  A few things to expect:
• You won't need as many FTEs to do that stuff anymore.  Tribal knowledge in people's brains will now be in software as policy.  Those FTEs will be able to spend time doing more fulfilling, innovative things that benefit the business instead of spending 90% of their time keeping the lights on.
• You will have naysayers.  These guys are poison to the transformation.  You must have Executive buy-in and mandates from the top to ensure this is controlled.  But if you find poison and it won't magically turn to sugar, suck it out.
• The team will need a vision of the brighter, better future.  They may be fearful, anxious and may turn to poison, as described above.  Best to get ahead of this.  
3. The App Owners within supported LOBs should lead the requirements charge, not IT Ops.  In fact, it's probably best to keep them out of it for the first few miles of the journey.  This is not a slight on the IT Ops folks, just a reality that the AppOwners know what they need to stay ahead of the competition in their market.  Have them build this from the top down, from their perspective back ... however you want to describe it.  "How?" and "what?" is much less important that "why?"  Start with why, then figure out how from there.
4. Automate EVERYTHING.  Look for every repeatable manual process and commit it to workflow automation.  Don't skip a thing.  You'll never reach the level of automation of the big cloud guys, but they have an advantage in that they can just vanilla-ize everything.  No so with an Enterprise.  But the more you automate, the more efficient and agile your cloud.
5. Keep an eye on your cloud.  And automate that too.  It should be a closed system where it is watching, maybe even optimizing and correcting itself.  

My tips:  Plan with a trusted partner.  Don't be cheap (but don't be taken either - do your diligence, of course).  Go with what's been proven.  This is a fairly new industry in the grand scheme of things, so there is not a lot that has truly been proven, but there are few that have done this many hundreds of times.  There are also many who will talk like they have, but haven't.  Not even close.  Best to measure twice and cut once on that decision.

--Written by Greg Dean, but with structure and much content from the article mentioned above.

Selecting a Cloud Automation Solution: The Limitations of Inflexible Tools

The Limitations of Inflexible Tools

You have decided to consider off-the-shelf cloud automation solution.  The next challenge is finding software that is flexible enough to meet your needs but can be deployed quickly, demonstrating value to the business.

Time-to-value of your cloud automation solution is critical to achieving management and business support for continued investment in your “as-a-service” delivery framework.  However, if the solution does not meet the needs of the business, just because it is deployed quickly does not guarantee adoption.

Inflexible Cloud Automation Tools

There are many cloud automation solutions out there that advertise simple, easy and quick cloud deployments.  Many of these solutions were built for a specific problem like lab management; they have prescribed processes, limited interoperability, and lack extensibility features that are needed to adapt to more broad scale deployment requirements. Other tools are focused exclusively on automating infrastructure services for their specific infrastructure. 

Any cloud automation solution which requires drastic changes to existing management tools, infrastructure components, or operational processes will result in both additional capital costs required to replace existing technology as well as additional investment in people to be able to use this new technology and processes.  The other challenge is that your company will likely not be able to achieve the savings you have envisioned because the automation solution will not meet the needs of the various lines of business.  

These businesses will stay with their current manual process or look to public cloud solutions to meet their needs before they leverage yours, if given the choice (or if they don't get caught).   The other alternative is that each group will implement a completely different cloud automation solution which dodges the potential for the operational scalability they could have with a single integrated solution.

As you ponder your cloud automation decision, simple, quick and easy alone does not always achieve the best long term results.  That simplicity needs to be coupled with flexibility and scalability if you wish to satisfy the needs of your business.  

In our next blog post on selecting a cloud automation solution, we will explore why flexibility is an important attribute and what capabilities you should be looking for.

Watch this IT Private Cloud – Exceeding Expectations video (2:28 min)

--Courtesy of Rich Bourdeau, VMware.

The Alure of "Free"

"I already have an ELA with ABC Company and they have a solution for Private Cloud / DevOps.  We need to try it first."

"I'm a big fan of open source.  It's cheaper to go that way."

Have you ever made any of the above statements?  If so, no harm no foul, but I'd like to take you a layer deeper to understand the true Total Cost of Ownership story for the options you may have under consideration to achieve your "next evolution" in IT delivery.

A theory becomes fact once it's been proven enough times in real life.  So I won't posit this as a theory, but as a proven fact:  Currently, there are exceedingly few offerings on the market for automated IT Infrastructure and Platform delivery which:

1. Stand up and configure quickly - from install to in-use.  Most take 6-18 months, no matter what the vendor advertises.  Very few take only 1-2 months.
2. Won't take a high-dollar (as well as high project duration) consulting SOW to achieve the end state you were promised.
3. Won't take 2-4 FTEs to administer ... because the "solution" in question is really made up of 6-9 products behind the scenes.
4. Won't take an Act of Congress to make a change without vendor consultants and another lengthy project duration, and the cost that comes with it.

So, let's take a real scenario, although I will remove the company and specific vendor names to "protect the innocent".  This is just for illustration purposes anyway ...

Option A:  "We already have something through a large EA we signed last year" or "We're going to give open source a try."

1. Software licensing cost = $0 ... free!  But don't celebrate yet.
2. 3 years of annual software maintenance = $300,000 ($100,000 x 3 years)
3. Services to enable end state = $1,000,000
4. FTE equivalent man-hours needed to support for 3 years = $1,350,000 ($150,000 x 3 FTEs x 3 years)
5. Ongoing services to make changes, adjustments = $300,000
6. Opportunity cost related to time-to-reach-end-state = efficiency gains and agility returns not realized for 6-15 months (assumes a 9-18 month implementation) = $3,000,000+ (this is a SWAG, but I think we can agree that it's likely a conservative SWAG)

Total Cost of Option A:  $4,600,000+

Option B:  "We're going with a proven solution for IT Service delivery"

1. Software licensing cost = $500,000
2. 3 years of annual software maintenance = $300,000 ($100,000 x 3 years)
3. Services to enable end state = $50,000
4. FTE equivalent man-hours needed to support for 3 years = $225,000 ($150,000 x 0.5 FTEs x 3 years)
5. Ongoing services to make changes, adjustments = $20,000
6. Opportunity cost related to time-to-reach-end-state = efficiency gains and agility returns not realized for 1-2 months (assumes a 1-2 month implementation) = $100,000

Total Cost of Option B:  $1,195,000

S/W cost is just the tip of the iceberg

As you can see, the difference over a 3 year term is staggering.  It costs about 4X (at least) more to implement the "free" solutions. 

Few vendors - VMware is one of them - can state with a straight face that they can deliver Option B.  The others you're considering ... all Option A. 

My Mom told me, "There's no such thing as a free lunch", and Grampa said, "You get what you pay for."

Which Vendors Are "Eating Their Own Dog Food"?

In the white noise that is this DevOps and Cloud space, thousands of vendors are vying for their piece of the pie ... and your money.  It's hot, and everyone knows it.  But a good indicator of how effective, powerful and - let's face it - REAL an offering is, might be to look at the extent to which the vendor has consumed their own solution.

So, with permission from Rich Bourdeau of VMware, I've copied and pasted his most recent blog entry here for your review and analysis.  Enjoy.

---

VMware IT Streamlines Application Development with DevOps Automation

The DevOps chasm

DevOps is a methodology that stresses increased collaboration between groups which - although highly dependent on each other for success - frequently operate as independent entities. 

Development relies on IT Operations to provision the dev and test environments required to produce new applications and/or features that provide competitive differentiation. Operations relies on Development to produce high quality applications that don’t break when used in production. 

Unfortunately, both teams frequently feel let down by the other. Development needs quicker access to standardized development and test environments.  Operations frequently spend longer than they would like making sure new applications will run smoothly in product environments.

Crossing the chasm
The ability to rapidly deploy standardized application environments and keep these environments consistent throughout the development process is key to reducing the time to deploy new features and increasing delivery frequency.  High quality Dev-Test environments which are consistent with production environments not only improve application delivery times they also result in higher quality applications.  Automation is the key to delivering consistent high-quality application environments and maintaining that consistency through the development process. 

DevOps productivity in action 
VMware IT leveraged Software Defined Data Center services and vCloud Suite management software to help streamline their development and release process.  The results:

·         Decreased Provisioning times by 95% (from weeks to hours)

·         Increased developer productivity by 20%

·         Reduced cost per VM by 80%

)

To learn more about how VMware IT simplified their DevOps Provisioning process, increased developer productivity and reduced VM costs, check out the video above.

---

Thanks Rich. 

What's the REAL Impact of DevOps?

Let's start with a level set.  The term "DevOps" is as overused and as misunderstood as the term "Cloud" has been over the past 2-3 years.  Here is how I¹ am defining the term:

Connecting of the Application Development and IT Operations silos/teams via unified automation of processes and policies, ending with codified Platform as a Service (PaaS), inclusive of all necessary infrastructure and platform components.  Example:  Click-button delivery of a "fully baked" LAMP stack for a Java developer to drop jar files,  inclusive of compute, network, storage, app stack, etc..

We hear vendor claims of seemingly incredible (literally) returns in areas of efficiency, utilization optimization, and speed, resulting in huge CapEx gains and even greater OpEx returns.  But how real is this versus just another case of vendor hyperbole?

Quick answer:  It depends.  It depends on willingness of the IT organization to work toward this goal.  It depends on the vendors involved.  It depends on the amount of time and effort it takes to make it do what it's advertized to do.  It depends on how virtualized the environment is already.  and so on. 

However, to provide some realistic ball park return figures, I'll cut right to the chase.  On average, a $3-5B company² who takes a true DevOps approach and implements full PaaS, will see these results³:

• >90% reduction in time to deliver fully-baked IT services
• $3-5M infrastructure cost reduction through right-sizing, reclamation
• $1.5M IT operational costs reduction
• 20% developer productivity improvement (if 200 developers, this is like finding 40 free developers)
• 70-80% drop in cost per VM per month

But those who have accomplished this note that the above results are secondary byproducts of the real areas of return on their investment:

• Market share gains, revenue increase
• Customer satisfaction gains
• IT seen as a business partner to the LOBs, a "competitive advantage"
• Running IT like a true profit/loss business (e.g. transparency into costs, consumption allocation, etc.)
• Ability to say “yes” to all developer requests since it's exponentially faster AND policies are enforced automatically
• Developer creativity increases (when it takes hours rather than weeks to spin up and spin down, many MANY more ideas are flown)
• Greater control, consistency AND greater agility
• And so on

Are these types of results applicable to every company?  Yes, absolutely.  They can apply to ANY and EVERY company.  But, of course, "it depends" on some key assumptions.  Here are a few assumptions that must be considered: 

1. You've partnered with a vendor or partner to walk this path with you.  a.k.a. You've not chosen to be cheap and go it alone because you believe your people are pretty smart (FYI - they are smart, but smart does not equal "familiar" or "been there, done that").
2. This transition has been mandated from the top down.  While the technology and deployment are important, this is mostly an organizational change issue - everyone must play.  And to ensure everyone "plays", Executive Management must mandate.
3. The compute environment is already greater than 50% virtualized.
4. You are able to stand it up fully in less than a few months (note: there are many vendors that CAN do it - or can even offer it for "free" - but if it takes too long or takes too much effort/cost, you've lost your return)
5. You are considering all components of the Total Cost of Ownership (TCO) equation over a 3-5 year time horizon:  

TCO =
software cost⁴
+ maintenance cost 
+ services to deploy/customize 
+ FTEs to support it 
+ ongoing services when things change 
+ delays due to extensive implementation time/effort

Written by Greg Dean, DevOps and Cloud Management Advisor with VMware.  Greg has an MBA from McCombs School of Business at the University of Texas Austin, with emphasis in Information Management and serves in a strategy and advisory role within the Cloud Management BU of VMware, Inc.

Feel free to contact Greg Dean at gdean@vmware.com

---

1 This may not be the official definition of DevOps, but from my many data points collected from hundreds of meetings on the topic, it seems to be what most mean when the term is used.
2 Obviously not all $3-5B companies were created equal.  As a result, this is fraught with "it depends" statements.
3 This will depend on many factors, of course, but these results are a good approximation for the vast majority of organizations.
4 Many will include a solution as part of a large EA or ELA, but beware ... the balance of the costs over the time horizon far outweigh the cost of the software.