Amazon Relational Database Service (RDS)

[Sam Johnston]

This may well prove to be the cloud news of the week:

Amazon Relational Database Service (Amazon RDS) is a web service that makes it easy to set up, operate, and scale a relational database in the cloud. It provides cost-efficient and resizable capacity while managing time-consuming database administration tasks, freeing you up to focus on your applications and business.

Amazon RDS gives you access to the full capabilities of a familiar MySQL database. This means the code, applications, and tools you already use today with your existing MySQL databases work seamlessly with Amazon RDS. Amazon RDS automatically patches the database software and backs up your database, storing the backups for a user-defined retention period. You also benefit from the flexibility of being able to scale the compute resources or storage capacity associated with your relational database instance via a single API call. As with all Amazon Web Services, there are no up-front investments required, and you pay only for the resources you use.

Amazon RDS Functionality

Amazon RDS is designed for developers or businesses who require the full features and capabilities of a relational database, or who wish to migrate existing applications and tools that utilize a relational database. It gives you access to the full capabilities of a MySQL 5.1 database running on your own Amazon RDS database instance.

To use Amazon RDS, you simply:

• Launch a database instance (DB Instance), selecting the DB Instance class and storage capacity that best meets your needs.
• Select the desired retention period (in number of days) for your automated database backups. Amazon RDSwill automatically back up your database during your predefined backup window. For typical workloads, this allows you to restore to any point in time within your retention period, up to the last five minutes. You can also restore from a DB Snapshot, a user-initiated backup that can be run at any time with a simple API call.
• Connect to your DB Instance using your favorite database tool or programming language. Since you have direct access to a full-featured MySQL database, any tool designed for the MySQL engine will work unmodified with Amazon RDS.
• Monitor the compute and storage resource utilization of your DB Instance, for no additional charge, via Amazon CloudWatch. If at any point you need additional capacity, you can scale the compute and storage resources associated with your DB Instance with a simple API call.
• Pay only for the resources you actually consume, based on your DB Instance hours consumed, database storage, backup storage, and data transfer.

↑ Top

---

Service Highlights

Simple to Deploy – Amazon RDS makes it easy to go from project conception to deployment. Use simple API calls to access the capabilities of a production-ready relational database without worrying about infrastructure provisioning or installing and maintaining database software.

Managed – Amazon RDS handles generic, time-consuming database management tasks, such as patch management and backup, which allows you to pursue higher value application development or database refinements.

Compatible – With Amazon RDS, you get full native access to a MySQL database. This means Amazon RDS works with your existing tools, applications, and drivers. You can port an existing database to Amazon RDS without changing a line of code – just point your tools or applications at your Amazon RDS DB Instance and you are ready to go.

Scalable – With a simple API call you can scale the compute and storage resources available to your database to meet your business needs and application load.

Reliable – Amazon RDS runs on the same highly reliable infrastructure used by other Amazon Web Services. AmazonRDS gives you additional peace of mind by enabling automated database backup. For typical workloads, this allows you to restore your DB Instance to any point in time during your retention period, up to the last five minutes. And, there is no additional charge for backup storage, up to 100% of your primary provisioned storage size.

Designed for use with other Amazon Web Services – Amazon RDS is tightly integrated with other Amazon Web Services. For example, an application running in Amazon EC2 will experience low-latency database access to an Amazon RDS DB Instance in the same region.

Secure – Amazon RDS provides web service interfaces to configure firewall settings that control network access to your database.

Inexpensive – You pay very low rates and only for the resources you actually consume. There are no long-term contracts or up-front commitments to use Amazon RDS.

↑ Top

DB Instance Classes

Amazon RDS currently supports five DB Instance Classes:

• Small DB Instance: 1.7 GB memory, 1 ECU (1 virtual core with 1 ECU), 64-bit platform.
• Large DB Instance: 7.5 GB memory, 4 ECUs (2 virtual cores with 2 ECUs each), 64-bit platform
• Extra Large DB Instance: 15 GB of memory, 8 ECUs (4 virtual cores with 2 ECUs each), 64-bit platform
• Double Extra Large DB Instance: 34 GB of memory, 13 ECUs (4 virtual cores with 3,25 ECUs each), 64-bit platform
• Quadruple Extra Large DB Instance: 68 GB of memory, 26 ECUs (8 virtual cores with 3.25 ECUs each), 64-bit platform

For each DB Instance class, RDS provides you with the ability to select from 5GB to 1TB of associated storage capacity. One ECU provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.

↑ Top

---

Pricing

Pay only for what you use. There is no minimum fee. Estimate your monthly bill using the AWS Simple Monthly Calculator.

Amazon RDS DB Instance Pricing

On Demand Instance Pricing:

DB Instance Class	Price Per Hour
Small DB Instance	$0.11
Large DB Instance	$0.44
Extra Large DB Instance	$0.88
Double Extra Large DB Instance	$1.55
Quadruple Extra Large DB Instance	$3.10

Provisioned Database Storage

For each DB Instance class, Amazon RDS provides you the ability to select from 5 GB to 1 TB of associated storage capacity for your primary data set.

• $0.10 per GB-month of provisioned storage
• $0.10 per 1 million I/O requests

Backup Storage

Backup storage is the storage associated with your automated database backups and any user-initiated DB Snapshots you have taken. Increasing your backup retention period or taking additional database snapshots increases the backup storage consumed by your database.

• There is no additional charge for backup storage up to 100% of your provisioned database storage for an active DB Instance.* After the DB Instance is terminated, backup storage is billed at $0.15 per GB-month.
• Additional backup storage: $0.15 per GB-month

* For example, if you have an active DB Instance with 10GB-month of provisioned database storage, we will provide up to 10GB-month of backup storage at no additional charge. Based upon our experience as database administrators, the vast majority of databases require less raw storage for a backup than for the primary data set, meaning that most customers will never pay for backup storage.

