I am happy Oracle is losing this battle (edit: or at least feeling the heat), one sort of personal reason is that they have killed/crippled many open source projects.
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.
But if you really want to see your money well spent, Oracle is not at all the way. The recent decision by Yandex to shift from Oracle to Postgres should be seen here. [1]
> 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!"
For many people in IT, generally not the Hacker News crowd, but the guys in the trenches of [insert corporation name here] with ops in many countries, The Money is NOT really the important thing. Risk mitigation by having a passthrough to the big IT vendors is what they are paying for specifically. I work in the IT consulting / business research space. In our surveys, "vendor viability" is a frequent concern, and the more critical the workload, the more weight is given to wondering whether the vendor will be around, unchanged, in the next 3 years.
The risk mitigation factor from large vendors comes not from performance but from reliability. You can trust that old mainframe code will continue to be supported for many years. You can trust that your COBOL workload will be continue to run, and that the 20 years of updates, patches, and tweaks have made it reliable and predictable in a way that precludes rip and replace in all but the most extenuating circumstances.
IT budgets tend to be governed by an 80/20 rule - maintenance vs innovation. Sometimes, its more of a 95/5 in practicality due to shrinking budgets. My experience says that the innovation side is drastically shifting away from these big vendors, but that the maintenance side has a lot more riding on it still.
Well, thing is, Open Source is changing that proposition. As long as you're prepared to be conservative in your choices, something like Debian + Apache + OSS programming language will likely be around 20-40 years from now.
When is the last time an OSS programming language that took off actually died? For example, even though it's not as popular Perl 5 is still used professionally in many environments and as far as I know the ecosystem actually went through a sort of renaissance a few years back.
And these days I think it's even easier for OSS ecosystems to achieve critical mass and sustain themselves for decades since communication is easier (a lot more broadband internet in the world) and there's a lot more programmers around. Python, Ruby, PHP & co will probably be around long after I'm dead.
A lot of large U.S. organizations wont use software they cant buy support for. So, you can use RedHat and buy support. When you create software, your developers are going to use all kinds of tools, libraries, etc. and depending on the policies of the organization they are going to want to manage that risk. For example, if you're a bank and the devs who make your mobile app use some random authentication library that later turns out to have major security issues- the bank wants to have support for fixing the problem immediately. And, they want to know who they sue to recover the money they lost due to the security issues.
This is certainly a cultural thing. In some organizations (and even the governments of other countries) open source is well regarded and sometimes required. These organizations realize that a strong trusted community around an open source project is usually good enough- especially when you invest in good employees.
Part of the reason that Postgres is popular is that there are multiple companies selling support for it, several of which are also major contributors. So there's actual competition to keep prices somewhat under control.
I disagree that there's PostgreSQL support out there. When I was having serious performance issues, I did a ton of Googling and couldn't find a single place that could offer a-la-carte support, only very, very expensive yearly subscriptions from questionable places - ie. no name brand consultants or anyone connected to PostgreSQL itself.
I agree. However one additional thing to keep in mind in the COTS vs FOSS is if there is some bug that affects the company and requires attention. The company doesn't generally have the engineers on staff to actually change that software, and there's no guarantee that the associated FOSS community will prioritize the bug. With a COTS solution, you can pick up the phone and call the support team. Generally my company chooses COTS over FOSS because they want guaranteed support even if it costs more.
Note, some FOSS products also provide a strong support team to handle this exact thing, and in those cases they were usually the winner.
Edit: Looks like abakker posted the same idea simultaneously.
Indeed. It seems that the most sustainable business model for Open Source so far is a combination of FOSS product + paid support / consulting company. It has some potential conflict of interest (e.g. deliberately not improving some aspects of the product that brings in support calls), but being a successful open-source product often depends on outside contributions which themselves depend on reputation, and that may keep companies honest.
Many of the companies making proprietary products with high lockin have terrible support just because they know you cant leave. Whereas it's the opposite for some startups and FOSS companies knowing how easy it is for them to loose business. So, I dont buy that as an advantage of companies like Oracle.
You want support for sure but big companies are hit and miss on support quality.
From what I have experienced, open source is acceptable, as long as it has a support contract behind it. So basically for Linux you can use Red Hat or Suse, and with the occasional Ubuntu in there as well.
It's not about whether the technology will die per se; it's about whether they are contractually guaranteed that there will be a professional support team in place to support it for X years, and whether the vendor's ability to fulfill that contract over the long term is perceived as realistic by the client.
Consulting mailing lists and IRC for a DIY solution is not an acceptable solution for most enterprise users. Moreover, there's nobody to sue if something goes wrong.
Red Hat was formed to fill that gap, but so far it has had only modest success. Companies like IBM, HPE, and Oracle exist because they are perceived as stable, likely to be able to support their technology over the long term.
For example, mainframes and COBOL are largely long dead technologies, but banks that bought mainframes running COBOL from IBM in the 1970s are still very much getting active commercial-grade support for those technologies from IBM today.
Open source may perpetuate, but it is the on-call, active support that enterprises value. You can't exactly demand prompt action from the support forums, can you? Now maybe open source like Red Hat works that way, but it is very much the commercial terms and operating models that businesses are interested in.
Again, for innovative new projects, this is changing.
You can't necessarily demand prompt action from a big vendor like Oracle, either.
Years ago, I worked on a project that used Oracle's BPM product. It was the only time I've worked on something where the team had a direct line to vendor support. When we had issues, all they ever seemed to do was ask for more logs, over and over again. I think they were hoping we'd give up and close our SRs.
Luckily, I got off that project pretty quick. I later learned that they 1) rewrote their BPM product and did not offer a clear upgrade path to the new version, and 2) planned to end support for the old version in a few years.
As a developer, the promise of vendor support doesn't ease my mind very much.
This is, of course, how oracle and others earned its reputation. These things and worse really happen. Obviously nobody wants this when they pay for better.
I agree with another commenter that in the long run, it'll end up as OSS + support from a 3rd party consultant or vendor that is commercially aligned with your success.
It has taken a very long time to convince most IT to behave like a branch of business that can create new value. Once that shift happens fully, we'll see the "keep the lights on at all costs" mindset change a bit in favor of truly measuring ROI and true total cost of ownership. For most large companies this has never been done.
Being able to pass the buck to IBM if things go wrong was actually the theme of IBM's ads in 2001. In a typical ad, the CEO is getting blamed because the system is down / can't be upgraded. CEO: "And whose job is it to make sure all this stuff works the way it's supposed to?" Assistant: "That would be yours." Tagline: "And that's when it hits you, you are so ready for IBM.”
(Of course I have to admit they were successful ads if I remember them 15 years later.)
> Someone is delivering business value; whomever that is is the one who is getting paid.
I was going to respond to this by pointing out some common exceptions, but patio11 actually covered this issue in his post too:
"Businesses do things for irrational and political reasons all the time (see below), but in the main they converge on doing things which increase revenue or reduce costs. Status in well-run businesses generally is awarded to people who successfully take credit for doing one of these things. (That can, but does not necessarily, entail actually doing them.)"
EDIT:
"Their [Salesforce's] motto and sales point is “No Software”, which conveys to their actual customers “You know those programmers you have working on your internal systems? If you used Salesforce, you could fire half of them and pocket part of the difference in your bonus.” (There’s nothing wrong with this, by the way. You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.)"
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 horrifying to watch.
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.
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.
Don't forget the original reason: backward compatibility with complicated, mission-critical software on weird hardware nobody can legally clone. These businesses would have to port all their stuff to avoid IBM. They probably don't even know what it does. So, they stick with them to mitigate that risk.
I just spent today in meeting hell with networking vendor sales engineers. One thing everyone agreed on was what an absolute delight it was moving from Oracle to Postgres. Oracle is a top-class database - it saves your data, it gives it back really fast and reliably - but every other detail of dealing with them is awful. The biggest benefit of moving to PG is we never have to think about licenses again.
> 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.
Well, this can be said for any big business software company. It's the same story with SAP, IBM and friends. Business software is simply not about spending money well.
People say that a lot, but I work with customers all the time who are very happy with their solutions. I don't disagree that some people hate them, or hate this or that ui, but I can think to many companies/interactions with people that love the products.
That's never really expressed places like here. It's just "not spending money well", when I think there are legitimate positives to a lot of business software.
I don't claim that I know the ultimate truth, but I worked for many years for one of those big business software companies. But from my experience, only the people who don't have to interact with such products in any form like it. (Who are often also making the decision to purchase it)
It happened only a few times that users of such products (analysts, admins, support, devs, ...) told me that they like this or that. And I still remember each one of those guys and girls. (Weren't that many)
I know what those companies charge for their software and maintenance. I've been involved in the development of those products for a couple of years. And my very personal opinion is: they're not worth their money. No matter what a customer tells the press how much easier their business is after purchasing product X from company Y.
As I said, it's my personal opinion on that matter.
Big companies are often are complicated mess, and I can emphasize with desire to simplify and streamline operation. There's some benefit with setting your infrastructure in such a way that there's a known party you can pay to fix things quickly, and that you can sue if they can't.
Often they also like to stay understaffed in IT, so having consistent vendors, and similar systems allows them to keep just a few guys around that have any clue how it works, and supplement with consultants and vendor support.
"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."
- Is there any source to justify this comment ?
Even though I think it's a lot more nuanced than that so I don't exactly agree asking for a source for every little thing, particularly things that are clearly understood through experience (or something you can Google yourself), is a redditism that I think HN would be much better off without. It's often an underhanded way to effectively kill a discussion with a cheap "checkmate". If you disagree or have a differing experience simply say so.
The reality when you work in these fields are that there are many different reasons why a given solution is selected, and often times people really like it.
I almost don't want to post about this here because I know it's going to be disliked, and I'm not trying to start an argument. But you never get that perspective here.
I agree in the general sense but it's important to understand that the reason you see so much disdain for these pieces of enterprise software are motivated by reasons that are just as valid as the reasons for choosing it in the first place. Is Oracle RAC a database with compelling features and a large pool of adequate DBAs? Sure. Is it a piece of shit that requires X Windows on the server? Sure. The reason it needs an X Windows server to install and manage is because it needs to have a GUI that those pool of cheap DBAs is capable of reasoning about.
SharePoint is good for locking everything down, enabling complex workflows and intricate business processes. Because of that it's a total shit show from and employees perspective because it drains your life force every time you have to slog through it.
Heck even something like JIRA is an example of this. Its infinite knobs and levers let managers and PMs layer on complexity until a nice out of the box experience turns a lot of HNers into JIRA haters for life.
Earlier this week, Oracle had their OpenWorld conference in San Francisco. Thousands of badge-wearing attendees swarmed the city and signs plastered all over declared Oracle "The fastest-growing cloud company."
But even the Oracle conference attendees weren't buying it. In a live audience poll held during the live keynote, they voted that Oracle would be unlikely to meet it's cloud goals, and challenged the company's "fastest-growing" claim, giving the title to Amazon instead.
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 because X is used by other big corporations and you never get fired for choosing X.
3. The products (Oracle,MS SQL) are not that bad. (Not sure if there is a better way to put this)
I could be wrong, but I can't think of any other important reason. Can anyone pitch in their experience?
We use Oracle. When starting a new project you are told to use Oracle because that is strategic plan of the company. There are teams of Oracle specialists in house that assist us. There are Sybase, SQL Server apps around but would ideally be migrated.
I think its probably time to move off to a free open source platform like PostGres, esp for non critical apps.
Don't underestimate the power of corporate support. I had a problem with IBM DB2 in a previous job - to diagnose IBM went out and bought an exact copy of our hardware, installed the exact copy of our build and ran automated queries to match our load and recreated the problem. You don't get that support from stackoverflow.
This! Enterprise DB vendors like Oracle will send a team of engineers to your site and work with you until the problem is solved. For IT managers, knowing they can rely on this level of commitment is something they will happily pay for.
I guess the number of millions you need to spend per year to get this service is in the double digits, because it sure ain't in the single digits.
Oracle will let the ticket bounce around Tier 1 asking you basic questions for months until you just give up, just like every other vendor.
Sure, we've had our reps bring in pizza and beer during huge Oracle downtimes, but they never actually SOLVE anything. "Escalation" means "get a manager really mad at the poor support person", not "give it to somebody who knows what they're doing", because those support orgs don't have those people anymore.
OTOH, Oracle knows you're not about to stop your business for a year or two so you can figure out how to migrate a 150TB DB, and figure out how every little piece of code written over the past decade or two will handle the migration to different software.
Almost all companies need databases. Very few companies can or want to hire highly skilled database engineers with years of experience of debugging and performance profiling complex applications.
Right, when I go to major client sites, often their people don't know anything about databases really. It's in some random city, and they hire the people that are local.
You get very wildly different levels of skill, and many times very low levels of skill. Then they hire consultants, because we can make the thing go.
The support point is well made, but IBM isn't doing that for free: you're paying them enough that they're eager and able to do so. I'd wager that EnterpriseDB would do the same if you threw sufficient money at them to fix a PostgreSQL installation.
I'd say MS SQL is better than not that bad. It's an excellent product. One of Microsoft's best. It's generally comparable to PostgreSQL (also an excellent piece of software), and has a few advantages over that which may make it worth the extra cost to a business (Management Studio, Reporting Services and clustering).
The query optimizer takes some of the most insane, convoluted, gargantuan queries and somehow produces relatively good plans. I've messed with a variety of DBMS but I've never encountered one with such a forgiving optimizer. Unfortunately, that is also a downside, since it lets people get away with writing truly maddening T-SQL queries in the first place.
No, as of SQL Server either 6.5 or 7, I can't remember which, it was a ground up re-write. You can do cool stuff if you're Windows-native rather than a port from Unix, e.g. http://stackoverflow.com/a/5284537/447514
I started with SQL Server 7, which was soon after the fork from Sybase.
The current versions still have the same syntax and core features. Performance, replication, features, and tools are all vastly improved. But it still feels like the same product.
4. We are paying big bucks to license industry-specific commercial software that forces Oracle or SQL Server.
5. We already have the licenses available via an EA, so why not keep using the same tech for other projects?
6. We can't find highly qualified offshore labor to support FOSS software/platforms (this isn't really true anymore, but it definitely was 10 years ago).
7. We have various data interchanges with our trading partners and using X makes it easier.
8. We already have all this ingrained experience with X and we're a thin margin company already. We can't afford the switching costs. Another angle for this argument is CapEx (big purchases) vs OpEx (labor), and how corps handle IT budgeting.
Post mergers the mantra is "you say that we will get $n from putting all our systems together and it will cost $n/10 but I say you are a bloody liar and want proof and hostages."
Nope. It's true of every Fortune 1000 who are poor at IT and in the hands of vendors. It's not true where I work, and I am pretty sure it's not true at Microsoft, Google, Facebook...
My company nearly had #2 pushed on us. We've been using Postgres and there is no solid reason for us to switch but a consultant came in an suggested Oracle just because all the big boys use it. That argument has a measurable amount of sway for some reason.
> how many of them use Oracle database or SQL Server?
All of them on our portfolio, which are all non software based companies, rather telecomunications, manufacturing, healthcare, commerce, and so on.
Sometimes there are a few projects using Postgres or MySQL, but usually those are small department experiments that either stay small or are eventually migrated to Oracle/SQL Server.
You missed one critical situation: "You must use X because this required / desired product uses X as a backend". Thus, I pay Oracle every year because some Software Developer used it in a product.
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.
5. you can buy/hire accredited expertise as well, which is something BigCo risk-averse management often prefers over competent-but-unaccredited people.
I've never had accredited even come up in a conversation. It's more about paying someone, with deliverables to get something done. Now they must get it done.
Their in house teams are already over worked, under staffed, and usually lower skilled because they are not paying a premium for staff. Could be in some random city without a strong base of people to hire.
That's why consulting works. You pay me a ridiculous amount to fly to your random city every week, where I essentially work as staff, but with clear deliverables on a timeline that must be met.
Then I work ridiculous hours every day while your inhouse staff goes home to see their family.
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.
Also, the fact that once you have almost complete monopoly in the enterprise market, only a huge paradigm shift will knock you down. Most of the times, the market leaders are able to adapt, and the clients give them a lot of leeway - not the least because of the points which you pointed out.
I've worked with a ton, and they are moving from Oracle/DB2 to SAP HANA, but I work in the SAP ERP space, so that's not indicative of the broader world I don't think. Just the trends here.
Also working in SAP ERP space-many clients moving from Oracle to Hana, or planning to move to it. Of course this is only in the existing ERP space, I do migrations.
Keep in mind that Oracle is not just a database company. They have many server and storage products, CRM, ERM, analytics, hosting, "engineered systems", ticketing, etc. etc.
However, there were two big limitations with hierarchical databases: first, relationships were pre-determined; what was a parent and what was a child was a decision made before any data was actually entered
Well, yes and no. IMS was developed for bill-of-materials processing, which is a kind of thing you do in engineering to keep track of all the parts in your thing you're building. It was first used for the Saturn V rocket. At or at least near the top level you would have things like "a booster" and at the bottom level you would have something like "a bolt", "a nut", "a washer". There was no conceivable case in which you'd want to make a bolt out of boosters so having these relationships pre-determined wasn't actually a "limitation" at all, in the sense that it would never, ever stop a user of the system doing what they needed to do with it.
Secondly, queries analyzing the children of different parents are impractical: you would need to traverse the hierarchy to retrieve information for every potential item
The sort of query you'd do with this system would be, I want to make a rocket engine, what exactly do I need to order and how many of them, I want to give this piece of the work to this group, do they have all the parts they need in their inventory, and so on and so on. So that's not really an unreasonable sort of query if you are managing an inventory of parts and the processes that make them into ever bigger parts until finally you have your very top level parent "a moon mission".
> IMS was developed for bill-of-materials processing
Right, and the restrictions that are appropriate for that domain weren't necessarily appropriate for all the other domains to which it was later applied.
> 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.
There are alternative models that are better suited for some tasks (e.g., graph model), at least on a pragmatic level, but I don't see that the hierarchical model is one of them.
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 sentence.
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.
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.
What a lot of these analysts overlook is why Oracle is trying to take on Amazon, despite being years late to the party. I believe it's a defensive move: Oracle is seeing long-time customers deploy new applications in AWS, and that customer starts to realize, "hey, that went pretty well, why not move more of my stuff to AWS?" Their Oracle sales rep comes calling, and suddenly a once-reliable customer needs fewer Oracle licenses than last year.
Oracle therefore needs an answer to those customers transitioning to the cloud; they want their own cloud to sell. Oracle can undercut Amazon on price--even run their own cloud offerings at a loss for a while--because losing some money on their cloud is better than losing customers from their high-margin products.
> why Oracle is trying to take on Amazon, despite being years late to the party. I believe it's a defensive move
Ellison is all about the money. When "the cloud" started, he quietly bankrolled a bunch of companies spearheading the space, so he didn't have to risk his cash-cow. Once the space was proven, he's steered the whole company - and he didn't do it yesterday, he's done it about 6 years ago. You're seeing results today because Oracle is large, it takes a while to release stuff that has almost been rewritten from scratch to fit the new paradigm, and it takes even more to sell it to Oracle's very conservative userbase.
If it succeeds, the subscription model will make Oracle even more money than before. However, they are effectively rewriting from scratch a large number of their products; this is why they are very limited. It will take another 5 years before they can reach feature-parity with on-premise solutions, assuming on-prem doesn't get anything new in the meantime. Performance is also pretty dismal for some cloud products at the moment.
Oracle selling higher-end products as a service makes total sense, and I agree, the subscription model has potential to make them a good deal of money. What I'm getting at, however, is why are they so aggressively taking on Amazon in the IaaS space? That's the part which doesn't make sense on the surface--they show up late and then attempt to compete on price. Since when has Oracle competed on price?
The conclusion I come to is that Amazon must be eating away at their customer base. Once a customer starts to move some of their IT into AWS, and it goes well, that puts Oracle on the defensive--not a spot they like to be in.
I doubt Oracle really wants to be in the IaaS business just for the sake of IaaS. They want to focus on higher-margin services. The IaaS part must be a defensive move to keep customers away from AWS and within the Oracle ecosystem.
There's another thing that is specific to IaaS: auditability. Part and parcel of Oracle's business model is sending goons to count your servers running this or that appserver, and invariably telling you are not paying enough in licenses. A serious cloud-based architecture that can scale up and down at will (which is what you would deploy on AWS) is fundamentally non-auditable, because it can be scaled down to minimal levels when auditors land. But if you're running on Oracle's servers...
But I think Oracle's "taking on" Amazon is mainly a marketing move. When you think "big cloud providers", #1 is obviously AWS, & then there's MSFT & GOOG, & then other players. Oracle is trying to elevate its offering in especially existing customers minds as a viable competitor, thus raising it's profile. It's the Avis/Hertz strategy
(long time ex-Oracle employee ... take with whatever size grain of salt you wish :-)
As the article mentions, Oracle aims primarily at its own installed-base, which limits how much "innovation" they can do .. can't piss-off the paying customers! Their world-view is incredibly narrow ... years ago they discovered that even though they have millions of paying customers, there is a core of only about 5000 customers that they really need to listen to.
Oracle should look carefully at IBM's recent moves within the Cloud eco-system: instead of offering the AWS-style "everything-including-the-kitchen-sink", IBM's purchase of 'The Weather Network's big-data division has lead them to offer high-level cloud-APIs for dealing with weather data without the need to put it all together (S3+SQS+DynamoDB+EMR...)
He's not wrong. He brings up several good examples and how "cloud computing" is basically meaningless. He says they're gonna change the marketing to be "cloud computing" friendly since both gmail and salesforce are considered "cloud computing". In that world Oracle DBs are also cloud computing.
He's not dumb. He's a very competent businessman. He's not gonna let a 2009 Q/A session get in the way of getting more money just so he can be consistent about ragging on "cloud computing".
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 it. And I don't need an DB in itself anymore. I have my customer data in my CRM, and runs in SFDC datacenters. SFDC is the largest known user of Oracle DB, but it is abstracting away the raw DB product from enterprise users. Like any other SaaS product does.
Which means the total number of ORA DBs will shrink, massively. Hence Oracle buying business apps left and right with all that DB money, to augment the sellable stack. Oracle is the elephant graveyeard of enterprise software, in CRM alone they acquired 5-6 different solutions and still sell a bunch of those (Siebel, Oracle CRM, Oracle OnDemand, Fusion, Peoplesoft, etc.).
SFDC has announced a big move onto AWS, getting away from running their own datacenters - they're moving upstream, going after the business end users. The underlying tech is a commodity, plumbing, invisible.
And what happens to price points of commodities? bye bye fat margin DB business...
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 harping on this. The counterpoint, of course, is if you are running on the best platform, lock-in is not a problem because you don't want to switch.
> Software Development Laboratories implemented it and called it Oracle, and in 1979 sold it to the CIA...
I've long suspected that Oracle's success was due to becoming the de facto RDBMS for any and all government TLA's. I think this is part of Ellison's legendary arrogance. He knows he has the US government by the short hairs when it comes to IT.
I think it also ties well with Sun CEO Scott McNealy's famous, "You have no privacy; get over it," comment. McNealy understood that the CIA (and NSA, FBI, et. al.) were running big data mining operations -- with Oracle, as that was the only game in town, at that point -- on his hardware, but he couldn't just come out and say that.
That's not exactly how it happened - Oracle got the CIA as a customer specifically because doing so would let them skip the queue for a new mainframe, for which there was a waiting list. It was what kids these days would call a "growth hack".
The original "Oracle" was a scheme for storing data on mylar strips, getting into database game was what kids these days would call a "pivot".
I sat next to someone who worked for a well-known company on a plane on the way back from re:invent last year. They were ripping out Oracle and switching to AWS with extreme prejudice after one too many 'guilty-until-proven-innocent' license audits.
The days of being able to treat their customers like dirt with impunity are well and truly over.
This is a wonderful explanation of the original rationale for relational databases. Periodically poeple re-invent IMS' hierarchical design only to rediscover why relations are important. MongoDB's "document database" is a current example.
Actually, I just got a little training on IMS last week, and I have to say, IMS should be reinvented. But not for its weaknesses (hierarchy), but for its strengths (speed).
The idea that the application program gets a compiled representation of the exact data pointers that are in the database, and those data pointers optimized for the problem, is very sound, IMHO. IMS is very close to the metal, at the expense of flexibility, and that's how it should be reinvented.
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).
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.
I think what IMS does is they have those pointers, but these are pointers between records on disk (to minimize IO), not in memory. And the hierarchy is essentially a pre-calculated one-to-many join. So what you do when you design IMS DB is you look at what joins you need and you build your DB structure around that. And that's where, even though IMS is still row-oriented, it differs from the relational model, which is more flexible, but at the cost of higher IO per query.
DataDraw is kinda similar, but in memory. There is a reason why it doesn't have a generic SQL interface, although it would be probably possible to build a slow one on top of it.
P.S. I don't know HyPeR, and I can't google it. And yes, it's possible that somebody already reinvented IMS, I am just not aware of it.
I wish people would stop projecting this relational databases are the only solution to storing data nonsense.
If you are storing a single customer view a document database is the best option since it is a single request per entity id. Likewise if you are storing highly nested data it sometimes is extremely cost to try to model that relationally.
It's akin to saying C++ is the best choice for ALL programming choices.
Whatever view you want it is always a single query for the data in a relational database. In some ways that is the key difference: store the data normalised, query for the view you want.
And anyway, I have yet to see any real world business app which is "a single customer view" and even if is, it quickly expands and changes as the business does.
Oracle is going to be hobbled by Cloud providers in similar manner as TV networks by Netflix. If Oracle reduce access of its software to Cloud infrastructure providers then they lose potential revenue stream and Cloud providers can start promoting alternatives. On the other hand if cloud providers have access to Oracle products in their cloud then Oracle cloud looks unimpressive to customers and no reason to use Oracle cloud.
Like networks learned that must watch shows are decreasing on their networks in last few year Oracle will learn their software is must for decreasing number of customers.
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?
What db does the new enterprise use - airbnb, tesla, uber... even google, apple, facebook, amazon?
If "software is eating the world", and the new enterprises are software companies (even if they don't sell software), do they write their own custom solution, optimized for their usage patterns?
Or do they "grow up" into traditional companies, and rely on outside vendors for their software? I don't think so.
The first versions of Azure were a disaster. It took a good 4 years for MS to turn it around. So whoever this Deepak Patil fellow is - I wouldn't place him in high regard.
I guess this is an off topic question, but shouldn't the example of the Hierarchical Database show Customer as the Root and Order as the Parent and Books as the Child?
I guess it makes sense if the query is "Show me all the Orders in the system".
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.
But if you really want to see your money well spent, Oracle is not at all the way. The recent decision by Yandex to shift from Oracle to Postgres should be seen here. [1]
[1] https://www.pgcon.org/2016/schedule/attachments/426_2016.05....