Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oracle’s Cloudy Future

stratechery.com

Post reply on HN
Print view View original

141–150 of 154 posts

Re: Oracle’s Cloudy Future

#141

Post by gaius »

Karunamon wrote: post #90
planetjones wrote: post #66

Are any new companies choosing Oracle products? Or are they really only relying on banks,insurance companies and other blue chips to take up their 'cloud' offerings?

This is actually a question I never had a good answer for. If I'm a developer, and am going to create a complicated line of business application, are there non-political reasons that I'd want to target Oracle as opposed to, say, Postgres or Maria?

If it has a feature that's cheaper than creating and supporting it yourself. Oracle the database is literally state-of-the-art.

Being database-neutral means only using lowest-common-denominator features, which in turn means if you need it, you gotta write it and maintain it.

Re: Oracle’s Cloudy Future

#142

Post by tracker1 »

hinkley wrote: post #60
treehau5 wrote: post #5

Earlier quoted context omitted.

> Other reason, they are gaining money mainly because there are enough fools around running big corps, who can conveniently pass the buck if something goes wrong. Similar is true for MS too. This is also the sole reason IBM still exists, at least in services. "Oh our system is an overengineered pile of garbage that takes two weeks to deploy an update to a static asset? It's (cue dramatic music) their fault !" CTO pro…

IBM Global Services seems to prefer hiring masochists. They will deploy the most complicated solution they can (almost) keep running and then ask for more time and materials when they miss. The FTEs at the company will want nothing to do with their Rube Goldberg sparkly bullshit and are all too happy to walk away and work on something else. Nobody can make XML impenetrable like IBMGS can. It is both fascinating and h…

This is part of why my initial and strong reaction against most "Enterprise" patterns and libraries... It often leads to so much indirection and complexity, that those working with it don't ever stop to thing "why" they are doing things a certain way, and when new people come in to support said solution, they face a mountain of difficulty.

In the end, I tend to prefer discoverable code (hate angular because it is anti-discoverable), and when there are abstractions, prefer to keep them isolated and clean in purpose. It sometimes requires changes as requirements evolve, but then again, I've been in touch with enough people who've worked on projects I've started/built and haven't gotten any extreme WTFs about it.

Re: Oracle’s Cloudy Future

#143

Post by tracker1 »

dragonwriter wrote: post #54
gaius wrote: post #52

Earlier quoted context omitted.

Sure, my point is that RDBMS are not better they are different . Right tool for the job an' all that.

> Sure, my point is that RDBMS are not better they are different. I can't see any way in which the relational model, either abstractly in or practical application, is less suited to any task than the hierarchical model, and its clearly better suited for many tasks. Its both different and better. The hierarchical model is, especially given the alternatives that existed at the time, good enough for some tasks, sure. Th…

When a normalized entity for real world display and manipulation requires over 30 join operations for a single record and children. Or requires lookup tables (db anti-pattern) in order to keep the number of tables in the schema reasonable. JOINS kill db performance at scale, enough said.

This is why document, object, key/value, column and other types of database stores have become very popular in the past decade, precisely because relational RDBMS aren't a good fit, or even good enough in many cases.

Don't get me wrong, I'd be much more inclined to use a relational/sql RDBMS in many cases. That doesn't mean they are better in even half the cases.

Re: Oracle’s Cloudy Future

#144

Post by tracker1 »

gaius wrote: post #59
dragonwriter wrote: post #54

Earlier quoted context omitted.

> Sure, my point is that RDBMS are not better they are different. I can't see any way in which the relational model, either abstractly in or practical application, is less suited to any task than the hierarchical model, and its clearly better suited for many tasks. Its both different and better. The hierarchical model is, especially given the alternatives that existed at the time, good enough for some tasks, sure. Th…

You can do hierarchical queries in Oracle and now you can in Postgres too[1], but that's a relatively recent innovation and it's still horrible in MySQL[2] IMS is still a huge seller for IBM and a tiny fraction is periodically reinvented and hyped as the latest and greatest thing (e.g. MongoDB) so there are use cases for which it is still the right tool. I feel dirty for saying "MongoDB" and "right tool" in the same…

There's always RethinkDB as probably a better example... I don't really dislike MongoDB, I've used it, aware of its' issues, and liked it. I just find RethinkDB's approach much more sane.

Re: Oracle’s Cloudy Future

#145

Post by tracker1 »

gizmodo59 wrote: post #11

A genuine question: If you have worked with any fortune 500/1000 companies (Lets pick non software based companies) either directly or if they are your customers, how many of them use Oracle database or SQL Server? Some of the reasons why this trend WILL continue: 1. Critical software like databases needs support. To the point where there should be someone who can come on premise to fix things. 2. We need to use X be…

As to #3, MS-SQL is actually a really nice DB to work with, it's better than most out of the box, the admin functionality is nicely baked, and the replication story is easy enough to understand and configure for a dev-admin role.