Data Transfer

The pricing below is based on data transferred “in” and “out” of Amazon RDS.

Data Transfer In

• All Data Transfer $0.10 per GB

Data Transfer Out

• First 10 TB per Month $0.17 per GB
• Next 40 TB per Month $0.13 per GB
• Next 100TB per Month $0.11 per GB
• Over 150 TB per Month $0.10 per GB

Data transferred between two Amazon Web Services within the same region (e.g. between Amazon RDS US and AmazonEC2 US) is free of charge. Data transferred between AWS services in different regions will be charged as Internet Data Transfer on both sides of the transfer.

Availability Zone Data Transfer

• $0.00 per GB – all data transferred between instances in the same Availability Zone using private IP addresses. Regional Data Transfer
• $0.01 per GB in/out – all data transferred between Amazon EC2 instances, or between Amazon EC2 instances and Amazon RDS DB Instances in different Availability Zones in the same region.

All pricing listed above is for DB Instances running in the US Region. We expect to make the service available in the EU Region in the coming months.

[tluk...@exnihilum.com]

>> "This may well prove to be the cloud news of the week"

For sure this is a very significant thing; providing a MySQL database AND backup support is definitely another giant step in the right direction -- and great news for Cloud developers.

TJL

-----Original Message-----
From: "Sam Johnston" [sa...@samj.net]
Date: 10/27/2009 12:28 AM
To: "cloudforum" <cloud...@googlegroups.com>
Subject: Re: Amazon Relational Database Service (RDS)

This may well prove to be the cloud news of the week:


Amazon Relational Database Service (Amazon RDS) is a web service that makes it easy to set up, operate, and scale a relational database in the cloud. It provides cost-efficient and resizable capacity while managing time-consuming database administration tasks, freeing you up to focus on your applications and business.

Amazon RDS gives you access to the full capabilities of a familiar MySQL database. This means the code, applications, and tools you already use today with your existing MySQL databases work seamlessly with Amazon RDS. Amazon RDS automatically patches the database software and backs up your database, storing the backups for a user-defined retention period. You also benefit from the flexibility of being able to scale the compute resources or storage capacity associated with your relational database instance via a single API call. As with all Amazon Web Services, there are no up-front investments required, and you pay only for the resources you use.Amazon RDS FunctionalityAmazon RDS is designed for developers or businesses who require the full features and capabilities of a relational database, or who wish to migrate existing applications and tools that utilize a relational database. It gives you access to the full capabilities of a MySQL 5.1 database running on your own Amazon RDS database instance.

To use Amazon RDS, you simply:

Launch a database instance (DB Instance), selecting the DB Instance class and storage capacity that best meets your needs.Select the desired retention period (in number of days) for your automated database backups. Amazon RDSwill automatically back up your database during your predefined backup window. For typical workloads, this allows you to restore to any point in time within your retention period, up to the last five minutes. You can also restore from a DB Snapshot, a user-initiated backup that can be run at any time with a simple API call.Connect to your DB Instance using your favorite database tool or programming language. Since you have direct access to a full-featured MySQL database, any tool designed for the MySQL engine will work unmodified with Amazon RDS.Monitor the compute and storage resource utilization of your DB Instance, for no additional charge, via Amazon CloudWatch. If at any point you need additional capacity, you can scale the compute and storage resources associated with your DB Instance with a simple API call.Pay only for the resources you actually consume, based on your DB Instance hours consumed, database storage, backup storage, and data transfer.↑ Top


Service HighlightsSimple to Deploy – Amazon RDS makes it easy to go from project conception to deployment. Use simple API calls to access the capabilities of a production-ready relational database without worrying about infrastructure provisioning or installing and maintaining database software.

Managed – Amazon RDS handles generic, time-consuming database management tasks, such as patch management and backup, which allows you to pursue higher value application development or database refinements.
Compatible – With Amazon RDS, you get full native access to a MySQL database. This means Amazon RDS works with your existing tools, applications, and drivers. You can port an existing database to Amazon RDS without changing a line of code – just point your tools or applications at your Amazon RDS DB Instance and you are ready to go.
Scalable – With a simple API call you can scale the compute and storage resources available to your database to meet your business needs and application load.
Reliable – Amazon RDS runs on the same highly reliable infrastructure used by other Amazon Web Services. AmazonRDS gives you additional peace of mind by enabling automated database backup. For typical workloads, this allows you to restore your DB Instance to any point in time during your retention period, up to the last five minutes. And, there is no additional charge for backup storage, up to 100% of your primary provisioned storage size.
Designed for use with other Amazon Web Services – Amazon RDS is tightly integrated with other Amazon Web Services. For example, an application running in Amazon EC2 will experience low-latency database access to an Amazon RDS DB Instance in the same region.
Secure – Amazon RDS provides web service interfaces to configure firewall settings that control network access to your database.
Inexpensive – You pay very low rates and only for the resources you actually consume. There are no long-term contracts or up-front commitments to use Amazon RDS.
↑ Top

DB Instance ClassesAmazon RDS currently supports five DB Instance Classes:
Small DB Instance: 1.7 GB memory, 1 ECU (1 virtual core with 1 ECU), 64-bit platform.Large DB Instance: 7.5 GB memory, 4 ECUs (2 virtual cores with 2 ECUs each), 64-bit platformExtra Large DB Instance: 15 GB of memory, 8 ECUs (4 virtual cores with 2 ECUs each), 64-bit platformDouble Extra Large DB Instance: 34 GB of memory, 13 ECUs (4 virtual cores with 3,25 ECUs each), 64-bit platformQuadruple Extra Large DB Instance: 68 GB of memory, 26 ECUs (8 virtual cores with 3.25 ECUs each), 64-bit platformFor each DB Instance class, RDS provides you with the ability to select from 5GB to 1TB of associated storage capacity. One ECU provides the equivalent CPU capacity of a 1.0-1.2 GHz 2007 Opteron or 2007 Xeon processor.
↑ Top







