There are a few vendors* in the telco industry that have their claws deep into the telcos, and one of them is Oracle. Telcos are dying to get off Oracle databases, and because Oracle doesn’t have a strong roadmap for its future, Oracle knows it. So what’s the plan? Raise prices. The database behemoth ran this play outside of telco in the past, and Amazon saw the ambush coming. So what did it do? Switched off 100% of its Oracle databases. Here’s the story on how Amazon did it so you can do it too.
Amazon’s consumer business shut down its last Oracle database three years ago, in October 2019. The team migrated 75 petabytes of data in nearly 7500 Oracle databases to multiple Amazon Web Services (AWS) database services over the course of several years.
According to the case study AWS published about the project, the move cut database operating costs by 50%, eliminated most database-administration and hardware-management overhead, and lowered latency of most critical services by 40%.
You may think you’re stuck with your legacy databases. That Oracle databases are fait accompli. But if Amazon can migrate to AWS and achieve gains like this, so can you. (In fact, AWS is happy to help you do it! More on that later.)
Why Amazon ditched Oracle
You can read all about the migration in the AWS case study, but I’ll give you the quick and dirty. Back in 1994 when Amazon started operations, on-premise databases were the best thing going for storing and managing enterprise data. And Oracle was at the top of the heap.
As Amazon’s retail business grew to become the powerhouse it is today, it became more entrenched with Oracle each passing year. At the same time, database technology was changing, with Amazon itself driving a lot of the change. When AWS launched in 2006, the company started to realize that it was spending way too much time and money managing all these legacy databases. It was a huge struggle to get them to scale to accommodate additional data that needed to be stored and the exponentially increasing transaction rates, especially for heavy transactions days like Prime Day or Black Friday (requiring 105-million requests per second).
Even though the AWS grass was clearly greener, the size and complexity of Amazon’s consumer business deployment kept it in Oracle, as did concerns about what would become of the army of database administrators (DBAs). Sound familiar? Things reached a breaking point over the price: staying the course with Oracle while continuing to grow would increase Amazon’s cost by 10% a year. When you’re already talking about an annual spend in the tens of millions of dollars, 10% more every year was just too high a price to pay. So the team decided to make a bold move: move off Oracle.
Gas on the fire: trading barbs with Larry Ellison
On top of the cost, a heated rivalry developed between the companies. It started in 2014 when AWS introduced the Aurora relational database service, directly competing with Oracle, and amped up over the years. Oracle CEO Larry Ellison (being Ellison, of course) was quoted as saying AWS’s lead was over, that its database wasn’t ready for prime time, that there was no way “any normal person would move from an Oracle database to an Amazon database.” Talk about famous last words.
AWS bided its time, kept its heads down, and did the work. When the consumer business turned off its Oracle data warehouse, AWS CEO Andy Jassy taunted back with a “keep talkin’ Larry” tweet. AWS CTO Werner Vogels said it was his “best day” at Amazon.
I’m sure the competition and trash-talking motivated the AWS team. I wonder if they had Larry’s face on dart boards around the office? Did they make a thermometer poster that tracked when Larry would have to sell one of his yachts due to the loss of sales to Amazon? We will probably never know. But they definitely had a party to celebrate the accomplishment.
How they did it and why you should, too
You can learn about how AWS made its move by reading this “Migration Complete” blog post from AWS chief evangelist and my Twitter buddy, Jeff Barr. To get into the nitty-gritty technical details, you can watch this hour-long fireside chat with Thomas Park, senior manager of solutions architecture for Consumer Business Data Technologies at Amazon.com.
The truth is that the project took years and involved more than 100 teams in Amazon’s consumer business. Every single row was eliminated from Oracle databases and moved into different AWS database services, including DynamoDB, Amazon Aurora, Amazon Simple Storage Service (S3), Amazon Relational Database Service (RDS), and Amazon Redshift. Each team involved in the migration got to choose which services would best fit its workloads and budget. In other words: they picked the right database for the job.
Remember the DBAs? Instead of cutting them loose, Amazon offered training and turned them into database migration specialists and advisors! So now, AWS has a team of former Oracle DBAs who have *real* migration experience and are ready to shepherd your company through the same process: AWS Database Migration Service. Giddy up.
Do you want to get off of your expensive, slow Oracle databases? You know you do. So, do it! Follow Amazon’s example and follow these simple steps:
- Do a technical deep dive to understand what kind of cloud databases you need for which workloads;
- Set a goal for when to get there, including milestones;
- Start the transition, working from easiest to hardest to do; and
- Publish your results and celebrate the win.
To really get things going, piss off Larry and see what happens! It may give your team nonstop motivation. Love you, Larry. Mwah.
*You know who they are, don’t make me name them!
How to start your move to the public cloud
More and more telco execs are ready to make their move to the public cloud. Now, they’re asking how to get started. Here’s where to begin …
Another great reason to use the public cloud: Variable data-storage pricing
The economics are simple: you’ll save money by storing data in the public cloud.
The double bubble is not double trouble
There are two common approaches telcos use when moving workloads to the public cloud. Which one is best?