Amazon’s Consumer Business Turned Off Final Oracle Database
aws.amazon.com
aws.amazon.com
Amazon is considered a paragon of IT, so their expulsion of Oracle is a useful tool at the CIO/CTO level of "nobody ever got fired for IBM" level of reasoning.
Unfortunately, AWS is becoming the new IBM in that reasoning. Great that it took ten years to reach that level of agreement, now hybrid cloud needs to take over the grey haired CIO / CTO level.
Long live Postgresql!
They are not nice to their partners either.
Amazon and Oracle couldn't be more different in this point of view.
Amazon's predatory instincts are pointed inwards and downwards, towards employees and vendors, while being mostly great towards the customer.
Everything from their warehouse workers with timers, the crying software engineers and all other things I hear about them are about running an internally facing extraction economy.
The squeeze is being put on those who draw a paycheck (or at least, a profit) from Amazon, while the consumers see instant access servers on EC2, Amazon Go for lunch breaks in a city or One hour shipping of diapers.
In comparison, Oracle seems to be going after those who pay them already.
Just like to point out that that NYT hit piece didn't actually interview any software engineers IIRC.
Any place that can lay off a significant majority of a team has issues.
Some of the best people I know that have gone to work there have been subjected to this.
After cycles of this, the only way to survive is to backstab and move up in management.
Amazon/AWS really shows this in it's core web sites and console, which are really backwards and show no signs of improvement or evolution, because all the people that built it have been fired by now or moved on.
Microsoft originally thrived on this, but eventually the culture collapses into backstabbing and the worst breed of middle management Machiavellis, and any productivity is new bolt-on products.
So IMO Bezos built a fundamentally good infrastructure ten years ago that is fuelling Amazon's continued growth, but if anyone fundamentally improves in some way that Amazon would need to fundamentally change the company it will be impossible.
And won't invest in basic stuff like that?
Their CLI is irritating too.
I am not making an argument against what you are saying. I am saying that a common interface between the two would be the sane and rational decision. It should be trivial to use the console and turn that back into your new behavior for committing back to your repository.
And it's pretty bad at this.
I'm not saying the interfaces are the worst ever invented, just that they are a step above internal enterprise software, and despite the fact that AWS makes almost 8 BILLION DOLLARS there appears to be less that 1/1000th of that revenue invested in improving it.
Of course we could re-write on a different cloud, just like Amazon can move off Oracle, but it would take time and we would put up with a lot of abuse before it happened, just like Amazon no doubt did with Oracle.
Which is what you were just bragging about: your numbers show that your customers are locked in enough that you can abuse them plenty before they can effectively retaliate.
Congrats.
I still think that your notion of intentional vendor lock in is misinformed at best and poor design and architecting from your side (at worst). I do happen to work at Amazon but my post history will show you how critical I am of the company.
But nothing you’re saying is valid, and I don’t see any parallel here with the migration from Oracle. If you’ve used Oracle DB or have familiarity with its one off special “features”, there’s no parallel between that and using something like RDS or Dynamo. RDS is replaceable. Dynamo is a key value store first and foremost.
There are also enough third party abstractions that let provide you their own configuration and syntax for spinning up resources on AWS, Azure, GCP, etc or mix and match.
DynamoDB is not directly portable, Cassandra is closest, and it's a bear to roll your own. Are you an Amazon employee outright telling people to not use the fundamental datastore of AWS?
S3 also is fairly proprietary, are you, an Amazon employee, outright telling people to not use the fundamental file storage of AWS?
I could go on, obviously.
S3 is blob storage. Dynamo is a key value store with support for additional indexes. Neither technologies are particularly novel today or provide specific features that would lock you in. You could use comparable technologies on Azure or Google Cloud. Like I said before, you can’t blame Amazon or any cloud provider for poor design/architecting on your end.
Your questions are written as sarcastic personal attacks, which you write instead of posting something of more substance. It seems like you’re just trying to incite a response from me aka trolling. I won’t engage with you anymore. Good luck.
It's hard to get fired as a college hire. It happens, but only if you're pretty lazy or a fuckup or a mis-hire to begin with. I've seen vanishingly few cases where someone was managed out at a time that it denied them stock vests, and only once that it was even mentioned (then by an exceptionally petty manager).
To be perfectly clear: working at Amazon sucks for plenty of reasons, some of them covered in this thread. Compensation is not commensurate with the quality of engineer you have to be to work there, the company is disgustingly cheap in general, many teams are drowning in tech debt (the original post's cheerleading aside, half my org is still suffering from the slapdash way the Oracle migration was sped through to meet arbitrary internal deadlines), and the fraction of managers interested in building petty fiefdoms rather than interesting or good tech is increasing at an alarming rate. But anyone who thinks it's a huddled mass of sobbing husks with PTSD is overstating it.
year 1: $X cash + $Y cash bonus (vests daily) + $Z RSUs (vest at end of year), where approximately 95% of the comp is cash.
year 2: $x cash + $Y cash bonus (vests daily) + $Z RSUs (vest at end of year) where approximately 90% of the comp is cash. Likely a few percent more than year 1 in total comp.
years 3 and 4: $x cash + $Y RSUs (vests semi-annually for most) where the RSUs make up a meaningful part of the comp. Likely a few percent more than year 2 in total comp.
Given that comp structure, it is essentially impossible to do what AtlasBarfed has suggested, as people get paid quite quickly.
Would I prefer a genuine article assurance? In general, yes. Would I prefer that over a wide selection of products and range of delivery services? Probably not.
For anything outside of books/music/movies/video games I nowadays mostly use other retailers, and generally those that specialise in that kind of item.
I recently bought some shelves from Amazon that aren't as described and getting a return and refund has turned into a complete shitshow. Totally fed up of Amazon.
I know 10+ software engineers at Amazon, including people in their early 30s making close to half-a-million in yearly income, and people working 10-6 M-F. Most of them are very happy with their careers, and I don't know a single person who describes their work-life the way you just did.
I'm not disputing that horror stories exist and that some people are being given bad reviews and are being managed out. However, there is a severe disconnect between the median Amazon employee's experience, and public perception.
If the consensus for my company is so wrong, the consensus on every company is highly suspect.
Not to get into whether Amazon employees have it good or bad, but using the software engineers to explain the median Amazon employee's experience seems a bit odd. Given that Amazon is widely reported to have well over half a million employees now, and I doubt the software engineers are anywhere near the majority, using them as an example to support the claim that the median employee is not what the public expects doesn't make a lot of sense.
First, we do. There's been plenty of stories and Apple has gotten a lot of flak about Foxconn. Rightly so.
Second, I really have no idea why you're bringing outsourced companies into this. Amazon is actually employing massive amounts of people. According to a recent NYT article[1], "Amazon had 653,300 employees around the world at the end of June, not including temporary workers and contractors." What's the point of trying to inflate the number when Amazon is already one of the largest employers in the world?
Seems people would gripe either way
Nothing I said had anything to do with that... I specifically started my comment with "Not to get into whether Amazon employees have it good or bad" to avoid that conversation, since I don't think I have enough facts to weigh in usefully. My comment was about statistics.
I'll be honest and admit that I'm not sure what working experiences are like for the warehouse/delivery guys. However, neither does the person I'm responding to. Given how completely wrong they are in describing the median tech worker's experience, they have no credibility when it comes to warehouse workers either.
With 500,000+ employees, you can write an entire book of horror stories at Amazon, and you could still be describing only the outliers. You really can't form any judgements without using random-sampling techniques or mass-employee surveys.
What do these people do?
BUT I can also say that it rolled right off my back and had little effect on my friends who are still there after 5+ years
The key is to have enough savings that you don't feel like you're trapped there, IMO. And to have some real world perspective. If you've ever experienced real deal poverty then you'll laugh off anything a toxic management chain can throw at you.
I'd definitely recommend leaving Amazon ASAP in any case though, unless you're some sort of hardcore ladder-climbing business shark. I got super screwed by a lack of bonuses and raises despite being a "top performer", and it sounds like that's the norm rather than the exception.
As with every company, which manager you have and which organization you are in makes ALL THE DIFFERENCE. Are there people here I wouldn't want to report to? You bet. Is my manager one of them? No. I even switched teams to continue reporting to my manager after they moved to a new role.
I feel compelled to say that I am in no way a shill for Amazon and have never been for any company where I've worked (I've worked in tech companies for a few decades now). When my friends complain to me about how awful Amazon is, I cringe hard and do my best to remain balanced in how I view their feedback. Some of the stories I've read and heard about other people's experiences (especially in fulfillment centers) have been super discouraging and made a lot of us angry. Hey, why don't you quit working there in protest? I've worked in a few other major companies, and I can tell you that all of them have done awful shit that made me want to quit in protest--unfortunately, quitting in protest doesn't pay the mortgage.
Amazon naturally attracts people who want to accomplish big things. It just happens that many of these folks are assholes.
Is Amazon predatory to its employees? Some organizations are - yeah absolutely. Are we worse than other companies I worked prior to Amazon? No. Does that mean it’s okay? No. I’m just saying there’s a public perception of Amazon being at the deepest level of hell and it’s not true.
We absolutely burn people out. We overwork employees. We don’t promote them when we should. We try to find the tiniest bit pick reasons not to promote. We practice stupidity and call it frugality? You’re an engineer making $200K total comp a year? Your computer doesn’t work and is crashing? Oh too bad - we won’t replace it for you. Yeah I mean that kind of fucking stupidity.
We encourage everyone to automate their role so we can replace those folks with college hires.
Amazon is not a place you can have a long career at. You’ll have to jump teams or orgs every couple years and eventually you’ll get tired enough that you learn to manage upwards yourself and stick with a manager that you can manage.
You could probably just replace "Amazon" with "Silicon Valley"
Your description sounds like my friends who worked there or just left, they were used for 2-4 years and then nitpicked to deny the deferred compensation stock. It's a rolling scam! But so is the rest of the new economy.
I'd hate to know what it was like before.
Interesting that you said "it's being fixed" traces right around the time the various worker stories went viral. And yet you and several other people say "it's not bad!".
I get there's no stats and its all anecdotal and situational, but the very experience of being hired is terrible. Even though I had friends there, I never bothered interviewing. Why waste two days?
At least google has free food. I'd waste an interview with them.
I'll tell you what was REALLY stressful: Trying to find my first engineering job after graduating from college. It took almost 9 months, and I ended up in a really shitty low-paying internship. The whole time bills I couldn't pay kept piling up, and my best friend in the world (my cat) ended up passing away partly because I couldn't afford to pay for any more surgeries after putting thousands of dollars' worth on my card.
If you can land a job at Amazon, though, congratulations: You've made it. You can get a programming job anywhere in the world and make money in the 95th+ percentile. You've got health benefits, a 401k plan, life insurance, etc. If you ever get so burned out that you're crying at your desk, just quit your job, sell your shit, break your lease, and backpack around the world for a year. (Or go get a laughably easy ~$100k/year job out in the Midwest)
That might appear to be a valid distinction, to an outsider it appears less material. Perhaps you can start by describing how the culture varies within Amazon.
Within Amazon, some places will absolutely grind engineers with nightmare on call rotations, untenable deadlines or deliverable dates, etc. but these things are part of any job depending on your company. What really sets Amazon apart is the brutal honesty - if you’re not performing or meeting someone’s expectation, regardless of how reasonable or unreasonable it is - you will get called out, sometimes in front of colleagues.
Over time, you learn there’s ways of influencing people or motivating them to be at their best. One such way is running a cut throat organization where people end up blaming others to save themselves - sometimes because it is the other person who dropped the ball - other times because that’s how you preserve yourself.
As a business model, this actually works. Running a cut throat organization where people are terrified to go out of line out of fear of losing their jobs - it has worked at Amazon at scale.
But to be clear - not all of Amazon is like this. I’ve been lucky to bounce between really great teams during my 7 years at this company. I’ve had one bad manager who didn’t know how to manage and honestly wasn’t qualified for his role. I’ve met people who legitimately helped me grow and become a better engineer and mentor to others. I’ve gone through two promotions. I’m paid really well.
At least for Germany I know that Amazon is paying above average salaries for them (compared to DHL and others). And generally speaking warehouse workers, and all other rank and file logistics workers, are treated like drones. Again, nothing special about Amazon. But that doesn't mean the situation should be accepted.
All that being said, Amazon is a great place to learn and gain a shit load of experience. On all levels, even if there is a hard ceiling for blue collar workers to get promoted to white collar positions these promotions do happen regularly. The blue collar worker still has to suck up to a manager, so. In other places I know these promotions do never happen. The most important thing to have in mind when working for Amazon is, IMHO, to work on a feasible exit strategy from day one. Because long careers are the exception to the rule there. Oh, and be aware that it is a tough place to work at. Of you are om with that, go for it. Otherwise, stay away.
One last comment, one I learned the hard way. If you are not really comfortable with the way Amazon can treat people, even if you do what you can to make a difference there, you will be part of the problem simply by pushing forward and going a good job delivering high quality results. The one cannot be had without the other. Personally, I am not sure how I see Amazon, pretty peculiar place.
I know you only said "mostly", but I find their product comingling to be very bad for the consumer and products in general on Amazon.com seem to be a lot worse now. If we're specifically talking about AWS, I'm not anti-AWS and do use them, but lets be honest here: they are very expensive, especially for bandwidth, and their pricing models are definitely not consumer friendly. I find it very hard to determine ahead of time how much my bill will be.
« (h) use the Software for competitive analysis or to build competitive products; (i) publicly disseminate information regarding the performance of the Software; or (j) encourage or assist any third party to do any of the foregoing. »
Mwahahaha!
A quick search of "Oracle" from the homepage search (only in the last year, since your account isn't much older than that), shows most articles are non-technical in nature.
https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=tru...
A case could be made that the database itself is predatory, insofar as Oracle encourages use of non-standard functions that make migration to an alternative very difficult.
10 years ago (at Amazon in fact) was the last time I used Oracle and I've never felt any desire to use it again. I wasted far too much of my working life fixing queries that used the silly outer join operator (+) or debugging proprietary functions that already had a perfectly good ANSI alternative.
It's the canonical enterprise vendor on the database side (DB2 has far smaller market share, and SQL Server market play is slightly different), so it's the poster child for anything from no two customers paying the same price for same metrics, to opaqueness and perceived unfairness of the contracts, to seemingly predatory fees, to ambiguous and frequently awful licensing on virtual CPUs, to the various shakedowns and so on.
I'm not saying others in the same market are markedly different; but just like IBM is the HN poster child for a "no longer relevant tech dinosaur", Oracle is the HN poster child for "predatory licensing & fees".
(* Note/disclosure, I have the distinct privilege of being happily employed by one to reasonably happily work on the products of the other :-D )
In reality, your experience as a dev might not be that bad from within the ecosystem.
But take the hate for what it is: learn portable tooling, be aware of the proprietary bindings, and architect to be more database agnostic.
It may save your job if the budget cuts are between ludicrous oracle licensing and auditing costs, or your salary.
Things listed as lock in with AWS usually have easy migration paths. E.g. DynamoDB integrates with Database migration service and Lambda functions are easy enough to expose by shifting code to dedicated servers.
A lot of the lock-in is historical. Before there was Kubernetes, there was ECS. I am sure a lot of people embraced containerization and not managing individual machines early, and are now stuck on Amazon's proprietary platform.
Just because AWS spent years both creating an alternative to Oracle and millions migrating, doesn’t mean that your company is.
No matter how often some bushy tailed developer tells the CTO that they used the “repository pattern and standard sql”, they aren’t going to move away from their six figure+ Oracle installation. The risk of regressions are too high and the benefits are usually not worth it.
You see patterns like this from “architects” who want to avoid “lockin”:
- A DBFactory that creates an instance of an OracleRepository that they access through an IGenericRepository interface just in case later on they decide to use a different database and then they don’t take advantage of any Oracle specific features for fear of “lock in”.
- A StorageManagerFactory that you call to create a S3StorageManager that implements an IStorageManager just in case later they decide to move from S3 they can “migrate easily”
You’ll find people who will spin up a bunch of EC2 instances and host their own logging, queueing, messaging servers to avoid using AWS specific services. Now they are spending more for hosting than just going to a colo and spending just as many man hours babysitting infrastructure.
I’m saying that once you choose your foundational infrastructure pieces, no matter what they are, it usually makes sense to go all in instead of creating layers of abstraction.
We thought we'd be okay.
But when AWS started getting too expensive and we began looking to migrate, we discovered that there was a lot of 'glue' in our stack using bits and pieces of AWS-specific services. A continuous integration was using S3 buckets and Lambda, a few clever devOps guys had found ways to create alarms with SNS and SQS.
So while 90% of it was just a matter of moving to general CentOS containers on another platform and spinning up new Postgres and MySql and Mongo instances, that 10% of AWS specific code still causes issues that had to be remedied.
If I were in charge of a large infrastructure on AWS, the first thing I'd do is absolutely lock down every service that wasn't explicitly whitelisted, and open them as needed. Not wait till half your operation depends on dozens of AWS services that, while make things easy initially, lock you in to their platform.
The ones that should be 100% motivated to develop these tools (the Apache ones are ... meh, and terraform/ansible/config management always gets hard-wired to your cloud) are obviously Google and others that are also-rans.
Google might not be doing it to keep Amazon out of their roadhouse.
There's still meta-tooling for admin and management that are hard to abstract, but come on. K8s is the opportunity to do this, and also serverless to a lesser degree.
replace nvl with coalesce
replace rownum <= 1 with LIMIT 1
replace listagg with string_agg
replace recursive hierarchy (start with/connect by/prior) with recursive
replace minus with except
replace SYSDATE with CURRENT_TIMESTAMP
replace trunc(sysdate) with CURRENT_DATE
replace trunc(datelastupdated) with DATE(datelastupduted) or datelastupdated::date
replace artificial date sentinels/fenceposts like to_date(’01 Jan 1900’) with '-infinity'::date
remove dual table references (not needed in postgres)
replace decode with case statements
replace unique with distinct
replace to_number with ::integer
replace mod with % operator
replace merge into with INSERT ... ON CONFLICT… DO UPDATE/NOTHING
change the default of any table using sys_guid() as a default to gen_random_uuid()
oracle pivot and unpivot do not work in postgres - use unnest
ORDER BY NLSSORT(english, 'NLS_SORT=generic_m') becomes ORDER BY gin(insensitive_query(english) gin_trgm_ops)
Oracle: uses IS NULL to check for empty string; in postgres, empty string and null are different
If a varchar/text column has a unique index a check needs to be made to make sure empty strings are changed to nulls before adding or updating the column.
PostgreSQL requires a sub-SELECT surrounded by parentheses, and an alias must be provided for it. - SELECT * FROM ( ) A
any functions in the order by clause must be moved to the select statement (e.g. order by lower(column_name))
Any sort of numeric/integer/bigint/etc. inside of a IN statement must not be a string (including 'null' - don't bother trying to use null="" it won't work). Concatenating a NULL with a NOT NULL will result in a NULL.
Pay attention to any left joins. If a column from a left join is used in a where or select clause it might be null.
For sequences, instead of .nextval use nextval('')
> any functions in the order by clause must be moved to the select statement (e.g. order by lower(column_name))
I'd pull the hair outta my head
> Oracle: uses IS NULL to check for empty string; in postgres, empty string and null are different
Any programmer who doesn’t distinguish NULL and "" has not passed the 2-year experience. Being generous. How did this make it to production?
- Get upvote snapshots of all top-level comments' authors in this thread. Take repeated measurements at relatively low time resolution. Also compare this to any other comments they may be making (have a model of the type of comment: follow-ups that are deeply nested probably have a lower upvote velocity)
- Find archive.org snapshots of OP as well as the authors of all other upvoted comment threads. Find the delta from then to now. Some authors will have recent data.
- For a better model, construct historical graphs of all authors using these methods and use it to iteratively adjust.
- Make sure you understand the ranking algorithm and that it is reflected in your model.
Nontrivial, but could be a fun exercise.
https://news.ycombinator.com/bestcomments
Archived:
http://web.archive.org/web/20191016003251/https://news.ycomb...
While they keep their Oracle compatibility stuff proprietary, they do employ several of the postgresql core developers.
What does this refer to? AFAIK, you can invoke functions just about anywhere including in the ORDER BY clause:
=> CREATE FUNCTION some_func (int) RETURNS int AS $$ SELECT $1 + 1; $$ LANGUAGE SQL;
CREATE FUNCTION
=> SELECT t.* FROM (SELECT 1 AS a) t ORDER BY some_func(t.a);
a
---
1
(1 row)
=> SELECT 1 AS a ORDER BY some_func(a);
ERROR: column "a" does not exist
LINE 1: SELECT 1 AS a ORDER BY some_func(a);No secret, that with oracle you have few full-blown IDEs where you can literally step by step execute triggers, write unit tests for them etc.
PostgreSQL supports MERGE statements [1], and a cursory glance doesn't seem to show that Oracle deviates that much from the SQL standard. Is there a particular reason you are avoiding the merge statement or is it simply a readability preference for the non-standard "upsert" ON CONFLICT extension?
(I'm curious because I was a big fan of MERGE statements in a past life. Part of being allowed to use them in that codebase was proving that the standard was pretty well followed across DB vendors [not that we used more than one], as well as that MERGE performance was critical to some very large dataset joins with complex update logic.)
[1] https://www.postgresql.org/message-id/attachment/23520/sql-m...
https://www.postgresql.org/docs/12/sql-insert.html#SQL-ON-CO...
For other cases there is work being done by 2nd Quadrant to add MERGE into PostgreSQL, but I’m glad the other functionality was added first to avoid a common and faulty use case of MERGE.
Obviously, you have to watch your execution plans and make sure everything is indexed accordingly, because the guts of almost every Merge are a JOIN and if your database isn't set up for performant joins then of course you will hate Merge's performance.
And again, certainly anecdotal and a relatively long time ago in this industry's terms that I did any of that. But still something I'm fascinated by.
[ETA: Also, yes Merge is overpowered and underperformant for single row upsert, but as soon as you need bulk upsert, chef's kiss.]
A lot of people who think Oracle is amazingly fast, think so because who puts a million dollar DB on thousand dollar hardware? Put any major DB on equivalent hardware and you'll get some pretty damn good performance.
https://www.informationweek.com/open-source-postgresql-trail...
My experience is that Postgres has better performance than Oracle on much smaller machines. If you have very simple data, with very simple joins, and never deviate from the trivial "select columns from table join table using (foreign key)" you may have a different experience, because Oracle is just great on those.
For sorting on the result of a function, consider using a subselect. "SELECT foo FROM (select fun(z) as foo from blaz) tmp order by 1".
I hope they name it SADL Consulting.
rownum is a pseudocolumn numbering entries, sorting the results will give you records in non increment rownum. On such queries rownum <= N will give you the record that was first in the results before sorting.
LIMIT will give you the first record after sorting.
So rownum != LIMIT and if you really want to implement the same logic you would need to use select row_number() over () as rownum in the ported query, put that into a subquery and filter with where rownum <= N in the outer level.
Example:
select * from (select row_number() over () as rownum, * from pg_class order by relname) as x where x.rownum < 5;
select * from pg_class order by relname LIMIT 5;
Will give two very different results.
The first one maps to oracle:
select * from pg_class where rownum < 5 order by relname;
The second one doesn't.
select * from ( select * from pg_class order by relname ) where rownum <= 1
So select * from pg_class order by relname limit 1
works for us.
"stop oracle", and the URL https://aws.amazon.com/products/databases/freedom.
Not that I'm complaining, Oracle deserves all the hate they get for their business practices.
But associating AWS with "breaking free" is extremely ironic. It's just as much of a source for vendor lock in as Oracle.
If you are not extremely careful/dedicated with your system design, you are never moving off of AWS ever again, or only with a huge engineering effort that almost no-one will swallow. AWS also knows this very well: discounts are harder to come by if they can tell you are totally locked in to their infrastructure.
Combine that with the fact that AWS loves to fork OS projects and build products out of them, without contributing back upstream.
AWS is a terrific platform in many ways, but it is certainly not something that will lead to freedom of choice.
I could go on... there are so many factors why it took Amazon a while to get off Oracle. Ellison is a heaping pile of dog shit fraudster. Before you dismiss me as being biased, look at my post history. I’m critical enough of Amazon.
I used to work on a team at Amazon that was _very_ relieved and happy to move away from Oracle and onto the AWS databases. I wasn't directly involved but I understand the migration work was monstrous. I think it's clear from Ellison's comment that Oracle considers that to be a product feature.
RDS probably affords enough flexibility to get your data out, but Dynamo... that's a different story.
Like, Google Cloud SQL has 5 minutes of planned downtime every month by design, in comparison, or something.
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
I miss it. Daily. Took the amount of time I spent on DB maintenance every month from about 5 hours to about 0 hours.
For example, I haven't seen a cassandra sstable export tool, since Cassandra is one of the most natural export/migration targets of a large Dynamo datastore.
I'm not saying its impossible, and AWS isn't responsible for providing all databases as a migration out target, but considering they have a good cassandra importer...
"This company's software is so useful you can't help but use it because it saves you so much time, effort, and money" is NOT lock in.
You can absolutely choose to develop on AWS In a way that avoids lock-in (Containers, managed DB engines, other cloud storage providers have s3-compatible apis). People don't because it's more CONVENIENT not to - nobody is forcing the to.
I started on Heroku, switched to AWS Elastic Beanstalk. Didn't much care for it so I switched to AWS EC2, running Dokku to replicate the Heroku experience. Simple database backup and restore with Postgres I manage myself. Switched to DO with the same setup with zero downtime. I expect Azure will be the same.
You create your own lock-in to save time and/or money. Those are business decisions like any other business decision. But in no way are any cloud providers forcing lock-in.
> The team added an additional 63 petabytes of storage ahead of Prime Day; the resulting fleet handled 2.1 trillion requests per day and transferred 185 petabytes of data per day.
> Prime Day 2019 also relied on a massive, diverse collection of EC2 instances. The internal scaling metric for these instances is known as a server equivalent; Prime Day started off with 372K server equivalents and scaled up to 426K at peak.
Woah.
https://aws.amazon.com/blogs/aws/amazon-prime-day-2019-power...
Having said that, Oracle is probably the COBOL of databases, in that it will still be around (collecting good $$) from its existing customers for a long, long time.
I still hear implementations.
I don't hear implementations of Oracle.
I still love Java, but I won’t be surprised if that language becomes a business risk because of Oracle’s behavior in other spaces.
To be clear the licensing appears to be open enough so that this shouldn’t be a real threat, but IANAL.
Yes, maybe there will be built in automatic fail over in a few years so you don't have to hack it together using a bunch of scripts.
Of course there's overlap in functionality and most companies should probably chose PG over Oracle. But PG is a joke in some areas like the above mentioned.
thanks microsoft !!
Yeahh I guess not. Let me know when I don't have to hack it together with a bunch of scripts and the PG team takes availability seriously.
Even then Oracle tools were horrible for developers and still are. The only reason they had that many databases was Oracle's business is licensing, massive, expensive licenses, and their sales pushed them sold through upper management. Those days are almost over, developers choose the tech, the cloud is here. Without Tom [1], Oracle was basically not even a great developer community, all documentation was bad and the Java interfaces on the tools / management studio were horrendous. Oracle is fast but for most things on the web caching comes into play heavily and other databases are good enough. Oracle is good for large datasets/reporting, cursors are extremely fast when Oracle is tuned, the problem is it is like vehicle that needs tuning and optimization all the time or it drives bad. The cost and upkeep make Oracle mostly overkill and too painful.
Ellison laughed at the cloud like Ballmer laughed at the iPhone. That was a major error. But ultimately Ellison is an engineer that forgot to make sure developers like to use the product. That will ultimately be their fatal flaw as now the developers choose the tools not what is sold in above them.
All other platforms are developer centric and cloud first now. Oracle the all seeing one says the end is nigh for Oracle the database. No new projects will be using it without force. Too bad Oracle also owns MySQL, Java etc. I really wish someone else had bought Sun.
The OpenJDK (not 'OpenJVM', that's not a thing) is literally 100% the same build as Oracle JDK now. There can't be any technical reason.
And there are other concerted efforts to keep control from Oracle in releases and the validity of the JDK.
As long as a sufficiently large majority (and AWS is helping here a lot, admittedly) maintain such regimented discipline, the JDK will be ok.
Oracle mostly wanted it to sue google for billions. That suit is basically dead, and Oracle knows the JVM isn't worth any large scale revenue.
This said, the likes of RedHat, Amazon and Azul are pretty happy to offer those guarantees, and I bet their prices are lower than Big Red O.
Guess which One Rich Asshole company has this practice.
This is just personal abuse.
Purge every oracle product slowly but surely
Yeah. Say no more... If only you would have looked. Anyhow, Oracle does the following:
- Contributes pretty much all of the closed source technologies (or what was originally to become closed source) of the Oracle JDK to OpenJDK, for example giving the community: JDK Flight Recorder; JDK Mission Control; ZGC; …and probably more stuff I can’t think of right now;
- Ensures the Oracle JDK and the OpenJDK builds are virtually indistinguishable;
- Starts providing a free OpenJDK build (which includes all these donated technologies);
- Provides uncountable man hours of maintaining and innovating the Java platform;
- Ensures that the community knows where to find the free bits by linking to them, and slaps on a bright yellow warning sign, so that everyone can see that the licensing has changed;
And how does the community react, you wonder? Yep, that’s right. “Oracle is the Devil”, “This is a bait and switch operation” etc. Ad nauseum.
ONCE AGAIN. You do not need to use OracleJDK. Just use OpenJDK from AdoptOpenJDK.
The long short of it is we aren't a booming industry and we do it for the money so one less vendor we have to send a 7 figure check to will only increase the bonus pool.
Fun fact: Java (Apache) Struts 2 [2] is a vulnerability mess. It was used by Equifax on the breach:
> Struts 2 has a history of critical security bugs, many tied to its use of OGNL technology; some vulnerabilities can lead to arbitrary code execution. In October 2017, it was reported that failure by Equifax to address a Struts 2 vulnerability advised in March 2017 was later exploited in the data breach that was disclosed by Equifax in September 2017. [2]
They probably went with Java EE because it was "secure", little did they know Struts would enter the game. Equifax I am sure treats their developers good by how often their software was updated /s.
The Dynamo part of it, the pure application server part, had a few genuinely decent features. I've never seen a dependency injection framework like Nucleus, despite the fact that it makes an awful lot of sense. And you got /dyn/admin!
The whole publishing thing - derive a versioned dual of your database schema, edit data in it using a reflective CMS, then automatically publish changes to your production database - is kind of amazing. Source control for databases. I haven't seen anything else like that. Apart from just putting databases in source control, i guess. It occasionally got absolutely screwed up, but the idea was cool!
But a lot of it was absolute garbage. Repositories, where database entities are mapped to these crappy dictionary things that you need to either wrap or go mad trying to customise to actually use. Form handlers, whole classes for what would be a single handler method in a modern framework. The wacky build and packaging stuff.
And then whole commerce layer of it. Pipelines where the majority of the steps are about doing cleanup and normalisation that's only necessary because of how weak ATG's data model is, and the real commerce value could have been a single 20-line function, and adding your own stages becomes and exercise in boilerplate-smithing. Catalogue maintenance, which you have to run sometimes, because apparently it's too hard to just keep the database consistent. Scenarios, the businessperson-usable customisation tool that isn't, in practice, usable by businesspeople!
However, publishing has always been a dumpster fire for me, from the very first time I've used it (around 2004-2005 IIRC) to 2015 when I stopped working with ATG. Deploying changes never worked reliably, full deployments could take days, if not weeks, and relying on RMI made for a very fragile system anywhere multiple network interfaces were involved.
Nucleus and /dyn/admin are incredible features, not only for development but for having near total control of your application in production. I can't count how many production incidents I've solved with curl and /dyn/admin alone.
- Contributes pretty much all of the closed source technologies (or what was originally to become closed source) of the Oracle JDK to OpenJDK, for example giving the community: JDK Flight Recorder; JDK Mission Control; ZGC; …and probably more stuff I can’t think of right now;
- Ensures the Oracle JDK and the OpenJDK builds are virtually indistinguishable;
- Starts providing a free OpenJDK build (which includes all these donated technologies);
- Provides uncountable man hours of maintaining and innovating the Java platform;
- Ensures that the community knows where to find the free bits by linking to them, and slaps on a bright yellow warning sign, so that everyone can see that the licensing has changed;
Some bits do not even make sense: >OpenJDK might survive as permanently stuck in version 8
??? Wat?
> Like many other open-source communities, the OpenJDK Community requires Contributors to jointly assign their copyright on contributed code. If you haven't yet signed the Oracle Contributor Agreement (OCA) then please do so, scan it and e-mail the result to oracle-ca_us(at)oracle.com. Please make sure to specify OpenJDK as the project you'd like to contribute to so that we can process and store your OCA. Allow at least two weeks for processing. If your request is urgent contact the appropriate Project Lead.
It seems to me that they actually own OpenJDK. I'm not a lawyer, but I think that they have the power to make all code proprietary if they want.
they cant pull the this licence from already published code, which means that they cant forcefully monetize it anymore. if they tried, someone else would fork it and continue its maintenance.
They do own it. They own the copyright on the source code (all of it - even if Google or Intel wrote it). They own the trademarks. They own the specifications.
At that point, someone else could attempt a hard fork. Same as what AWS did for Elastic search and MongoDB. The existing release code is still under open source license and so would allow for that. But whoever's attempts that fork, unlike Oracle, would not be allowed to change the license terms beyond what the current open source license allows.
And, someone could also choose to not re-use any code, and re-imement from scratch the spec, like what Google did for Android. That said... the open lawsuit against Google is still deciding of the legalities of that one.
1) they have significant investment in the human capital side of Oracle, which is to say, Oracle DBAs on staff who are highly capable at keeping the lights on for their Oracle databases, but have little or no familiarity with alternatives 2) enterprise architects are required to get approval from their DBAs for the design of new systems, who won't approve non-Oracle databases that they can't support, so new systems get built with new Oracle databases 3) the financial cost of the additional databases is organizationally far enough removed from the design phase that Finance has no real power to say no, and anyway such enterprises have other areas of the business that are far more bloated grabbing Finance's attention, where the cost of additional Oracle licenses is a rounding error by comparison 4) Anybody at a high enough level to see why this is a problem has far bigger problems to deal with and so the situation persists.
I doubt that apathetic enterprises are enough to make Oracle database a growth center overall when nobody in their right mind adopts it for new companies, but I doubt that all of their customers are looking for a migration exit.
The large Accounting firms handle 80% of the financial audits of Fortune 500 corporations. They are used to walking up to Oracle DBs and extracting the reports needed for compliance and reporting.
If they have to learn a new ERP or proprietary Accounting system, then the T&M costs can mount.
Last company was very reliant on Oracle, we ran the entire business on a single Oracle instance for a couple of decades.
We had our share of adventures, but over the years never lost a minute's worth of data despite server, hard drive and other issues. We've also had a few scary performance problems, but have always been able to tune the DB to get past them. And once or twice, we've been in a dark place where you are googling for cryptic error codes, and we've always come through. That's a lot of business and millions of dollars earned through having a very reliable database underneath.
For us, the cost equation is whether it's worth learning a new DB. It's not. If you can run your business on a single instance, then on AWS, it's cheaper to stick with what you know than to try and move to a new DB for a few K of saved licence fees.
What's more, using Oracle is a good answer when the PHBs at our customers ask about our stack. No one ever got fired for using Oracle.
So yes, it certainly makes sense to use Oracle for new projects if you are already Oracle experts.
Java is somewhat the same equation as well ;)
Yet.
>We migrated 75 petabytes of internal data stored in nearly 7,500 Oracle databases to multiple AWS database services including Amazon DynamoDB,Aurora, RDS, and Redshift.
>We kept careful track of the costs and the performance, and realized the following results:
>Cost Reduction – We reduced our database costs by over 60% on top of the heavily discounted rate we negotiated based on our scale. Customers regularly report cost savings of 90% by switching from Oracle to AWS.
>Performance Improvements – Latency of our consumer-facing applications was reduced by 40%.
>Administrative Overhead – The switch to managed services reduced database admin overhead by 70%.
What stopped Oracle charging them a billion dollars a CPU for the last few years since they’ve already announced they were moving off?
How the hell is Oracle still able to charge so much? Earlier this year we were looking to spin up a temporary development instance of Oracle DB for a proof-of-concept project, but the license alone was over $50k. People were already pissed about them adding licensing costs to Java, so this kicked off an effort to start migrating to a modern tech stack.
So Amazon saves 60%, when switching to paying "cost" for Amazon services - and they still claim customers paying cost+markup save 90%?
I'm sure there's probably savings - but that math sounds optimistic.
Or more likely they're apple to oranges - porting a service that could run on a single postgres node from oracle to anything will save you maybe 10k USD a year in licensing for which you see a pretty slim return.
An Intel core is 0.5 units.
Running Oracle on single, 4 core CPU (or VM, because you can't partially license cores and you'd be lucky to find a 4 core server CPU) is $40,000 per year in licensing alone (amortised over 5 years)… for a single machine.
Want an active/passive replication set… double that cost.
- Oracle will schedule periodic audits on their customers and legally threaten them for inadvertent licensing oversights
- AWS makes it a mandatory policy that all their sales folks periodically sit with their customers to help optimise and reduce their ongoing AWS Cloud costs
If you are making a case that Oracle == AWS, you don't know what you are talking about. Yes, I have dealt with both these companies up close.
Their KPIs are to reduce costs for customers but also to increase usage of AWS services to make more money. The KPIs seem to contradict each other.
I wonder how much of the reason for that was actually a wish to avoid getting further locked in to Oracle (changing or removing a database that backs a single service is very much easier than changing a database that also acts as an integration point).
Imagine what Oracle is going to try and charge Amazon per month for every remaining DB given how publicly hostile Amazon has been.
The contracts almost certainly have pre-negotiated rate increases. You don’t put the vendor in a position to double your rates after you’ve adopted software.
1) The birth of the service oriented architecture as a standard at Amazon
2) Took place long before AWS was used by Amazon's commercial business, and most software systems were monolithic, requiring mainframe-like dedicated hardware.
3) Was inspired due to the epic spaghetti monster known as FC Software, whose entire non-architecture revolved around a massive Oracle database.
When Amazon hit the limits of scaling the Oracle databases with beefier hardware, they realized what a clusterfuck they had created. There were literally hundreds of applications, doing different things, but all connected to the oracle database. The oracle database functioned as a database, but also as a high throughput queue, as well as a message passing platform. At high loads, different applications were hitting the same rows so frequently that the transaction errors alone could bring down an entire fulfillment center.
And it should also be noted that it was the same FC Systems (the inspiration for the move towards SOA) that took 12 years to finally get rid of Oracle.
Moral of the story: you need competent software architects, and at the very least, a scalability plan. Also, fuck Oracle.
Isn't that how everyone uses Oracle? I've seen exactly the same complains from developers at banks. Although building software around big featureful RDBMSs in general encourages poor architectures and messy software.
One of the main selling points of EnterpriseDB (built on top of and supporting development of Postgres) is a significant degree of Oracle compatibility, including PL/SQL, client interfaces, etc., so if you go that route you might not need much translation.
sarcasm
sarcasm intensifies
moar sarcasm.
Amazon have been using MySQL even before all these forks happened. And not only that, if Oracle decided to pursue a lawsuit, or if MariaDB, Percona, Elasticsearch or EnterpriseDB did, Amazon will have to cough up.
This is not really a thing that Amazon should be bragging about, because it makes no real sense! They still run a lot of software they did not write.
Amazon did not replace Oracle with MySQL. You seems to talk a lot given your knowledge of how Amazon operates internally and how licensing works is... blatantly false.
All of those DB's that could "pursue" a lawsuit are built on open source licenses which Amazon is not violating.
But the most important point here: The idea that you have to write a database to be happy to be off Oracle is insane. Amazon moved to an alternative that doesn't have a deep license designed to financially screw their clients as much as possible. That's a win.
2. Open Source licenses that Amazon is not violating - a 3rdparty lawyer would be able to ascertain better about the extent of legality on Amazon's changes and its contribution back to open source software than you and I do.
3. Ex-Amazon employee here. My comments are purely based on my observation - and purely my opinions. Why can't I talk a lot?
2. If there was a means to sue Amazon for hosting databases, Oracle would have already done it a LONG time ago with MySQL. The burden is on you to prove your claim.
3. You are free to talk as much as you want, just expect push back when you aren't right, a lot. ;)
3. Except when the other person isn't. You just lost me on the last comment.
Pursue a lawsuit over... what, exactly?
Oracle's strategy of buying companies like PeopleSoft is paying off.
Amazon accomplished the task by building their own Oracle replacement. You have to be approximately as large as Amazon for that to be a realistic option.
If you'd like to use the alternatives that Amazon built, you can, of course, migrate to Amazon Web Services. Though, if you dislike the vendor lock-in you're experiencing with Oracle, and are considering Amazon as a good place to flee to, you possibly haven't been paying attention. With Oracle, you're just renting the software. With Amazon, you're renting both the software and the hardware, and renting the hardware is a precondition of being able to continue using the software, AND they charge you a fee to move your data off of their hardware. It's one of the most well-engineered enterprise vendor lock-in traps the industry has ever seen.
I suspect that one of MySQL, Postgres or Microsoft SQL Server can fill in for Oracle if you have access to the source code and can make changes yourself. (If you've bought software that is Oracle-only, then it's not an option -- but it wasn't an option for Amazon, either). I suspect that in a lot of cases, this will pay for itself, but it might take 10 years to do so.
Out of the frying pan, into the fire.
I've worked in both MSSQL shops and PostgreSQL shops, and, while I wasn't in charge of the budget, I wouldn't be at all surprised to find out that, once you factor paying your programmers and DBAs for their time into the equation, the MSSQL shop ended up having lower overall costs associated with its choice of DBMS.
It seems they have changed their pricing strategy:
Oracle: What is your IT budget? We'll take it. (all of it)
Microsoft: Hey, at least we're not as bad as Oracle.If you're a tiny startup, the differences won't amount to all that much, and it will be hard to justify MSSQL's price tag, which is fine, because, yeah, you can't afford it, anyway. If you're an enterprise or otherwise have large database needs, the differences can very quickly become apparent, and easily worth the money.
By far, PostgreSQL has more knowledge sharing and documented edge cases. Not to mention that the official PostgreSQL documentation is probably one of the best documented software systems ever. This makes PostgreSQL a lot easier to learn and use and that also affects the amount of money you need to spend.
SQL Server has some annoying edge cases, licensing is a real pain point these days, but so are the technical issues like lack of schema support in the JDBC driver. Other things are that you cannot pipe the backup. I would love to take backup of an Azure SQL service to my local machine with SSH.
The only thing SQLServer has over PostgreSQL is multiply resultsets. That’s it. I really wish that existed in PostgreSQL to prevent round trips.
Yes, they charge you a fee to move your data off. However, that is not the limiting factor for people moving off of Oracle. (And if it is, they're probably not looking at AWS in the first place.)
Also, as far as I know, all cloud providers charge for data transfer out.
It doesn't take a ton of magic to allow a developer to spin up a pg cluster with a few clicks via some custom web tool. Reporting and operations are trickier to handle, but if you don't need to satisfy the same customer base as Amazon does (i.e. you are your only customer), you could probably pull this off at nearly any scale.
That said, I will certainly grant you the cloud vendor lock-in angle. It truly is one of the biggest ploys of this decade. My organization takes great pride in only using the most fundamental of cloud resources (compute instances, block storage, DNS, VPN, routing). If we had to evacuate AWS to on-prem or some other provider, it would not be a huge ordeal. For those who wound up with their entire business stuck firmly inside vendor-specific things like Lambdas, you have my deepest sympathies.
1. https://media.amazonwebservices.com/blog/2019/bye_bye_oracle...
What Amazon shown here is the transition at scale is possible.
Seriously, Oracle goes after their customers like criminals. I refuse their calls at work, they really are just looking for something to make you pay.
That's going to end soon - the partner ecosystem has been royally shafted by Oracle's big "cloud push", people are moving away from a vendor who simply sold them down the river; and in their Brave New Cloud World, there is no need for license resellers and auditors.
Ironically, that might end up improving Oracle's reputation - they'll just be seen like Google, where everything is automated and support goes from mediocre to nonexistent.
How would they turn that inside out? What would GCP actually run on if they ran GCP on GCP? Or do you mean run search/gmail/youtube on GCP? Isn't their internal infra basically kubernetes in all but name?
One of the more interesting things I've observed over the past few years is the incremental effort to get AWS teams "lower in the stack" onto native AWS offerings. This makes sense: the less parallel or underlying infrastructure you have to maintain to scale and support the public cloud, the more time and attention you can devote to public services. Many (most?) new AWS services are fully native AWS (including the one I work on :)), and design and operational readiness reviews require justification for not using native AWS rather than the opposite.
Because one-off internal IT never goes down? This isn't a good argument, especially since AWS wants to handle their other customers' availability.
Anyone know of a comprehensive resource that we could use to figure out which DB to use?
After that I'd do some PoCs or talk to a consultant.
If only a single user/device needs to access the data: use SQLite. In all other cases: use PostgreSQL.
To be fair, that would be the 5% :).
But really, you should understand what kind of data store you need based on your use case is first and then decide on an implementation later...
Take that, Larry Ellison.
https://www.youtube.com/watch?v=xrzMYL901AQ&feature=youtu.be...
Would have loved to have read some technical details on how 40 Tbyte was transferred in an hour, even migrated.
Perhaps I'm missing something but that doesn't seem hard considering:
1) It's only like 3x high end consumer level 16TB HDDs
2) This is Amazon...they have AWS - really fat pipes and endless horsepower on demand
The maximum sustained transfer rate of a 16TB Seagate Exos X16 is 261MB/s. That would take 17 hours to transfer at full speed.
Not that the data storage would look like that, but even at 100Gbps networking operating at 80% (about what you'd achieve realistically) it would take 70 minutes to transfer 40TB at full wire speeds.
But we're not talking about full-wire speeds. We're talking about exporting from an Oracle DB and importing to an entirely different DB. The file transfer task isn't the hard bit, it's the actual data migration along the way. That's a massive undertaking and I'm surprised any of the migration tasks were able to complete with such a small amount of downtime.
With all the database engines available, is there really not another one that can match Oracle without massive customizations?
It's not really "switching relational DBs", it's "rebuilding all of the legacy systems to not use relational DBs". Their scale had long since left the realm where it was reasonable to run everything on massive monolithic DBs, but the technical debt hadn't been paid down -- so they just kept putting more money into bigger and bigger hardware and larger DBA teams to support them. For instance when I last worked the there each warehouse ran on a single massive Oracle DB. That isn't solved by swapping to another database; it was well beyond reasonable.
I suspect that this article seems like a bit of self-promotion but it's actually intended as a giant middle-finger to Oracle.
When they were all cheering, I actually felt bad for Oracle for a nanosecond.
But that is not what happens.
First problem is - majority of mature enterprise systems (which tend to use Oracle), are not designed in such a schoolbook way, so that's you first problem. Codebases are ugly and teams loose the knowledge to maintain some parts that are mature and work mostly ok - often the DB layer.
Another concern is regressions in the product that is hard to properly test for. Minor details that are exposed by even small changes in DB behaviour or performance, that won't get caught in testing, but will cause an impact when your next scheduled job happens to fall on the first friday of that one month where the customer has that very special report that is just slightly so different and runs only once every 7 years.
Another major pain point are operational concerns. When dealing with DB technologies, managing, deploying, operating your back end DB servers can be quite a different beast. In theory your teams should be able to handle it, as they are experienced engineers that know how to learn new tech quickly. In practice, you don't have money for those, and your team is lazy and doesn't really want to learn that new cool tech, just let them do their job.
And finally, if it all "just works" at the moment, it is a hard sell to switch such a fundamental part of the system and properly validate the investment versus the risks.
And this is all if you're not a super user of Oracle specific pieces, surrounding tooling or consultants/expertise.
In practise, you want to cheap out on paying for training, have your team do their job and learn an entirely new system to expert level at the same time, the "cool new tech" isn't and your team knows that you're trying to sell it as "cool" to pull a fast one on them because you think they're idiot children, and you won't even commit to using it for long enough to make it worth the bother of trying to learn before changing your mind or prioritising something else, and you're humming and hawing about investing in the tools to make the new tech work well because it's free software so why should it cost you any money?
Besides, you won't prioritise maintenance or design, so the codebase is a mess and people are incentivised towards panic-of-the-day fixes and don't-ever-ever-break-anything conservatism - their fault not yours, obviously, it can't be your fault, you don't even work with the tech (you just choose it by fiat).
Whatever talent available in the company that wants to migrate off Oracle, would not want to take the risks of migration failure.
But you'll probably have Forms, Reports, and Apex too. These are all designed to make building an app a piece of cake but make it impossible to migrate except if you rewrite the whole thing.
Edit: I did see "some third-party applications are tightly bound to Oracle and were not migrated". Curious if that's all that is left, globally, at AMZN.
I can easily imagine how "normal" companies will not have such an easy time doing so. I guess we're going to have Oracle around for a long time.
https://www.cnbc.com/2018/08/01/amazon-plans-to-move-off-ora...
About Oracle Database (not Oracle company), I am very much in agreement that (PL)SQL can be used as one language to take care of Relational Algebra, Row oriented, Column oriented, Document oriented and also Blockchain oriented disk persistent tables with local node partitioning and distributed sharding, Graph traversals queries using recursive CTEs, auto tuning of indexes, streaming materialized views, distributed topic/queues.
Oh by the way with little effort you can accomplish almost all what Oracle does with PostgreSQL and its community extensions.
I wasn't aware they are doing this PR pieces on a department by department basis.
Are there any more remaining Amazon departments still doing this process?
Many customers on AWS have contracts that guarantee discounted rates given sufficient volume. People have commented on hn about negotiating them, and you can see some examples from recent IPO filings. Amazon (the non-AWS parts) are yet another customer of AWS, and wherever possible you should expect them to operate like one. They even buy RIs!
1) How much money do you have 2) How much would it cost you to switch to something else
Your annual license cost is the smaller of the two inputs, minus a 10% discount.
Wondering what you think of the following quote:
> Baseball is ninety percent mental and the other half is physical.
I also love that they didn't just replace Oracle with <insert competing RDBMS here> but instead thoughtfully pieced together a strategy based on what the data was going to be used for.
Well done!
It is extremely expensive, for data storage and performance. Queries are limited and cumbersome to write.
If you are looking at it, put a reasonable amount of test data in and play with it too see what costs look like compared to the performance you need from it.
But yes, absolutely prototype and measure costs with real workloads
Does this mean they have a custom set of books running atop DynamoDB or is this specific to aggregate reporting and financial data warehousing?
Something along the lines of JavaEE, deployed on something derived from WebLogic, bound together with reliable messaging bus (Tuxedo), backed by Oracle database.
https://www.youtube.com/watch?v=9yBP5gnnZi4&feature=youtu.be
Now Amazon should do this to every company using them.
This was an expensive exercise in spite, took a long time and a lot of people - and everyone knows it.
They could have done this far efficiently already if they wanted to scale out, but that company has too many conflicting internal priorities that they took a heck of a long time to move away to anything that scales.
They never try to invent things and if not Oracle, they'd use some other vendor built software. That is the true reality of this company.
So no, if you're thinking you're better than this company for moving away from vendor built software, you are mistaken. In the worst possible way.
True, but similarly few people would be able to swing the kind of discount they got at Oracle. I'd be really interested in seeing what those discounts worked out to overall.
Why people can't admit that their opinions can be unpopular sometimes. That's not a bad thing. Not all the things you say need to be popular to have meaning to yourself and others. It sucks to be downvoted but that's part of having a healthy discourse in HN.
I've slammed Google, FB and some other tech companies on certain occasions BTW, and I absolutely never felt bad about it. Thanks!
1. https://www.statista.com/statistics/250520/forecast-of-amazo...