Oracle’s Cloudy Future
stratechery.com
stratechery.com
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....
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.
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.
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.
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 proceeds to get bonus
IBM Consultants are brought in
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.
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.
Again, for innovative new projects, this is changing.
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.
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.
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.
You could say the same about proprietary software, no?
Reliable on call support. Oracle is not going to vanish overnight or de prioritize you due to lack of resources.
The possibility of that risk in other firms is sufficient to make them non options
You want support for sure but big companies are hit and miss on support quality.
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.
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.
(Of course I have to admit they were successful ads if I remember them 15 years later.)
Links to the ads: http://www.landscapesofcapital.com/items/show/893 http://www.landscapesofcapital.com/items/show/888
http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro...
Someone is delivering business value; whomever that is is the one who is getting paid.
> 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.)"
Holy shit. That hits hard.
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.
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.
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.
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.
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.
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.
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?
It becomes a self perpetuating system.
The boss finds that proposition attractive, because the alternative with in-house databases is that it's the boss' fault.
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.
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.
Also I am yet to work in any NoSQL project.
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."
Sorry, but this story is true in every Fortune 1000, except maybe a very small number of technology companies.
Why? Line of business team X demands product Y, that only runs on prem on DB Z. Done.
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.
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.
What are they getting paid for then? They take the TPS reports from the in-house engineers to the Oracle managers? They're people people?
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.
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.
Like COEs, and all sorts of other things that a EnterpriseDB can't compete with due to the money involved. It just isn't the same.
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.
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.
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".
That won't stop idiots from wanting it to happen.
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.
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.
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.
[1] http://stackoverflow.com/q/24898681/447514 [2] http://stackoverflow.com/q/7631048/447514
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.
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.
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.
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.
Additionally, AWS will provide partner ISVs with detailed reports on how customers used their products over a given billing period.
That being said, this transparency might be an issue for Oracle as it limits their usual predatory sales/auditing practices.
Since they are now a "serious" cloud player with whom one has already ties they get invited to tenders that threaten the status quo.
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...)
"The computer industry is the only industry that is more fashion driven than women's fashion."
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...
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.
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.
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".
(Source: Larry Ellison's bio).
The days of being able to treat their customers like dirt with impunity are well and truly over.
If you are running a Fortune 1000 IT group, you'd be a fool not to use Oracle; if you are running a startup, you'd be a fool to use Oracle.
It's a pain to create something using Oracle. But it's just there :-(
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.
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.
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.
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.
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.
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?
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.
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.
"it comes as “bare metal,” a attention tenure for servers with no program installed"
I guess it makes sense if the query is "Show me all the Orders in the system".