December 24, 2024 • 35 mins
On this Screaming in the Cloud Replay, Corey is joined by Nipun Agarwal, Senior Vice President of MySQL HeatWave Development at Oracle, to discuss the release of MySQL HeatWave and how it will benefit users among the sea of database offerings on AWS. Nipun reveals why Oracle decided to develop HeatWave, how HeatWave is providing meaningful cost savings to users, and how HeatWave has been optimized for the cloud. Nipun explains how they’ve lowered the barriers to entry for new users of HeatWave, and Oracle’s focus on implementing customer feedback when developing new offerings.
Show Highlights
(0:00) Intro
(0:55) The Duckbill Group sponsor read
(1:28) The significance of HeatWave coming to AWS
(2:20) What is MySQL HeatWave?
(5:13) What jumped out to Corey during his conversations with Nipun on Oracle
(8:40) What’s “under the hood” of MySQL HeatWave
(14:12) How Oracle built out its pricing for MySQL HeatWave
(16:41) Why MySQL HeatWave doesn’t show up on AWS bills
(21:27) The Duckbill Group sponsor read
(22:09) Oracle’s historical customer base and the company’s credit system
(24:30) The point behind MySQL HeatWave
(27:51) How MySQL HeatWave runs
(33:53) Where you can find more from Nipun and Oracle
About Nipun Agarwal
Nipun Agarwal is a Senior Vice President, MySQL HeatWave and Advanced Development, Oracle. His interests include distributed data processing, machine learning, cloud technologies and security. Nipun was part of the Oracle Database team where he introduced a number of new features. He has been awarded over 170 patents., Nipun Agarwal is Senior Vice President of MySQL Database & HeatWave Development. He leads a global engineering organization responsible for Oracle’s MySQL innovations that enable organizations to use a single database for both transactional and analytical workloads. His interests include data processing, distributed systems, machine learning, cloud computing and security. Prior to his current position, Nipun was with Oracle Labs and the Oracle Database team, where he introduced a number of new features. He has been awarded over 175 patents.
Links
- Oracle: https://oracle.com
- MySQL HeatWave info: https://www.oracle.com/mysql/
- MySQL Service on AWS and OCI login (Oracle account required): https://cloud.mysql.com
Original Episode
Sponsor
The Duckbill Group: duckbillgroup.com
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Data plane, control plane, console.
They’re all running natively in AWS.
And this provides for a very seamless integration
or seamless experience for the AWS customers.
Welcome to Screaming in the Cloud.
I’m Corey Quinn.
This promoted episode is sponsored by our friends at Oracle, and back for
(00:25):
a borderline historic third round going out and telling stories about these
things, we have Nipun Agarwal, who is, as opposed to his first appearance
on the show, has been promoted to senior vice president of MySQL HeatWave.
Nipun, thank you for coming back.
Most people are not enamored enough with me to subject themselves
(00:46):
to my slings and arrows a second time, let alone a third.
So first, thanks.
And are you okay, over there?
Thank you, Corey.
Yeah, very happy to be back.
This episode is sponsored in part by my day job, the Duckbill Group.
Do you have a horrifying AWS bill?
That can mean a lot of things.
Predicting what it's going to be.
Determining what it should be.
(01:07):
Negotiating your next long term contract with AWS.
Or just figuring out why it increasingly resembles a
phone number, but nobody seems to quite know why that is.
To learn more, visit duckbillgroup.com.
Remember, you can't duck the duck bill, Bill.
And my CEO informs me that is absolutely not our slogan.
(01:28):
[laugh] . So, since the last time we’ve spoken, there have
been some interesting developments that have happened.
It was pre-announced by Larry Ellison on a keynote stage or an earnings call,
I don’t recall the exact format, that HeatWave was going to be coming to AWS.
Now, you’ve conducted a formal announcement, this usual media
(01:49):
press blitz, et cetera, talking about it with an eye toward
general availability later this year, if I’m not mistaken, and
things seem to be—if you’ll forgive the term—heating up a bit.
That is correct.
So, as you know, we have had MySQL HeatWave on OCI for just about two years now.
Very good reception, a lot of people who are using MySQL HeatWave,
(02:12):
are migrating from other clouds, specifically from AWS, and
now we have announced availability of MySQL HeatWave on AWS.
So, for those who have not done the requisite homework of
listening to the entire back catalog of nearly 400 episodes of
this show, what exactly is MySQL HeatWave, just so we make sure
that we set the stage for what we’re going to be talking about?
(02:36):
Because I sort of get the sense that without a baseline working knowledge of
what that is, none of the rest of this is going to make a whole lot of sense.
MySQL HeatWave is a managed MySQL service provided by Oracle.
But it is different from other MySQL-based services in the sense that we
have significantly enhanced the service such that it can very efficiently
(02:57):
process transactions, analytics, and in-database machine learning.
So, what customers get with the service, with MySQL HeatWave,
is a single MySQL database which can process OLTP, transaction
processing, real-time analytics, and machine learning.
And they can do this without having to move the data
out of MySQL into some other specialized database
(03:20):
services who are running analytics or machine learning.
And all existing tools and applications which work with MySQL
work as is because this is something that enhances the server.
In addition to that, it provides very good performance and very
good price performance compared to other similar services out there.
The idea historically that some folks were pushing around the idea
(03:43):
of multi-cloud was that you would have workloads that—oh, they live
in one cloud, but the database was going to be all the way across
the other side of the internet, living in a different provider.
And in practice, what we generally tend to see is that
where the data lives is where the compute winds up living.
By and large, it’s easier to bring the compute resources to the data than
it is to move the data to the compute, just because data egress in most of
(04:08):
the cloud providers—notably exempting yours—is astronomically expensive.
You are, if I recall correctly, less than 10% of AWS’s data
egress charge on just retail pricing alone, which is wild to me.
So first, thank you for keeping that up and not raising prices because
I would have felt rather annoyed if I’d been saying such good things.
(04:29):
And it was, haha, it was a bait and switch.
It was not.
I’m still a big fan.
So, thank you for that, first and foremost.
Certainly.
And what you described is absolutely correct that while we have a lot
of customers migrating from AWS to use MySQL HeatWave and OCI, a class
of customers are unable to, and the number one reason they’re unable to
(04:50):
is that AWS charges these customers all very high egress fees to move
the data out of AWS into OCI for them to benefit from MySQL HeatWave.
And this has definitely been one of the key incentives for us,
the key motivation for us, to offer MySQL HeatWave on AWS so that
customers don’t need to pay this exorbitant data egress fees.
(05:13):
I think it’s fair to disclose that I periodically advise a variety of
different cloud companies from a perspective of voice-of-the-customer
feedback, which essentially distills down to me asking really annoying
slash obnoxious questions that I, as a customer, legitimately want to
know, but people always frown at me when I asked that in vendor pitches.
(05:34):
For some reason, when I’m doing this on an advisory basis, people instead nod
thoughtfully and take notes, so that at least feels better from my perspective.
Oracle Cloud has been one of those, and I’ve been kicking the tires on
the AWS offering that you folks have built out for a bit of time now.
I have to say, it is legitimate.
I was able to run a significant series of tests on this, and what I found
(06:00):
going through that process was interesting on a bunch of different levels.
I’m wondering if it’s okay with you, if we go through a few
of them, just things that jumped out to me as we went through
a series of conversations around, “So, we’re going to run a
service on AWS.” And my initial answer was, “Is this Oracle?
Are you sure?” And here we are today; we
(06:21):
are talking about it and press releases.
Yes, certainly fine with me.
Please go ahead.
So, I think one of the first questions I had when you said, “We’re
going to run a database service on AWS itself,” was, if I’m true
to type, is going to be fairly sarcastic, which is, “Oh, thank God.
Finally, a way to run a MySQL database on AWS.
(06:41):
There’s never been one of those before.” Unless you count
EC2 or Aurora or Redshift depending upon how you squint
at it, or a variety of other increasingly strange things.
It feels like that has been a largely saturated market in many respects.
I generally don’t tend to advise on things that I find patently ridiculous,
(07:02):
and your answer was great, but I don’t want to put words in your mouth.
What was it that you saw that made you say, “Ah, we’re going to put a
different database offering on AWS, and no, it’s not a terrible decision.”
Got it.
Okay, so if you look at it, the value proposition which MySQL HeatWave offers
is that customers of MySQL or customers have MySQL compatible databases,
(07:24):
whether Aurora, or whether it’s RDS MySQL, right, or even, like, you know,
customers of Redshift, they have been migrating to MySQL HeatWave on OCI.
Like, for the reasons I said (07:33):
it’s a single database, customers
don’t need to have multiple databases for managing different kinds
of workloads, it’s much faster, it’s a lot less expensive, right?
So, there are a lot of value propositions.
So, what we found is that if you were to offer MySQL HeatWave on AWS, it will
significantly ease the migration of other customers who might be otherwise
(07:55):
thinking that it will be difficult for them to migrate, perhaps because
of the high egress cost of AWS, or because of the high latency some of the
applications in the AWS incur when the database is running somewhere else.
Or, if they really have an ecosystem of applications already
running on AWS and they just want to replace the database, it’ll
be much easier for them if MySQL HeatWave was offered on AWS.
(08:18):
Those are the reasons why we feel it’s a compelling proposition, that if
existing customers of AWS are willing to migrate the cloud from AWS to OCI
and use MySQL HeatWave, there is clearly a value proposition we are offering.
And if we can now offer the same service in AWS, it will hopefully
increase the number of customers who can benefit from MySQL HeatWave.
(08:40):
One of the next questions I had going in was, “Okay, so what actually is
this under the hood?” Is this you effectively just stuffing some software
into a machine image or an AMI—or however they want to mispronounce
that word over an AWS-land—and then just making it available to your
account and running that, where’s the magic or mystery behind this?
(09:00):
Like, it feels like the next more modern cloud approach
is to stuff the whole thing into a Docker container.
But that’s not what you wound up doing.
Correct.
So, HeatWave has been designed and architected for
scale-out processing, and it’s been optimized for the cloud.
So, when we decided to offer MySQL HeatWave on AWS, we have actually
(09:21):
gone ahead and optimize our server for the AWS architecture.
So, the processor we are running on, right, we have
optimized our software for that instance types in AWS, right?
So, the data plane has been optimized for AWS architecture.
The second thing is we have a brand new control plane layer, right?
So, it’s not the case that we’re just taking
(09:41):
what we had in OCI and running it on AWS.
We have optimized the data plane for AWS, we have a native control plane,
which is running on AWS, which is using the respective services on AWS.
And third, we have a brand new console which we are offering, which is a
very interactive console where customers can run queries from the console.
(10:04):
They can do data management from the console, they’re able to use Autopilot
from the console, and we have performance monitoring from the console, right?
So, data plane, control plane, console.
They’re all running natively in AWS.
And this provides for a very seamless integration
or seamless experience for the AWS customers.
(10:25):
I think it’s also a reality, however much we may want to pretend otherwise,
that if there is an opportunity to run something in a different cloud
provider that is better than where you’re currently running it now, by
and large, customers aren’t going to do it because it needs to not just
be better, but so astronomically better in ways that are foundational
(10:49):
to a company’s business model in order to justify the tremendous expense
of a cloud migration, not just in real, out of pocket, cost in dollars
and cents that are easy to measure, but also in terms of engineering
effort, in terms of opportunity cost—because while you’re doing that
you’re not doing other things instead—and, on some level, people tend
(11:09):
to only do that when there’s an overwhelming strategic reason to do it.
When folks already have existing workloads on AWS, as many of
them do, it stands to reason that they are not going to want
to completely deviate from that strategy just because something
else offers a better database experience any number of axes.
(11:30):
So, meeting customers where they are is one of the, I guess, foundational
shifts that we’ve really seen from the entire IT industry over the last
40 years, rather than you will buy it from us and you will tolerate it.
It’s, now customers have choice, and meeting them where they are and being
much more, I guess, able to impedance-match with them has been critical.
(11:50):
And I’m really optimistic about what the
launch of this service portends for Oracle.
Indeed, but let me give you another data point.
We find a very large number of Aurora customers
migrating to MySQL HeatWave on OCI, right?
And this is the same workload they were running on Aurora, but
now they want to run the same workload on MySQL HeatWave on OCI.
(12:13):
They are willing to undertake this journey of migration
because their applications, they get much faster,
and for a lot less price, but they get much faster.
Then the second aspect is, there’s another class of customers who are for
instance running, on Aurora or other transactions or workloads, but then they
have to keep moving the data, they’ll keep performing the ETL process into some
(12:35):
other service, whether it’s Snowflake, or whether it’s Redshift for analytics.
Now, with this migration, when they move to MySQL HeatWave,
customers don’t need to, like, have multiple databases, and
they get real-time analytics, meaning that if any data changes
inside the server inside the OLTP as a database service, right?
If they were to run a query, that query
(12:56):
is giving them the latest results, right?
It’s not stale.
Whereas with an ETL process, it gets to be stale.
So, given that we already found that there were so many customers
migrating to OCI to use MySQL HeatWave, I think there’s a clear
value proposition of MySQL HeatWave, and there’s a lot of demand.
But like, as I was mentioning earlier, by having MySQL HeatWave be offered
(13:18):
on AWS, it makes the proposition even more compelling because, as you
said, yes, there is some engineering work that customers will need to
do to migrate between clouds, and if they don’t want to, then absolutely
now they have MySQL HeatWave which they can now use in AWS itself.
I think that one of the things I continually find myself
(13:39):
careening into, perhaps unexpectedly, is a failure to really
internalize just how vast this entire industry really is.
Every time I think I’ve seen it all, all I have to do is talk to one
more cloud customer and I learn something completely new and different.
Sometimes it’s an innovative, exciting use of a thing.
(14:00):
Other times, it’s people holding something fearfully
wrong and trying to use it as a hammer instead.
And you know, if it’s dumb and it works, is it really dumb?
There are questions around that.
And this in turn gave rise to one of my next obnoxious questions as
I was looking at what you were building at the time because a lot of
(14:20):
your pricing and discussions and framing of this was targeting very
large enterprise-style customers, and the price points reflected that.
And then I asked the question that Big E enterprise never
quite expects, for whatever reason, it’s like, “That
looks awesome if I have a budget with many commas in it.
What can I get for $4?” And as of this recording, pricing has not been
(14:45):
finalized slash published for the service, but everything that you have
shown me so far absolutely makes developing on this for a proof of concept
or an evening puttering around, completely tenable (14:56):
it is not bound
to a fixed period of licensing; it’s, use it when you want to use it,
turn it off when you’re done; and the hourly pricing is not egregious.
I think that is something that historically, Oracle
Database offerings have not really aligned with.
(15:18):
OCI very much has, particularly with an eye toward its
extraordinarily awesome free tier that’s always free.
But this feels like it’s a weird blending of the OCI model versus historical
Oracle Database pricing models in a way that, honestly I’m pretty excited about.
So, we react to what the customer requirements and needs are.
So, for this class of customers who are using, say, RDS, MySQL,
(15:41):
Aurora, we understand that they are very cost sensitive, right?
So, one of the things which we have done in addition to offering
MySQL HeatWave on AWS is based on the customer feedback and such.
We are now offering a small shape of HeatWave
instance in addition to the regular large shape.
So, if customers want to just, you know, kick the tires,
if developers just want to get started, they can get a
(16:03):
MySQL node with HeatWave for less than ten cents an hour.
So, for less than ten cents an hour, they get the ability to
run transaction processing, analytics, and machine learning.
And if you were to compare the corresponding cost of Aurora for the same,
like, you know, core count, it’s, like, you know, 12-and-a-half cents.
And that’s just Aurora, without Redshift or without SageMaker.
(16:26):
So yes, you’re right that based on the feedback and we have found that it would
be much more attractive to have this low-end shape for the AWS developers.
We are offering this smaller shape.
And yeah, it’s very, very affordable.
It’s about just shy of ten cents an hour.
This brings up another question that I raised pretty early on in the
process because you folks kept talking about shapes, and it turns out that
(16:48):
is the Oracle Cloud term that applies to instance size over an AWS-land.
And as we dug into this a bit further, it does make sense for how
you think about these things and how you build them to customers.
Specifically, if I want to run this, I log into cloud.oracle.com
and sign up for it there, and pay you over on that side
(17:10):
of the world, this does not show up on my AWS bill.
What drove that decision?
Okay, so a couple of things.
One clarification is that the site people log in to is cloud.mysql.com.
So, that’s where they come to (17:24):
cloud.mysql.com.
Oh, my apologies.
I keep forgetting that you folks have multiple cloud offerings and domains.
They’re kind of a thing.
How do they work?
Given I have a bad domain by habit myself, I have no room to judge.
So, they come to cloud.mysql.com.
From there, they can provision an instance.
And we, as, like, you know, Oracle or MySQL, go ahead
(17:45):
and create an instance in AWS, in the Oracle tenancy.
From there, customers can then, you know, access their data on AWS and such.
Now, what we want to provide the customers is a very seamless experience,
that they just come to cloud.mysql.com, and from there, they can do
everything (18:00):
provisioning an instance, running the queries, payment and such.
So, this is one of the reasons that we want customers just to be able to
come to the site, cloud.mysql.com, and take care of the billing and such.
Now, the other thing is that, okay, why
not allow customers to pay from AWS, right?
Now, one of the things over there is that if you were to do that and there’s
(18:22):
a customer, they’ll be like, “Hey, I got to pay something to AWS, something
to Oracle, so we’d prefer, it’d be better to have a one-stop shop.” And since
many of these are already Oracle customers, it’s helpful to do it this way.
Another approach you could have taken—and I want to be very clear here that I
am not suggesting that this would have been a good idea—but an approach that
(18:43):
you could have taken would have been to go down the weird AWS partner rabbit
hole, and we’re going to provide this to customers on the AWS Marketplace.
Because according to AWS, that’s where all of
their customers go to discover new softwares.
Yeah, first, that’s a lie.
They do not.
But aside from that, what was it about that Marketplace model
(19:08):
that drove you to a decision point where okay, at launch,
we are not going to be offering this on the AWS Marketplace?
And to be clear, I’m not suggesting that was the wrong decision.
Right.
The main reason is we want to offer the MySQL HeatWave service at
the least expensive cost to the user, right, or like, the least cost.
If you were to, like, have MySQL HeatWave
(19:29):
in the Marketplace, AWS charges a premium.
This the customers would need to pay.
So, we just didn’t want the customers to have to pay this additional
premium just because they can now source this thing from the Marketplace.
So, it’s really to, like, save costs for the customer.
The value of the Marketplace, from my perspective, has been
effectively not having to deal as much with customer procurement
(19:52):
departments because well, AWS is already on the procurement approved
list, so we’re just going to go ahead and take the hit to wind up
making it accessible from that perspective and calling it good.
The downside to this is that increasingly, as customers are making larger
and longer-term commitments that are tied to certain levels of spend
(20:12):
on AWS, they’re increasingly trying to drag every vendor with whom they
do business into the your AWS bill so they can check those boxes off.
And the problem that I keep seeing with that is vendors who historically
have been doing just fine, have great working relationships with
a customer are reporting that suddenly customers are coming back
(20:34):
with, “Yeah, so for our contract renewal, we want to go through the
AWS Marketplace.” In return, effectively, these companies are then
just getting a haircut off whatever it is they’re able to charge
their customers but receiving no actual value for any of this.
It attenuates the relationship by introducing a third party into the process,
(20:56):
and it doesn’t make anything better from the vendor’s point of view because
they already had something functional and working; now they just have to
pay a commission on it to AWS, who, it seems, is pathologically averse
to any transaction happening where they don’t get a cut, on some level.
But I digress.
I just don’t like that model very much at all.
It feels coercive.
(21:17):
That’s absolutely right.
That’s absolutely right.
And we thought that, yes, there is some value to be going to Marketplace,
but it’s not worth the additional premium customers would need to pay.
Totally agree.
Here at the Duckbill Group, one of the things we do with,
you know, my day job, is we help negotiate AWS contracts.
We just recently crossed five billion dollars of contract value negotiated.
(21:40):
It solves for fun problems such as how do you know that your
contract that you have with AWS is the best deal you can get?
How do you know you're not leaving money on the table?
How do you know that you're not doing what I do on this podcast
and on Twitter constantly and sticking your foot in your mouth?
To learn more, come chat at duckbillgroup.com.
(22:02):
Optionally, I will also do podcast voice when we talk about it.
Again, that's duckbillgroup.com.
It’s also worth pointing out that in Oracle’s historical customer
base, by which I mean the last 40 years that you folks have been in
business, you do have significant customers with very sizable estates.
(22:24):
A lot of your cloud efforts have focused around, I guess,
we’ll call it an Oracle-specific currency (22:28):
Oracle Credits.
Which is similar to the AWS style of currency
just for a different company in different ways.
One of the benefits that you articulated to me relatively early on was that
by going through cloud.mysql.com, customers with those credits—which can be
in sizable amounts based upon various differentiating variables that change
(22:52):
from case to case—and apply that to their use of MySQL HeatWave on AWS.
Right.
So, in fact, just for starters, right, what we give to customers is we offer
some free credits for customers to try a service on OCI of, you know, $300.
And that’s the same thing, the same experience you would
like customers who are trying HeatWave on AWS to get.
(23:13):
Yes, so you’re right, this is the kind of consistency we want
to have, and yet another reason why cloud.mysql.com makes
sense is the entry point for customers to try the service.
There was a time where I would have struggled not to laugh in
your face at the idea that we’re talking about something in the
context of an Oracle database, and well, there’s $300 in credit.
(23:35):
That’s, “What can I get for that?
Hung up on?” No.
A surprising amount, when it comes to these things.
I feel like that opens up an entirely new universe of experimentation.
And, “Let’s see how this thing actually works with his
workload,” and lets people kick the tires on it for
themselves in a way that, “Oh, we have this great database.
Well, can I try it?
(23:55):
Sure, for $8 million, you absolutely can.” “Well, it can stay great and
awesome over there because who wants to take that kind of a bet?” It feels
like it’s a new world and in a bunch of different respects, and I just can’t
make enough noise about how glad I am to see this transformation happening.
Yeah.
Absolutely, right?
So, just think about it.
So, you’re getting MySQL and HeatWave together
(24:17):
for just shy of ten cents an hour, right?
So, what you could get for $300 is 3000 hours for MySQL HeatWave
instance, which is very good for people to try for free.
And then, you know, decide if they want to go ahead with it.
One other, I guess, obnoxious question that I love to ask—it’s not really a
question so much as a statement; that that’s part of the first thing that makes
(24:37):
it really obnoxious—but it always distills down to the following that upsets
product people left and right, which is, “I don’t get it.” And one of the
things that I didn’t fully understand at the outset of how you were structuring
things was the idea of separating out HeatWave from its constituent components.
(24:58):
I believe it was Autopilot if I’m not mistaken, and it was
effectively different SKUs that you could wind up opting to go for.
And okay, if I’m trying to kick the tires on this and contextualize it
as someone for whom the world’s best database is Route 53, then it really
felt like an additional decision point that I wasn’t clear on the value of.
(25:19):
And I’m still not entirely sure on the differentiation point and
the value there, but now you offer it bundled as a default, which
I think is so much better, from the user experience perspective.
Okay, so let me clarify a couple of things.
Please.
Databases are not my forte, so expect me to wind
up getting most of the details hilariously wrong.
Sure.
So, MySQL Autopilot provides machine-learning-based automation
(25:43):
for various aspects of the MySQL service; very popular.
There is no charge for it.
It is built into MySQL HeatWave; there is no additional
charge for it, right, so there never was any SKU for it.
What you’re referring to is, we have had a SKU for the MySQL node
or the MySQL instance, and there’s a separate SKU for HeatWave.
(26:03):
The reason there is a need to have a different SKU for
these two is because you always only have one node of MySQL.
It could be, like, you know, running on one core, or like, you
know, multiple cores, but it’s always, like, you know, one node.
But with HeatWave, it’s a scale-out
architecture, so you can have multiple nodes.
So, the users need to be able to express how many
nodes of HeatWave are they provisioning, right?
(26:25):
So, that’s why there is a need to have two
SKUs, and we continue to have those two SKUs.
What we are doing now differently is that when users
instantiate a MySQL instance, by default, they always
get the HeatWave node associated with it, right?
So, they don’t need to, like, you know, make the decision to—okay
when to add HeatWave; they always get HeatWave along with the
(26:47):
MySQL instance, and that’s what I was saying a combination of
both of these is, you know, like, just about ten cents an hour.
If for whatever reason, they decide that they do not want
HeatWave, they can turn it off, and then the price drops to half.
But what we’re providing is the AWS service
that HeatWave is turned on by default.
Which makes an awful lot of sense.
It’s something that lets people opt out if they decide they don’t need this
(27:11):
as they continue to scale out, but for the newcomer who does not, in many
cases—in my particular case—have a nuanced understanding of where this offering
starts and stops, it’s clearly the right decision of—rather than, “Oh, yeah.
The thing you were trying and it didn’t work super well?
Well, yeah.
If you enable this other thing, it would have been awesome.” “Well, great.
(27:31):
Please enable it for me by default and let me opt out
later in time as my level of understanding deepens.”
That’s right.
And that’s exactly what we are doing.
Now, this was a feedback we got because many, if not most, of our customers
would want to have HeatWave, and we just kind of, you know, mitigating
them from going through one more step, it’s always enabled by default.
As far as I’m aware, you folks are running this effectively as any
(27:56):
other AWS customer might, where you establish a private link connection
to your customers, in some cases, or give them a public or private
endpoint where they can wind up communicating with this service.
It doesn’t require any favoritism or special permissions from AWS themselves
(28:16):
that they wouldn’t give to any other random customer out there, correct?
Yes, that is correct.
So, for now, we are exposing this thing as a public endpoint.
In the future, we have plans to support the
private endpoint as well, but for now, it’s public.
Which means that foundationally what you’re building
out is something that fits into a model that could work
extraordinarily well across a variety of different environments.
(28:39):
How purpose-tuned is the HeatWave installation you have running on
AWS for the AWS environment, versus something that is relatively
agnostic, could be dropped into any random cloud provider, up to and
including the terrifyingly obsolete rack I have in the spare room?
So, as I mentioned, when we decided to offer MySQL HeatWave on AWS, the idea
(29:02):
was that okay, for the AWS customers, we now want to have an offering which
is completely optimized for AWS, provides the best price-performance on AWS.
So, we have determined which instance types underneath will provide the
best price performance, and that’s what we have optimized for, right?
So, I can tell you, like, in terms of many of—for instance,
(29:22):
take the case of the cache size of the underlying processor that
we’re using on AWS is different than what we’re using for OCI.
So, we have gone ahead, made these optimizations in our code, and we
believe that our code is really optimized now for the AWS infrastructure.
I think that makes a fair deal of sense because, again, one of the big
(29:44):
problems AWS has had is the proliferation of EC2 instance types to the
point now where the answer is super easy, too, “Are you using the correct
instance type for your workload?” Because that answer now is, “Of course not.
Who could possibly say that they were with any degree of confidence?” But
when you take the time to look at a very specific workload that’s going
(30:04):
to be scaled out, it’s worth the time investment to figure out exactly
how to optimize things for price and performance, given the constraints.
Let’s be very clear here, I would argue that the better price performance
for HeatWave is almost certainly not going to be on AWS themselves,
if for no other reason than the joy that is their data transfer
(30:25):
pricing, even for internal things moving around from time to time.
Personally, I love getting charged data transfer for taking data from
S3, running it through AWS Glue, putting it into a different S3 bucket,
accessing it with Athena, then hooking that up to Tableau as we go
down and down and down the spiraling rabbit hole that never ends.
(30:45):
It’s not exactly what I would call well-optimized economically.
Their entire system feels almost like it’s a rigged game, on some level.
But given those constraints, yeah, dialing in it and
making it cost-effective is absolutely something that I’ve
watched you folks put significant time and effort into.
So, I’ll make two points, right, to the questions.
First is yes, I just want to, like, be clear about it, that when a user
(31:09):
provisions MySQL HeatWave via cloud.mysql.com and we create an instance in AWS,
we don’t give customers a multitude of things to, like, you know, choose from.
We have determined which instance type is going to provide the
customer the best price performance, and that’s what we provision.
So, the customer doesn’t even need to know or
care, is it going to be, like, you know, AMD?
(31:31):
Is it going to be Intel?
Is it going to be, like, you know, ARM, right?
So, it’s something which we have predetermined and we have optimized for it.
That’s first.
The second point is in terms of the price performance.
So, you’re absolutely right, that for the class of customers
who cannot migrate away from AWS because of the egress costs or
because of the high latency because of AWS, right, sure, MySQL
(31:53):
HeatWave on AWS will provide the best price-performance compared to
other services out in AWS like Redshift, or Aurora, or Snowflake.
But if customers have the flexibility to choose a cloud of their choice, it is
indeed the case that customers are going to find that running MySQL HeatWave
on OCI is going to provide them, by far, the best price performance, right?
(32:17):
So, the price performance of running MySQL HeatWave
on OCI is indeed better than MySQL HeatWave on AWS.
And just because of the fact that when we are running the service in AWS,
we are paying the list price, right, on AWS; that’s how we get the gear.
Whereas with OCI, like, you know, things are a lot less expensive for us.
But even when you’re running on AWS, we are
(32:38):
very, very price competitive with other services.
And you know, as you’ve probably seen from the performance benchmarks
and such, what I’m very intrigued about is that we’re able to run a
standard workload, like some, like, you know, TPC-H and offer seven
times better price-performance while running in AWS compared to Redshift.
So, what this goes to show is that we are
(32:58):
really passing on the savings to the customers.
And clearly, Redshift is not doing a good job of
performance or, like, you know, they’re charging too much.
But the fact that we can offer seven times better price performance
than Redshift in AWS speaks volumes, both about architecture
and how much of savings we are passing to our customers.
What I love about this story is that it makes testing the
(33:21):
waters of what it’s like to run MySQL HeatWave a lot easier
for customers because the barrier to entry is so much lower.
Where everything you just said I agree with it
is more cost-effective to run on Oracle Cloud.
I think there are a number of workloads that are best placed on Oracle Cloud.
But unless you let people kick the tires on those things, where
(33:43):
they happen to be already, it’s difficult to get them to a point
where they’re going to be able to experience that themselves.
This is a massive step on that path.
Yep.
Right.
I really want to thank you for taking time out of your
day to walk us through exactly how this came to be
and what the future is going to look like around this.
If people want to learn more, where should they go?
(34:04):
Oh, they can go to oracle.com/mysql, and there they can
get a lot more information about the capabilities of MySQL
HeatWave, what we are offering in AWS, price-performance.
By the way, all the price performance numbers I was talking
about, all the scripts are available publicly on GitHub.
So, we welcome, we encourage customers to download the scripts from
(34:25):
GitHub, try for themselves, and all of this information is available
from oracle.com/mysql where they can get this detailed information.
And we will, of course, put links to that in the show notes.
Thank you so much for your time.
I appreciate it.
Sure thing, Corey.
Thank you for the opportunity.
Nipun Agarwal, Senior Vice President of MySQL HeatWave.
I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud.
(34:48):
If you’ve enjoyed this podcast, please leave a five-star review
on your podcast platform of choice, whereas if you’ve hated
this podcast, please leave a five-star review on your podcast
platform of choice along with an angry insulting comment.
You will then be overcharged for the data transfer to
submit that insulting comment, and then AWS will take a
percentage of that just because they’re obnoxious and can.
Data plane, control plane, console.
They’re all running natively in AWS.
And this provides for a very seamless integration
or seamless experience for the AWS customers.
Welcome to Screaming in the Cloud.
I’m Corey Quinn.
This promoted episode is sponsored by our friends at Oracle, and back for
(00:25):
a borderline historic third round going out and telling stories about these
things, we have Nipun Agarwal, who is, as opposed to his first appearance
on the show, has been promoted to senior vice president of MySQL HeatWave.
Nipun, thank you for coming back.
Most people are not enamored enough with me to subject themselves
(00:46):
to my slings and arrows a second time, let alone a third.
So first, thanks.
And are you okay, over there?
Thank you, Corey.
Yeah, very happy to be back.
This episode is sponsored in part by my day job, the Duckbill Group.
Do you have a horrifying AWS bill?
That can mean a lot of things.
Predicting what it's going to be.
Determining what it should be.
(01:07):
Negotiating your next long term contract with AWS.
Or just figuring out why it increasingly resembles a
phone number, but nobody seems to quite know why that is.
To learn more, visit duckbillgroup.com.
Remember, you can't duck the duck bill, Bill.
And my CEO informs me that is absolutely not our slogan.
(01:28):
[laugh] . So, since the last time we’ve spoken, there have
been some interesting developments that have happened.
It was pre-announced by Larry Ellison on a keynote stage or an earnings call,
I don’t recall the exact format, that HeatWave was going to be coming to AWS.
Now, you’ve conducted a formal announcement, this usual media
(01:49):
press blitz, et cetera, talking about it with an eye toward
general availability later this year, if I’m not mistaken, and
things seem to be—if you’ll forgive the term—heating up a bit.
That is correct.
So, as you know, we have had MySQL HeatWave on OCI for just about two years now.
Very good reception, a lot of people who are using MySQL HeatWave,
(02:12):
are migrating from other clouds, specifically from AWS, and
now we have announced availability of MySQL HeatWave on AWS.
So, for those who have not done the requisite homework of
listening to the entire back catalog of nearly 400 episodes of
this show, what exactly is MySQL HeatWave, just so we make sure
that we set the stage for what we’re going to be talking about?
(02:36):
Because I sort of get the sense that without a baseline working knowledge of
what that is, none of the rest of this is going to make a whole lot of sense.
MySQL HeatWave is a managed MySQL service provided by Oracle.
But it is different from other MySQL-based services in the sense that we
have significantly enhanced the service such that it can very efficiently
(02:57):
process transactions, analytics, and in-database machine learning.
So, what customers get with the service, with MySQL HeatWave,
is a single MySQL database which can process OLTP, transaction
processing, real-time analytics, and machine learning.
And they can do this without having to move the data
out of MySQL into some other specialized database
(03:20):
services who are running analytics or machine learning.
And all existing tools and applications which work with MySQL
work as is because this is something that enhances the server.
In addition to that, it provides very good performance and very
good price performance compared to other similar services out there.
The idea historically that some folks were pushing around the idea
(03:43):
of multi-cloud was that you would have workloads that—oh, they live
in one cloud, but the database was going to be all the way across
the other side of the internet, living in a different provider.
And in practice, what we generally tend to see is that
where the data lives is where the compute winds up living.
By and large, it’s easier to bring the compute resources to the data than
it is to move the data to the compute, just because data egress in most of
(04:08):
the cloud providers—notably exempting yours—is astronomically expensive.
You are, if I recall correctly, less than 10% of AWS’s data
egress charge on just retail pricing alone, which is wild to me.
So first, thank you for keeping that up and not raising prices because
I would have felt rather annoyed if I’d been saying such good things.
(04:29):
And it was, haha, it was a bait and switch.
It was not.
I’m still a big fan.
So, thank you for that, first and foremost.
Certainly.
And what you described is absolutely correct that while we have a lot
of customers migrating from AWS to use MySQL HeatWave and OCI, a class
of customers are unable to, and the number one reason they’re unable to
(04:50):
is that AWS charges these customers all very high egress fees to move
the data out of AWS into OCI for them to benefit from MySQL HeatWave.
And this has definitely been one of the key incentives for us,
the key motivation for us, to offer MySQL HeatWave on AWS so that
customers don’t need to pay this exorbitant data egress fees.
(05:13):
I think it’s fair to disclose that I periodically advise a variety of
different cloud companies from a perspective of voice-of-the-customer
feedback, which essentially distills down to me asking really annoying
slash obnoxious questions that I, as a customer, legitimately want to
know, but people always frown at me when I asked that in vendor pitches.
(05:34):
For some reason, when I’m doing this on an advisory basis, people instead nod
thoughtfully and take notes, so that at least feels better from my perspective.
Oracle Cloud has been one of those, and I’ve been kicking the tires on
the AWS offering that you folks have built out for a bit of time now.
I have to say, it is legitimate.
I was able to run a significant series of tests on this, and what I found
(06:00):
going through that process was interesting on a bunch of different levels.
I’m wondering if it’s okay with you, if we go through a few
of them, just things that jumped out to me as we went through
a series of conversations around, “So, we’re going to run a
service on AWS.” And my initial answer was, “Is this Oracle?
Are you sure?” And here we are today; we
(06:21):
are talking about it and press releases.
Yes, certainly fine with me.
Please go ahead.
So, I think one of the first questions I had when you said, “We’re
going to run a database service on AWS itself,” was, if I’m true
to type, is going to be fairly sarcastic, which is, “Oh, thank God.
Finally, a way to run a MySQL database on AWS.
(06:41):
There’s never been one of those before.” Unless you count
EC2 or Aurora or Redshift depending upon how you squint
at it, or a variety of other increasingly strange things.
It feels like that has been a largely saturated market in many respects.
I generally don’t tend to advise on things that I find patently ridiculous,
(07:02):
and your answer was great, but I don’t want to put words in your mouth.
What was it that you saw that made you say, “Ah, we’re going to put a
different database offering on AWS, and no, it’s not a terrible decision.”
Got it.
Okay, so if you look at it, the value proposition which MySQL HeatWave offers
is that customers of MySQL or customers have MySQL compatible databases,
(07:24):
whether Aurora, or whether it’s RDS MySQL, right, or even, like, you know,
customers of Redshift, they have been migrating to MySQL HeatWave on OCI.
Like, for the reasons I said (07:33):
it’s a single database, customers
don’t need to have multiple databases for managing different kinds
of workloads, it’s much faster, it’s a lot less expensive, right?
So, there are a lot of value propositions.
So, what we found is that if you were to offer MySQL HeatWave on AWS, it will
significantly ease the migration of other customers who might be otherwise
(07:55):
thinking that it will be difficult for them to migrate, perhaps because
of the high egress cost of AWS, or because of the high latency some of the
applications in the AWS incur when the database is running somewhere else.
Or, if they really have an ecosystem of applications already
running on AWS and they just want to replace the database, it’ll
be much easier for them if MySQL HeatWave was offered on AWS.
(08:18):
Those are the reasons why we feel it’s a compelling proposition, that if
existing customers of AWS are willing to migrate the cloud from AWS to OCI
and use MySQL HeatWave, there is clearly a value proposition we are offering.
And if we can now offer the same service in AWS, it will hopefully
increase the number of customers who can benefit from MySQL HeatWave.
(08:40):
One of the next questions I had going in was, “Okay, so what actually is
this under the hood?” Is this you effectively just stuffing some software
into a machine image or an AMI—or however they want to mispronounce
that word over an AWS-land—and then just making it available to your
account and running that, where’s the magic or mystery behind this?
(09:00):
Like, it feels like the next more modern cloud approach
is to stuff the whole thing into a Docker container.
But that’s not what you wound up doing.
Correct.
So, HeatWave has been designed and architected for
scale-out processing, and it’s been optimized for the cloud.
So, when we decided to offer MySQL HeatWave on AWS, we have actually
(09:21):
gone ahead and optimize our server for the AWS architecture.
So, the processor we are running on, right, we have
optimized our software for that instance types in AWS, right?
So, the data plane has been optimized for AWS architecture.
The second thing is we have a brand new control plane layer, right?
So, it’s not the case that we’re just taking
(09:41):
what we had in OCI and running it on AWS.
We have optimized the data plane for AWS, we have a native control plane,
which is running on AWS, which is using the respective services on AWS.
And third, we have a brand new console which we are offering, which is a
very interactive console where customers can run queries from the console.
(10:04):
They can do data management from the console, they’re able to use Autopilot
from the console, and we have performance monitoring from the console, right?
So, data plane, control plane, console.
They’re all running natively in AWS.
And this provides for a very seamless integration
or seamless experience for the AWS customers.
(10:25):
I think it’s also a reality, however much we may want to pretend otherwise,
that if there is an opportunity to run something in a different cloud
provider that is better than where you’re currently running it now, by
and large, customers aren’t going to do it because it needs to not just
be better, but so astronomically better in ways that are foundational
(10:49):
to a company’s business model in order to justify the tremendous expense
of a cloud migration, not just in real, out of pocket, cost in dollars
and cents that are easy to measure, but also in terms of engineering
effort, in terms of opportunity cost—because while you’re doing that
you’re not doing other things instead—and, on some level, people tend
(11:09):
to only do that when there’s an overwhelming strategic reason to do it.
When folks already have existing workloads on AWS, as many of
them do, it stands to reason that they are not going to want
to completely deviate from that strategy just because something
else offers a better database experience any number of axes.
(11:30):
So, meeting customers where they are is one of the, I guess, foundational
shifts that we’ve really seen from the entire IT industry over the last
40 years, rather than you will buy it from us and you will tolerate it.
It’s, now customers have choice, and meeting them where they are and being
much more, I guess, able to impedance-match with them has been critical.
(11:50):
And I’m really optimistic about what the
launch of this service portends for Oracle.
Indeed, but let me give you another data point.
We find a very large number of Aurora customers
migrating to MySQL HeatWave on OCI, right?
And this is the same workload they were running on Aurora, but
now they want to run the same workload on MySQL HeatWave on OCI.
(12:13):
They are willing to undertake this journey of migration
because their applications, they get much faster,
and for a lot less price, but they get much faster.
Then the second aspect is, there’s another class of customers who are for
instance running, on Aurora or other transactions or workloads, but then they
have to keep moving the data, they’ll keep performing the ETL process into some
(12:35):
other service, whether it’s Snowflake, or whether it’s Redshift for analytics.
Now, with this migration, when they move to MySQL HeatWave,
customers don’t need to, like, have multiple databases, and
they get real-time analytics, meaning that if any data changes
inside the server inside the OLTP as a database service, right?
If they were to run a query, that query
(12:56):
is giving them the latest results, right?
It’s not stale.
Whereas with an ETL process, it gets to be stale.
So, given that we already found that there were so many customers
migrating to OCI to use MySQL HeatWave, I think there’s a clear
value proposition of MySQL HeatWave, and there’s a lot of demand.
But like, as I was mentioning earlier, by having MySQL HeatWave be offered
(13:18):
on AWS, it makes the proposition even more compelling because, as you
said, yes, there is some engineering work that customers will need to
do to migrate between clouds, and if they don’t want to, then absolutely
now they have MySQL HeatWave which they can now use in AWS itself.
I think that one of the things I continually find myself
(13:39):
careening into, perhaps unexpectedly, is a failure to really
internalize just how vast this entire industry really is.
Every time I think I’ve seen it all, all I have to do is talk to one
more cloud customer and I learn something completely new and different.
Sometimes it’s an innovative, exciting use of a thing.
(14:00):
Other times, it’s people holding something fearfully
wrong and trying to use it as a hammer instead.
And you know, if it’s dumb and it works, is it really dumb?
There are questions around that.
And this in turn gave rise to one of my next obnoxious questions as
I was looking at what you were building at the time because a lot of
(14:20):
your pricing and discussions and framing of this was targeting very
large enterprise-style customers, and the price points reflected that.
And then I asked the question that Big E enterprise never
quite expects, for whatever reason, it’s like, “That
looks awesome if I have a budget with many commas in it.
What can I get for $4?” And as of this recording, pricing has not been
(14:45):
finalized slash published for the service, but everything that you have
shown me so far absolutely makes developing on this for a proof of concept
or an evening puttering around, completely tenable (14:56):
it is not bound
to a fixed period of licensing; it’s, use it when you want to use it,
turn it off when you’re done; and the hourly pricing is not egregious.
I think that is something that historically, Oracle
Database offerings have not really aligned with.
(15:18):
OCI very much has, particularly with an eye toward its
extraordinarily awesome free tier that’s always free.
But this feels like it’s a weird blending of the OCI model versus historical
Oracle Database pricing models in a way that, honestly I’m pretty excited about.
So, we react to what the customer requirements and needs are.
So, for this class of customers who are using, say, RDS, MySQL,
(15:41):
Aurora, we understand that they are very cost sensitive, right?
So, one of the things which we have done in addition to offering
MySQL HeatWave on AWS is based on the customer feedback and such.
We are now offering a small shape of HeatWave
instance in addition to the regular large shape.
So, if customers want to just, you know, kick the tires,
if developers just want to get started, they can get a
(16:03):
MySQL node with HeatWave for less than ten cents an hour.
So, for less than ten cents an hour, they get the ability to
run transaction processing, analytics, and machine learning.
And if you were to compare the corresponding cost of Aurora for the same,
like, you know, core count, it’s, like, you know, 12-and-a-half cents.
And that’s just Aurora, without Redshift or without SageMaker.
(16:26):
So yes, you’re right that based on the feedback and we have found that it would
be much more attractive to have this low-end shape for the AWS developers.
We are offering this smaller shape.
And yeah, it’s very, very affordable.
It’s about just shy of ten cents an hour.
This brings up another question that I raised pretty early on in the
process because you folks kept talking about shapes, and it turns out that
(16:48):
is the Oracle Cloud term that applies to instance size over an AWS-land.
And as we dug into this a bit further, it does make sense for how
you think about these things and how you build them to customers.
Specifically, if I want to run this, I log into cloud.oracle.com
and sign up for it there, and pay you over on that side
(17:10):
of the world, this does not show up on my AWS bill.
What drove that decision?
Okay, so a couple of things.
One clarification is that the site people log in to is cloud.mysql.com.
So, that’s where they come to (17:24):
cloud.mysql.com.
Oh, my apologies.
I keep forgetting that you folks have multiple cloud offerings and domains.
They’re kind of a thing.
How do they work?
Given I have a bad domain by habit myself, I have no room to judge.
So, they come to cloud.mysql.com.
From there, they can provision an instance.
And we, as, like, you know, Oracle or MySQL, go ahead
(17:45):
and create an instance in AWS, in the Oracle tenancy.
From there, customers can then, you know, access their data on AWS and such.
Now, what we want to provide the customers is a very seamless experience,
that they just come to cloud.mysql.com, and from there, they can do
everything (18:00):
provisioning an instance, running the queries, payment and such.
So, this is one of the reasons that we want customers just to be able to
come to the site, cloud.mysql.com, and take care of the billing and such.
Now, the other thing is that, okay, why
not allow customers to pay from AWS, right?
Now, one of the things over there is that if you were to do that and there’s
(18:22):
a customer, they’ll be like, “Hey, I got to pay something to AWS, something
to Oracle, so we’d prefer, it’d be better to have a one-stop shop.” And since
many of these are already Oracle customers, it’s helpful to do it this way.
Another approach you could have taken—and I want to be very clear here that I
am not suggesting that this would have been a good idea—but an approach that
(18:43):
you could have taken would have been to go down the weird AWS partner rabbit
hole, and we’re going to provide this to customers on the AWS Marketplace.
Because according to AWS, that’s where all of
their customers go to discover new softwares.
Yeah, first, that’s a lie.
They do not.
But aside from that, what was it about that Marketplace model
(19:08):
that drove you to a decision point where okay, at launch,
we are not going to be offering this on the AWS Marketplace?
And to be clear, I’m not suggesting that was the wrong decision.
Right.
The main reason is we want to offer the MySQL HeatWave service at
the least expensive cost to the user, right, or like, the least cost.
If you were to, like, have MySQL HeatWave
(19:29):
in the Marketplace, AWS charges a premium.
This the customers would need to pay.
So, we just didn’t want the customers to have to pay this additional
premium just because they can now source this thing from the Marketplace.
So, it’s really to, like, save costs for the customer.
The value of the Marketplace, from my perspective, has been
effectively not having to deal as much with customer procurement
(19:52):
departments because well, AWS is already on the procurement approved
list, so we’re just going to go ahead and take the hit to wind up
making it accessible from that perspective and calling it good.
The downside to this is that increasingly, as customers are making larger
and longer-term commitments that are tied to certain levels of spend
(20:12):
on AWS, they’re increasingly trying to drag every vendor with whom they
do business into the your AWS bill so they can check those boxes off.
And the problem that I keep seeing with that is vendors who historically
have been doing just fine, have great working relationships with
a customer are reporting that suddenly customers are coming back
(20:34):
with, “Yeah, so for our contract renewal, we want to go through the
AWS Marketplace.” In return, effectively, these companies are then
just getting a haircut off whatever it is they’re able to charge
their customers but receiving no actual value for any of this.
It attenuates the relationship by introducing a third party into the process,
(20:56):
and it doesn’t make anything better from the vendor’s point of view because
they already had something functional and working; now they just have to
pay a commission on it to AWS, who, it seems, is pathologically averse
to any transaction happening where they don’t get a cut, on some level.
But I digress.
I just don’t like that model very much at all.
It feels coercive.
(21:17):
That’s absolutely right.
That’s absolutely right.
And we thought that, yes, there is some value to be going to Marketplace,
but it’s not worth the additional premium customers would need to pay.
Totally agree.
Here at the Duckbill Group, one of the things we do with,
you know, my day job, is we help negotiate AWS contracts.
We just recently crossed five billion dollars of contract value negotiated.
(21:40):
It solves for fun problems such as how do you know that your
contract that you have with AWS is the best deal you can get?
How do you know you're not leaving money on the table?
How do you know that you're not doing what I do on this podcast
and on Twitter constantly and sticking your foot in your mouth?
To learn more, come chat at duckbillgroup.com.
(22:02):
Optionally, I will also do podcast voice when we talk about it.
Again, that's duckbillgroup.com.
It’s also worth pointing out that in Oracle’s historical customer
base, by which I mean the last 40 years that you folks have been in
business, you do have significant customers with very sizable estates.
(22:24):
A lot of your cloud efforts have focused around, I guess,
we’ll call it an Oracle-specific currency (22:28):
Oracle Credits.
Which is similar to the AWS style of currency
just for a different company in different ways.
One of the benefits that you articulated to me relatively early on was that
by going through cloud.mysql.com, customers with those credits—which can be
in sizable amounts based upon various differentiating variables that change
(22:52):
from case to case—and apply that to their use of MySQL HeatWave on AWS.
Right.
So, in fact, just for starters, right, what we give to customers is we offer
some free credits for customers to try a service on OCI of, you know, $300.
And that’s the same thing, the same experience you would
like customers who are trying HeatWave on AWS to get.
(23:13):
Yes, so you’re right, this is the kind of consistency we want
to have, and yet another reason why cloud.mysql.com makes
sense is the entry point for customers to try the service.
There was a time where I would have struggled not to laugh in
your face at the idea that we’re talking about something in the
context of an Oracle database, and well, there’s $300 in credit.
(23:35):
That’s, “What can I get for that?
Hung up on?” No.
A surprising amount, when it comes to these things.
I feel like that opens up an entirely new universe of experimentation.
And, “Let’s see how this thing actually works with his
workload,” and lets people kick the tires on it for
themselves in a way that, “Oh, we have this great database.
Well, can I try it?
(23:55):
Sure, for $8 million, you absolutely can.” “Well, it can stay great and
awesome over there because who wants to take that kind of a bet?” It feels
like it’s a new world and in a bunch of different respects, and I just can’t
make enough noise about how glad I am to see this transformation happening.
Yeah.
Absolutely, right?
So, just think about it.
So, you’re getting MySQL and HeatWave together
(24:17):
for just shy of ten cents an hour, right?
So, what you could get for $300 is 3000 hours for MySQL HeatWave
instance, which is very good for people to try for free.
And then, you know, decide if they want to go ahead with it.
One other, I guess, obnoxious question that I love to ask—it’s not really a
question so much as a statement; that that’s part of the first thing that makes
(24:37):
it really obnoxious—but it always distills down to the following that upsets
product people left and right, which is, “I don’t get it.” And one of the
things that I didn’t fully understand at the outset of how you were structuring
things was the idea of separating out HeatWave from its constituent components.
(24:58):
I believe it was Autopilot if I’m not mistaken, and it was
effectively different SKUs that you could wind up opting to go for.
And okay, if I’m trying to kick the tires on this and contextualize it
as someone for whom the world’s best database is Route 53, then it really
felt like an additional decision point that I wasn’t clear on the value of.
(25:19):
And I’m still not entirely sure on the differentiation point and
the value there, but now you offer it bundled as a default, which
I think is so much better, from the user experience perspective.
Okay, so let me clarify a couple of things.
Please.
Databases are not my forte, so expect me to wind
up getting most of the details hilariously wrong.
Sure.
So, MySQL Autopilot provides machine-learning-based automation
(25:43):
for various aspects of the MySQL service; very popular.
There is no charge for it.
It is built into MySQL HeatWave; there is no additional
charge for it, right, so there never was any SKU for it.
What you’re referring to is, we have had a SKU for the MySQL node
or the MySQL instance, and there’s a separate SKU for HeatWave.
(26:03):
The reason there is a need to have a different SKU for
these two is because you always only have one node of MySQL.
It could be, like, you know, running on one core, or like, you
know, multiple cores, but it’s always, like, you know, one node.
But with HeatWave, it’s a scale-out
architecture, so you can have multiple nodes.
So, the users need to be able to express how many
nodes of HeatWave are they provisioning, right?
(26:25):
So, that’s why there is a need to have two
SKUs, and we continue to have those two SKUs.
What we are doing now differently is that when users
instantiate a MySQL instance, by default, they always
get the HeatWave node associated with it, right?
So, they don’t need to, like, you know, make the decision to—okay
when to add HeatWave; they always get HeatWave along with the
(26:47):
MySQL instance, and that’s what I was saying a combination of
both of these is, you know, like, just about ten cents an hour.
If for whatever reason, they decide that they do not want
HeatWave, they can turn it off, and then the price drops to half.
But what we’re providing is the AWS service
that HeatWave is turned on by default.
Which makes an awful lot of sense.
It’s something that lets people opt out if they decide they don’t need this
(27:11):
as they continue to scale out, but for the newcomer who does not, in many
cases—in my particular case—have a nuanced understanding of where this offering
starts and stops, it’s clearly the right decision of—rather than, “Oh, yeah.
The thing you were trying and it didn’t work super well?
Well, yeah.
If you enable this other thing, it would have been awesome.” “Well, great.
(27:31):
Please enable it for me by default and let me opt out
later in time as my level of understanding deepens.”
That’s right.
And that’s exactly what we are doing.
Now, this was a feedback we got because many, if not most, of our customers
would want to have HeatWave, and we just kind of, you know, mitigating
them from going through one more step, it’s always enabled by default.
As far as I’m aware, you folks are running this effectively as any
(27:56):
other AWS customer might, where you establish a private link connection
to your customers, in some cases, or give them a public or private
endpoint where they can wind up communicating with this service.
It doesn’t require any favoritism or special permissions from AWS themselves
(28:16):
that they wouldn’t give to any other random customer out there, correct?
Yes, that is correct.
So, for now, we are exposing this thing as a public endpoint.
In the future, we have plans to support the
private endpoint as well, but for now, it’s public.
Which means that foundationally what you’re building
out is something that fits into a model that could work
extraordinarily well across a variety of different environments.
(28:39):
How purpose-tuned is the HeatWave installation you have running on
AWS for the AWS environment, versus something that is relatively
agnostic, could be dropped into any random cloud provider, up to and
including the terrifyingly obsolete rack I have in the spare room?
So, as I mentioned, when we decided to offer MySQL HeatWave on AWS, the idea
(29:02):
was that okay, for the AWS customers, we now want to have an offering which
is completely optimized for AWS, provides the best price-performance on AWS.
So, we have determined which instance types underneath will provide the
best price performance, and that’s what we have optimized for, right?
So, I can tell you, like, in terms of many of—for instance,
(29:22):
take the case of the cache size of the underlying processor that
we’re using on AWS is different than what we’re using for OCI.
So, we have gone ahead, made these optimizations in our code, and we
believe that our code is really optimized now for the AWS infrastructure.
I think that makes a fair deal of sense because, again, one of the big
(29:44):
problems AWS has had is the proliferation of EC2 instance types to the
point now where the answer is super easy, too, “Are you using the correct
instance type for your workload?” Because that answer now is, “Of course not.
Who could possibly say that they were with any degree of confidence?” But
when you take the time to look at a very specific workload that’s going
(30:04):
to be scaled out, it’s worth the time investment to figure out exactly
how to optimize things for price and performance, given the constraints.
Let’s be very clear here, I would argue that the better price performance
for HeatWave is almost certainly not going to be on AWS themselves,
if for no other reason than the joy that is their data transfer
(30:25):
pricing, even for internal things moving around from time to time.
Personally, I love getting charged data transfer for taking data from
S3, running it through AWS Glue, putting it into a different S3 bucket,
accessing it with Athena, then hooking that up to Tableau as we go
down and down and down the spiraling rabbit hole that never ends.
(30:45):
It’s not exactly what I would call well-optimized economically.
Their entire system feels almost like it’s a rigged game, on some level.
But given those constraints, yeah, dialing in it and
making it cost-effective is absolutely something that I’ve
watched you folks put significant time and effort into.
So, I’ll make two points, right, to the questions.
First is yes, I just want to, like, be clear about it, that when a user
(31:09):
provisions MySQL HeatWave via cloud.mysql.com and we create an instance in AWS,
we don’t give customers a multitude of things to, like, you know, choose from.
We have determined which instance type is going to provide the
customer the best price performance, and that’s what we provision.
So, the customer doesn’t even need to know or
care, is it going to be, like, you know, AMD?
(31:31):
Is it going to be Intel?
Is it going to be, like, you know, ARM, right?
So, it’s something which we have predetermined and we have optimized for it.
That’s first.
The second point is in terms of the price performance.
So, you’re absolutely right, that for the class of customers
who cannot migrate away from AWS because of the egress costs or
because of the high latency because of AWS, right, sure, MySQL
(31:53):
HeatWave on AWS will provide the best price-performance compared to
other services out in AWS like Redshift, or Aurora, or Snowflake.
But if customers have the flexibility to choose a cloud of their choice, it is
indeed the case that customers are going to find that running MySQL HeatWave
on OCI is going to provide them, by far, the best price performance, right?
(32:17):
So, the price performance of running MySQL HeatWave
on OCI is indeed better than MySQL HeatWave on AWS.
And just because of the fact that when we are running the service in AWS,
we are paying the list price, right, on AWS; that’s how we get the gear.
Whereas with OCI, like, you know, things are a lot less expensive for us.
But even when you’re running on AWS, we are
(32:38):
very, very price competitive with other services.
And you know, as you’ve probably seen from the performance benchmarks
and such, what I’m very intrigued about is that we’re able to run a
standard workload, like some, like, you know, TPC-H and offer seven
times better price-performance while running in AWS compared to Redshift.
So, what this goes to show is that we are
(32:58):
really passing on the savings to the customers.
And clearly, Redshift is not doing a good job of
performance or, like, you know, they’re charging too much.
But the fact that we can offer seven times better price performance
than Redshift in AWS speaks volumes, both about architecture
and how much of savings we are passing to our customers.
What I love about this story is that it makes testing the
(33:21):
waters of what it’s like to run MySQL HeatWave a lot easier
for customers because the barrier to entry is so much lower.
Where everything you just said I agree with it
is more cost-effective to run on Oracle Cloud.
I think there are a number of workloads that are best placed on Oracle Cloud.
But unless you let people kick the tires on those things, where
(33:43):
they happen to be already, it’s difficult to get them to a point
where they’re going to be able to experience that themselves.
This is a massive step on that path.
Yep.
Right.
I really want to thank you for taking time out of your
day to walk us through exactly how this came to be
and what the future is going to look like around this.
If people want to learn more, where should they go?
(34:04):
Oh, they can go to oracle.com/mysql, and there they can
get a lot more information about the capabilities of MySQL
HeatWave, what we are offering in AWS, price-performance.
By the way, all the price performance numbers I was talking
about, all the scripts are available publicly on GitHub.
So, we welcome, we encourage customers to download the scripts from
(34:25):
GitHub, try for themselves, and all of this information is available
from oracle.com/mysql where they can get this detailed information.
And we will, of course, put links to that in the show notes.
Thank you so much for your time.
I appreciate it.
Sure thing, Corey.
Thank you for the opportunity.
Nipun Agarwal, Senior Vice President of MySQL HeatWave.
I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud.
(34:48):
If you’ve enjoyed this podcast, please leave a five-star review
on your podcast platform of choice, whereas if you’ve hated
this podcast, please leave a five-star review on your podcast
platform of choice along with an angry insulting comment.
You will then be overcharged for the data transfer to
submit that insulting comment, and then AWS will take a
percentage of that just because they’re obnoxious and can.
Popular Podcasts
24/7 News: The Latest
The latest news in 4 minutes updated every hour, every day.
Therapy Gecko
An unlicensed lizard psychologist travels the universe talking to strangers about absolutely nothing. TO CALL THE GECKO: follow me on https://www.twitch.tv/lyleforever to get a notification for when I am taking calls. I am usually live Mondays, Wednesdays, and Fridays but lately a lot of other times too. I am a gecko.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.