PricingPay only for what you use. There is no minimum fee. Estimate your monthly bill using the AWS Simple Monthly Calculator.
Amazon RDS DB Instance PricingOn Demand Instance Pricing:

DB Instance ClassPrice Per Hour
Small DB Instance$0.11
Large DB Instance$0.44
Extra Large DB Instance$0.88
Double Extra Large DB Instance$1.55
Quadruple Extra Large DB Instance$3.10

Provisioned Database StorageFor each DB Instance class, Amazon RDS provides you the ability to select from 5 GB to 1 TB of associated storage capacity for your primary data set.
$0.10 per GB-month of provisioned storage$0.10 per 1 million I/O requestsBackup StorageBackup storage is the storage associated with your automated database backups and any user-initiated DB Snapshots you have taken. Increasing your backup retention period or taking additional database snapshots increases the backup storage consumed by your database.
There is no additional charge for backup storage up to 100% of your provisioned database storage for an active DB Instance.* After the DB Instance is terminated, backup storage is billed at $0.15 per GB-month.Additional backup storage: $0.15 per GB-month* For example, if you have an active DB Instance with 10GB-month of provisioned database storage, we will provide up to 10GB-month of backup storage at no additional charge. Based upon our experience as database administrators, the vast majority of databases require less raw storage for a backup than for the primary data set, meaning that most customers will never pay for backup storage.Data TransferThe pricing below is based on data transferred “in” and “out” of Amazon RDS.Data Transfer InAll Data Transfer $0.10 per GBData Transfer OutFirst 10 TB per Month $0.17 per GBNext 40 TB per Month $0.13 per GBNext 100TB per Month $0.11 per GBOver 150 TB per Month $0.10 per GBData transferred between two Amazon Web Services within the same region (e.g. between Amazon RDS US and AmazonEC2 US) is free of charge. Data transferred between AWS services in different regions will be charged as Internet Data Transfer on both sides of the transfer.Availability Zone Data Transfer$0.00 per GB – all data transferred between instances in the same Availability Zone using private IP addresses. Regional Data Transfer$0.01 per GB in/out – all data transferred between Amazon EC2 instances, or between Amazon EC2 instances and Amazon RDS DB Instances in different Availability Zones in the same region.All pricing listed above is for DB Instances running in the US Region. We expect to make the service available in the EU Region in the coming months.

[yarapavan]

Also the price drop upto 15% in EC2 also is significant marking the
start of cloud wars :)

Link to Amazon News Announcement on Price Drop for EC2, effective Nov
1:
http://aws.amazon.com/about-aws/whats-new/2009/10/27/announcing-lower-amazon-ec2-instance-pricing/

On Oct 27, 10:57 am, "tluka...@exnihilum.com" <tluka...@exnihilum.com>
wrote:

[Bob Sutterfield]

I was mildly disappointed to see that HA support didn't make the initial release feature set:

New Features for Amazon RDS Coming Soon

To help you better plan future hardware and software investments, Amazon RDS would like to share the following features that we plan to make available in the coming months:

• Reserved DB Instances — With Reserved DB Instances you pay a low, one-time fee and in turn receive a discount on the ongoing hourly usage charge for that DB Instance. Reserved DB Instances can provide substantial savings over owning your own hardware or even running only On-Demand DB Instances.
• High Availability Offering — For developers and business who want additional resilience beyond the automated backups provided by Amazon RDS at no additional charge. With the high availability offer, developers and business can easily and cost-effectively provision synchronously replicated DB Instances in multiple availability zones (AZ’s), to protect against failure within a single location.

Some interesting questions to watch as this product develops:

• Will replication traffic be charged at the full rate as other data between Availability Zones or between Regions?
• Will CloudWatch expose replication latency?
• Will Amazon offer a SLA for replication latency?

--
Bob Sutterfield
b...@sutterfields.us
http://www.linkedin.com/in/BobSutterfield

[Sam Johnston]

On Tue, Oct 27, 2009 at 6:57 AM, tluk...@exnihilum.com <tluk...@exnihilum.com> wrote:

>> "This may well prove to be the cloud news of the week"

For sure this is a very significant thing; providing a MySQL database AND backup support is definitely another giant step in the right direction -- and great news for Cloud developers.

It's also a significant thorn in the side of those proclaiming SQL is dead (and in doing so missing the point of the whole ACID vs BASE consistency/scalability tradeoff)...

Sam

 

[Pat Wendorf]

Agreed.  RDBMS's are still the right tool for many tasks, and having an auto-scaling solution in a cloud infrastructure is a big step closer to the "No need to re-write or port, just re-host", type of ideal.

[Geir Magnusson Jr.]

On Oct 27, 2009, at 11:17 AM, Pat Wendorf wrote:

> Agreed. RDBMS's are still the right tool for many tasks, and having
> an auto-scaling solution in a cloud infrastructure is a big step
> closer to the "No need to re-write or port, just re-host", type of
> ideal.

How is this auto-scaling?

geir

[Pat Wendorf]

"

Amazon Relational Database Service (Amazon RDS) is a web service that makes it easy to set up, operate, and scale a relational database in the cloud."

and

Scalable – With a simple API call you can scale the compute and storage resources available to your database to meet your business needs and application load.

It looks like I fell for the marketing :)  The first statement implied scalability, the second made it clear it was through external API calls, not internal threshold triggers.  My bad.

[tluk...@exnihilum.com]

