The enterprise virtualization market

I’m often asked by some of my colleagues at Juniper as well as potential customers about whether OpenContrail is applicable to the enterprise virtualization market. This market is today dominated by VMWare while OpenContrail has chosen to focus its energy at OpenStack. The question often comes in the form as to whether I see enterprise adopting OpenStack for virtualization. The answer is, of course, “no”.

To quote an analyst report, “The shift to SaaS is the leading agent of change” in enterprise I.T. This is the main driver of transformation, not OpenStack. While the traditional approach used to be for enterprises to buy software packages and install them on premise, this is now becoming a quaint approach to doing business. I.T. management and operations, like just about everything else, is more efficient at scale. It is simple to understand that it is cheaper to administer 1000 instances of a CRM application “as-a-service” than for 1000 enterprises to do so themselves.

It is also intuitive to understand that the organization that developed a particular software application is then one that can most effectively administer, manage it and maintain it. From an economical perspective, safe some exceptions, if an organization did not develop an application it probably has no business in hosting it. Data security concerns are real. But today’s enterprise centric cloud providers are very conscious of these issues and can most likely bring more resources to bear in terms of information security than your typical I.T. department.

It is quite common to see companies switch their sales support system, CRM applications, all the critical systems that support the business from in-house hosted to SaaS. The applications just work better. One example that i’ve seen personally is how painful the traditional hosted expense report systems used to be vs. how much nicer is the SaaS tool that my employer is currently using.

This “leading agent of change” is going to affect I.T. spending in general and data-center spending in particular. SaaS providers are growing rapidly. They are the target customers of anything that it is being done in data-center automation today. For a SaaS company the kind of automation that a system like OpenStack brings is crucial. The name of the game is to reduce the time between start of development and deployment. Cycles are measured in weeks. This is totally incompatible with the traditional management workflows in enterprise I.T. where to get trivial resources like a set of VMs it would take days if not weeks with trouble tickets being processed by humans.

Data-center automation systems built for a SaaS providers do not need to use traditional compute virtualization in the form of hypervisors. Some of the automation being built is still using hypervisors today but the trend is clear. KVM, Xen or ESXi are not required for the vast majority of compute loads than will be running in the next 5 years. Technologies such as Linux containers are significantly more efficient than hypervisors at isolating applications. And tools such as docker do a much better job at managing software distribution and change control than virtual machine images. With docker it is much faster to build an image with the components that are required for the specific application.

By getting rid of hypervisors it is also simpler to manage memory over-subscription. Systems that use hypervisors are typically capable to correctly manage CPU over-subscription but not memory. Memory is as expensive of a resource as CPU and should not need to be managed in static blocks given to the guest OS (which doesn’t have a useful job to perform).

The hypervisor may still be a useful tool to deal with exceptions… but by and large it is unnecessary for a data-center where the large majority of the workloads run on the same OS as the hosts. It is clear that all the trend lines point away from virtualization as traditionally defined.


The RedHat controversy

Several articles, including one in the Wall Street Journal
hit the press last week regarding RedHat policy of only supporting RedHat guests in RedHat Linux, VMWare or HyperV Hosts.

While this policy had probably been around for a while, several RedHat customers i work with have recently changed their deployment plans towards having dual hypervisor sulotions (ubuntu + RHEL) in order to be able to run RHEL hosts under support.

RedHat seems to be using this tatic to stem its market share loss in the virtualization and OpenStack hypervisor space. In a blog post, RedHat seems to imply that its competitors providing Linux hosts “cavalierly compile and ship, untested OpenStack offerings”. Ironically, several people that i spoke with last week have echoed the opinion that RHEL 6.x is rather problematic for a cloud deployment, questioning whether it can be used in production.

One cloud provider that i spoke with, immediatly replied that they had to replaced the kernel and KVM versions in their CentOS 6.x version when i questioned thier choice of OS distribution. This seems to match the general consensus of what I hear through the grapevine. I understand than an anecdote is not data but in the sample universe i’ve access to there seems to be a strong signal.

The underlying problem here seems to be that RHEL 7 is late. That is most likely the main reason ubuntu is continuing to gain market share in virtualization / OpenStack. This is the reflection of RedHat’s success. Given its large user base, it is quite difficult to transition between 6.x and 7. Enterprise customers do expect backwards compatibility and consistency of behavior, which ends up meaning than one customer’s bug is another customer’s feature.

By strong arming its customers using the RHEL guest support policy RedHat will achieve short term gains at long term costs. Customers will certainly think twice next time they will have a project where there is an option to choose guest OSes.

RedHat is also proving something that most already know: Open source is not an antidote for vendor lock-in. Customers writing an application for a RHEL OS are using mostly APIs that are available on other systems and API portability is extremely important; but a product must be validated along with its platform and that implies that it is not trivial to switch OS distributions. 

