VCE: mid market play for the Enterprise?

VMWare, Cisco and EMC announced the VCE coalition today. It is a great move which can deliver value to the customer. The question is which customer?

Typically vertical integration of layers into an easy to use and consume package has been the mantra for selling solutions to mid-market or small workgroups. For larger enterprises this has not worked. Also most of such packages in the past have been focused on ease of use and simplifying management.

VCE just by the power it packs looks more like an enterprise offering. Usually the challenge in doing this for the enterprise is that the high end its is very difficult to characterize the input or standardize the parameters, thus fix the output in any meaningful fashion. V-Blocks will answer the question: for this workload we have tested, here are the performance numbers. The question is whether it is representative workload. I have not met a fortune 1000 database administrator yet, who will agree that his workload can be templatized.

Also I think Acadia is a mistake. One thing that Citrix mastered from a channel point of view is product should be simple enough for the channel to install it, complicated enough that the customer can’t do it themselves. This enables the channel to make some high margin money and thus promote the product. Cisco would have been better off having the likes of Accenture or Infosys stand up with them with v-Blocks being an area of competence. Maybe thats the plan.

AppLocker and App-V

Interesting article on brianmadden.com regarding using applocker as a licence enforcement mechanism.

http://www.brianmadden.com/blogs/timmangan/archive/2009/10/29/AppV-and-AppLocker.aspx

App-v and other technologies like it create breakage. The question is how much breakage and how easy it is to fix. The answers to those questions determines whether it is a dev tool for developers, something that consulting houses can do or an IT admin can do.

What has this got to do with security you ask? Well the answer to that question determines how much lockdown you can do with applocker.

If there is a lot of downstream cusatomization, it becomesd hard to use app-locker. The challenge in whitelisting is not the enforcement mechanism, but the configuration of the white-list: its coverage and maintenance.

Over the years the wrapping of apps by app-v has improved. There is betterr handling of things like winzip (which broke because it registered a shell extension) or apps which required a service. But still in general apps which have multiple processes communicating with each other and/or a service are very challenging.

Citrix has had this problem for a long time also. So if you are a developer of the app you can fix this, but to do it in the field and for complex applications not only is tough but also complex. Then to make a whitelist for it is challenging.

Another difference between whitelisting for security versus licencing is that for security the whiterlisting need to be complete. Imagine you missed some drivers from the whitelist, your machine won’t even boot.

But for licensing you are using the WL as an access control mechanism, very different. For example you can say that WL is applicable only to app-v apps, that’s not security but licensing.

We should keep the two separate.

Cloud for Consumers in Japan and India

I am sitting at Bangalore airport, having spent the day at nasscom and the previous week in Japan. A little homesick and exhausted.

One thing which hit me in Japan and here is the number of people talking about cloud. At first I dismissed it as people following the buzz. But it seemed to be deeper than that.

One thing very different about India and Japan is that they are phone centric. When people start a company in India they think mobile, not PC. In this world cloud means VAS or value added services on the mobile network.

Those services have always lived in the cloud. Imagine a headline like “Your phone will backup your computer to the cloud”. It is the complete opposite of what we would think in the US “your computer will backup your phone”.

Phone based services have always lived in the cloud. As netbooks and things like kindle which connect to the phone network by default OR if the connectivity is provided by the same companies the notion of cloud based services changes.

So we may find in a copuple of years that the cloud is a telco or mobile operator thing with countries like Japan and India way ahead in consumer adoption while the US is ahead in enterprise adoption.

Wonder which one will be bigger?

Cloud Operating System

Most of us struggle to understand what is a cloud operating system? We hear the buzz words flying around, and wonder if it’s a fad or something real. If it is real, what is it and how is it going to change my life? Where “my” is in the context of an IT professional, an average user, an executive etc?

This article  aims to explore what a cloud operating system is and how can we learn from the past to predict the future. It also talks about contemporary cloud products to see where they are in the evolution curve.

So what is a cloud operating system?

Let me start with the climate control on your car. Your first car out of college, or if you are old enough your first car, had an A/C and heater hopefully (in mine only the heater worked). Next to it were two knobs: one to control the relative temperature and one to set the fan to various speeds. If it got hot you turned the A/C to maximum and if it got cold you turned the heat on.

As the cars got more sophisticated you got separate controls for the rear and the front. And if you happened to own a minivan with kids in the back screaming its hot, you found yourself juggling the temperature and several knobs.

