7 ms·

"a specialist advisory company helping clients deal with Oracle licenses" I would (naively, I know) imagine that if you need to hire a third party to help you

by krylon 3y ago

"a specialist advisory company helping clients deal with Oracle licenses" I would (naively, I know) imagine that if you need to hire a third party to help you sort out your licenses with a vendor, you would do whatever it takes to get rid of that vendor. It's almost as if Oracle wants their customers to ditch them the first chance they get.

kragen 3y ago
oracle products aren't really products you can ditch in most cases. generally what it takes to get rid of them is to go out of business and be replaced by a business that isn't an oracle customer. i had a very interesting thread about that dynamic on here with pamar three weeks ago, which will be very interesting reading for anyone who is wondering why people don't ditch oracle https://news.ycombinator.com/item?id=39397513 https://news.ycombinator.com/item?id=39397513
- pantulis 3y ago
  Thanks for pointing that thread out!
  - kragen 3y ago
    i'm glad you're enjoying it! i found it very educational
  - le-mark 3y ago
    I think the missing piece from that exchange is the reality that a lot of surviving, legacy, mission critical applications is that they are generally internal to large companies and have grown over decades to encapsulate business processes for entire industries. Consider an application that has been under active development for 30-40 years by 10-100 developers. The cost to rewrite is staggering, and the risk of failure is huge.
    - kragen 3y ago
      i agree with that point and i would add a link to your comment if i could still add to that thread
      - pantulis 3y ago
        I would add that that's the type of work our industry is mostly comprised of. What gets usually discussed here in HN is the tip of the iceberg.
        kragen 3y ago
        i think that's mostly other industries where programmers work
- konschubert 3y ago
  That’s why it’s so important that competition is possible in a market. Such that legacy players with inefficient legacy technologies can be driven out of the market.
  - geodel 3y ago
    And which is efficient modern technology taking its place?
    - konschubert 3y ago
      For oracle DB, it’s mostly Postgres I guess?
      - kragen 3y ago
        postgres is adequately efficient technology from last millennium, but at the level of execution efficiency it's pretty much the same as oracle, maybe a bit worse more recent systems like impala, spark, kafka, cassandra, leveldb, influxdb, rocksdb, duckdb, monetdb, lmdb, sqlite, parquet, hbase, etc., are a lot more efficient at execution efficiency, though in many cases that's only 'up to such-and-such a scale' or 'above such-and-such a scale' or 'for such-and-such use cases'. there's a perhaps too comprehensive overview of the scene at https://github.com/newTendermint/awesome-bigdata https://github.com/newTendermint/awesome-bigdata but the big business inefficiency with oracle is not technical, it's the human problem of not having control over your core business processes or the ability to continue carrying them out if, when oracle says 'jump', you say anything but 'how high?'
        konschubert 3y ago
        Disregarding your list of "modern technologies" for a second, I think we agree on the core point here: Postgres may or may not be better than oracle DB. The sizeable advantage it has: you're not dependent on another company that will try to extract your margin as a fee.