>> "The first statement implied scalability, the second made it clear it was through external API calls, not internal threshold triggers."

OK.. so while it may not be "fully automatic", if it can "scale up" as needed in response to a simple enough API call from your application (let's call it "semi-automatic") that's still offloading the details of "making it happen" and in the process giving us a decent boost toward achieving RDBMS scalability compared with classic or legacy database techniques.

TJL

-----Original Message-----
From: "Pat Wendorf" [dung...@gmail.com]
Date: 10/27/2009 11:35 AM
To: cloud...@googlegroups.com
Subject: Re: Amazon Relational Database Service (RDS)

"Amazon Relational Database Service (Amazon RDS) is a web service that makes it easy to set up, operate, and scale a relational database in the cloud."

and

Scalable – With a simple API call you can scale the compute and storage resources available to your database to meet your business needs and application load.


It looks like I fell for the marketing :)  The first statement implied scalability, the second made it clear it was through external API calls, not internal threshold triggers.  My bad.


On Tue, Oct 27, 2009 at 11:20 AM, Geir Magnusson Jr. <ge...@pobox.com> wrote:


On Oct 27, 2009, at 11:17 AM, Pat Wendorf wrote:

> Agreed.  RDBMSs are still the right tool for many tasks, and having

> an auto-scaling solution in a cloud infrastructure is a big step
> closer to the "No need to re-write or port, just re-host", type of
> ideal.


How is this auto-scaling?

geir


>
> On Tue, Oct 27, 2009 at 10:24 AM, Sam Johnston <sa...@samj.net> wrote:
> On Tue, Oct 27, 2009 at 6:57 AM, tluk...@exnihilum.com <tluk...@exnihilum.com
> > wrote:
>
> >> "This may well prove to be the cloud news of the week"
>
> For sure this is a very significant thing; providing a MySQL
> database AND backup support is definitely another giant step in the
> right direction -- and great news for Cloud developers.
>

> Its also a significant thorn in the side of those proclaiming SQL

[Sam Johnston]

To further elaborate, from RDS::

Monitor the compute and storage resource utilization of your DB Instance, for no additional charge, via Amazon CloudWatch. If at any point you need additional capacity, you can scale the compute and storage resources associated with your DB Instance with a simple API call.

and CloudWatch:

Amazon CloudWatch is a web service that provides monitoring for AWS cloud resources, starting with Amazon EC2. It provides customers with visibility into resource utilization, operational performance, and overall demand patterns—including metrics such as CPU utilization, disk reads and writes, and network traffic. To use Amazon CloudWatch, simply select the AmazonEC2 instances that you’d like to monitor; within minutes, Amazon CloudWatch will begin aggregating and storing monitoring data that can be accessed using the AWS Management Console, web service APIs or Command Line Tools.

So Geir's right - it's scaling alright, just not auto-scaling. Only a matter of time...

I expect resources allocated to machines machines to start tracking their requirements in real-time before long, and eventually we'll break away from the idea of a box having a fixed set of resources altogether (which is what the world looks like to processes thanks to virtual memory, scheduling, etc.).

Sam

[Geir Magnusson Jr.]

Is there anything about this announcement that makes you believe this
is any more than a convenient way to choose disk size and machine size
and run a MySQL instance?

Data in the cloud doesn't necessarily mean scalable. Think about the
DB portion of Azune as I understand it - there is the SQL part (put in
w/ the very astute recognition that not all data needs to scale, and
shoving in SQLServer/MySQL make life so easy for developers), and then
non-SQL part, which scales (or should).

geir

[Alexis Richardson]

Performance to disk may be improved, relative to running MySQL as an AMI.

[Sam Johnston]

On Tue, Oct 27, 2009 at 5:37 PM, Alexis Richardson <alexis.r...@gmail.com> wrote:

Performance to disk may be improved, relative to running MySQL as an AMI.

Let's not forget that my performance in widget-making and basket-weaving will certainly improve if I don't have to stuff around setting up and maintaining MySQL just to be able to use it too... or at least my profits will if I don't have to pay someone else to do it for me (except via the utility premium).

Sam

[Reuven Cohen]

Let me get this straight. Amazon basically created a Restful Meta API for deploying mySQL clusters for people not smart enough to figure out how to do it themselves using one of the dozens of mySQL cluster AMI's available at 8.5cent / hour.

Instead of a Web service, what they need is a giant red button labeled DummyDB.
Sorry folks, I am under-whelmed on this one. 

r/c

[James Watters]

I would like to ditto that comment. There isn't much magic built into this offering, its more a short-cut simple than cloud & scaling.

[tluk...@exnihilum.com]

>> "for people not smart enough to figure out how to do it themselves"

And why is "doing it yourself" somehow better? Are restaurants and catering services for people who "are not smart enough to cook a meal for thmselves"? There are a lot more productive ways for a Cloud developer to spend their time than to show how "smart they are" by "doing it themselves". Persistence ought to be for the asking.

TJL

-----Original Message-----
From: "James Watters" [watter...@gmail.com]
Date: 10/27/2009 01:30 PM
To: cloud...@googlegroups.com
Subject: Re: Amazon Relational Database Service (RDS)

I would like to ditto that comment. There isnt much magic built into this offering, its more a short-cut simple than cloud & scaling.

On Tue, Oct 27, 2009 at 10:27 AM, Reuven Cohen <r...@enomaly.com> wrote:

Let me get this straight. Amazon basically created a Restful Meta API for deploying mySQL clusters for people not smart enough to figure out how to do it themselves using one of the dozens of mySQL cluster AMIs available at 8.5cent / hour.

Instead of a Web service, what they need is a giant red button labeled DummyDB.
Sorry folks, I am under-whelmed on this one. 

r/c


