Oracle Bullies Enterprise Clients Into Cloud Purchases, Consultant Claims

An anonymous reader writes: A consultant claims that Oracle has adopted the widespread use of 'breach notices' this year to force existing enterprise customers to adopt its newly-bolstered range of cloud services, or else be told to stop using all Oracle software within thirty days. Speaking to Business Insider, the unnamed source described the tactic as a 'nuclear option' which is now practically the default when the need to add services or users to an existing contract triggers an 'audit' by Oracle. An ex-Oracle contract negotiator who now works in the ever-expanding business niche of 'Oracle contract negotiation' commented 'Internally, the water cooler gossip there is that they've never seen this kind of aggression before. Oracle has really dialed it up. Customers are buying cloud services to make the Oracle issue go away, not because they have any intention of using cloud services.'

Comments

How much you got?

[pigiron]

After dealing with Oracle for over thirty years I've learned that the answer to the question "how much does Oracle cost?" is "how much money do you have?"

Re:How much you got?

[Dutch Gun]

Seems like a desperation move for a company with under-target earnings, if they're willing to poison long-term relationships with their customers like that. You're going to see businesses deciding that they don't like having a gun held to their head. They'll pay the ransom for now, but some of them will probably start investigating other options in the background.

Re: How much you got?

[cyber-vandal]

MongoDB is webscale!

Re: How much you got?

[Nkwe]

Do you think gmail would have become the most popular email service if it would have used ACID? ACID is *not* the only option. It's the *old* option. It's the expensive and slow option.

Maybe ACID doesn't mean what you think it means. It is not a technology that is "old" or "new", it is a way to think about the requirements of your system. Each of the four letters in ACID stands for a particular property of a database system and these properties (in various combinations) may or may not be needed by the system being built.

If your system is processing something where the integrity of the data is important (like financial systems), you are very likely going to need all four properties. If you are moving money from one place to another, you want to guarantee that that the the money is completely moved or not. You don't want the money partially moved, you don't want money to be lost, and you don't want money to be created out of thin air. ACID (as a concept) guarantees this.

If your solution requires ACID, you don't have to use a database that supports all of the properties of ACID, you could instead implement ACID in your application layer. However if you do this, you have to guarantee that that your application layer implements it properly and that there is no possible way to get to the underlying data store without going through the application layer. You also have to guarantee that no changes, updates, upgrades, or bugs in your application layer every break the ACID guarantee at any time. Making all of these guarantees in your application layer is VERY HARD, which is why people use ACID complaint databases instead to solve this particular problem set.

If your requirements don't need the properties described by ACID, than there isn't anything wrong with using a non ACID database. If may be acceptable for your data to "eventually" become consistent, to be inconsistent, or maybe even lost.

In the gmail example, you don't really need all the ACID properties, so you don't need to use that sort of database to hold the information. Email is not transactional end to end; when you send an email you are not guaranteed that it will get there. Email is also not order guaranteed; if you send multiple emails there is not a guarantee (or need) for them to arrive in the destination mailbox in order. If you are bulk moving messages from one mailbox to another, and only some of them get moved, it is okay and you can just move the remaining messages later.

As always, it is important to chose the right technology to solve the problem you need to solve. ACID compliant databases solve a lot of important problems (usually involving money), and if you have one of those problems, there is nothing "old" about ACID.

Headline from the future:

[Gravis Zero]

The End of Oracle: Unhappy Customers Jumping Ship In Droves

You can only be pushy for as long as you are irreplaceable.

Apps

[Anonymous Coward]

You ( and so many others ) forget oracle is NOT just a database company. They also sell enterprise apps, and dev tools that lock you into their DB since that is the ONLY thing the final app will work with ( Apex for example ).. Once you get on the train it's really hard to get off, especially financially. ( actual hard cost of the change, then the soft cost of starting over ... )

Are there alternatives to everything? Sure, but it's not just a simple 'lets move our data somewhere else' and you have to address the entire ecosystem.

Oh, and remember they still 'own' java too, so a lot of us are potentially screwed if they find a way to stick it to us....

Re:We're ditching Oracle

[Shados]

And this is where things are getting dicey for Oracle. Even an open source DB can deal with billions of rows. And when you go beyond that, people start using multiple interconnected specialized systems instead: a big mismatch of a relational db, hadoop, redshift, dynamo, vertica, spark, etc.

If you need a trillion records in one table, there's better commercial options than Oracle. If you can need specialized tool to handle different data sets of various size, you'll be using a soup of tools, most of which are open source.

There's no reason to use Oracle stuff anymore, aside for legacy compatibility, or if you use their ERP (which for large Retail, is probably the best one, unfortunately)