IT 1.0 – Virtualization

The way that enterprises (Fortune 1000) will plan their journey to the Cloud will depend on their own priorities.

I view IT 1.0 as virtualizing your infrastructure. For many organizations this is the first priority and their first step to Cloud.

But’s lets face it: 1) only 15% of the data center is virtualized, and 2) when you look at large enterprise (aka Fortune 1000 or larger…where the money is), you will quickly realize that VMware is a small portion of the data center footprint and, in fact, that data center architects are already virtualizing with Solaris (Zones) and AIX (LPARs). In large enterprise most of the data center is NOT virtualized….meaning that many of the business applications powering corporations are running on “bare metal”…not “virtualized metal”. So even though virtualization is an important component to cloud, we need to support non-virtualized infrastructure in our enterprise cloud architecture.

IT 2.0 – Private IaaS

Ok…next step is to automate the way we provision infrastructure with private IaaS offerings. But is this really going to make a big impact? Why focus on reducing just IT spend (as a % of revenue) from 5% to 4% when you can make a much greater impact elsewhere? I can’t emphasize enough…that over the 50 or so CIO meetings I had in 2010, CIO’s eyes glazed over every time I began talking about how automating IT would save data center infrastructure costs and increase IT administration productivity. Yeah, yeah….private IaaS is a reality, but it’s boring. Bring in VMware’s VCloud Director, and Quest’s Surgient Private Cloud, or Cloud.com, or Eucalyptus, or…..and when you have that implemented, then lets really talk about saving enterprise $. Oh yeah, and don’t forget…when you do deploy your private IaaS, it better support both virtualized and non-virtualized infrastructure.

IT 3.0 – Private PaaS

Now lets talk about automating application lifecycle management. For example, how we can roll out a new retail banking application worldwide in 2.5 years versus 3 years? Lets focus on how to reduce the time-to-market to deliver your mission-critical business application by 6 months (cutting the delivery time by 17%). When I spoke to a CIO of large financial institution, we talked about a program where 650 application developers were working on rolling out a new banking application over a 3 year period. Fully-burdened ($200K/yr), that’s $130M per year for a total of $390M. So if we shaved off 6 months, we would save $65M by deploying those resources on to another project earlier, not including the value associated with delivering the application to the end-customer sooner.

From a pure technology viewpoint as well as a business case (as shown above), there is a strong reason for making a shared application development environment (internal, private PaaS), as this enables developers to reuse standard components more easily and do their work faster, at lower cost and more securely….and effectively delivering key business applications to end-users sooner. Lets face it, the greatest expense for most enterprises involves moving their applications through the lifecycle of design, development, test, QA, staging, and finally production.

The key here is the word “application”. I didn’t say that the greatest expense is in the servers, storage, networking…or infrastructure supporting these applications. Remember? IT spend is only 5% of revenue for most enterprises.

Yet that is not what we are seeing in the market. Actually most businesses are actually making desktop virtualisation their first step. You might see this as being a little risky, since changes to the desktop affect the entire business, but the prospect of rapid cost savings and productivity gains are very attractive, and many organisations believe this is the best way to transform their efficiency levels as quickly as possible. It’s also easier for business users to grasp this compared to the idea of an internal PaaS.

Try going to the VP of Sales and tell them that you are creating an internal private cloud for programmers….versus telling him/her that all their sales teams can access their desktops from any location virtually. Virtual desktop is an easier sell.

I find that CIOs are focusing on: 1) virtualizing the desktop (VDI), 2) outsourcing business applications (SaaS), and then 3) automating  IT (IaaS). When will they begin to work with business users to accelerate application deployment via a private PaaS and take advantage of that $65M savings? I think this presents an enormous value proposition to large enterprise.

Q&A

Below I capture additional perspective in the form of questions and answers:

Q: Agree that you can build a private IAAS without virtualization, but why would this make sense as an investment?

A: It’s not always a matter of investment. Many applications can not run on a virtualized platform, and various reasons require a bare metal footprint….or many may already have “virtualized” infrastructure with solutions such as Zones or LPARS, presenting fewer reasons to move to more recent virtualized offerings such as VMware, Citrix, RedHat, etc. (due to risk, or simply lack of time).

Q: Don’t you get a better ROI out of your private IAAS if it’s built on top of virtualization?

A: Agreed. A highly automated virtualized platform will be less expensive than a highly automated non-virtualized platform. But barring the issues mentioned above, you might think of the data center evolution as:  1) non-virtualized and non-automated / non-standardized, 2) non-virt + automated, and then finally 3) virt. + automated. Migration to the ideal will take time. Then there’s the whole discussion around PaaS versus IaaS, of course.

Q: How do you create catalog offerings and offer them on-demand if the services aren’t encapsulated in VM images?  You would have to do an insane amount of customization and scripting to enable the same level of automation on physical infrastructure, right?