On Tue, Oct 27, 2009 at 12:43 PM, Sam Johnston <sa...@samj.net> wrote:
On Tue, Oct 27, 2009 at 5:37 PM, Alexis Richardson <alexis.r...@gmail.com> wrote:

Performance to disk may be improved, relative to running MySQL as an AMI.

Lets not forget that my performance in widget-making and basket-weaving will certainly improve if I dont have to stuff around setting up and maintaining MySQL just to be able to use it too... or at least my profits will if I dont have to pay someone else to do it for me (except via the utility premium).

Sam



On Tue, Oct 27, 2009 at 4:35 PM, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> Is there anything about this announcement that makes you believe this
> is any more than a convenient way to choose disk size and machine size
> and run a MySQL instance?
>

> Data in the cloud doesnt necessarily mean scalable.  Think about the

> DB portion of Azune as I understand it - there is the SQL part (put in
> w/ the very astute recognition that not all data needs to scale, and
> shoving in SQLServer/MySQL make life so easy for developers), and then
> non-SQL part, which scales (or should).
>
> geir
>
> On Oct 27, 2009, at 12:30 PM, tluk...@exnihilum.com wrote:
>
>>
>>>> "The first statement implied scalability, the second made it clear
>>>> it was through external API calls, not internal threshold triggers."
>>
>> OK.. so while it may not be "fully automatic", if it can "scale up"
>> as needed in response to a simple enough API call from your

>> application (lets call it "semi-automatic") thats still offloading

[gary mazzaferro]

My take away on Ruv's remarks is the overall recurring costs and price differentials. The big question here is for the consumer to answer, "does the TCO of RDS warrant consideration ?"  Whether the technology is ReST or carrier pigeons and consumer "technical competency " is irrelevant to the value proposition. If the service has traction, then automagic provisioning and scaling should be fairly easy to add.

gary 

[Reuven Cohen]

I would agree with that. The question is if the extra 3 cents an hour is worth the reduction in effort required to do it yourself.

r/c

[James Watters]

That it lacked true auto scaling at launch told me they were just trying to get it to market before full azure launch.

Sent from my iPhone

[Sam Johnston]

On Tue, Oct 27, 2009 at 6:49 PM, tluk...@exnihilum.com <tluk...@exnihilum.com> wrote:

>> "for people not smart enough to figure out how to do it themselves"

And why is "doing it yourself" somehow better? Are restaurants and catering services for people who "are not smart enough to cook a meal for thmselves"? There are a lot more productive ways for a Cloud developer to spend their time than to show how "smart they are" by "doing it themselves". Persistence ought to be for the asking.

Right, there's a *lot* to be said for letting someone else deal with the details... after all *that's what cloud's all about*.

Let's put things in perspective with some quick napkin maths:

DBA salary: $70,000pa ~= $6,000pm

Amazon vDBA: $0.025/hr ~= $18.26pm

That is to say, at market rates Amazon are achieving a rate of one DBA for over 300 servers. And that's including their (quite probably significant) margin. Good luck achieving the same level of efficiency...

Sam

 

[gary mazzaferro]

Ruv, I think its even more fundamental than that, it affects the make vs buy decision. Is it worth purchasing servers hiring another body or taking one off another task. Can acquisition and setup complete in the time frame they need. Another consideration is whether RDS will be used for production or "special" projects. 

-gary

[Reuven Cohen]

You guys are assuming the AWS magic just works. There is a lot more to scaling a DB then just uploading your SQL.  I doubt this is going to put DBA's out of business anytime soon.

r/c

-- 

[Alexis Richardson]

Well said Sam.

[Alexis Richardson]

That's a good point, but I still don't see how RDB can be 'worse'
economically than 'MySQL AMIs'.

[Reuven Cohen]

I think my question is how or why is it better?

r/c

[Alexis Richardson]

I can see at least 3 ways:

1. for the same price, who would you rather buy support from?

2. performance may be better

3. upgrading to things like HA may be easier

a

[Niall Riddell]

I think it would take quite a bit of heavy lifting to get a recovery point of 5 mins.

Niall

2009/10/27 Reuven Cohen <r...@enomaly.com>

[Sam Johnston]

Ruv,

You seemed pretty impressed yesterday when it was Azure... what's the difference here?

Sam

[Reuven Cohen]

I'm probably the wrong guy for these types of services. I prefer to play with the configuration files. But I suppose it would be useful for some users. It just seems to run contrary to the the more technically focused users who seem to use AWS currently.  What is becoming obvious is that Amazon is taking steps to make their IaaS offer more PaaS like.

@Samj, my concerns would be the same for SQL Azure, although SQL Azure does make a little more sense given the PaaS focus for Windows Azure.

r/c

[gary mazzaferro]

@Sam,  well this is all very subjective, there is no track record for any of the services. Lets say that have a .19% error rate (dropped requests unfilled requests, etc. )  I couldn't use it for production, but if I had a special project, I would definitely consider the services.  Just for quick one-offs  and non-critical stuff. Budgets for acquisitions are few an far between these days and you can buy a lot of processing  for the price of a hardware server, OS and database. I'm not so sure about the vDBA. I haven't look into any in detail, I'd like to know the additional expertise needed to develop and administer.

gary

[G. Hussain Chinoy]

I agree with Sam here, the cost to benefit ratio of not having to sysadmin/dba way outstrips the few cents extra per hour.

What's wrong with an IaaS company offering PaaS?  I think it's a logical and more accessible offering for Amazon to provide a mySQL in the cloud along with AMIs, it's a leg up for them over Microsoft's Azure line, who are clearly targeting one layer of the cloud strata.  Honestly, there's nothing wrong with what Microsoft's doing - it's focused and directed to making things easy but no easier from their pov.

I enjoy playing with configuration files, too, but I also like putting together operable applications quickly.  It's really a matter of perspective/depth of the stack. 