In most modern cars you just set the temperature you want and a micro-computer inside decides which fans to turn on and what setting to keep the A/C on. You can override it if you want but the car does all the work.

What has this got to do with the cloud? If you have deployed virtualization in your environment today, you go and manage each ESX server as a discrete entity, you attach storage to it, attach a network to it, move vm’s off and on it etc etc. Just like you turned all those knobs for fans and temperature in the car; In the cloud you just have the equivalent of a temperature setting, for example, number of virtual machines of type small, large and big and the cloud will manage all the discrete components for you.

Let us explore a two step process in building such a system. The first step towards cloud is when we begin to manage resources as an aggregate rather than as individual items

Manage the resources as an aggregate

Today virtual datacenters are treated as a white-box. They let you look inside the VDC and create machines, monitor them, move them between physical machines etc. The user interface into these systems exposes the virtual machines, their mapping to physical machines etc to the user.

Now imagine the Virtual Data Center as a black box. It is just a huge machine, like an old main frame, just much cheaper. A user should be able to login to this VDC-machine and do what they want to do, without worrying about virtual machines or physical machines, their usage etc all that should happen under the covers.

The user submits jobs or virtual machines to be run and does not know where these virtual machines or jobs  are run. Only the system knows where a virtual machine is running at any given time. And it is not guaranteed to be running on the same box for any length of time.

Having a VDC-OS raises several intriguing questions:
•    Will the operating systems of today just become the equivalent of libraries?
•    What would be the equivalent of the unix shell
•    What would the file system look like to the user
•    When you fire a job what will run? A VM? A process as we know it today?
•    Will chroot become the equivalent of logging into a VM?

We will get to these questions later. First how do you design a system which can be managed as an aggregate rather than at an individual resource level?

It has to follow three fundamental tenets:

-    System document thyself
-    System manage thyself
-    System heal thyself
-    System change thyself

At first blush it might sound like theoretical gospel. But this stuff is real. For those of us who remember the windows world before plug and play, it used to be very difficult to install new devices. The first step in plug and play was that the device advertised I am a cannon camera, “system document thself”, and then the operating system was able to find the right driver for itself “system manage thyself”.

Just like plug-and-play detects that a device has been disconnected. Similarly a self-documenting system will detect when  there is a failure. A lot of the cluster protocols do precisely this. They use a heart beat to detect a node failure and fail over. It is known that google data centers assume that computers will fail, detect them and work around it.  Thus the system needs to heal itself.

There is a lot we can work from a network protocols. It is no surprise that the first things in vsphere which is truly managed as an aggregate is the network. Take the layer-2 ethernet protocol: spanning bridge. It has the three tenets embedded in it: when computers join the network they advertise my mac address is so and so and I am attached here (document), the spanning tree protocol then broadcasts this information to other parts of the tree, if the tree breaks the spanning tree is rebuilt.

There is one very important characteristic of such a system. Starting from no-state it can build and recover all its state, which also means that when you set it up it requires no configuration. An Ethernet switch is such a system. An IP router is not such a system. A router on the other hand needs a lot of configuration before it can connect networks. A switch with a router mode is what we need. But that’s for later.

So one asks the question how do systems like vsphere measure up to this. Let us see how vsphere and most management consoles for that matter work: most of them require you to add a physical machine using through a gui or cli to the system.

That is not a self-documenting system. In a self-documenting system, the node would wake up and send out something which says, hey I am here, join me to your cloud.

With the host profile feature which is a part of vmware a simple bootp proxy can help us here. Once a host boots up we can map it to a host profile or a template profile so it gets auto-configured without the user having to do anything. Note one will have to do this at all layers, storage, networking etc.

Some of the newer cloud stacks are integrating logic like these into the stack. Another debate which I frequently have is that all this is applicable only to clouds where all nodes are identical or the storage and network configuration’s are simple. That is simply not true. Yes having a switching abstraction or a usb-plug-and-play has its limitations but the philosophy of what we are articulating is universally applicable.

However if you have a self-documenting, managing and healing system. The underlying physical topology is hidden from the user. This works well if the performance characteristics are independent of the physical topology  but they rarely are. For example imagine one node in the cloud has a large dedicated SSD attached to it or one node is a single very large machine. So in essence the cluster is not uniform. How do we expose this capability or not?
Can we learn from NUMA?