A: Ahhh…but now you have hit the nail on the head. The true value is not simply encapsulating and repurposing with an OVF file, but encapsulating the metadata around the pre-defined stacks and the application requirements (and resulting infrastructure configurations). Think of a declarative language which is used to define application metadata and can be expanded to support non-virtualized environments.When push comes to shove, enterprises do not have that many “stacks” in their catalog….and, if they do, they should be consolidated. How many permutations do you really need to support for your production systems…..or SHOULD have to support? e.g. do you really want to have to support every release of RHEL + SUSE + all the other middleware software, etc.? Quick answer, is “NO”….especially in the “new world” of IT and application dev. In addition, you want to use the production environment for development, test, QA, and staging, of course….so that should minimize the size of the catalog. Then finally, large IT shops have already done the “insane amount of customization and scripting”…they (or should I say, that large System Integrators who are employed by the Fortune 1000) just need an environment to properly maintain and standardize it.

Q:  I think you should be careful to distinguish the opportunities available along 2 dimensions: a) layers of the stack (infrastructure, platform, application) b) role in the systems development lifecycle, “SDLC” (developer, tester, build/release, operations)…because I think vendors are approaching Platform as a service from different angles.  One perspective is the developer one you mention and shrinking development time.  But how about those other guys – the tester, build/release, and operations guys — they’re the ones who get hosed by the need to deal with the complexity of customer environments.

A: Agree. When you create your PaaS platform, you better incorporate support to guide the application through design, dev, test, QA, staging, and into production. However, that being said….we want to do so from the application perspective….not the infrastructure perspective (if we can avoid it). Can we provide a PaaS which guides you through the SDLC, providing access to reusable application services with 100% abstraction from the infrastructure? Now that would be a truly useful PaaS.

Q: If one of the benefits of moving to the cloud is increased standardization and automation, one would think that a value prop of a PAAS environment would be to crunch out standardized virtual appliances that can then be deployed on any virtual operating environment without the application inside the virtual appliance having to have any clue about the environment it is running in.

A: 300% agree with this….well, almost. Whether we call it a virtual appliance or a container or an application environment…..the key is to allow the application to live anywhere with clear abstraction from the infrastructure (I only know that I need a certain SLA within a given budget….and that translates into what and where and how much). The only thing I would add to this point is that it does NOT have to be VIRTUAL…..it can be any environment (based on the application requirements). If you don’t support non-virt environments, you may be forced to exclude some of the most interesting (and large, mission-critical, etc.) applications.

Q: So instead of thinking application, enterprises should be thinking appliances.

A: Disagree. “appliance” is an IT point of view. EVERYONE should be thinking APPLICATION…..or the business user point of view….and, thus, the suite of application services needed/available. We’re beyond the days of OS, middleware, stacks, catalogs, infrastructure and entering into the days of application platforms….and that means that we have to expand beyond the common application services of public PaaS platforms today…such as:

• Security Services
• DataBase Services
• Blobs Services
• Data Backup/Snapshots Services
• Data import/export Services
• Data Manipulation Services
• User ID Mgmt / Collaboration Services
• Workflow/Approval Process/Services
• Integrated Billing Services
• Email Services
• IM Services
• Image Handling/Manipulation Services
• Reporting/Dashboard Services
• Mobile Services

Q: By doing so, test/build/release for the vendor should get easier since you won’t have to qualify every OS, every database, etc in the world….configuration for the customer should get easier since they don’t have to care compatibility, support, etc either.

A: Agreed. But this value proposition is already obtained by sophisticated IT shops…Fortune 1000. What cloud vendors need to provide is a more automated way of adding, managing, and deploying application services which app dev teams can use. I’m no longer talking about OS, DB, but rather expanding on the list above…true application-level services….reusable functionality that app-dev teams can apply over and over again….in a standardized and error-free way. Here are a few other application service examples:

• Apigee for Twitter
• Cloudant
• Cloudmailin
• Cron
• Deploy Hooks
• Hoptoad
• IndexTank
• Memcached
• Moonshado SMS
• New Relic RPM
• Panda Stream
• Redis To Go
• Sendgrid SMTP
• SSL
• Websolr search
• Zerigo DNS

The Era of Application Platforms

We’re playing catch-up with large enterprise….they already have home-grown solutions for the above….what they don’t have is a vendor, or set of vendors, who have taken customer learnings in application lifecycle automation and truly commoditized it….thus, justifying the move for sophisticated IT shops to outsource or migrate off their internal automation systems.

VMware focuses on VSphere + Spring, RedHat on KVM + JBoss/Makara, Oracle on OVM + Fusion, etc…..all silos, all only small pieces of the puzzel….we have a long way to go before we truly realize the value of private cloud within large enterprise…..until then, many focus on the mid-sized companies and/or chip away at the large company iceberg with small incremental projects.

The application platform needed by large enterprise needs to support both the legacy and the new….non-virtualized and virtualized. 2011…here we come!