As with SQL Azure, which are large shared instances of SQL2008, I'm going to assume that the AWS RDS's are large shared mySQL db servers - how they decide to make tuning transparent's all part of the PaaS portion.

Just as with http://aws.amazon.com/elasticmapreduce/, RDS adds depth to AWS's PaaS offering and I find that beneficial.

H

[Bernard Robertson-Dunn]

Question: At what level does/will scalability work in a cloud environment?

Take the case of a multi-tier/multi-platform application. ie multiple
web servers, multiple application servers and a DB layer.

How would scalability work?

At the individual application component level (eg OS instance?
At the whole of application level (ie overall response time)?

Who provides the monitoring and feedback capability? The user or the
cloud provider?

Or have I got this wrong?

--

Regards
brd

Bernard Robertson-Dunn
Canberra Australia
b...@iimetro.com.au

[gary mazzaferro]

Ok, how do you get away without having a dba? I don't see it.

You need someone to transfer the data, execute any additional programming, retrieve the results.. Then there is the master data issues... How does this happen without an admin ?

gary

[Sam Johnston]

On Tue, Oct 27, 2009 at 10:55 PM, gary mazzaferro <garymaz...@gmail.com> wrote:

Ok, how do you get away without having a dba? I don't see it.

You need someone to transfer the data, execute any additional programming, retrieve the results.. Then there is the master data issues... How does this happen without an admin ?

Even if you were foolish enough to pay a DBA contractor $1,000 an hour you're still in front if you use less than 70 hours a year (about 1/2 a dozen hours a month)... and that's not including on-costs of what 25%, as well as the additional risk of being responsible for their @%#^ ups.

Amazon's RDS offering is a great addition to their lineup and complements SimpleDB well (I can envisage applications using both)... it may not be as polished/tested as SQL Azure but it's a damn sight better than rolling your own.

Sam

PS If anyone actually wants to pay a DBA $1,000 an hour then I'm all yours...

[Guy Korland]

Hi Bernard,

Your question is very interesting since many people has this strange believe that moving to the cloud also yields better scalability.

And reality proves otherwise, in fact posting your standard three tier application to the cloud without adapting the programming model won't help you get better scalability.

For that we in GigaSpaces believes that only a combined shift can work, one which includes moving to a next generation application server (e.g. GigaSpaces XAP) which has a close integrating with infrastructure provider can really answer all your questions.

__________________

Guy Korland

www.gigaspaces.com/cloud/

--
Guy Korland

[G. Hussain Chinoy]

Gary,

That's not a bad point, but I see it as a matter of what scenario the service is after.

I don't think it's "getting away without having a dba" - I think it's a matter of where the line is for the necessity of a DBA (and also for another thread?)

For some things, including transferring data and "additional" programming it's well within a programmer's ability to throw down a few PowerShell scripts and push local SQL 2008 data to SQL Azure, add users, and configure the SQL firewall.  Not to mention using ORMs (Hibernate/NHibernate) to create a schema. Unfortunately, I haven't had the time to do the same with a mySQL/RDS app (this weekend, for sure), so I can't speak to the ease of Amazon's offering.

Now, automated backups, filegroups, san placement, log shipping, mirroring - that's (for me) over on the DBA side of the line (though, programmatically, it doesn't have to be).  For control over that, I guess I'd be leaning towards an AMI of my very own.

For a scenario where there're lots of hats worn, RDS/SQL Azure seems to fit that sweet spot.  In a larger corp / ent / gov where there's significant separation of duties, this might not fly - choosing an IaaS solution'll still have a sys admin type be giving special account access to a dba type who'll still have to work together to do the filegroup arrangement etc. and then work with a dev type for other account access, etc., etc. - "scaling"/"failing" over to the cloud'll have procedural line-crossing issues, regardless.

What I really like about the AWS RDS announcement is the possibility for "semi-automated" scaling based upon monitoring - I don't believe SQL Azure has either (it comes in 1gb and 10gb db flavors and I don't know of a way to spin up another and transfer based upon monitoring - all that'd have to be custom coded) - I can't recall if there're any wmi stats for SQL Azure, either.

H

[Sam Johnston]

On Tue, Oct 27, 2009 at 8:28 PM, James Watters <watter...@gmail.com> wrote:

That it lacked true auto scaling at launch told me they were just trying to get it to market before full azure launch.

Another sensible explanation (especially in light of the criticism they received today for stamping FathomDB out of existence) would be that they're leaving this missing link missing so that others (like RightScale) can take care of it...

Sam

[Reuven Cohen]

I know one thing is true, building a business atop of AWS is a very dangerous endeavour. 

r/c

[Reuven Cohen]

Let me restate that, building a business that relies on the AWS ecosystem alone, is a very dangerous endeavour. 

r/c

[Geir Magnusson Jr.]

I'm utterly perplexed what you might be talking about. What real
scaling can you do w/ MySQL w/o resorting to partitioning, sharding or
other techniques that break the relational model?

geir

[Sam Johnston]

You can scale vertically without a problem, and with the introduction of the new super-quadruple-extra-large-with-a-side-of-fries instances that gets you a lot further than it did yesterday (and with advances like the Tilera 100-core chip it will stretch even further tomorrow).

You are absolutely right though in that once you reach a certain point you need to go horizontal and that is where a good deal more complexity lies - can you even mount an EBS on multiple machines concurrently yet?

Sam

 

[Guy Korland]

In fact a long proved solution for scalability in big clusters and with high demands as you can easily get on a cloud is data access offloading.

Meaning using a distributed dynamically scale in memory relational cache.

And this what we (GigaSpaces) offer on EC2.

DB data partition is usually only works for the short term and hard to do. And a more scalable solution is usally needed. 