Again there is wealth of knowledge we can learn from. This time it’s in the area of NUMA: Non Uniform Memory Architecture. Very large machines had this concept of memory being closer to one processor, but the memory was shared across all processors. However if a processor accessed memory not close to it, the access times were much higher. Thus non-uniform memory architecture.

If we give a flat abstraction for any resource: network, storage, CPU in a cloud, the reality is that underlying it we will have a non-uniform physical layer.

Some NUMA architectures tried to expose this to the applications but that turned out to be really hard to work with. So NUMA machines ended up putting caches and caching alogirhms which made the performance more uniform.

In a cloud we have several interesting ways to solve this. Simplest is to make all nodes uniform. While this is easier to do on the CPU side and now on the network side, because of switching technologies. It is not that easy to do on the storage side. Although the convergence of networking and storage is helping.

The other option is to have caching just like NUMA architectures did. This may be beneficial for other reasons also for example in clouds built with VDI in mind.

There is another approach to making this happen: to make the user quantify the performance or the SLA they want and then manage the internal scheduling and resource allocation to that SLA.

This is an area where I think vsphere has made tremendous strides.

System Change Thyself

Imagine that the user submits a job in this case a VM and specifies the performance characteristics in terms of size of resource like we do today, but also performance in terms of bandwidth and latency to storage or network, and the system can schedule on its own where the VM should live and also adapt based on performance.

Ah! We are back to temperature control. Given a system which can measure itself and knows what goals it needs to achieve all we need is a mapping between internal knobs and desired output. Turn the air in the back on or on the left where the sun is.

If the performance is strictly a question of location in the cloud for example which machine and storage cluster you are attached to this can even be learnt by the system without the need for explicit or complicated algorithms.

Now you may ask, Vmware bought AppSpeed with a similar vision. The answer is yes, they understand that you need to put sensors at the application level and the map them to a system which can make changes to. But I think before we jump to the app level we need to apply the basic tenets to the infrastructure level.

Summary

In summary a cloud is a system where the resource are managed as an aggregate rather than one at a time. One way of building such a system is to follow the 4 tenets: system document thyself, system manage thyself, system heal thyself and system change thyself. Vendors like Vmware with vsphere are not far from this vision and lot of the emerging cloud stacks are embodying these constructs albeit with different lingo.

Amazon is a big boon for Xen

I am working with a startup which is pitching a Xen based solution to enterprises and telco’s. In the past years it was difficult to answer the question whether Xen was as good as vmware. This startup answers this questions by saying “It is good enough for Amazon”. 9 times out of 10 that silences most of the critics in the room. This will only get easier.

Symantec is also embedding Xen with their volume manager and storage products to create a competitor to virtual infrastructure.  It is also rumored that Xen should do 10s of million kind of revenue this year for Citrix. Which is small compared to vmware, but a 10-20 fold increase over last year.  The rate of change is more interesting.

VMW vs MSFT

 

Over the years people have learnt that there are some battles you can’t fight and win against Microsoft. You may look at the list below and say, “huh” that might have been true of others, but Vmware is different. I won’t argue with you, some companies like Apple have beaten Microsoft on these points, but the odds are low and it’s a difficult play to pull off.

 

• Features: you can’t win by having more features
• Slick UI: Microsoft will design the best UIs ultimately (Apple being the only exception to this rule)
• Desktop Oriented Software: MS had demonstrated uncanny ability to assimilate any features that came out on the desktop
• Speed: Lotus 123 vs Microsoft Excel, they eventually got it right and beat the speed
• Integrated Developer Systems: MS has a lock on this, they will integrate virtualization into visual studio, debuggers etc, making there solution the best
• Price: you can’t undercut Microsoft on price and sustain the business model

 

So if you are Vmware what do you do?  Vmware is in  hyper growth mode and in such a phase people are so busy trying to deal with the day to day operations that most thinking becomes incremental, not because the people are not smart, they are incredibly smart: but there is no time to stop and ponder. Incremental thinking usually results in product roadmaps and directions which will fall in one of the six buckets above.

 

If you are VMW how can you beat MSFT: hypervisor, Virtual Infrastructure or Management & Automation or something else? MSFT, Xen (Citrix) and others pose a thread to the “hypervisor”. NTAP, EMC and other storage/networking vendors pose a threat to the Virtual Infrastructure Layer. Management & Automation is already a crowded market. So how does VMW find a blue ocean to expand into?