The only solution for vendor lock-in is a market with healthy competion. It is curious to note than open source can also be used as a tool to reduce competition is an specific market: either by reducing the monetizable value of a specific type of products or when companies with a strong presence in a particular open source project use that position to control access.

It will be interesting to watch the fallout from this story as it develops.

Role inversion

At the OpenStack summit in Atlanta this week there was a very interesting phenomenon. Vendors that have been traditionally positioned in the I.T space seemed to be directing their energy around OpenStack on the carrier / telecom space; while vendors traditionally in this space where doing the best they could to get beyond it and into non-traditional I.T deployments.

As an example, canonical’s booth was primary advertising their “Carrier Class OpenStack” and RedHat seemed very interested in NFV; with several senior developers organizing a cross project NFV subteam to focus on how OpenStack can be a better fit for carrier data-centers.

The traditional telecom vendors on the other hand seemed to be rather less sanguine on the NFV market. At least when it comes to the timelines required to get to production deployments: 2018 seems to be a reasonable target.

I don’t currently have access to market research data; but i would be very curious to take a look at it and how it is being interpreted. Either the I.T. vendors are over-investing or the traditionally Service Provider focused vendors are under-investing in this space. Cisco, for instance, which is typically quite business savvy is nowhere to be seen in “Carrier Grade OpenStack” space; other vendors (e.g. Ericsson, Alcatel, etc) are investing. But by my rather un-scientific guestimate, a much smaller percentage of their energy and resources when compared to the traditional I.T players.

I do believe in OpenStack in the carrier space. I’m convinced that it will happen. But for the carriers it will be first and foremost a cultural transformation rather than an incremental technology; and these typically take a very very long time.

In the enterprise space itself infrastructure automation is a step function. Going from systems and networks administration to automated infrastructure is non-trivial. It is a very different mind set. It assumes that operational procedures are executed as software rather than people; it requires architects, designed and operators to be software engineers. That takes time.

This transformation is picking up steam in companies that offer Software-as-a-service (SaaS) or cloud based solutions; they are typically more nimble. But it is a hard sell in traditional enterprise. This could be the reason for I.T. vendors to focus on the carrier space.

I doubt that the premisse here is that carriers will adopt infrastructure automation faster than enterprise. That is not particularly well supported by past history and the carriers are mostly in positions of quasi-monopoly without fundamental threats to many of their core services.

The one transformation that is happening rather quicly is enterprise applications moving to SaaS. Over-simplifying a bit, if one does not write an application, there is no point in hosting it on site. It can be done better and more economically by the people that built it. But this transformation should favor OpenStack: workloads moving away from traditional virtualization to SaaS providers.

My naive perspective would be that the focus of OpenStack vendors would be on SaaS: clouds for companies with a significant software development effort. Most of the early adopters of OpenContrail are in this category (with the remaining ones being IaaS providers).

I should definitivly go dig out some market research on NFV; i’m puzzled as to why vendors traditionally in the I.T. space are all focusing on this space.

It could be an example of the “grass is greener on the other side” syndrome. Working from a traditionally Service Provider focused company i expect that commercial success in OpenStack would come in the short and medium turn in the I.T. space, not SP.

OpenContrail at the summit

There was a lot happening at the OpenStack summit in Atlanta this week. I got the opportunity to meet several of the most active OpenContrail developers; and envangilize the project with several people that are looking for an OpenStack networking solution that meets their needs.

The buzz on Neutron can be sumarized by: the default implementation of neutron doesn’t work. Many users find that running neutron service rack with l3-agent and dhcp agent isn’t working out for them: the neutron router is a choke point for traffic; there is no resiliency and some of the services (e.g. DHCP) are prone to melt down. This seemed to be the rought consensus of those who i spoke with (admitedly a rather un-scientific sample).

It is easy to explain the advantages of the OpenContrail implementation in this context. By implementing a fully distributed router implementation as well as distributing the DHCP, metadata proxy and floatingip functionality, OpenContrail solves most of the current pain points of Neutron.

On the other side, some of the users I spoke to where often concerned with the relativly small size of the community. Hopefully this weeks annoucement of the OpenContrail Advisory Board will help aliviate this concern. Growing the community continues to be the top priority.

On the technical side, I had the opportunity to work with Edouard and Sylvan on the source-nat blueprint / prototype. It is one of the gaps at the moment that we have to address. As a temporary workarond 1:N NAT will be implemented as a centralized service; hopefully we can follow it up quicly with the fully distributed approach that we have planned using BGP flow-spec.

“Distribute all the things !!!”. That needs to be the offical motto of the project.