- burningChrome 3y ago
  A smaller company I worked for a few years ago was migrating its old ERP legacy system and brought in some people from Oracle, SAP and Epicor. They decided to go with SAP, but I remember my boss in several lunch meetings saying that they didn't get a sales pitch from the other vendors as much as a litany of horror stories about why they shouldn't go with Oracle. It worked since my manager said he asked around and did his own research and wondered how they're even still in business since everybody he talked to said the same thing - whatever you do, do not go with Oracle.
  - AtlasBarfed 3y ago
    How does anyone in IT management not know that Oracle is poison? That blows my mind. I encountered two Oracle audits within 7ish years in the industry, and heard about others. If anyone goes to MIS school, there should probably be a contracts day somewhere in that curriculum, and "don't use Oracle" should be the first bullet point. Maybe in the 80s and 90s without the internet it might be more hush-hush. But this is now two decades of aggressive Oracle audits. Two decades is a LONG TIME for companies to get off of a vendor. And now there's Postgres with, what, 30 years of engineering into it? Honestly if your database scale exceeds Postgres, you should be on Cassandra or other specialized database that will actually scale to really large sizes, not some weirdo hyper-hardware Oracle setup. Virtually every large org has a very involved process for vendor selection. HOW DOES ORACLE SURVIVE THESE? How does any IT organization not have a standing policy of "generally don't use oracle unless you absolutely have to"?
    - kragen 3y ago
      postgres dates from 01974, it used to be called ingres, so it has 50 years of engineering, not 30. the 'post' is from when they added 'object-oriented' features to make it 'post-relational' as i understand it, oracle mostly sells to executives above it management, but there are also lots of executives in it management who aren't as concerned about the survival of their company as they are their own careers. it's hard to point to cases where company failure can be specifically pinned on oracle licensing fees, but since a company running on oracle can never switch away, ultimately there's no reason for oracle to leave any profits for the company shareholders when they could simply extract them in licensing fees. unless the company has pre-existing licensing contracts in place, i guess, and successfully defends them — which it won't be able to do if it fails oracle's licensing audit, and obviously copyright infringement is ubiquitous in every company, so most will fail, and then oracle can alter the deal
icedchai 3y ago
Once you're using an Oracle database, you are probably using proprietary Oracle features, SQL syntax, client libraries, etc. The first chance you get might be a while. I once worked on a project porting an app from Oracle to another commercial DB. When Oracle is deeply embedded in your applications, it's easier said than done.
- __loam 3y ago
  It's a good thing there aren't numerous open source alternative databases that can be hosted by numerous other services then.
  - SteveNuts 3y ago
    These companies are also using EBS as their ERP, which you most certainly cannot swap out the underlying database.
  - mickeyp 3y ago
    This is a great way to tell everyone you've never had to do this type of migration. Oracle's got a lot of nasty things going for it, for sure. But there's a reason people still use it: part of it is vendor lock-in, of course; the other is that the database is actually really nice.
    - __loam 3y ago
      Yeah I mean, I get it. Amazon spent years getting off of oracle. I'm just saying the only reason to be on oracle now is because migration is expensive. It says a lot that it's not a competitive product for new applications, and is in fact a liability.
  - lazide 3y ago
    Oh man, in theory SQL is standard - in practice, you’ll need to rewrite (or do major surgery) on nearly everything that interacts with your Oracle instance. Unless you’ve been incredibly careful, which is unlikely. And chances are, you started using Oracle because of some enterprise software somewhere for which you don’t even have the source - so good luck. And don’t forget, Oracle will encourage you to use all their Oracle specific stuff everywhere in their documentation. It’s a giant, idiosyncratic mess.
toomuchtodo 3y ago
Even Amazon had a hard time migrating. https://aws.amazon.com/solutions/case-studies/amazon-database-migration/ https://aws.amazon.com/solutions/case-studies/amazon-databas... https://aws.amazon.com/blogs/aws/migration-complete-amazons-consumer-business-just-turned-off-its-final-oracle-database/| https://aws.amazon.com/blogs/aws/migration-complete-amazons-... https://news.ycombinator.com/item?id=21258127 https://news.ycombinator.com/item?id=21258127 (Edit: 2019)
- falcor84 3y ago
  Do you happen to know when that took place? I can't seem to find any dates on that page
  - SmooL 3y ago
    It was a multi year effort mainly around 2015/16 but extended into 2018 IIRC
  - cyberax 3y ago
    It started in the early 2010-s. First, relational databases were discouraged for new projects, then some projects started migrating from RDBMS to DynamoDB (or to the special internal NoSQL storage systems). The final push to move off Oracle (and RDBMS in general) started around 2016.
    - icedchai 3y ago
      Dynamo locks you in as much as Oracle. This is not a problem for Amazon, but if you're a normal customer, you should should think carefully.