_________

Guy

www.gigaspaces.com/cloud

--
Guy Korland

[Mark]

At 3 cents per hour, that's just 72 cents per day. Why not?

On Oct 28, 6:23 am, Reuven Cohen <r...@enomaly.com> wrote:
> I would agree with that. The question is if the extra 3 cents an hour is
> worth the reduction in effort required to do it yourself.
>
> r/c
>
> On Tue, Oct 27, 2009 at 3:16 PM, gary mazzaferro

> <garymazzafe...@gmail.com>wrote:

>
>
>
> > My take away on Ruv's remarks is the overall recurring costs and price
> > differentials. The big question here is for the consumer to answer, "does
> > the TCO of RDS warrant consideration ?"  Whether the technology is ReST or
> > carrier pigeons and consumer "technical competency " is irrelevant to the
> > value proposition. If the service has traction, then automagic provisioning
> > and scaling should be fairly easy to add.
>
> > gary
>

> >> On Tue, Oct 27, 2009 at 12:43 PM, Sam Johnston <s...@samj.net> wrote:
> >> On Tue, Oct 27, 2009 at 5:37 PM, Alexis Richardson <
> >> alexis.richard...@gmail.com> wrote:
>
> >> Performance to disk may be improved, relative to running MySQL as an AMI.
>
> >> Lets not forget that my performance in widget-making and basket-weaving
> >> will certainly improve if I dont have to stuff around setting up and
> >> maintaining MySQL just to be able to use it too... or at least my profits
> >> will if I dont have to pay someone else to do it for me (except via the
> >> utility premium).
>
> >> Sam
>

> >> On Tue, Oct 27, 2009 at 4:35 PM, Geir Magnusson Jr. <g...@pobox.com>

> >> wrote:
>
> >> > Is there anything about this announcement that makes you believe this
> >> > is any more than a convenient way to choose disk size and machine size
> >> > and run a MySQL instance?
>
> >> > Data in the cloud doesnt necessarily mean scalable.  Think about the
> >> > DB portion of Azune as I understand it - there is the SQL part (put in
> >> > w/ the very astute recognition that not all data needs to scale, and
> >> > shoving in SQLServer/MySQL make life so easy for developers), and then
> >> > non-SQL part, which scales (or should).
>
> >> > geir
>

> >> >>> On Tue, Oct 27, 2009 at 10:24 AM, Sam Johnston <s...@samj.net> wrote:
> >> >>> On Tue, Oct 27, 2009 at 6:57 AM, tluka...@exnihilum.com <
> >> tluka...@exnihilum.com

[Mark]

Because it's a no-brainer, that doesn't have much incremental cost and
it moves the ball forward for cloud computing. Even a small step
forward is making progress.

On Oct 28, 7:04 am, Reuven Cohen <r...@enomaly.com> wrote:
> I think my question is how or why is it better?
>
> r/c
>
> On Tue, Oct 27, 2009 at 3:52 PM, Alexis Richardson <
>
>
>
> alexis.richard...@gmail.com> wrote:
>
> > That's a good point, but I still don't see how RDB can be 'worse'
> > economically than 'MySQL AMIs'.
>
> > On Tue, Oct 27, 2009 at 7:50 PM, Reuven Cohen <r...@enomaly.com> wrote:
> > > You guys are assuming the AWS magic just works. There is a lot more to
> > > scaling a DB then just uploading your SQL.  I doubt this is going to put
> > > DBA's out of business anytime soon.
>
> > > r/c
>
> > > On Tue, Oct 27, 2009 at 3:45 PM, gary mazzaferro <

> > garymazzafe...@gmail.com>

> > >>>>> On Tue, Oct 27, 2009 at 12:43 PM, Sam Johnston <s...@samj.net>

> > wrote:
> > >>>>> On Tue, Oct 27, 2009 at 5:37 PM, Alexis Richardson
> > >>>>> <alexis.richard...@gmail.com> wrote:
>
> > >>>>> Performance to disk may be improved, relative to running MySQL as an
> > >>>>> AMI.
>
> > >>>>> Lets not forget that my performance in widget-making and
> > basket-weaving
> > >>>>> will certainly improve if I dont have to stuff around setting up and
> > >>>>> maintaining MySQL just to be able to use it too... or at least my
> > profits
> > >>>>> will if I dont have to pay someone else to do it for me (except via
> > the
> > >>>>> utility premium).
>
> > >>>>> Sam
>

> > >>>>> On Tue, Oct 27, 2009 at 4:35 PM, Geir Magnusson Jr. <g...@pobox.com>

> > >>>>> wrote:
>
> > >>>>> > Is there anything about this announcement that makes you believe
> > this
> > >>>>> > is any more than a convenient way to choose disk size and machine
> > >>>>> > size
> > >>>>> > and run a MySQL instance?
>
> > >>>>> > Data in the cloud doesnt necessarily mean scalable.  Think about
> > the
> > >>>>> > DB portion of Azune as I understand it - there is the SQL part (put
> > >>>>> > in
> > >>>>> > w/ the very astute recognition that not all data needs to scale,
> > and
> > >>>>> > shoving in SQLServer/MySQL make life so easy for developers), and
> > >>>>> > then
> > >>>>> > non-SQL part, which scales (or should).
>
> > >>>>> > geir
>

> > >>>>> >>> On Tue, Oct 27, 2009 at 10:24 AM, Sam Johnston <s...@samj.net>
> > >>>>> >>> wrote:
> > >>>>> >>> On Tue, Oct 27, 2009 at 6:57 AM, tluka...@exnihilum.com
> > >>>>> >>> <tluka...@exnihilum.com

[yarapavan]

Exactly.

That is the question - How or Why is this RDS better than MySQL AMI's.

