Today, Microsoft announced pricing for Azure (which isn't open for business yet) on their Azure Windows MSDN blog. Here are some of the basics:
Windows Azure
SQL Azure:
NET Services:
As you might expect, the compute model is similar to EC2 in that the pricing is "per hour" and per GB. The missing part in the model is the size (or type in EC2 terms) of the compute platform. I would expect Microsoft to augment pricing for compute based-on the amount of compute resources an application requires. I don't think Microsoft would allow an applications that requires 5x the amount of memory or CPU time to be the same price as another application with lesser requirements. There must be tiers at some point. Nothing is infinitely scalable.
Transactions, which I think will translate to I/O, are similar as well -- although Amazon is cheaper (more I/O per cost). The SQL and .NET services are different, as to be expected, since Azure is more of a full featured PaaS.
What I found interesting was this statement:
Burton Group has been saying that we believe that IT organizations need more predictable cloud costs. Some organizations have no idea how much cloud services they are consuming until the bills start to trickle in. IT governance will demand that predictable cost controls be put in place. An "all you can eat within limits" model seems to fit the bill. This could be a good move by Microsoft.
If I had one piece of advice for Microsoft it would be regarding this statement:
Microsoft, please do these things regarding the SLAs:
[posted by: Drue Reeves]
A group hug happened Monday, July 13, in Arlington, VA.
A gathering of cloud compute aficionados circled to hold hands and mind meld on the subject of cloud compute standards. All this happened under the watchful eye of the feds – ever lurking in the background.
The goal of the meeting was in the words of the organizers: “to initiate a dialogue with government IT leaders on the theme of "Coordinating Standardization Activities to Remove Government Cloud Computing Roadblocks". Potential government implementers of Cloud Computing will supply their feedback on key issues that could delay federal Cloud Computing deployments.”
I really like it when the government is forward thinking.
But, how sad if it takes the government to finally tame the cloud computing market. Is free enterprise that broken? Whatever happened to co-opetition?
In past cloud storage blogs, I’ve harped on the lack of interoperability between cloud storage vendors.
Yes, some use common web technologies such as REST, but that is not enough. As always, the devil is in the details. For example, the specifics for “getting” and “putting” can vary widely. And, the metadata – that’s the information that describes what the data is – is, well let’s just say, freeform between vendors. All this adds up to a huge distraction from achieving a ubiquitous and commodity-like cloud storage offering. Sure, the likes of Amazon, and soon Azure from Microsoft, can offer cloud storage, but getting the two to interoperate will take, well, that elusive rocket scientist to bridge the interfaces.
On a side note, a recent “Visual Studio Magazine” article titled “Targeting Azure Storage” purported to show how easy it was to hook up and use Azure storage. After reading the article, my head hurts. The article instructs: “You’ll need to download and install the Windows Azure SDK to provide the local Developer Fabric and Storage services, as well as the Storage Client sample C# class library which enables manipulating blobs as .NET objects.” Sounds like a standards-based cloud storage API is a long way off….but I digress.
Back to the group hug and interoperability:
This past Monday, the Object Management Group and friends met to discuss and organize around defining cloud compute standards. This is joint effort by a variety of groups to please not only end users but a Federal government cliental. Kinda like trying to define the charter for the UN; a truly gargantuan task. Talk about your league of nations, presenting were SNIA, DMTF, Open Cloud Consortium, Open Grid Forum, OASIS, Cloud Security Alliance, Cloud Computing Interoperability Forum and some others for good measure. Even - OMG (the more familiar “Oh my god”) - a vendor presented. This is quite the distinguished crew and includes some familiar names in the industry.
Meetings like this can only help to keep the focus on cloud interoperability.
Don’t expect great things, but do have hope that incremental progress for leveling of the cloud compute (and by extension the cloud storage) playing field. Cloud interoperability issues weave not just through vendors, but also into government and legal realms. Unfortunately, the legal representation at this little get together is lacking. But, nevertheless, getting everyone in the same room is the best hope to get the ball rolling. For example, SNIA is boldly (tongue in cheek) defining a new term: Data Storage as a Service (DaaS). This may seem like a small thing but, hey, it’s something. What’s more interesting is SNIA’s attempt to architect a cloud storage interface separating data paths from management paths – definitely an approach with promise and worth a hug.
I have no doubt that smart folks can define a cloud storage interface, elegant beyond expectations.
The fear I have is: can a standardized API become relevant to the key cloud storage/compute vendors? Will Microsoft bend their Azure .NET interface to a standard? Or does the standard need to bend to Microsoft?; or Amazon, or Nirvanix, or Rackspace, or whoever. Maybe the best thing is for a significant player to throw a spec on the table as a starting point.
If cloud storage vendors take up the standards work, its needs to happen quickly and include the leading suppliers with strong support from end customers.
Otherwise, we will spend years in a quagmire of competing cloud storage suppliers, locking in customers. To that end, for any standard to emerge and become the “lingua franca” of the cloud industry, this pointed question needs to be put to the cloud storage providers: Do you plan to compete on a commodity basis? If a pause ensues and the answer is “ahh,no”, then there is little hope for an interface standard and cloud storage will amount to a reinvention of an outsourcing play.
Posted by Gene Ruth
So the web is alive with stories today saying that 60% of companies plan to skip Windows 7[1,2 3 for example, I’m sure there are others], wow, that’s huge news, can this be true?
No, If you actually read the articles, they don’t say that at all, what they say is:
Now anybody with even the most basic reading comprehension skills can see that the survey doesn’t say that they would skip Windows 7 entirely. Ed McCracken’s blog on Windows adoption rates (see here), puts these figures in some perspective, according to his report, Windows XP had roughly 36% market share by the end of 2002, so I doubt Microsoft is losing too much sleep over this report. In fact 33% by the end of 2010 looks like a pretty standard enterprise Windows adoption cycle, and much better than Vista did in the corresponding period. But why let factual reporting get in the way of a good headline!
I bet they got lots of web hits with headline like “Microsoft Windows 7 Will Be Skipped by 6 in 10 Companies, Says Survey”, throw in some meaningless speculation about Google’s desktop and you’ve got perfect fodder for Slashdot discussions!
Update
It’s actually worse than I thought, Ed Bott has tracked down the original report (here) which says that 41% of the respondents plan to implement Windows 7 by the end of 2010, which is a very high figure for a new operating system release (especially pre-SP1). Ed also found a slew of additional articles that seemed to willfully miss the point. Ed’s blog entry is here. Seriously, how does the tech press get away with this?
Posted by: Nik Simpson
I’m currently doing some research on data center cost models and part of the research is being conducted through an online survey. So, if any of the readers of this blog could spare a few minutes to tell me a little about your data center by responding to my survey, I’d be grateful. The survey can be found at:
http://www.burtongroup.com/datacentersurvey
Needless to say, all the information provided is anonymous, I won’t know who you are from the results. Once the survey is complete I’ll post a summary of the findings to the blog.
Thanks.
Posted by: Nik Simpson
In case you missed it, my colleague Eric Maiwald (Research Director for Burton Group Security and Risk Management Service) made an excellent post on the risks associated with resource aggregation in the cloud. He used the recent Rackspace outage to make his point that customers had better know their providers environment before using their services.
Eric's post draws out another issue -- cloud infrastructure secrecy (or better stated -- the lack of cloud transparency). You see, many vendors are so secretive about their infrastructure, customers are unable to determine whether or not a particular vendor can meet their availability or performance needs. How is a cloud consumer supposed to appropriately manage risk if vendors won't discuss their data center architecture?
Now, I realize why cloud vendors won't discuss these issues (ask any vendor and they'll tell you)... security and competitive advantage are top vendors concerns. Cloud vendors must protect their current customers from would-be attackers, hackers, etc. If you're a hacker, a cloud data center -- where millions or billions of dollars of business are being conducted -- is a prime target. In addition, cloud vendor business models are designed to amortize lots of customers across as little infrastructure as possible. Thus, an efficient data center architecture can be a real competitive advantage. Disclosing that information (no matter how many NDAs are in place) will eventually leak to the general public.
But in my opinion, some of this is overblown and speaks to the immaturity of the market. Vendors often use these issues as an excuse not to discuss anything related to their operations, architecture, availability, or performance. The attitude is: "here's our service, use it at your own risk". However, as the cloud matures, I don't think this attitude will fly with customers. At some point, customers need to have a sense of assurance when it comes to service availability and performance....especially for enterprise applications. If the cloud vendors want to host enterprise applications on their service (not just transient workloads), then vendors must prove their availability and performance capabilities...and not just through historical data. Historical data is a rear-view mirror. It tells customers how well the service has performed in the past. While that data may have some bearing on the future, it does not predict what might happen. Disasters strike, power outages happen, pandemics happen. How will the vendor's infrastructure perform in these circumstances?
Cloud vendors: get used to the spotlight. Every outage will be put under a microscope because it's you who are claiming that you can handle everyone's IT needs. When you go down, lots of people go down....that's Eric's whole point about risk aggregation. So, a 45 minute outage may not be much compared to an outage in a single customer's data center, but when you're a cloud vendor, it's a big deal...like it or not.
And if you think about it, the "competitive advantage of secrecy" may become a competitive disadvantage if customers will not use cloud services due to a indeterminate risk. Over time, cloud computing vendors may find that their market is limited because customers simply aren't willing to put many of their applications in the cloud without some risk assurance. This point isn't lost on all cloud vendors. Many of the smaller cloud vendor and some of the really large hosting vendors (who we already know their infrastructure) have begun to realize they can create their own competitive advantage by actually opening up their infrastructure to give potential customers a sense of assurance. These savvy vendors realize that they don't compete on data center architecture or security through obscurity. They realize they compete on service. In the future of cloud computing, having a highly available, secure data center will be the entry point to being a cloud vendor. It's time for vendors to be more transparent about their infrastructure and stop hiding behind the "security and competitive advantage" claim.
[posted by: Drue Reeves]
In my previous post on this topic I promised to take a look at how a more “vertically integrated” set of IT suppliers might change things. In this post we’ll look at the challenges faced by a combination of Oracle and Sun.
The first challenge that any company will face is that a modern IT organization is orders of magnitude more complex and diverse than in era when IBM ruled the data center. For example, most IT organizations today run tens or even hundreds of applications from a wide variety of vendors on a diverse set hardware. That’s a far cry from the IBM era when an organization might have one or two computers and a handful of applications. So the big question is whether true vertical integration all the way up the hardware and software stack for the entire enterprise is even possible today. I’m inclined to think not, because even Oracle only has a handful of the applications needed by a modern enterprise
So if full vertical integration isn’t an option, the key questions are “how far up the stack can Oracle go?” and “does the convenience of vertical integration for part of the IT environment offset the issues of vendor lock-in and higher upfront purchase costs?”
The answer to the first question is that Oracle could offer a well integrated stack for Oracle databases and any applications from Oracle that live on top of that Oracle database. Using Sun’s hardware and operating system (along with OEM products like the Hitachi Data Systems enterprise arrays) they have access to a complete suite of enterprise hardware and system software. The problem is that much of that hardware is not widely used in the enterprise and many IT organizations have long since made the choice of another supplier, so Oracle has to persuade them to rip-n-replace a significant chunk of their infrastructure in order to benefit from integrated Oracle solutions.
The answer to the second question will depend a great deal on the previous choices made by an IT organization. For example an IT organization running Oracle on Sun hardware using Sun storage products may find the idea of tighter integration quite attractive. On the other hand an organization using HP servers and EMC storage to underpin it’s Oracle applications may not be interested at all.
An area of particular concern is the hypervisor, given Oracle’s recent acquisitions, it’s clear that they want to be a player in the server virtualization world. The problem is that many large enterprises are already deploying VMware ESX and to a lesser degree Microsoft HyperV and Citrix XenServer along with a suite of tools to manage the virtual environment. If Oracle fails to displace these products and becomes a “virtualization island” with it’s own set of management tools, then much of the vertical integration advantage disappears, as IT organizations are forced to work with two sets of tools, one for Oracle solutions and one for everything else.
Posted by: Nik Simpson
When Cisco launched it’s UCS blade system in March, they were adamant that they did not plan to get into the rack mount server business. As I pointed out at the time (see here) the lack of rack mount servers would be a significant barrier to entry in the Enterprise because:
So guess what, today Cisco announced a range of 1U and 2U rack mount servers designed to complement the USC blade systems. I suspect that this is the result of early feedback from potential resellers and end users, i.e. “if you want to be taken seriously, then you have to bring more than blades to the data center gunfight.” Given the short timeframe between this launch and the March UCS announcements, it’s hard to avoid the conclusion that Cisco always had a contingency plan here, and just hoped they wouldn’t need it.
The range of servers is still limited compared to the major server vendors, but 1U and 2U dual processor systems are certainly the sweet spot of the market, and should help the get a foot in the door at many enterprise IT organizations. Of course, this is all moot until Cisco actually has general availability on USC and its rack mount cousins, at the moment they seem to be as rare as rocking horse droppings outside of Cisco data centers!
Posted by: Nik Simpson
As you may have gathered by now (see [1],[2]), I’m skeptical about Oracle’s plans to create a one stop shopping experience for IT organizations by combining their software offerings with Sun’s hardware. But let’s assume for the moment that I’m wrong and Oracle really does plan to go down that path.
Such a move would attempt to turn the industry clock back 40 years or more to an era when IT companies were vertically integrated and IT organizations sourced pretty much everything from one mainframe vendor. At that time there was very little in the way of an Independent Software Vendor (ISV) community, you bought your hardware, operating system and applications from the same place. Over time vertical integration gave way to the horizontal integration that we have today, were companies pick and choose hardware, operating systems, and applications from a wide variety of vendors.
Each model has distinct advantages and disadvantages:
If Oracle is right and the industry is ripe for a move back to vertical integration, then we have to ask the question “how will this impact existing vendors.” That’s a big subject and too much to cover in one blog, so I’ll tackle in a series of blogs over the next weeks. The vendors I plan to look at are:
Posted by: Nik Simpson
The last time I blogged on the Data Domain play, the title was:
“NetApp buys Data Domain” (5/20/2009)
So much for that. Here’s the 7/09/2009 update:
Assuming no other suitor shows up at the altar, it looks like EMC has bought the Data Domain bride.
I have to wonder though – what does EMC get? One should be careful what they wish for. As some have said privately or publicly, is Data Domain really worth $33.50 a share?
Let’s step back for a moment.
Data Domain’s beauty comes from deduplication technology and of course, its broad customer set. The hardware that the dedup algorithms run on is not particularly unique, but does offer a means to generate profit margins. And, no doubt the service contracts are lucrative.
A few years ago, the ability to perform dedup duties was important as the technology emerged from obscurity. But now – my gosh – dedup is near commodity status. In fact, vendors are starting to consider pricing dedup as a commodity; look at what Acronis is doing with their dedup pricing. Yes, they are small, but their dedup per unit pricing is a harbinger of the future.
The dedup game has moved past who has the best dedup ratio to who can scale and best fit into large and complex topologies. Topologies encountered in datacenters and across remote offices. My bet is that dedup becomes a feature, expected as part of any storage infrastructure. Look at the message that Symantec is espousing – dedup everywhere. Everywhere means commodity. Dedup becomes a feature not a product. In fact, look around the backup and archive product offerings in the enterprise/SMB market. It’s hard to find a product that does not include dedup.
So I wonder what EMC sees in Data Domain?
No doubt it’s the customer base. That’s no small thing. Getting the proverbial EMC (and their partner DELL) foot in the door for every account is a big positive. For where there is a need for dedup, there is also a bucket full of primary data needing its own equipment with a dependency on dedup for backup space efficiency. In a conspiratorial way, EMC also keeps Data Domain out of NetApp’s hands.
But EMC already has dedup’ing equipment. With the Data Domain acquisition, confusion will reign across the rest of the EMC dedup’ing products. What happens to the EMC/Quantum based dedup products? I guess they get put on an end-of-life cycle. Take note: dedup algorithms are not interoperable. Now EMC has a cacophony of dedup engines (Quantum’s, Avamar’s, and Data Domain) to mash together. Good luck with that.
Challenging hardware implementations, is a growing trend to move dedup capability into the software and thus divorcing it from the hardware. Just listen to Symantec and Commvault. They will be happy to fill you in. To meet this threat, Data Domain must separate the dedup engine from dependence on the hardware, but that kills the hardware revenue stream.
So in the end I’m confused by EMC’s move.
Just what is this new relationship about? Why is it worth so much? Data Domain employees and stock owners get a nice dowry but does EMC gets its money’s worth long term? The long-term prospects for profits from Data Domain dedup technology are, to be polite, murky. Short term, EMC can capture some net market share but marriages should be about the long haul.
Maybe NetApp is the lucky one.
They could conceivable pickup Quantum and its dedup technology for pocket change compared to the Data Domain deal. They won’t get Data Domain’s global customer base but they also don’t need to dilute their company’s value either. In any case, NetApp is certainly free to find a new suitor or suitee; but that’s a different story….
Posted by Gene Ruth
I’ve been covering Oracle licensing and support issues in x86 virtualized environments for quite some time, beginning with the January 2008 report “Virtualization Licensing and Support Lethargy: Curing the Disease That Stalls Virtualization Adoption.” You can also view these earlier blog posts for additional background:
A few weeks ago one of our clients pointed me to a recently published Oracle support article (Metalink 794016.1 published March 27, 2009), which prompted me to write my previous post. That’s when the fun really began. After my last post on May 6th, Oracle published a completely revised version of the Metalink document on May 8th. The document was referenced by the same document ID (794016.1), but had a completely different title and content.
For context, the March 27th version of the Metalink document was titled “Platform Vendor Virtualization Technologies and Oracle E-Business Suite” while the revised May 8th edition of the document was titled “Hardware Vendor Virtualization Technologies on non x86/x86-64 Architectures and Oracle E-Business Suite.” If you recall, the first iteration of the document described how x86 virtualization technologies were supported with the following statement:
The use of platform vendors’ virtualization technologies (both software and hardware based) to host Oracle E-Business Suite 11i and R12 is covered by Oracle’s policy with regards to 3rd-party products – that is, they are ‘not explicitly certified, but supported’.
The support document listed Microsoft, VMware, and Citrix as examples. In the May 8th edition of the support document, the above statement was revised to:
The use of hardware vendors' virtualization technologies to host Oracle E-Business Suite 11i and R12 follows the same policy as Oracle's policy with regards to customizations - that is, they are 'not explicitly certified, but supported'.
Examples of x86 virtualization hypervisors were replaced by the following statement:
This document provides a statement regarding Oracle E-Business Suite (11i, R12) support of Hardware Vendor Virtualization technologies on non x86/x86-64 systems.
The bottom line – the revised support document went from describing support for x86 hypervisors to ignoring them altogether, with the exception of Oracle’s hypervisor Oracle Virtual Machine (OVM). I was told that the revisions were needed to address confusion, but feedback I received from numerous Burton Group clients made it clear that there was no confusion until the May 8th revision was published.
Since early last week, I have had numerous calls with Oracle on the subjects of both licensing and support, and unfortunately the news isn’t all good. Let’s start with the positive. According to Oracle, VMware’s ESX hypervisor “has been supported since November 2007.” As proof, you can view Oracle Metalink document 249212.1 (note that you’ll need an Oracle support account to view the doc). The document states the following:
Oracle has not certified any of its products on VMware virtualized
environments. Oracle Support will assist customers running Oracle products on VMware in the following manner: Oracle will only provide support for issues that either are known to occur on the native OS, or can be demonstrated not to be as a result of running on VMware.
If a problem is a known Oracle issue, Oracle support will recommend the appropriate solution on the native OS. If that solution does not work in the VMware virtualized environment, the customer will be referred to VMware for support. When the customer can demonstrate that the Oracle solution does not work when running on the native OS, Oracle will resume support, including logging a bug with Oracle Development for investigation if required.
The statement goes on to say that Oracle RAC is not supported on VMware environments. If you’re looking for additional background on Oracle support for VMware environments, I suggest reading the following other perspectives:
Regarding VMware support, here’s the translation – if you call for support and you have a known bug, you’re good to go. If you’ve found a new (previously unknown) bug, you’re first going to have to reproduce the fault on physical hardware before Oracle will help you. Compared to other vendors that support enterprise applications on VMware or x86 virtualization environments, this is one of the most restrictive policies out there. Most enterprise software vendors only require faults to be reproduced on the bare metal if they are directly related to performance that could be attributed to the virtualization layer.
The recent Virtual Iron acquisition further cements the fact that Oracle is serious about virtualization. Microsoft and Citrix both have clear public support statements about virtualization and the hypervisors they support (I’m mentioning these two vendors because they’re both virtualization vendors and enterprise software vendors). Oracle needs to loosen its support restrictions for VMware and all x86 virtualization environments, and needs to broaden its list of supported (but not certified) hypervisors to include Microsoft, Citrix, Novell, and Red Hat.
Finally, as I previously mentioned, the larger problem here is licensing. Oracle is requiring customers who wish to deploy Oracle products on x86 hypervisors to license Oracle software by physical server CPUs. Suppose you had two Oracle Database VMs (each with two virtual CPUs) running on a two-node ESX cluster that uses two four-socket servers. Since it’s possible that you’d have a VM on each node, you’d need to purchase licensing to cover the 8 total sockets. If you ran Oracle’s hypervisor, you could license by virtual CPU, however this is only allowed if you pin the VM to fixed CPU cores by hard coding CPU bindings. You can read more about that here. This does create a slight advantage for OVM over competing products, but by binding a VM to one or more physical CPU cores, you have to give up advanced virtualization functionality such as live migration. If I’m using application-level high availability features, this configuration may not be a big deal and would in turn favor Oracle; however it is far from ideal.
Oracle’s competitors in the database arena allow their products to be licensed by virtual CPU without requiring physical bindings (see Microsoft’s and IBM’s policies), and so should Oracle. Doing so allows VMs to move about the physical infrastructure as required to support IT operations. Binding enterprise software licenses to physical assets is a legacy licensing model, and Oracle is practically alone in their licensing policies.
Oracle’s strategy with regard to licensing is one that I’ve seen before. Oracle is effectively taxing organizations for running Oracle Database in a VM. In most cases, organizations will have to pay increased licensing fees. This policy hurts the customer, and in my opinion is an attempt to stall market adoption while Oracle finishes building out its own x86 virtualization platform.
Oracle, it’s time to classify all x86 hypervisors as “hard partitioning.” Our clients are increasingly deploying enterprise applications on x86 virtualization hypervisors. You’re putting them in a tough position, and many consider the virtual infrastructure the foundation for their cloud architecture. Some clients have told me they are now considering moving forward with DB2 or SQL Server because they are unwilling to pay a penalty to run Oracle on any x86 hypervisor. In the end, our clients shouldn’t have to make that choice. They should have the freedom to run the applications they want on the platform they want. This licensing policy is affecting the bottom line of our clients and could ultimately affect your bottom line too. It shouldn’t have to come to that. Let’s just "right the wrong.” Besides, your “Partitioning” document which describes software licensing for virtual environments was last updated in January 2008. In response to my last blog post, you were able to revise a support statement within two days. How about taking the time to revise a licensing policy that is clearly outdated and places an unnecessary burden on our clients?
Ever since the Oracle/Sun deal was announced (see my comments here), the rumor mill has been working fulltime on the issue of what Oracle will do with Sun’s Hardware business. Last week, in an interview here, Larry Ellison tried to put rumors of the imminent demise of Sun’s hardware business to rest. The gist of the interview is Oracle is going to embrace Sun’s hardware business with the zeal of a convert.
Unfortunately, the effect of these protestations of undying hardware love were somewhat undermined this week when Sun made the details of it’s courtship of Oracle public (see here for the gory SEC details). Apparently, all Oracle really wanted was part of Sun’s software business and a minority stake in the company, apparently Sun turned that idea down.
Plan B was to go in with an unnamed hardware company (HP according to most sources) with Oracle taking the software and HP getting the hardware business. That plan failed as well, leaving Oracle with two choices, walk away, or buy Sun with its hardware baggage and all, and sort it out later.
Apparently buying the entire company was preferable to walking away. Subsequently, on the road to Santa Clara to finalize the deal, Larry had a religious experience and became a born again hardware geek.
Of course, you cynics out there might be thinking that Oracle had to say nice things about the hardware business, at least for now. The last thing they want is to confirm a Sun customer’s worst nightmare and SPARC a mass exodus.
Posted by: Nik Simpson
By now, I guess everyone has seen the incredible news that the EU has levied a €1.06 ($1.45USB) fine on Intel for "illegal sales practices". As you can imagine, Intel was unhappy about the news, while AMD applauded the move.
From a technical analysis perspective, there are no immediate implications. Intel will still continue to ship it's entire portfolio of processor products, including the new Nahalem (XEON 5500 series) processor. Well, at least for now. However, one has to question the long term implications, including whether or not Intel has the cash to sustain these product lines given the fine. Intel, like many other companies in this economic climate, are watching every dime. Will this fine affect their ability to produce product in sufficient quantities to meet IHV demand? These types of issues make IHVs (e.g. Dell, HP, and IBM) very nervous. Often times, there simply aren't enough chips to go around in the server market. That's why every IHV scrambles to be "on stage" with Intel when they announce a new processor...to guarantee they are "first to market" and corner as much of Intel's capacity as possible. The more processors the IHVs have on hand, the more serves they can manufacture... and the easier it is to keep the competition from shipping similar servers. It's been this way in the server market for years. How many times have customers attempted to purchase a server from an IHV, only to find out that the ship date is extended 3+ months?
Another question: will this judgment hinder Intel from making more investments in future products? Chips design is a long process. New processors are on the drawing board 5+ years in advance. If Intel is forced to make hard decisions, R&D may be the place.
Part of what we've been blogging on here in DCS is the increasing competition within the IT industry...including Ciscos's entry in the blade server market with UCS and Oracle's Virtual Iron acquisition. We think it's an inevitability that larger companies will begin to compete across technical, geographical, and vertical market boundaries. Companies that were once "close partners" are now suspiciously watching each other from across the table. Stands to reason the the governing agencies will be closely following these unfolding events.
[posted by: Drue Reeves]
As Richard has already pointed out in an earlier blog, Oracle acquired additional server virtualization technology today by purchasing Virtual Iron. This acquisition had long since been in the works and predicted not only by Burton Group, but by several other organizations too.
The big question on everyone's mind is: why? After acquiring Sun Microsystems earlier last month, one would think that Oracle has all the virtualization technology they need. Richard has already pointed out several reasons why Oracle made this move... including SMB customer acquisition, better management tools, and the ability to sell Oracle's new found virtualization technology as a standalone product. All good points...I'm sure these were on the top of Oracle's list. There is another potential reason -- to keep VirtualIron out of the hands of a potential competitior such as RedHat or Novell. In fact, Oracle may view VirtualIron as another item on their grocery list of companies to acquire that includes RedHat. By purchasing Virtual Iron, Oracle prevents RedHat from acquiring additional virtualization technology, perhaps in attempt to keep RH's price low for a future acquisition. It also prevents Novell from buying VirtualIron's technology, which uses Novell's SuSE Linux for it's services partition.
There are other implications too.
Oracle is now in an interesting position. For many IT technology companies, Oracle has moved from being a strategic partner, to a potential competitor. With the Sun acquisition, both server AND storage companies -- who once happily sold Oracle database solutions -- have to wonder if Oracle will compete by offering highly-tuned servers and storage for their data base technology. Microsoft and Oracle have been competing for a while, but these two acquisitions open a new competitive chapter in virtualization and operating systems. VMware too, realizes there is a new player with deeper pockets in the virtualization space.
But one can hardly blame Oracle. Increasing competition is a sign of the IT industry times. How long could Oracle grow revenues with a single flagship product that has captured a large portion of the market? Oracle is doing what well-managed companies do...return value to shareholders. Cisco reached the same conclusion earlier this year, and has since expanded into the server hardware market with the UCS announcement. Yes, it's an interesting time in the IT industry, there simply isn't enough market share to go around anymore. Competition among the bigger players was inevitable at some point.
[posted by: Drue Reeves]
This morning, Oracle announced its intent to purchase Virtual Iron with the acquisition expecting to close this summer. I had blogged about this just over two months ago when some rumors had hit the street of a possible acquisition by Oracle and what that would mean. So let’s recap what this means:
1. First and foremost, if Oracle keeps the Virtual Iron product in tact plus its distribution channel, this will signal a move down market for Oracle. Virtual Iron is a channel only product targeted at the small to medium enterprise market. This is a market dominated by the likes of Microsoft and not Oracle. Virtual Iron had done very well in this market until Microsoft launched Hyper-v at which time Virtual Iron’s market began.
2. The move gives Oracle’s virtualization management tools a shot in the arm. As I had mentioned in my earlier blog, Virtual Iron meets 83% of Burton Group’s required criteria for production worthy hypervisors. The big missing piece for Virtual Iron was enterprise level support and support lifecycle – easily filled by Oracle.
3. This gives Oracle a virtual machine management product not requiring their Enterprise Manager. The biggest advantage is the ability to sell virtualization stand-alone.
4. What does this mean for Novell? Virtual Iron depends heavily on SLES 10 for its services partition. The only answer I can see is that long term, this will get swapped out for Oracle Enterprise Linux (OEL) bits. Still, how this plays out is in Novell’s hands. Will Novell aggressively partner with Oracle? Historically, Novell has not done so.
Let’s watch the first point above. I believe this will be the hardest for Oracle to preserve, if they even intend on preserving Virtual Iron’s channel into the small to medium enterprise. It is an opportunity for them to compete more with Microsoft down market, but it will require some additional pricing and product changes including pushing OVM into the down market channel without the rich management capabilities as the “starter pack” or free version to compete against Hyper-V, VMware ESX and Citrix XenServer 5 – all of which are free.
As the merger completes, we expect to see more clearly how the products will end up being positioned in the channel.
[Posted by: Richard Jones]