Amazon is a slightly annoying company that I rarely root for, but Oracle is a predatory company whose customer relations strategy seems to actively involve litigating them as a default assumption.
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.
> Amazon is a slightly annoying company that I rarely root for, but Oracle is a predatory company
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.
I’m an engineer now at Amazon. I’ve been here 7 years. 5 years ago, our culture was far more toxic. More recently, some orgs are horrible places to work and others are much better. I don’t think we’re much worse than other companies. Our pay for engineers is less than Google and Facebook, as far as I know, but we beat other companies such as MSFT.
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.
Sooooo.... it's not toxic anymore, but you still need to hop teams like crazy or they kick you to the curb?
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.
It was basically as that guy described when I was there through 2015, but it really wasn't that bad. I saved enough money in the bank to quit and live off it for 6 months, and after that it was less like an oppressive life and more like a game I was playing.
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)
While I won't go as far as calling it a scam (as one comment did below), I can to a certain degree confirm what you said. Also, is it bad? Yes. Worse than other places? No, simply more open and direct about it. Personally, I prefer the openess about it. And from a company perspective, it works out pretty well, doesn't it? All that is for the office workers and managers. Warehouse workers are different.
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.
You (and other Amazon) employees keep saying orgs/organizations while talking about Amazon vs. Google vs. FB vs. .... I was confused and after reading for a bit I realized you mean divisions within Amazon.
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.
Amazons internal organizations all have slightly different culture, although there’s a core set of company values (Leadership Principles) that keep us bounded together.
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.
401K match is garbage but salaries are decent. I’d say we’ve gotten far more competitive in pay, and that’s not even counting the crazy stock appreciation over the past several years. In terms of overall benefits, we aren’t competitive - which makes sense considering Amazon isn’t a cash printing machine like FB or Google. We genuinely don’t have the money to spend unless Bezos was to deliberately sell $1 billion each year for Amazon corporate benefits. That itself is a fuzzy proposition - how do you give benefits to these corporate badges while squeezing warehouse workers? If you do something, it should benefit everyone.
> Amazon's predatory instincts are pointed inwards and downwards, towards employees and vendors... 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
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.
It's the same way with my company. In the rare situation I see my employer mentioned on HN, I can't even bother reading the comment. It's all so overwhelmingly negative. Not just on the management, but on the employees as well. HN's perception of the company who signs my paychecks is so wildly different from my own perspective as an employee there that I have a hard time believing anyone on HN who talks about a negative work experience at Company X or Company Y.
If the consensus for my company is so wrong, the consensus on every company is highly suspect.
HN isn’t even bad as far as Internet forums go, but the longer you work in the field, the more and more obvious it becomes that Internet forums are generally full of shit.
> However, there is a severe disconnect between the median Amazon employee's experience, and public perception.
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.
In that case, should we not count how badly Foxconn workers who manufacturer Apple’s phones have it? While technically they aren’t Apple employees, that’s a distinction without a moral difference. Would the same people who are criticizing how Amazon treats “its” employees change, if Amazon contracted out all of its warehouse workers? Somewhere in every tech company’s supply chain there are some blue collar workers that aren’t treated as well as the white collar workers.
> In that case, should we not count how badly Foxconn workers who manufacturer Apple’s phones have it?
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?
> Would you prefer Amazon outsource their warehouse operation staffing or hire them direct and pay them $15 an hour?
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.
Then we can include the same foxconn (or insert odm) employees that build echo devices and Amazon still ends up in the bottom of the barrel relatively speaking.
Yes. Every tech company outsources the dirty work. Facebook even outsources the mentally draining work of monitoring videos for child porn and violence. None of the large tech companies are innocent. We just put more emphasis on struggling factory workers in America than the conditions of people in other countries that “work for” them.
To be precise, I meant to say the median software engineer at Amazon. My parent comment had called out "crying software engineers" and anyone who draws a paycheck from Amazon, and I was responding in that context.
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.
I'm coming up on five years, and I can tell you that the negative shit spewed in this thread is nothing I've experienced at Amazon. Is it possible some people have experienced these things, even in the last 1-5 years? Yes, it is possible. Just telling you that my experience has not been like this at all.
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.
I can confirm that Amazon is a stressful place so far as tech jobs go, and I saw a lot of the abusive bullshit people are talking about in this thread.
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.
I have gotten two counterfeit items from Amazon (that I know of, of course). In both cases, A2Z took care of the problem without fuss on my end. (One with a full refund-don't even send it back; the other with "send it back on us or keep it at half price".)
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.
This is salient: there are some items where I'm confident I could distinguish real from fake, but there are many more where I'm not. And returns/refunds or not, it's a hassle I can live without.
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.
Amazon IT employees are carrot-dangles a rolling set of future stock and other money, but as it stands now almost every new hire won't see that money. Amazon will get what they can out of them, and then mark them underperforming and fire them before it pays out any money.
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.
I'm at Amazon now, my team is fairly shitty - let's say in the bottom third of engineering teams anyone at the company would want to work for - and the average tenure of people on the team is close to 5 years.
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.
Absolutely incorrect. I worked there for 3 years, saw one person fired, and everybody who joined with me ended up vesting their shares. Most got promoted too.
Shortly after I joined my team, everyone above SDE2 left and were replaced by college hires. There was literally no one around who knew anything about the original project.
Could be related to the stock development. My personal theory is that everyone who was hired around 2014 turned out to incredibly expensive, Amazon seemed to be surprised by the stock going about almost tenfold in the next 4 years. That alone made it really hard for that generation of hire to stick around, of the people I know who joined with me at that time I only know of two who were still there (out of a dozen) in early 2018. That ratio is a lot higher for those who joined before or after 2015. Not that I would complain so, including RSUs my last pay turned out to more almost three times what other companies in the same region pay.
This comment doesn't hold up to scrutiny if you know how Amazon comp works. A standard SDE package is something like this:
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.
The console sucks because it's done by the individual back-end service teams who have no idea about UX or front-end coding, and don't coordinate with each other or any cross-service owners of the console.
You might hate the console or CLI tools, but people at Amazon have real data telling them the CX is good enough and their capital would be better spent investing in other features. Source: I work there. :P
What’s your problem domain? You shouldn’t be locked into AWS. No offense, but sounds like bad design or more generally, you or your engineers don’t know what they’re doing.
As a percentage of offerings, how much of the AWS portfolio is portable between clouds? 5%? 1%?
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.
You didn’t answer my question and deflected, only responding with personal attacks. Nice.
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?
You just wrote that I’m abusing customers and then say it’s not an attack.
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.
How so? Op is correct - you shouldn’t be using the console to actively manage your infrastructure. The consoles primary purpose is to let you quickly spin up resources while you explore. If you have a real business use case, all your infrastructure should be defined in configuration and deployed out to AWS. That way, you always know what you need to spin up and it’s exact, specific configuration, all stored in source control.
Because when you do that nothing ever needs tweaked on the fly? Because issues of load and scale aren't often times emergent?
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.
"The consoles primary purpose is to let you quickly spin up resources while you explore."
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.
100% not true in my experience, but can't speak for any org other than the one I work in (which has been by far the best job, team, and management I've ever worked with).
I walked away from taking a job there after I had a "peer lunch" with the team I would be working and found out it was mostly vacant due to firings and departures for "performance reasons".
Any place that can lay off a significant majority of a team has issues.
The NYT hit piece came out when I worked at AMZN. I was honestly shocked and surprised at how the company was described because it didn’t match my experience nor those of anyone I knew there. It was the first time I’ve personally experienced Gell-Mann amnesia, except I didn’t forget.
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.
Back in the early days of Oxygen Media I remember the then CTO saying that Oracle's pricing model appeared to him to be based on turning the customer upside down to empty all of the money from their pockets.
« (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. »
Also, kudos to them for not just cutting loose the DBAs who have a lot of institutional knowledge and training them to be consultants on AWS data storage services both internally and externally.
Isn't AWS much less prone to customer lock-in? May be I don't have experience with tweaking AWS under heavy high load, but 98% of code I write for backend that I host on Amazon isn't specific to AWS or it's services in any way.
Not exactly. If you stick to EC2 or containers with general Linux for your servers, and RDS Postgres and Mysql for DBs, and similarly for other services, you supposedly would be able to move to another cloud without issue.
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.
THere needs to be a broad abstraction toolset to enable hybrid cloud.
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.
That doesn’t make sense a lot of what AWS provides is services such as cloud front at scale. You’d still need to test at scale so infrastructure and experience at scale is part of what makes AWS successful and profitable
And when you do “architect an agnostic solution” you now have the worse of both worlds. You’re spending more on hardware than bare metal and you’re spending just as much on management and development time”.
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.
Can you please explain how exactly am I having worse of both worlds here? Not trying to prove you wrong, genuinely curious: if I have a generic NodeJS app with PotgreSQL hosted in RDS and, say, use AWS-specific services like S3 and Cloudwatch, am I doing something wrong?
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.
I’m more responding to the sentiment of “avoiding lock in”, at a certain scale, you’re always “locked into” to your architectural choices where it doesn’t make sense to spend the time or effort to try to avoid it.
This is a strange comparison. Cloud provider IaC offerings like Cloud Formation are obviously going to be specific to their service. AWS also has EKS for Kubernetes.
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.
I don't think it's a strange comparison. Cloud providers offer a combination of services that do lock you in and don't lock you in. If you are using EC2 and SSH in to screw around with Linux, you are going to be fine if you get a better deal from GCP. If all of your deployments are managed by a CloudFormation stack and custom scripts that speak the AWS API, you are never going to be able to move. (This is not unique to AWS, of course! Everyone has their value-adds.)
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.
I don’t think most people would view the companies that way. Amazon is taking on mom & pops, warehouse employees, etc. Oracle might be super aggressive, but their targets are generally larger businesses and often huge corporations that are perfectly capable of taking care of themselves.
Unless your company is going to spend years and millions of dollars to create their own OLAP database product for their own internal use knowing that they can then charge customer $4.80 an hour for a usable system, Amazon isn’t a useful model for any other IT organization.
How is Oracle predatory? PostgreSQL is great for web developers and small businesses but in terms of support, security, and enterprise features I think Oracle has PostgreSQL beat. I have been an Oracle database developer for the last five years, they have a great database, not sure what all the hate on HN is about.
I believe the "HN hate" is more on the accounting/contract side, rather than strict technology side.
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 )
It's not about Oracle the db product, it's about Oracle the company. Why did you think everyone was saying the "Oracle database is predatory", that makes no sense.
That is fair, when I enter an HN post I automatically think of HN as hosting technical discussions, not business, and that is why I decided to look at the technical side.
Looking at the front page now (and virtually any time), there's quite a few articles that are more of a business or a political bend than technical.
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.
> Why did you think everyone was saying the "Oracle database is predatory", that makes no sense.
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.
I'm sorry your comment has been blasted to oblivion. There really is that level of Oracle hate out there. There's no way my top level comment should be 100+ upvotes, it's a pretty vanilla opinion. But man people hate oracle...
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.
We've been working on migrating from Oracle to Postgres for a few years now. We are about 2 weeks from being finished. It is not for the faint of heart, but it is totally worth it. The documentation is much much better, performance is equivalent or better, the sql dialect is saner, etc. Other than moving the data itself (ora2pg was invaluable for this), rewriting the queries is what has taken the most amount of time. Some of our tips on differences between oracle and postgres sql:
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('')
- 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.
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;
> any functions in the order by clause must be moved to the select statement (e.g. order by lower(column_name))
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)
Are you referring to not being able to reference column aliases in an ORDER BY clause? (work around is to use a subquery)
=> 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);
I would note that "foo IN (a, b, c)" can often be better done as "foo = ANY(ARRAY[a, b, c])" in Postgres - not least because you can shift to passing in an array of variable size without having to construct a special statement for each.
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".
Do you mean why does Oracle treat NULL and empty string as the same thing? Internally Oracle changes empty string to NULL values. Oracle won't let you insert an empty string.
> replace merge into with INSERT ... ON CONFLICT… DO UPDATE/NOTHING
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.)
Interesting, I can see where some of my confusion comes from if it was discussed but not completed. It's somewhat disappointing as I do think the ANSI MERGE statement is a good tool.
The MERGE statement is less functional and has a LOT of hidden gotchas, I won’t argue that I can be useful but I don’t disagree when them not providing the footgun.
I won't argue that debugging MERGE statements is easy, and that there aren't pitfalls, but it's a very declarative relational model reduce pattern so calling it "less functional" doesn't seem accurate to me, if you mean functional as in functional programming. (If you mean functional as in the raw number of features supported, I also heavily disagree because I know from past experience there are reductions you can do with MERGE that you cannot do easily if at all with other "upsert" patterns.) Again, I might be biased because in that past life I was doing some wild "big data" (of a sort, of a sort) map/reduce type stuff with MERGE (in T-SQL on Microsoft SQL Server, if that matters for painting a picture).
I should have clarified for it’s intended purpose MERGE is a useful statement, but for the use case handled by INSERT .. ON CONFLICT the ANSI MERGE statement falls flat, as it does not have the same concurrency and atomicity guarantees. It’s routinely a pain point when people try to use it to implement upsert’s in MSSQL.
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.
Merge in SQLServer is horrible imo. It’s horrifically slow. And causes more problems than it solves. After learning about upsert in PostgreSQL. Ah I wish we had it in sqlserver. The PostgreSQL code is so much cleaner and more efficient.
We've all got our anecdotes, of course, but I every time I replaced a CTE, cursor, or temp table sproc with an easier to read Merge statement performance skyrocketed. It wasn't even a fair challenge because all the CTEs and cursors were written WITH (NO LOCK) because who needs consistency or transactions, but yet Merge was faster with locks and transactions than CTEs avoiding them (and kowtowing to the local "we use NO LOCK in these parts" culture left them nearly "instantaneous").
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.]
not really true.
postgres supports "insert .. on conflict" which is functionally a subset of sql merge. the feature was introduced years ago and i would not be surprised if eventually sql merge is glommed into pg core.
Very useful - anyone using oracle should try to use ANSI keywords now to avoid work in the future, always use COALESCE instead of NVL, use ANSI date functions, etc.
I have a hard time believing PostgreSQL performance is better than Oracle, can you give an example? How big is your database and how much did migrating cost you?
Yep, it's surprising how much performance you can get when you're not paying Oracle millions for licensing.
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.
Nobody has any data they can show you, because Oracle's EULA prohibits both running their software and sharing that data, you can only do one of those.
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.
have you tried both? the oracle eula prevents disclosing performance stats. pg allows user defined indexes to be added to kernel and integrated with optimizer, creating some pretty sophisticated optimization techniques. we have the text search index easily handling 20mil+ pdfs with the rum index from postgrespro http://github.com/postgrespro/rum.
Have you seen the pricing for Exadata racks? I ran the numbers a few months back and over 5 years, Oracle was 4x as expensive for my workloads. It's also easier to find AWS people than Oracle people.
@irrational, you have my sympathy. But next time you hear of anybody wanting to torture themselves with such an endeavor you might want to save their soul by asking them to look at CompilerWorks.com. Full disclosure, I work at/for CompilerWorks and will be biased since they pay the bills. But as an ultimate compliment for the kind of work we do, one of our customers brought xz0r's comment about us to our attention.
This wasn't too bad. The first one was the worst - figuring out the difference in the syntax. But after that it was fairly simple to convert all the rest to Postgres syntax. It took a few days to convert all of them in our system (about 500).
Oh, well, honestly none. I just write them by hand. I've written hundreds that way. It probably would be faster to investigate tools, but it seems like there is always something with higher priority to work on.
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 work at Amazon. Ellisons assessment is trash meant to fool maybe Wall Street analysts, but as an engineer, his claims are laughable. In reality, database migrations are hard. Removing that factor entirely for a moment, engineers don’t want to work on lift and shift projects. They come to Amazon to build interesting shit. Now imagine database migrations are easy and your engineers love this work - well, now it turns out you’ve basically stopped real innovation in your organizations to do this operational work for cost savings.
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.
Haha, that's a great link. I actually laughed out loud at how ridiculous his comment sounds.
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.
This is a popular opinion but it simply fails to resonate to me.
"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.
Exactly. I currently host my side project on Digital Ocean, but before that I was on AWS and before that I was on Heroku. I'm considering a move to Azure in the future. And switching between these services costs me basically nothing in time and almost zero code.
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.
Better price than RDS, better speed, never worrying about the disk size and needing to plan to scale up, built in data redundancy and restart times of under a minute in the event of a crash (faster than replica failover so you don’t need a replica unless you just really want one).
I miss it. Daily. Took the amount of time I spent on DB maintenance every month from about 5 hours to about 0 hours.
Fully MySQL/PostgreSQL-compatible DBMS with automatic failover across AZs so you get upgrades all the time, fully managed, without ever having downtime. It's really good. Access management can be through IAM.
Like, Google Cloud SQL has 5 minutes of planned downtime every month by design, in comparison, or something.
I've seen the nice migration service for getting data INTO dynamo, but I haven't seen one for getting it out, beyond doing some custom streams.
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...
> Across the 48 hours of Prime Day, these sources made 7.11 trillion calls to the DynamoDB API, peaking at 45.4 million requests per second.
> 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.
The largest scale I've ever needed to work at was 2 EC2 instances (really just 1 for incoming and 1 for background SQS job handling). The numbers in that post are simply staggering to me.
I wonder if anyone here has seen any net new adoption of Oracle DBs in the last few years? It was an absolute juggernaut 10-15 years ago and has rapidly tanked their reputation and spread their business across software, services and cloud with mixed results. Is it actually still growing or just milking their stodgy enterprise customers for more money?
In 2001/2003, I led a small team at an agency that converted Kraftfoods and 50+ brands from 25+ ATG Dynamo web/app CMS servers + 20+ Oracle servers to .NET 1.0 CMS on 3 web servers, 3 app servers and 3 Microsoft SQL Servers.
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.
Oracle's new licensing requirement for Java is a bit threat to that platform. My company for technical reasons can't switch to OpenJVM so we're going to pay Oracle their new licensing money but we're not doing any greenfield Java development and are going to work towards moving our Java applications to another platform. That's an n=1 example but wouldn't be surprised if others end up migrating away, causing longterm harm to Java.
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.
I am aware... I work in old school financial services there is more red tape and politics with these types of things. I am merely stating what our plans are. We don't really use Java for any new development on our team so the easier solution is to just avoid it. There is a big team that will need to switch over but that isn't our problem.
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.
So rewriting everything onto a new platform is cheaper and less risky than doing the work to break dependencies on Oracle JDK? I know nothing about your situation, but it sounds to me like you've made a mistake somewhere.
ATG Dynamo. Brings back some memories. It was actually a really smart platform that was killed by the vastly inferior J2EE. Spring is basically the same premise as Dynamo and is still going strong.
"Memories" is an interesting way of spelling "nightmares".
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!
I kind of agree on the pipelines, it's a serious case of over-engineering for very little benefit and many frustrating sessions of debugging kilometers of stack traces under which the actual error was hiding.
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.
J2EE reminds me of another blast from the past, a contract around the time for Java (Apache) Struts [1], boilerplate hell and not fun.
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.
While I know Oracle thrives off unearned reputation, (and that Ms SQL is a seriously underrated product outside of enterprises)- I refuse to believe that 3 ms-sql servers were equivalent to 20 oracle's. You must have lost something .
I can imagine that there are more than a few Oracle customers whose spend increases year-over-year because:
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.
When they threaten you with lawsuits for using their software, and make their pricing completely opaque so you don’t really know what you owe (Comcast style), why would you knowingly choose that? Postgres is pretty darn good these days.
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.
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.
I think that not very many existing customers of Oracle migrate off, but I have to think that they are no longer the default for new and growing businesses to move into. AWS seems to have become that, with Oracle not even the second-most likely option (that would probably be Google or Microsoft).
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.
We started a new SaaS company last year. We use Java + Oracle from the get go.
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.
I’m interested in seeing how much they try to milk Java in the next 10 years. I can see them getting desperate enough to really bring the hammer down on licensing, killing off openjdk, and making life miserable for everyone in the process.
Why do you think that they don't own OpenJDK? Here's snippet from "OpenJDK: How to contribute" page:
> 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.
Well they definitely can just like Microsoft can with all their open source projects which require CLA and all the other big corps with same open source model but the already published code also stays under the currently assigned license. They can only change newer version's licese which would probably cause a fork and do more damage than help
This ownership of copyright gives them the possibility to release the next version of (not-)OpenJDK under a proprietary license, but does not give them a possibility to kill off the current version of OpenJDK as every single user who has received explicit perpetual irrevocable license to use, change and redistribute the current version - so there's always a possibility for a true open source fork.
you're right, vbezhenar... i believe the spirit of my message remains unchanged: openjdk is almost entirely open source (GPLv2 + Classpath Exception).
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.
There are a couple ways they are trying to do this. They’re actively fighting the court battle vs Google for copyright of the Java api. They’re also adding more features to Java that are only supported in new versions, and they can/will attempt licensing lock in for those features. OpenJDK might survive as permanently stuck in version 8, or it might survive as a fork which will divide the community.
- 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
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.
Apart for their lawsuit against Google, they're ownership of copyright just means they could choose to relicense future code under a different license, even proprietary if they wanted.
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.
Oracle is slashing positions in a lot of their sales divisions. There was a large layoff this spring/summer, and from what I can tell from contacts that were there, anyone who can is jumping ship to AWS or other competitors, and poaching as many of their old customers with them as they can.
Often it's the apps, like eBiz Suite, that drive the net-new adoption of the underlying DB.
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.
One area of growth - Accidental Oracle customers. Oracle makes software acquisitions and bases the new version of the product on Oracle DB. Customers are forced to upgrade and take on an Oracle DB, or get a firm push into the Oracle cloud.
I believe the business model is that it is near impossible to leave the ecosystem (this is also how SAP can still thrive). It takes a lot of money and expertise to make the migration happen. Few companies have scaling problems as pronounced as Amazon and as much of a vested interest in migrating to their own custom solutions.
>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%.
> Customers regularly report cost savings of 90% by switching from Oracle to AWS.
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.
> 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.
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.
Oracle Enterprise (RRP) is $47,500 per unit.
Software updates are $10,500 per unit per year.
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.
That's why we switched years ago. Going from single CPU to multiple ballooned the costs so much that it was economically viable to do the work to port everything to Postgres.
Another thing - They reduced administrative overhead 70% and cost 60%. If I was a parser, I could say that the result is more expensive. However I think they just didn't account salary savings. That is, their admins can do other stuff now.
I'd guess it goes something like, "We have 75 petabytes of data to move over and would like to use your services but are concerned about costs. What kind of prices can you give us?".
- 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.
> 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
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've been in some of these meetings, and strangely the KPIs don't actually contradict themselves. Most of the recommendations we were given were around switching workload from one way of running things to a service which would be a better fit, and because we'd be using it as intended ended up being cheaper than the original implementation.
Amazon's leadership famously pushed hard in the early 2000s for all its systems to share data only via service interfaces ( https://gist.github.com/chitchcock/1281611 ).
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).
If the goal of SOA was to reduce Oracle lock in then it utterly failed. After SOA practically every team had an Oracle db, so now they have to convince tens of thousands of engineers to migrate thousands of databases.
Imagine what Oracle is going to try and charge Amazon per month for every remaining DB given how publicly hostile Amazon has been.
I think you missed the point slightly. If the interfaces between these services are now Oracle agnostic, it makes migrating off Oracle (by mandate, if necessary) more feasible. More pointedly, I struggle to imagine a scenario where using Oracle of e.g. Postgres would be meaningful in any sense outside of the specifics of Oracle's out of the box integrations. If they aren't being used, why would anyone use Oracle at all?
Amazon has enough money to not care. The marketing from this announcement will make them enough money to not care even less.
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.
It should be noted that the email that Steve Yegge made famous was:
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.
I dunno about that. Maybe this could be read as a success story. They built half-assed software quickly, scaled it to ridiculous levels, made billions of $, and finally had to replace it with something better. And now they are just fine.
> 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.
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.
I've seen the same architecture implemented in MSSQL and MySQL. It's pretty easy to paint yourself into a corner where your one database is doing all sorts of stupid things because you never sat down and identified the problem space in the larger context and moved to a wider configuration instead of simply using a table with short-lived rows as a queue. It's the same arguments about nails and hammers.
In my mind the true "hard part" would be in migrating business logic that lives in Oracle stored procedures (PL-SQL). Are there any tools that do a decent job in translating procs to non-Oracle dialects?
Yep, we built SQL Tran to do exactly that. https://www.spectralcore.com/sqltran. Finishing the rewrite right now which allows us to make changes much faster.
In a few months, it's not so far away. If you can share your database code (data is not important), we can make sure that our parsers and translation layer work with all the code constructs you use from day 1.
> Are there any tools that do a decent job in translating procs to non-Oracle dialects?
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.
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.
Most places likely aren't using Oracle at Amazon's scale, either.
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.
Depending on the size of your install, there are companies that are very good at converting over something like Oracle to Postgres for probably much less than you'd expect. With the price of oracle licensing, your break-even could be in a year or two.
MSSQL's really not too bad. Yes, it's a commercial offering, but there's nothing inherently evil about charging money for software, and you do get what you pay for.
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.
Have you worked on MSSQL licensing in the age of Virtualization and per-core licensing? It's gotten VERY complex according to some of my friends that still run it.
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.
I'm currently working on a mssql shop, and on aws it's more than twice the price vs postgres or aurora. I don't see how you can justify the price difference
I'm not sure I follow this logic. Wouldn't both databases require the same amount of care and feeding? Are you suggesting that you need less DBA's per MSSQL database than for a PostgreSQL or Maria database?
Yep. Because the tooling is stronger. The developer ergonomics are better. The performance is better, meaning you'll be able to do more with fewer servers. MSSQL has a boatload of useful features that PostgreSQL lacks. (Clustered indexes and table-valued parameters are the ones I like to fixate on.) And so on. I can only personally speak to the developer story, but my experience has been that the productivity difference is huge. There's a night and day difference in the information you can get out of an EXPLAIN on each of them, for example, and I would get detailed emails warning me if a MSSQL query plan unexpectedly changed in production. With PostgreSQL you're more likely to need to build your own tooling for that sort of stuff, or just wait for a user to complain. On the DBA side, I'm hazier on the details, but I've seen PostgreSQL DBA's sinking hours' or sometimes even days' worth of effort into grinding through tasks tasks that an MSSQL DBA can bang out by spending a couple minutes clicking through a wizard dialog.
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.
I have worked with both databases over a decade. The biggest difference between SQL Server and Postgresql is neither tooling or performance(both are excellent), but the community and culture.
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.
That said, if you restrict yourself to the PostgreSQL subset of Aurora, you will be able to move to any Postgres implementation down the line.
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.)
I would protest the point that you have to be as large as Amazon to produce your own database-as-a-service solution, especially if you are only building it for yourself. Throwing some automated tooling around Postgres and any arbitrary linux VM hypervisor API should get you a lot of the same value.
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.
They don't really charge you a fee. The only thing you are charged is data transfer out cost of whatever amount of data you transfer out. And that price is the same whether you are transferring data out for backup, for use by your internal systems, etc. Or for leaving to another vendor.
Also, as far as I know, all cloud providers charge for data transfer out.
There are plenty of alternatives that don't lock you to Amazon. One of my teams just migrated from oracle to MariaDB and saw big performance gains. We happen to be using AWS for hosting, but it's Maria, we can go anywhere.
It's not really a fee. It's just the price they charge you for data transfer to external systems. This is known as Data Egress charges and all cloud providers I know off has it. The cost of egress will depend on which service you are using. Some services have lower data transfer out costs, some have higher, etc..
can you give an eli5 of postgresql's offering vs oracle db? Why isn't there an open source equivalent right now? What 'extra stuff' did Amazon have to build to make it 'more' than the open source stuff available right now.
I think the approach can be applied to many companies. I have seen some companies turning every single data storing problem into an Oracle problem. Amazon turned many of the problems into ones that are easier to solve. Using 6 different technologies[1]. I am sure not all applies to all departments but it is a better approach to do this at the scale they got. For small companies this really does not matter. If your hot data fits a single node disk cache you obviously won't benefit from using a horizontally scalable database but Oracle's customers are often in the higher end of the scale spectrum. The question is how can Amazon compete with Oracle where the relationship is there for decades between a customer and Oracle. Good example of this is banks. They managed to get some of the financial companies to move some workloads to AWS but to move Oracle workloads to something else is a whole different game.
It is. The effort is not really as other comments put out to build a Oracle competitors. Arguably for most companies, the open source alternatives are enough for them to be happy with.
What Amazon shown here is the transition at scale is possible.
It shows that a big company like Amazon, hiring thousands of SDEs still needed other vendors software than their own, because of all that time they spent in hiring and firing people and obsessing over their customers needs.
Yeah but the client interfaces are all MySQL. Oracle should buy off PostgreSQL too. And then it should start charging only Amazon for using these interfaces.
There was also MaxDB, and a few other that Monty built. There's also Percona, WebscaleSQL and a few other forks.
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.
1. When did I say that Amazon replaced Oracle with MySQL? I just said that MySQL is an Oracle database.
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?
1. I assumed it was implied. Why else bring it up?
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. ;)
1. and 2. Amazon does use a lot of MySQL, and the fact that they still do. Oracle can determine when and how it wants to bill Amazon. You and I can't change any of that.
3. Except when the other person isn't. You just lost me on the last comment.
>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.
No, it means that Amazon reached the point of considering other solutions than Oracle (I bet partially because of cost) at the time when this project started to move their database workloads that at the time were residing on Oracle to something else. Amazon uses many software vendors, they by no mean suffer from the NIH (not invented here) plague.
Oracle goes after customers with 3rd party companies, if you use oracle expect calls for audits and more licenses. You download virtualbox extension at work? Thats a fee per user. Use an Oracle VM in a vmware cluster? They want paid for all cores in your environment now.
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.
> Oracle goes after customers with 3rd party companies
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.
Migrating everything to the same externally-available cloud infrastructure is exactly the thing that Google needs to do, but has been failing at for going on a decade now. Yes, I'm bitter about it.
Is it not the case that it is actually the opposite? That GCP is running on the internally-available cloud infrastructure at Google?
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?
I've heard that Google is bad at dog fooding their own cloud infrastructure and even that Borg is still dominant over Kubernetes in their internal infra but don't have any insider knowledge. If true this is one thing that Amazon is vastly superior than Google at.
Internal teams are using some GCP services, but overall nearly all teams stick with Borg. Many key services like Search are not able to switch to GCP b/c performance degradation.
Yeah there was a post about that on HN that got a lot of attention a week or two ago. I think that letter/essay was written before google cloud platform was really a thing, would be interesting to know how things have changed since ~2006.
It depends where you are in the stack. At a low level they're using the same data centers, but the public stuff like GCP and Kubernetes is a rewrite of earlier internal software and migration of higher-level servers to a different stack is nontrivial.
Amazon Cloud itself is not externally available, and runs on parts of its infrastructure that are non-public. It's like GCP in that regard, except that most of the rest of Amazon's products are then built on top of this cloud, whereas with Google that's not the case; there's a parallel internal-only infrastructure that every Google product you've ever heard of
(Search/Gmail/YouTube/etc) runs on.
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.
At least in azure, the "platform" that azure runs on doesn't have anything like a managed sql database or a distributed queue service. It's strictly a compute platform. I'd imagine GP is suggesting that only the things that absolutely must run on internal-only infra do so and the rest like YouTube or Gmail run purely on top of GCP (which only happens to be on top of internal infra)
The claim is that some of the data was migrated to publicly available systems. I'm guessing that quite a bit of it is stored in amazon specific systems, for two reasons. First, availability. If the amazon product catalog depends on Aurora, then when Aurora has an issue, so does Amazon retail. Second, custom solutions that were developed before modern alternatives existed have an insurmountable inertia in a big company.
No, not at all, but it rarely goes down at the same time. I mean, I could be wrong, but that's my read of the announcement. Another issue with the managed services is that they don't provide total control over configuration, which is a complete show stopper for a large high performance data store.
> The migration gave each internal team the freedom to choose the purpose-built AWS database service that best fit their needs, and also gave them better control over their budget and their cost model.
Anyone know of a comprehensive resource that we could use to figure out which DB to use?
Not sure how much sarcasm is built into your statement but as a long time user & supporter of Postgres I have to disagree. Postgres is fantastic at many things but there are times when it's not the best choice. An example would be high-scale OLAP. I've tried to use PG for those cases but ingesting thousands+ of events per second into PG and then trying to perform rollups on them in an online capacity (near real-time availability) requires a TON of extra legwork to get it going and near continuous maintenance thereafter. Other purpose-built DB's for OLAP such as Druid, Clickhouse, etc are much better suited for this type of use-case. The main advantage these systems have over Postgres is their column-oriented nature vs. row-oriented of PG and other RDMS.
Glib perhaps but no sarcasm intended. I do agree that there are use cases where PG loses out to more specialized tools, but that’s the 5%, and if you are in that zone you probably know you are and are likely to be capable of doing your own more robust evaluation.
on the similar MS stack of SQL Server it breaks down hard when you start trying to max its throughput. You have to start tearing down all the features, turning off indexes, foreign keys, etc. Otherwise what could take hours will take days or even weeks.
That, and Oracle's legendary shitty business tactics, probably pushed AWS to make this a higher priority, and stick it in oracle's face with videos of oracle shutdown parties and blog posts.
My 2011 MBP is still my primary. This is the case for a lot of people because the newer versions just don't compare. On to of that you can't even upgrade the components in them since everything is integrated into the board.
In my opinion the best user friendly mac was the unibody early 2009 15" MacBook Pro.
It was the last Mac with a removable battery.
Plenty of technological improvements have been made since then but I still love that model.
Ditto. My 2011 MBP is a truck that just won't quit. Although I've replaced just about everything in it but the processor, the fact that I was able to do so makes me love the machine.
We currently have two 2018 MBPs on the shelf that were bought as 'upgrades' back then but they're sitting unused because people are sticking with their 2015 MBPs until they won't be maintainable anymore or Apple (or someone else) releases a version that's an improvement over 2015 MBP instead of a downgrade.
I'm also on a 2015 model, but it was manufactured in early 2017 so it's not that old. I and several people I know are holding out on the 2015s for as long as they can because of ports, no touch bar, and a better keyboard compared to the newer models.
"This team moved 40 TB of data with just one hour of downtime, and realized the same or better performance at half the cost, powered by Amazon Aurora."
Would have loved to have read some technical details on how 40 Tbyte was transferred in an hour, even migrated.
Presumably they didn't go for a 'turn it off, do the transfer, turn it on again' strategy. I'd guess they transferred the bulk of the data beforehand then applied incremental updates until the databases matched then turned off the old db.
Have you tried transferring 40TB from 3x spinning disk HDD… let alone an actively running DB infrastructure?
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.
Oh man. I used to work at Amazon at a time when this Oracle deprecation was starting up. It's utterly non-trivial.
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.
In theory SQL is SQL, even more so if your App uses a layer of indirection like an ORM. If you don't use any Oracle specific features, procedures and similar, in theory you could just replace it.
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 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.
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).
It really depends on how your applications were designed. If you "go deep" with Oracle - and if you've hired Oracle DBAs, you probably have - you probably have a lot of your business logic buried in a large body of stored procedures that aren't version controlled and rely on Oracle-specific behavior.
I used to write PL/SQL long time back. In old days, every business logic was written in stored procedures, which the java code calls. Migrating stored procedures is a hard part since whoever wrote it left the company long time ago.
Whatever talent available in the company that wants to migrate off Oracle, would not want to take the risks of migration failure.
When you have an Oracle database, you probably have a lot of PLSQL. That, in itself, is not so serious (PgPLSQL is quite similar).
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.
Will be interesting to see whether Amazon can make their insight into a service. Countless companies would be glad about a migration path from Oracle to AWS's solutions.
Is "Amazon's Consumer Area" deliberately specific? That is, are they still using Oracle somewhere else? (Despite 75 petabytes being significant)
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.
Notice they don't say that AWS has completely migrated off Oracle. There was plenty of Oracle there 5 years ago, including at the core of some of the most popular services. (There was also a significant migration effort underway then as well, mostly to DynamoDB.)
Price is the only main reason I see which drive this migration.
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.
Oracle should have been doing everything to keep them as a customer and push their databases through cloud offerings. They already push their software through resellers, sort of the same thing, just automatic
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!
I think OP was asking if Amazon is calculating their savings based on the public AWS service pricing or their own cost for running on those AWS services (there's obviously a good chunk of margin on what it costs to run AWS and what the listed service prices are for those services).
I can't say either way, but they mention the average person saves even more than they do (90% vs the 60% Amazon saw). This was due to their Oracle license being much cheaper than normal Oracle customers. So if you extrapolate, even if they did get some discount being Amazon, the discount they were getting on Oracle probably makes the savings comparable to if they weren't getting large discounts on each side (regular customers of Amazon/Oracle).
The very fact that they are dogfooding DynamoDB (with core features of their business) makes me want to take it more seriously and use it more.
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.
Have used DynamoDB a couple times, most recently for data processing.
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.
I have the exact opposite experience. These are just anecdotal experiences. Without providing insight into the workload and your approach it is pretty meaningless.
> Financial Ledger – This team moved 120 TB of data, reduced latency by 40%, cut costs by 70%, and cut overhead by the same 70%, all powered by DynamoDB.
Does this mean they have a custom set of books running atop DynamoDB or is this specific to aggregate reporting and financial data warehousing?
Oracle would have the set of tools for providing a interesting opinionated cloud/onprem platform for microservices architecture.
Something along the lines of JavaEE, deployed on something derived from WebLogic, bound together with reliable messaging bus (Tuxedo), backed by Oracle database.
We have a huge database problem at my company (department). There are only 4 databases for 200 developers. I find this extremely cumbersome to develop on. Ideally there would be at least 1 DB per developer plus some shared environments. What do others do?
The business case to stop managing Oracle contracts and licencing is probably pretty good, especially when factoring in the sick days and stress leave of employees dealing with their infuriating people, processes and tools.
Sorry I wasn't saying I thought it was faked or something like that, in case that wasn't clear. I was saying that posting a video celebrating removing a vendor's software from your organisation could be seen as taunting them. Which - given that it's Oracle we are talking about - is pretty funny.
Sorry I wasn't saying it was faked and I'm talking about the act of posting of the video, which I don't think it would be unreasonable to view as being deliberately provocative.
Obviously, enough Amazon bots are giving me bad karma, but my point stands: No, Amazon is not a special snowflake because it did this.
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.
It is hard to understand what you are saying. HN is not really an AWS loving place. Expensive in regard of what? If you end up saving 50% of your year over year cost across all the company than spending millions on this project and running it for 5 years is still worth the investment in the long run at their scale. Amazon is not looking for 1 month investments, their AWS endeavour is 13 years old[1]. They can spend a long time on something if they really up to it.
"Amazon bots"... sure dude. Because all your opinions are popular by default. Otherwise is just "bots" downvoting you.
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.
Okay, all is fair in a really healthy discussion. The reason I write what I write anyway is because I believe in them. Your point is taken and accepted.
I've slammed Google, FB and some other tech companies on certain occasions BTW, and I absolutely never felt bad about it. Thanks!
They did move to vendor built software. They moved to one that they could get better prices for, AWS. Everyone else will not likely get the deal that they received.
> Everyone else will not likely get the deal that they received.
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.
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!