Cisco’s UCS Exit Strategy?

Cisco decided to shut down Flip last month. Why? Because it’s a low margin business that Cisco has no business owning. There is talk about killing Linksys, or spinning it out. Why? Low margins and it doesn’t jive with Cisco’s core competency. UCS (datacenter unified computing system) is another product that has very low margins, and really should be sold if Cisco is to remain as strong as it has been over the past two decades.

 

I find it interesting that only a year ago, all the industry pundits were talking up Cisco and their stock was riding high. How quickly the sands have shifted under their feet. Shareholders and industry experts are calling for Chambers to resign, and some have even suggested they get rid of UCS. Last week’s Infosmack featured some interesting commentary on Cisco selling UCS. GigaOm thinks Cisco has lost that lovin’ feeling for VCE. They seem to be investing as heavily as EMC, but they get a much, much smaller piece of the pie on all those sales. And let’s face it, VCE sales are expensive. Maybe Cisco should have bought EMC when they had the chance?

 

I thought Robin Harris’ comment over on Storagemojo was profound:

UCS lowers Cisco’s margins; enrages large resellers; and has no sustainable competitive advantage. Cisco can’t wish those facts away, and the stock market won’t forget them either.

 

The sustainable competitive advantage thing is a big one.

 

Even with the latest IDC report showing that UCS has overtaken Dell to become the #3 blade player, there is still plenty of uncertainty in the market. I can say from my own experience that executives, who admittedly know very little about UCS and what it brings to the table, are shying away from it out of fear that Cisco could exit the server business.

 

From the very beginning, there was talk of Cisco not being “serious” about becoming a server vendor. Add the recent stock troubles, and decision makers are less willing to stick their necks out on millions worth of UCS. After all, nobody has ever been fired for buying IBM.

 

Companies often take a bath when they get into areas that go against their long standing value propositions. BMW lost $4 Billion when it sold Rover to Ford for $1. Cisco spent $600 Million on Flip only 2 years ago. The fact that Cisco first approached IBM and HP with the UCS idea, and was rejected only proves that Cisco knew it didn’t want to be in the server business before it . . .got into the server business. Perhaps now that they have made their point, one of the server vendors will be interested in a UCS purchase.

 

With HP getting amazingly aggressive on pricing of their network offerings, and Juniper introducing QFabric, Cisco’s attention needs to be focused on their core competency if they wish to maintain those luxuriously high margins into the future.

VMware Cloud Foundry … Hypervisor 2.0?

Ever since the acquisition of springsource nearly two years ago, VMware has been generating a lot of excitement in the application development space.  That excitement was kicked into high gear a few weeks ago when VMware announced the industry’s first implementation of open PaaS, CLOUD FOUNDRY.

But I have a feeling much of that excitement is not felt or even understood by the average reader of this blog.  The reason largely has to do with the fact that most of us have an IT infrastructure/operations background.  We are really good at troubleshooting low-level infrastructure stuff, we can rattle off the differences between RAID5 and RAID10, and we can debate iSCSI vs NFS until we are blue in the face.  However, while we may able to go crazy, Einstein deep into infrastructure technologies, there are very few us who would have a single clue about things like MVC software architecture, Object/Relational Mapping, or Dependency Injection.

 

Sure, some of us (and probably not many of us) may have the ability to create useful automation scripts in PowerShell or PERL, but that’s a far cry from being able to create a full-blown application for end user consumption.   And I’m here to tell you the application development world is, now more than ever, something we all need to embrace.  Because worlds are colliding and CLOUD FOUNDRY is a glimpse of things to come.

 

What is CLOUD FOUNDRY?

Well you already know that Cloud Foundry is a PaaS, which means that at a very high level, you can think of Cloud Foundry as something on-par with Microsoft’s Azure, or Google’s AppEngine, or Salesforce’s Force.com, or Engine Yard.  Not familiar with those services?  Or not 100% clear on what a PaaS is?  OK, then for now, let’s think of Cloud Foundry as a Hypervisor for cloud based applications.  To be clear, I am NOT saying Cloud Foundry is a Hypervisor (because it is not); but let’s just start there.

 

So today, what do we do when we want to deploy an application in our virtual datacenters?  First, we start with a VM or a collection of VMs, and we either deploy them from a template, or we start from scratch and install an Operating System.  Then, after some routine IT processes (patching, updating, configuration management, etc.) we either install and configure the application, or we hand it off to an application team to do the rest.  The key point I want to make here is you start with an Operating System and build up from there.  Meaning, the primary point of abstraction, the place upon which we begin to start build, is the Hypervisor.

 

How does this translate to Cloud Foundry?  Well, Cloud Foundry allows us to start building applications directly on Cloud Foundry.  There is no need to install an Operating System, nor is there a need to patch it, apply configurations, and install application components.  That’s all taken care of behind the scenes.  So Cloud Foundry becomes the main point of abstraction, the place upon which we directly build our new cloudy applications.

 

Another way to look at it would be, the Hypervisor switches our focus from managing hardware to managing VMs.  Similarly, Cloud Foundry switches our focus from managing VMs to managing applications.  In the former case, the hardware doesn’t go away and in the latter case, the VMs won’t go away either.  But the way we interact with, manage and even think about hardware has fundamentally changed … and so it will be with VMs and Cloud Foundry.

 