DANmode 3y ago
They want any customers capable of avoiding their sand traps to self-select out, yes. They want the biggest, juiciest hits, not to have to fight with savvy buyers for what they believe they deserve.

by krylon 3y ago

kragen 3y ago

oracle products aren't really products you can ditch in most cases. generally what it takes to get rid of them is to go out of business and be replaced by a business that isn't an oracle customer. i had a very interesting thread about that dynamic on here with pamar three weeks ago, which will be very interesting reading for anyone who is wondering why people don't ditch oracle https://news.ycombinator.com/item?id=39397513 https://news.ycombinator.com/item?id=39397513

pantulis 3y ago
Thanks for pointing that thread out!
- kragen 3y ago
  i'm glad you're enjoying it! i found it very educational
- le-mark 3y ago
  I think the missing piece from that exchange is the reality that a lot of surviving, legacy, mission critical applications is that they are generally internal to large companies and have grown over decades to encapsulate business processes for entire industries. Consider an application that has been under active development for 30-40 years by 10-100 developers. The cost to rewrite is staggering, and the risk of failure is huge.
  - kragen 3y ago
    i agree with that point and i would add a link to your comment if i could still add to that thread
    - pantulis 3y ago
      I would add that that's the type of work our industry is mostly comprised of. What gets usually discussed here in HN is the tip of the iceberg.
      - kragen 3y ago
        i think that's mostly other industries where programmers work
konschubert 3y ago
That’s why it’s so important that competition is possible in a market. Such that legacy players with inefficient legacy technologies can be driven out of the market.
- geodel 3y ago
  And which is efficient modern technology taking its place?
  - konschubert 3y ago
    For oracle DB, it’s mostly Postgres I guess?
    - kragen 3y ago
      postgres is adequately efficient technology from last millennium, but at the level of execution efficiency it's pretty much the same as oracle, maybe a bit worse more recent systems like impala, spark, kafka, cassandra, leveldb, influxdb, rocksdb, duckdb, monetdb, lmdb, sqlite, parquet, hbase, etc., are a lot more efficient at execution efficiency, though in many cases that's only 'up to such-and-such a scale' or 'above such-and-such a scale' or 'for such-and-such use cases'. there's a perhaps too comprehensive overview of the scene at https://github.com/newTendermint/awesome-bigdata https://github.com/newTendermint/awesome-bigdata but the big business inefficiency with oracle is not technical, it's the human problem of not having control over your core business processes or the ability to continue carrying them out if, when oracle says 'jump', you say anything but 'how high?'
      - konschubert 3y ago
        Disregarding your list of "modern technologies" for a second, I think we agree on the core point here: Postgres may or may not be better than oracle DB. The sizeable advantage it has: you're not dependent on another company that will try to extract your margin as a fee.
burningChrome 3y ago
A smaller company I worked for a few years ago was migrating its old ERP legacy system and brought in some people from Oracle, SAP and Epicor. They decided to go with SAP, but I remember my boss in several lunch meetings saying that they didn't get a sales pitch from the other vendors as much as a litany of horror stories about why they shouldn't go with Oracle. It worked since my manager said he asked around and did his own research and wondered how they're even still in business since everybody he talked to said the same thing - whatever you do, do not go with Oracle.
- AtlasBarfed 3y ago
  How does anyone in IT management not know that Oracle is poison? That blows my mind. I encountered two Oracle audits within 7ish years in the industry, and heard about others. If anyone goes to MIS school, there should probably be a contracts day somewhere in that curriculum, and "don't use Oracle" should be the first bullet point. Maybe in the 80s and 90s without the internet it might be more hush-hush. But this is now two decades of aggressive Oracle audits. Two decades is a LONG TIME for companies to get off of a vendor. And now there's Postgres with, what, 30 years of engineering into it? Honestly if your database scale exceeds Postgres, you should be on Cassandra or other specialized database that will actually scale to really large sizes, not some weirdo hyper-hardware Oracle setup. Virtually every large org has a very involved process for vendor selection. HOW DOES ORACLE SURVIVE THESE? How does any IT organization not have a standing policy of "generally don't use oracle unless you absolutely have to"?
  - kragen 3y ago
    postgres dates from 01974, it used to be called ingres, so it has 50 years of engineering, not 30. the 'post' is from when they added 'object-oriented' features to make it 'post-relational' as i understand it, oracle mostly sells to executives above it management, but there are also lots of executives in it management who aren't as concerned about the survival of their company as they are their own careers. it's hard to point to cases where company failure can be specifically pinned on oracle licensing fees, but since a company running on oracle can never switch away, ultimately there's no reason for oracle to leave any profits for the company shareholders when they could simply extract them in licensing fees. unless the company has pre-existing licensing contracts in place, i guess, and successfully defends them — which it won't be able to do if it fails oracle's licensing audit, and obviously copyright infringement is ubiquitous in every company, so most will fail, and then oracle can alter the deal