No, it doesn't have every feature that pgsql has, but I'd rather work with it mainly because out of the box configuration and replication support is so good. The licensing costs are also pretty damned good compared to EnterpriseDB support contracts, and much less than equivalent for Oracle.

I've always found too many WTF moments with mysql for my liking, and Firebird simply isn't popular enough (though a very cool dbms option). On the flip side, for certain roles, I'd probably reach for RethinkDB (similar to MS-SQL in terms of admin ux, and a really nice db option). If you need pure scale in terms of read/write Cassandra (C*) is probably the best option.

YMMV of course, and on personal projects I'm very frugal, I really like Azure's Storage Tables for some instances. I think that if Azure had a good keygen service, that combined with Azure Storage Tables would be awesome.

Re: Oracle’s Cloudy Future

#146

Post by tracker1 »

brazzledazzle wrote: post #135
AndyNemmity wrote: post #124

Earlier quoted context omitted.

Certainly true with a variety of products. You are stuck with certain vendors because that's what was used, etc etc.

One thing you gotta give Atlassian credit for is supporting multiple SQL databases. They put in the time and effort and that can be a rare thing in enterprise or b2b software.

It somewhat depends on how much code targets DB specific features... if your data store is relatively "dumb", it's easy enough to abstract out ANSI queries with specific abstractions to keep the code very generic. I'd say that mysql is probably the oddest one out in a lot of cases.

The db/table creation is probably the one part that requires the most tweaking.

I have to admit, I always hated MS Enterprise Library, specifically the Data Application Blocks (I think that's what it was called). Mostly because it was a lot of abstraction for zero gain when you only targeted one database. The only time it was worthwhile was when I worked on an application targetting multiple backend databases. Even then it was a lot of work.

Re: Oracle’s Cloudy Future

#147

Post by bduerst »

dmourati wrote: post #113
bduerst wrote: post #97

Earlier quoted context omitted.

Amazon doesn't really have a PaaS though, right?

One could argue the entire suite of AWS products make up a PaaS. One could also argue that Elastic Beanstalk is their standalone PaaS offering. https://aws.amazon.com/elasticbeanstalk/

Except that isn't really a PaaS when stacked up to the others like App Engine, Heroku, and Azure.

Re: Oracle’s Cloudy Future

#148

Post by Jweb_Guru »

js8 wrote: post #78
Jweb_Guru wrote: post #73

Earlier quoted context omitted.

That's essentially the idea behind Protobuf and friends, is it not? It's not quite as optimized because there's a bounds check, but that's about it (and in many languages you can't get around a NULL or bounds check anyway, and just rely on the branch predictor).

Protobuf is not a database. What comes close is DataDraw, but that is an embedded database, not a server.

I don't understand your meaning, then... lots of database systems have hardcoded fixed pointer offsets for data structures, and some even compile queries into bytecode with those hardcoded pointer paths (for instance, HyPeR does this using LLVM, and I think some other column-stores do as well). Is your issue that those databases aren't hierarchical? On modern machines, pointer chasing is much slower than predictable sequential memory access, so that model doesn't seem like the performance win it was in the past... maybe I'm wrong.

Re: Oracle’s Cloudy Future

#149

Post by lightman_group »

dmourati wrote: post #112
pinaceae wrote: post #32

Good article, but misses the point on Oracle's risk against AWS. Understandable as Ben is more focused on consumer stuff. Oracle's main money maker is their database product. Running on prem, collecting money through license and maintenance contracts. The more DB installs out there, the better. Salesforce uses Oracle for their backend. But here's the rub - as a SFDC customer, I do not care which DB is running below i…

Correct. Amazon understand this dynamic and how to play the game. They can take something like Oracle's DB, turn it into a service, and manage it end to end for the customer, and even provide tools to do the migration. This is a straight attack on Oracle. Once in the AWS ecosystem, it becomes easy to follow the logic described in the CIO using MS products in the article. One real risk is lock in. Larry has been harpi…

You mean the best platform running 4 year old hardware? That one.

Re: Oracle’s Cloudy Future

#150

Post by hinkley »

tracker1 wrote: post #142
hinkley wrote: post #60

Earlier quoted context omitted.

IBM Global Services seems to prefer hiring masochists. They will deploy the most complicated solution they can (almost) keep running and then ask for more time and materials when they miss. The FTEs at the company will want nothing to do with their Rube Goldberg sparkly bullshit and are all too happy to walk away and work on something else. Nobody can make XML impenetrable like IBMGS can. It is both fascinating and h…

This is part of why my initial and strong reaction against most "Enterprise" patterns and libraries... It often leads to so much indirection and complexity, that those working with it don't ever stop to thing "why" they are doing things a certain way, and when new people come in to support said solution, they face a mountain of difficulty. In the end, I tend to prefer discoverable code (hate angular because it is ant…

We had a good convention for our Angular project that wasn't too bad. Certainly a lot more discoverable than the rails project I worked on before it.

I'd like to see a lot more formal work on discoverability. There are a lot of libraries being written by "smart" people who are behaving very stupidly right now.

Post reply on HN