The first part of the title of this article may seem like mathematics, but it’s really not. This is just about software packaging – a topic not so often discussed. In plain English, it basically says something like: one application with N features vs. N applications, each of which has one feature. More generally speaking, it can describe software entity with sub-elements. I will discuss it in the contexts of mobile/desktop, and virtual/physical.
From Desktop To Mobile
As a software professional, I am really impressed by the rapid growing number of mobile applications today. As estimated, there are more than 500,000 iPhone applications, similar number on Android, and less but good enough on Windows Phone 7.
While we are excited about the big number of choices, normal folks don’t really need that many applications at all. In general, majority of the applications are downloaded just a few times or even no download.
The long tail theory holds true, and it’s good for the store owners like Apple but not necessarily for majority of the app developers. That is a wholly different discussion that we’ll skip here.
Because of the limitation of computing power, small sized screen, lack of mouse and keyboard, it’s natural to have much smaller applications on mobile platforms. So far, it has worked pretty well.
Although rich in features, the traditional applications has majority of the features that normal users never use or think about. It’s fair to say 80% of users use only 20% features of applications like Microsoft Office. When the really simple mobile applications come, you can imagine the excitement.
While we sometimes find it a trouble to find particular menu/keystroke combinations in traditional applications, it’s no longer an issue in mobile applications – it just has one or two features therefore you can’t miss it.
However, the problem of finding right feature to get work done is not gone away. It just morphs to a different problem: finding a right application.
From Physical To Virtual
In theory, the rising of virtualization should not introduce the flatting out packaging. But because of the virtual appliance concept, the packaging in the virtual world is getting flatter than in the physical world.
For example, on a traditional operating system running on a physical machine, it normally has many applications installed. With virtual machines, you could do the same or simply package one application with one OS/virtual machine. It’s not that you cannot package only one application with OS in physical world, but that you can do it so easy and cost effectively in virtual world that it becomes feasible there.
The one to one mapping allows vendor to pre-install and configure an application in a virtual machine, therefore simplify installation and configuration. When a user receives the virtual machine, she can just run it with very few changes like IP address if static IP is needed.
While the installation/configuration issue is dramatically simplified for ONE application, you will have more operating systems to manage. This is the virtual machine sprawl as discussed in my previous article How to Avoid Virtual Machine Sprawl in Cloud Age.
A Rising Problem
While we solving the problem with traditional packaging, the solution brings a new problem, which is to manage more entities, either more applications or more virtual machines. It’s true that the single application or virtual machine is simpler and may easier to use, but the cost of extra applications and virtual machines are rising for sure.
Not only that, the information sharing is easier when an application or operating system is fat than when it’s flat. Multiple applications or virtual appliances takes more efforts and consumes more resources.
It’s hard and too early to say flat application or virtual appliance is a save or not. I don’t think there is a standard answer. Like most things, the result will be case by case.
1xN to Nx1: The World Is Flat In Computing originally appeared on DoubleCloud by Steve Jin, author of VMware VI and vSphere SDK (Prentice Hall) and creator of VMware vSphere Java API. Follow Steve on Twitter and receive future articles via RSS or Email.
Related Posts