At the best, RDS seems to be a very automated VPS hosting with some
additional benefits.
RightScale also expressed the same in their blog post and are hinting
at Drizzle and Cassandra for real cloud databases!!

URL:http://www.rackspacecloud.com/blog/2009/10/28/how-do-you-put-a-
database-in-the-cloud/

Regards,
Pavan Yara

On Oct 28, 1:04 am, Reuven Cohen <r...@enomaly.com> wrote:
> I think my question is how or why is it better?
>
> r/c
>
> On Tue, Oct 27, 2009 at 3:52 PM, Alexis Richardson <
>
>
>
> alexis.richard...@gmail.com> wrote:
>
> > That's a good point, but I still don't see how RDB can be 'worse'
> > economically than 'MySQL AMIs'.
>
> > On Tue, Oct 27, 2009 at 7:50 PM, Reuven Cohen <r...@enomaly.com> wrote:
> > > You guys are assuming the AWS magic just works. There is a lot more to
> > > scaling a DB then just uploading your SQL.  I doubt this is going to put
> > > DBA's out of business anytime soon.
>
> > > r/c
>
> > > On Tue, Oct 27, 2009 at 3:45 PM, gary mazzaferro <

> > garymazzafe...@gmail.com>

> > >>>>> On Tue, Oct 27, 2009 at 12:43 PM, Sam Johnston <s...@samj.net>

> > wrote:
> > >>>>> On Tue, Oct 27, 2009 at 5:37 PM, Alexis Richardson
> > >>>>> <alexis.richard...@gmail.com> wrote:
>
> > >>>>> Performance to disk may be improved, relative to running MySQL as an
> > >>>>> AMI.
>
> > >>>>> Lets not forget that my performance in widget-making and
> > basket-weaving
> > >>>>> will certainly improve if I dont have to stuff around setting up and
> > >>>>> maintaining MySQL just to be able to use it too... or at least my
> > profits
> > >>>>> will if I dont have to pay someone else to do it for me (except via
> > the
> > >>>>> utility premium).
>
> > >>>>> Sam
>

> > >>>>> On Tue, Oct 27, 2009 at 4:35 PM, Geir Magnusson Jr. <g...@pobox.com>

> > >>>>> wrote:
>
> > >>>>> > Is there anything about this announcement that makes you believe
> > this
> > >>>>> > is any more than a convenient way to choose disk size and machine
> > >>>>> > size
> > >>>>> > and run a MySQL instance?
>
> > >>>>> > Data in the cloud doesnt necessarily mean scalable.  Think about
> > the
> > >>>>> > DB portion of Azune as I understand it - there is the SQL part (put
> > >>>>> > in
> > >>>>> > w/ the very astute recognition that not all data needs to scale,
> > and
> > >>>>> > shoving in SQLServer/MySQL make life so easy for developers), and
> > >>>>> > then
> > >>>>> > non-SQL part, which scales (or should).
>
> > >>>>> > geir
>

> > >>>>> >>> On Tue, Oct 27, 2009 at 10:24 AM, Sam Johnston <s...@samj.net>
> > >>>>> >>> wrote:
> > >>>>> >>> On Tue, Oct 27, 2009 at 6:57 AM, tluka...@exnihilum.com
> > >>>>> >>> <tluka...@exnihilum.com

[Wil Sinclair]

Anyone who's had to deal with maintaining and scaling a MySQL instance can easily answer that question. And this looks to me like an initial offering that will be expanded over the next few months.

What would concern me as a customer is the following statement:

"Periodically, the Amazon RDS system performs maintenance on the DB Instance. This maintenance can include planned MySQL patch roll-outs, as well as changes to storage or CPU class for the DB Instance that have not been implemented immediately. Maintenance typically requires a short downtime, and will occur within a user-definable default four hour window on a weekly basis." from http://docs.amazonwebservices.com/AmazonRDS/latest/DeveloperGuide/.

This is a lot of hand waving around a very important piece of information. Unspecified amount of downtime in a four-hour window that could happen every week isn't going to go over well with those running production, customer-facing sites. Many admins will be uncomfortable with random upgrades to their database. If it ain't broke, don't fix it. :)

BTW, it was a good move IMO to go with Plain Old MySQL as a relational data store option. Those running Drupal, Wordpress, or any number of popular OSS projects will be able to use it out-of-the-box.

Good thinking, Amazon.

,Wil
http://www.wllm.com

[tluk...@exnihilum.com]

>> "building a business that relies on the AWS ecosystem alone, is a very dangerous endeavour."

I'm just curious, Ruv.. do you know of any similar systems or "ecosystems" from any vendors that you can rely on 100% and not be in an equal amount of danger and at significant risk? Is there something unique about AWS that makes it especially dangerous or risky?

TJL

-----Original Message-----
From: "Reuven Cohen" [r...@enomaly.com]
Date: 10/27/2009 07:15 PM
To: cloud...@googlegroups.com
Subject: Re: Amazon Relational Database Service (RDS)

Let me restate that, building a business that relies on the AWS ecosystem alone, is a very dangerous endeavour. 

r/c

On Tue, Oct 27, 2009 at 7:12 PM, Reuven Cohen <r...@enomaly.com> wrote:
I know one thing is true, building a business atop of AWS is a very dangerous endeavour. 

r/c

On Tue, Oct 27, 2009 at 7:08 PM, Sam Johnston <sa...@samj.net> wrote:
On Tue, Oct 27, 2009 at 8:28 PM, James Watters <watter...@gmail.com> wrote:

That it lacked true auto scaling at launch told me they were just trying to get it to market before full azure launch.

Another sensible explanation (especially in light of the criticism they received today for stamping FathomDB out of existence) would be that theyre leaving this missing link missing so that others (like RightScale) can take care of it...


Sam