icedchai 3y ago

Once you're using an Oracle database, you are probably using proprietary Oracle features, SQL syntax, client libraries, etc. The first chance you get might be a while. I once worked on a project porting an app from Oracle to another commercial DB. When Oracle is deeply embedded in your applications, it's easier said than done.

__loam 3y ago
It's a good thing there aren't numerous open source alternative databases that can be hosted by numerous other services then.
- SteveNuts 3y ago
  These companies are also using EBS as their ERP, which you most certainly cannot swap out the underlying database.
- mickeyp 3y ago
  This is a great way to tell everyone you've never had to do this type of migration. Oracle's got a lot of nasty things going for it, for sure. But there's a reason people still use it: part of it is vendor lock-in, of course; the other is that the database is actually really nice.
  - __loam 3y ago
    Yeah I mean, I get it. Amazon spent years getting off of oracle. I'm just saying the only reason to be on oracle now is because migration is expensive. It says a lot that it's not a competitive product for new applications, and is in fact a liability.
- lazide 3y ago
  Oh man, in theory SQL is standard - in practice, you’ll need to rewrite (or do major surgery) on nearly everything that interacts with your Oracle instance. Unless you’ve been incredibly careful, which is unlikely. And chances are, you started using Oracle because of some enterprise software somewhere for which you don’t even have the source - so good luck. And don’t forget, Oracle will encourage you to use all their Oracle specific stuff everywhere in their documentation. It’s a giant, idiosyncratic mess.

toomuchtodo 3y ago

Even Amazon had a hard time migrating. https://aws.amazon.com/solutions/case-studies/amazon-database-migration/ https://aws.amazon.com/solutions/case-studies/amazon-databas... https://aws.amazon.com/blogs/aws/migration-complete-amazons-consumer-business-just-turned-off-its-final-oracle-database/| https://aws.amazon.com/blogs/aws/migration-complete-amazons-... https://news.ycombinator.com/item?id=21258127 https://news.ycombinator.com/item?id=21258127 (Edit: 2019)

falcor84 3y ago
Do you happen to know when that took place? I can't seem to find any dates on that page
- SmooL 3y ago
  It was a multi year effort mainly around 2015/16 but extended into 2018 IIRC
- cyberax 3y ago
  It started in the early 2010-s. First, relational databases were discouraged for new projects, then some projects started migrating from RDBMS to DynamoDB (or to the special internal NoSQL storage systems). The final push to move off Oracle (and RDBMS in general) started around 2016.
  - icedchai 3y ago
    Dynamo locks you in as much as Oracle. This is not a problem for Amazon, but if you're a normal customer, you should should think carefully.

DANmode 3y ago

They want any customers capable of avoiding their sand traps to self-select out, yes. They want the biggest, juiciest hits, not to have to fight with savvy buyers for what they believe they deserve.