Again, as a point of clarification, is Cloud Foundry the textbook definition of a Hypervisor?  Nope.  But if we allow ourselves to loosely define a Hypervisor as the point of abstraction between layers of the compute stack (Hardware – Hypervisor – Operating System – Hypervisor – Application), then Cloud Foundry certainly fits the bill.

 

How is CLOUD FOUNDRY different from other PaaS offerings?

Now that we understand a bit about what Cloud Foundry is, I’m sure you’re wondering what makes Cloud Foundry any different than the other PaaS offerings out there.  The biggest differentiator can be summed up with one word:  choice.

Prior to Cloud Foundry, PaaS meant limited choices and ultimately PaaS meant vendor lock-in.   Writing an application for Microsoft’s Azure, as an example, means you will only be able to run your application on Azure.  I suppose that’s not a big deal if you’re 100% committed to Microsoft’s Azure solution and you’re OK with an off premise only option (Azure is not available for on premise consumption).  So there is definitely an element of vendor lock-in there.  And this is true for any PaaS offering out there today.  Whichever PaaS you go with, you are either limited in terms of the developer frameworks and application services the PaaS makes available to you, or you are limited in your deployment options (i.e. public vs. behind-my-firewall), or both.  For the customers I talk to, this is a very big deal.

But the good news is Cloud Foundry brings a big change to all of this.  Cloud Foundry has been designed eliminate vendor lock-in by offering:

  • choice of developer frameworks
  • choice of application services, and
  • choice of deployment (internal vs. external cloud).

Of course you might be thinking, “that sounds great, but ultimately we’ll have to run Cloud Foundry on top of vSphere, so we’ll still be locked in to VMware.”  Well, you would be wrong.  Yes, Cloud Foundry does run on vSphere, but it can run on non-VMware Infrastructure clouds as well.

 

Choice.  It’s super attractive, and it makes Cloud Foundry unique.

 

Why should you care?

But for you, the reader of this blog – someone who is probably focused on IT operations, not software development – why should you care?  Here’s one great reason …

If your IT shop does not like dumping the company Web app on Engine Yard but the dev team is threatening mutiny over working in a stone-age traditional Java production lifecycle (“that’s so 2005, man”), Cloud Foundry can basically become the in-house option.

– Carl Brooks, Senior Technology Writer for SearchCloudComputing.com

Another reason?  Whether we like it or not, PaaS is coming like a freight train and we need to get in front of it now. We need to embrace it.  We need to be the first to understand the Hypervisor 2.0, and all the moving parts around it.   We need to figure out how to offer it to our internal developers before they go consume it externally on their own.  Because ultimately, we will either add value to our employer and serve our users, or someone else will.  I know I’m not going to get run over by the train … are you?

 

What should you do next?

Here is my recommendation … be the first person in your organization to embrace and understand Cloud Foundry.  Believe me when I tell you this will pay handsome dividends for you far into the future.  To start you on your journey, here is some recommended reading …

 


 

VMware Clarifies Support for Microsoft Clustering

VMware published KB Article 1037959 ( http://kb.vmware.com/kb/1037959 ) on April 18, 2011 in an effort to clarify VMware’s position on running Microsoft Clustering technologies on vSphere. Below is a snapshot of the support matrix published by VMware in the KB (always refer to KB 1037959 for the most current information).

vmw_mscs_graph

 

For those familiar with VMware’s previous position on Microsoft Clustering, you will notice a couple changes. First, VMware has made a distinction in Microsoft Clustering technologies by segmenting them into Shared disk and Non-shared Disk.

  • Shared Disk – solution in which the the data resides on the same disks and the VMs share the disks (think MSCS)
  • Non-shared Disk – solution in which the data resides on different disks and uses a replication technology to keep the data in sync (think Exchange 2007 CCR / 2010 DAG).

Next, VMware has extended support for Microsoft Clustering to include In-Guest iSCSI for MSCS.

For those interested in leveraging Microsoft SQL Mirroring, the KB states that VMware does not consider Microsoft SQL Mirroring a clustering solution and will fully support Microsoft SQL Mirroring on vSphere.

Under the Disk Configurations section of the KB, the KB discusses how if using VMFS, the virtual disks used as shared storage for clustered virtual machines must reside on VMFS datastores and must be created using the eagerzeroedthick option. The KB provides detail on how to create the eagerzeroedthick disks for both ESX and ESXi via command line or GUI.  Additional information regarding eagerzeroedthick can be found in KB article 1011170 (http://kb.vmware.com/kb/1011170). Something to note in KB 1011170, at the bottom of the article it states using the vmkfstools –k command you can convert a preallocated (eagerzeroed) virtual disk to eagerzeroedthick and maintain any existing data. Note, the VM must be powered off for this action.

In closing, the VMware support statement exists to explicitly define what VMware will and will not support. It is very important for you to remember these support statements do not make any determination (either directly or indirectly) about what the software ISV (Independent Software Vendor) will and will not support.  So be sure to review the official support statements from your ISV and carefully choose the configuration that makes sense for your organization and will be supported by each vendor.