RHEL just tripled the size of its ISV ecosystem! November 14, 2007Posted by Sacha in IT, JBoss.
Red Hat (RHT) made several important announcements this week: the launch of its “Linux Automation” strategy , ,  and . While the related media coverage was pretty good, most articles perceived it much as a tactical announcement, while it was in fact a very strategic one. Let me show you why.
But first of all, some history… Picture a planet where “Linux” would be a mere kernel and Linux users would pretty much run their own customized distribution, picking up the packages they want and hoping these will work together properly. Now, imagine some big ISV out there, let’s say Oracle, wanting to sell and support its database on “Linux”. How would they do that? ORCL would not only have no way to make sure their database would run on all these custom Linux installations, but they would not even be able to make sure it installs properly! The huge diversity of possible packages and setup would make it a non-starter. Well, that planet did actually exist before the Linux distributions appeared, but it didn’t last long. Once the first distributions appeared, it became possible for ISVs to target a “specific Linux” (API’s, set of packages, directory structure, etc.): Linux was no longer a “big everything”, it became a set of clearly identified distribution brands and versions, each targeting a specific set of packages and API’s. The obvious consequence was that ISVs wouldn’t simply migrate their application to some random “Linux”, they would do it against a clearly identified/branded distribution; this would lead to predictable installation and runtime behaviour. Distributions enabled Linux as a first class Enterprise-OS citizen.
What do you want to run today?
Now, if you look at the profile of the lambda Linux user, that person is most probably not developing applications that directly execute against the kernel API. Instead, that user is mostly installing third-party applications (databases, DNS servers, file servers, ERPs, JVMs, etc.) Consequently, chances are high that, as a user, you are going to elect as your prime Linux distribution the ones that propose the highest number of certified third-party applications => having the largest ISV ecosystem.
While it would be wrong to over-simplify the reasons that led to the success of Red Hat Enterprise Linux (RHEL), one of them is pretty obvious: RHT has built the biggest ISV ecosystem of all Linux distributions (with more than 3’400 certified applications). That’s a very unique value proposal.
What will you want to run tomorrow?
So, how does the future landscape look like for Operating Systems? Well, outside of the two relatively traditional ways to run an OS today (i.e. either directly on the hardware or as a virtual machine on top of an hypervisor), it seems like two additional scenarios are growing in importance: virtual appliances and computing clouds. I’ll describe both and put them in perspective with the announcements RHT made last week.
The first scenario consists of getting your third-party applications delivered to you as a big binary BLOB: a Virtual Appliance. Such appliances consist of a pre-configured/pre-optimized ISV application deployed on a bare-bones operating system, the whole thing packaged as a virtual image that can be run on top of an hypervisor. As an end-user it means that you don’t need to care anymore about installing or optimizing an OS for a specific application or applying a proper set of OS patches for that application; the OS *is* the application. While that model delivers obvious value, it also comes with some threats:
- OS Jungle: the invasion of your IT by random “hidden” operating systems that sneak in through the deployment of virtual appliances. At the end of the day, embedded in an appliance or not, operating systems need to be maintained and supported (and security holes patched). And that’s a job in itself.
- Customizability: ISVs will want to make sure their Virtual Appliance is as efficient as possible and will not want a complete OS if a subset will suffice. A subset means a reduced binary image, but also means less OS patches, hence less downtime.
The first threat leads to the conclusion that OS vendors are the ideal Virtual Appliance OS providers: they avoid proliferation of zillions of random OS and ensure that you get your patches from a single, unified and trusted source. One of RHT’s announcements last week covered that exact scenario: Red Hat not only announced the availability of a highly customizable and supported OS for virtual appliances, but – and this is the cherry on the cake – that this OS is … RHEL itself.
The bottom line is that all ISVs that are certified on RHEL today could decide to provide a Virtual Appliance of their certified application tomorrow with no migration work required: the OS is the same one, coming with the same support (and with specific tools). Now if you compare RHT with other vendors in that field, RHT has some key advantages. For example, compared to a MSFT, RHEL is a truly embeddable and customizable OS: there is no need for a specialized OS that would only increase the ISV’s costs to enter the Virtual Appliance era.
The second scenario, cloud computing, pushes to the extreme the notion of virtualization. With virtualization, you are decoupling the physical hardware from the OS instance. With cloud computing, you are decoupling the physical servers from your CAPEX: you don’t need to buy servers. Instead you are going to rent them (pay-per-use). When is that useful? For example, when you have CPU-intensive tasks that must run very infrequently, such as running some Business Intelligence on your company’s data on a quarterly basis or if you predict your online business will have to go through some exceptional event: instead of buying a multitude of servers that will stand idle 350 days a year, you push your virtual instance images to tens or hundreds of servers “in a computing cloud” that you rent by the hour. While this mode of deployment might not fit all scenarios (because of the way the data is structured, for example, or for privacy concerns), this scenario is going to grow in usage and Red Hat must provide an answer to it.
And that is exactly what Red Hat did last week. RHT announced a partnership with Amazon whereby customers can now deploy their RHEL instances directly on Amazon Elastic Compute Cloud, aka EC2. Customers won’t be forced into an Amazon specific Linux distribution which would have a pretty much empty ecosystem with no ISVs. Instead, they will be able to snapshot their current RHEL instances and push them to EC2 for execution.
Through that series of announcements, Red Hat is lining up its complete RHEL strategy and making it clear that it can fit all deployment scenarios – traditional or emerging – through the exact same RHEL bits. That proves the flexibility of RHEL as a distribution and also factually multiplies the size of RHEL’s ecosystem by further enabling all existing RHEL’s ISV on two new emerging scenarios, Virtual Appliances and Cloud Computing. While that might seem like a trivial statement, it is far from the truth. Just look at VMWare for example: while they are getting great traction in the virtualization field, it is going to be very difficult for them to enter the two emerging fields discussed above, as they have a pretty much empty ISV ecosystem today. And you don’t build an ISV ecosystem overnight (you can partner with one or acquire one, but not build one overnight).
P.S. In a later post, I’ll focus on the cost of virtualization.