As Oracle CEO Larry Ellison touts the cloud-readiness of Fusion, he needs to deal with some critical questions around pricing and features.
Oracle CEO Larry Ellison took to the stage Wednesday to announce that Oracle's entire Fusion portfolio of applications would be available as both cloud and on-premises applications--and then proceeded to spew his uniquely mean-spirited take on reality for two hours. The bizzaro world that Oracle execs seem to live in clashed more than a few times with at least my reality, during the presentation about what looks to be a fine and interesting product.
First let's cover the announcement: Oracle will offer more than 100 Fusion applications as a service running from Oracle data centers around the world. Ellison and Oracle were sketchy on pricing details (though the products are supposed to be available as of the announcement). Ellison did say that pricing would be "per month per user, just like other cloud providers." Fusion apps available from Oracle via the cloud will run the same code line as applications run on premises. Databases and object stores will be unique for each user, and the Fusion software will run in a virtual machine on Oracle/Sun hardware.
Ellison explained that Oracle's cloud will be elastic, in the sense that when a user needs more capacity, additional VMs can be spun up as needed. One such customer mentioned in a brief promo video was Macy's, where a spokeswoman talked about the ability to seasonally adjust Macy's use of Oracle apps--to run on premises and then use the cloud service to meet peak demand. A perfect example if there ever was one.
But pricing is a big point where Oracle's claims cross each other. Is the pricing by user and month, or is it by VM used, or some combination of metrics? In the case of Macy's, certainly if it adds more users, Oracle might need to add a new VM, but this doesn't seem like something that should matter to the end user who's paying by user and month. The users want response time SLAs from Oracle and have probably specifically chosen the cloud to get out from under such things as guessing the right number of virtual machines that will be needed for a busy business day.
Pricing is similarly problematic for anyone who's looking for a hybrid operation. Ellison spoke not only to Oracle's ability to offer the functionality, but also to make it elegant. After all, it's all the same code base, so it's just a matter of migrating the VM in question and, we suspect, the end user having very similar hardware (i.e. Sun systems and storage, and maybe an Exadata machine depending on the app). But even if the customer has all that, you now have two competing pricing policies--the cloud one, and the on premises one. How's the billing work for that?
Anyone from Oracle who might have been able to answer was immediately out of the room after the presentations Wednesday. But the problem could be a sticky one for a company like Macy's, which might need to frequently cloud burst some workloads. How will Oracle's pricing policy handle such use? We don't know.
From an architectural point of view, Oracle has taken one of two reasonable paths. On one hand, a company could build new software from the ground up for its SaaS offering, as Workday and Salesforce have done. Such software has a full understanding of multitenancy, data protection, billing and so on. By running a single instance of the app, Workday and Salesforce gives users new features as they are released (whether a user wants them or not). The vendors get the efficiency of having just one code line to maintain.
Oracle has taken the other path, which calls for cloud-readiness being built into the Fusion application suite, so all instances, cloud or on premises, can be based on the same code line. This allows for a hybrid model that either isn't possible with other designs, or is at least highly discouraged, except in the cases of the biggest customers.
While the pure-play cloud vendors get operational efficiency, Oracle at least gets some testing and verification efficiency. Just one testing and validation suite is necessary as long as it includes tests for both environments. Now of course code lines rarely remain as lines, customers have special needs and invariably, that line becomes a tree--sometimes with lots and lots of branches. The more branches there are, the more unique testing must be done, and the more likely that errors will crop up.
Which model is better? It all depends on what you're looking for, but Oracle's promise to run every software instance in a VM would lead one to believe that its single instance competitors will have a better efficiency story to tell. But no one was expecting Oracle to be the cost leader, even if Sun hardware is the best and most suited to the job.
Fusion Features Details?
So what are those cloud ready features already baked into Fusion apps that make them all set for the cloud? Well, if multitenancy is built in, which we doubt, it isn't being used by Oracle. But there are plenty of other features that might merit the term cloud-ready. For instance, browser communication might be minimized and made efficient for higher latency networks. The ability to manage hundreds or thousands of pretty-much-similar application instances from a single station might be another. It would be interesting if there were accounting features built in for the purposes of cloud use. But Oracle execs didn't enumerate the cloud ready features built into Fusion; we were told only that they are there and they are important differentiators compared to the competition.
In terms of Fusion app features, since this is exactly the same Fusion as the existing on premises version, there wasn't much new to see. The social component is interesting, since all the apps are social-enabled if you're running Oracle's wiki. The big takeaway from Wednesday is if you want to start with Fusion in the cloud, and keep your options open to bring it in-house, you can--for a price. And no one was talking about price.
Oracle was too busy bashing competitors in general and SAP in particular. Ellison claimed SAP wouldn't have a single cloud-ready product (with the exception of SuccessFactors) until 2020. Thing is, SAP has bunch of apps it markets under the OnDemand sub-brand. There are not 100 of them, but there are about 20. We suspect that a definition exists somewhere for what cloud apps should be and that SAP's apps don't live up to it. But if it walks like a duck and quacks like a duck ... then spend your valuable presentation time better describing your own products.
Ellison's schoolyard shenanigans continued on to comments about Workday (too dependent on Flash) and Salesforce (one-trick pony) until it was time for a demo--well actually, the snubs continued after that, too. The demo was of a set of tools that can be used by marketers for B-to-B and B-to-C social relation management and analysis. Ellison's demo showed how easy it was to add the sale of another product into an existing store--in this case coffee, for an organic grocery store--and then to monitor what people said about it. Sure enough, after 15 minutes or so, the coffee, along with its price, was on Facebook and the grocery store's Web page.
Ironically, when we looked to see if Oracle's new products were given similar treatment, I couldn't find a "buy this product" button or price anywhere on the Oracle website. That would be at least one good use for this product.
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.