May 9, 2012 at 7:49 am
sku370870 (5/9/2012)
You've spend hundreds of hours developing. A lot of your business logic is in your stored procedures and functions. You can't afford SQL Server hosting of your own. You use this service - your web site gets popular ... what's to stop someone at Amazon ripping off your code?
That's just silly. I'm sure it happens, but when you have Netflix, AirBnB, Active.com, Ericsson, The Guardian, and more up there, all of whom have code worth stealing and are popular enough services to warrant it, your fears don't make any sense.
I've written it before, and I'll write it again. Almost everything you write in code is not some IP that's worth stealing or protecting. The integration of it all with your service is what your business sells. Worrying about anything else is naive, IMHO.
May 9, 2012 at 7:49 am
SQL Server Central is "a community service from redgate" as such it seems entirely reasonable for us to deal with an occasional marketing related blog post here for a redgate product or service.
As someone who does web development and thus often uses third party hosting where I control neither the web or database servers, this new service sounds like it could be useful.
May 9, 2012 at 7:52 am
Markus (5/9/2012)
Do you control the backups/restores? Is SQL Server patched automatically if a service pack or security patch comes out? If so, and it causes issues with your application how do your roll it back?I just do NOT like the thought of all of my data in the cloud where I have no idea if anyone else has access to it and I have no way of knowing this.
You can specify if you want patches applied automatically, and you can specify a backup window. They do a quiesce of writes and a snapshot of the server. They also do log backups and point in time recovery is available. Jeremiah Peschka wrote on it here: http://www.brentozar.com/archive/2012/05/sql-server-rds/
Please don't worry about someone in Amazon accessing your data among their thousands of virtual machines. It's much more likely a co-worker or friend gets access to your machine and takes the code/data if you get popular.
Plenty of companies, popular ones, have code and data in the cloud. I would not put financial, medical, PII info up there, mostly because of liability, but there are lots of apps where it would work fine. Like SQLServerCentral.
May 9, 2012 at 7:53 am
i think it would be a good location for general developer databases. less server maintenance. also good for putting databases on the web that you have no care to maintain. other than that, production should be served internally or your own managed DMZ server and maintained properly where you KNOW it will be backed up, updated, etc.
could be a great way to test which platform to use for a project. databases will be trashable with great cost to it especially man-hours cleaning it up.
May 9, 2012 at 7:59 am
george 86905 (5/9/2012)
First of all, I love this site, and therefore, by extension, I love Steve Jones, I suppose. You guys have saved me many hours of deadends and the hours some of you spend on editing your posts and example code is amazing.
Thanks, and glad we could help you.
I have to say this post really does read like marketing copy and to my mind that makes the poster pretty much a shill. I wonder if I'm going to see Amazon RDS banner ads on my Google search pages now? This press release-like post does not note a single negative aspect of Amazon's new product--and if course it is just another product. One would think that an actual informative post might also mention the costs or at least provide a link to a menu of cost options.
It's an opinion piece. I like the idea of the service and highlighted those things that I see. I think I wrote "There are a few restrictions at the instance level since you don't have access to the underlying host OS". My intention was not to provide a complete review of the service, but talk about what it does.
Cost wasn't finalized when I wrote this, so I left it out. It is up now: http://aws.amazon.com/rds/#pricing
Not trying to be totally negative without offering an alternative. What about this? Now that this 'news' is out there, what about an objective product comparision showing the other main players in this space and how they all rank along the most important decision vectors?
Not a bad idea. Though hard to compare services that aren't the same. SQL Azure doesn't offer SQL Server 2008 R2 or SQL Server 2012. It's some weird hybrid superset/subset combination. We could compare EC2 and a few other providers that let you see costs and capacities. I'll look into it, but it's challenging as the costs and services are evolving so rapidly.
May 9, 2012 at 8:02 am
sturner (5/9/2012)
"...And they'll even handle the backups automatically for your new database. "making backups is only 1 tenth of the infrastructure involved with hot standby-failover or DR procedures which typically have a lot more to it than just the database server itself. In our case it is dozens of database servers
Then this doesn't fit for you. Certainly once you reach a certain scale of server and application, this doesn't make any sense, especially financial sense.
However if you are smaller, a couple servers, this works. I can imagine if this were available in 2000, Facebook might have started on AWS.
May 9, 2012 at 8:04 am
hakim.ali (5/9/2012)
Which brings me to my point: any word on how the two compare? Amazon RDS vs SQL Azure.
Not yet, and I haven't done much probing in Azure. It's worth looking, but hard since Azure is rev'ing their system every 3-4 months. Right now it's a strange superset/subset of SQL Server out of the box, so it's hard to know. The RDS offering is most of SQL Server 2008 R2 (some OS limitations, no Windows accounts, no file system access, things like that).
Both are good services for your application if it fits in the model of the cloud.
May 9, 2012 at 8:08 am
Aaron N. Cutshall (5/9/2012)
Does it have the same physical limitations as SQL Azure? If so, then what's the advantage of their approach?
I don't have an exact comparison, but SQL Azure isn't SQL Server 2008 R2 or SQL Server 2012. It's a strange mix of features and limitations. So ultimately you need to test your code and develop in the cloud. The RDS offering is a standard SQL Server 2008 R2 database. The instance stuff is somewhat restricted since you can't access the host at all, but inside a database, it works just like Dev edition on your local machine. So development and testing can be done locally. That can be a big win.
Several people have questioned the security aspect wondering if Amazon would just help themselves to the code or data in the instance. I
They could, sure, but in practice this doesn't happen. It can happen in any hosted situation. In 1998-2000, tons of people worried about this with their websites, with ASPs, with co-location facilities. In practice, it was unfounded worry and nobody gives it a second thought. Obviously your data might have regulatory issues if it's in the cloud. If so, don't do it. If not, consider it.
May 9, 2012 at 8:09 am
Steve Jones - SSC Editor (5/9/2012)
Then this doesn't fit for you. Certainly once you reach a certain scale of server and application, this doesn't make any sense, especially financial sense.
However if you are smaller, a couple servers, this works. I can imagine if this were available in 2000, Facebook might have started on AWS.
Agreed, and for that reason I do like the concept and feel confident it will find many customers going forward.
The probability of survival is inversely proportional to the angle of arrival.
May 9, 2012 at 8:13 am
CriticalStatus (5/9/2012)
other than that, production should be served internally or your own managed DMZ server and maintained properly where you KNOW it will be backed up, updated, etc.
???
Served internally is necessary in some cases, but do you have any idea how many people don't do this. How many co-location facilities manage stuff? How many VMs are in use in rented spaces for production work for various companies? How many people outsource their email, which is just internal data?
AWS offers lots of these services, including virtual private networking.
It's not for everyone, which I've said, but if it fits your environment, I think you'd be negligent if you didn't consider it just because it's a "cloud" service.
May 9, 2012 at 9:23 am
WOW Steve - it seems that you really hit a 'hot' button on this one ...
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
May 9, 2012 at 9:39 am
Steve, as I said, I don't see anything that was worth an article or editorial about. It reads like a thin marketing pitch.
"Imagine being able to connect to SQL Server on a remote machine"
I connect to every SQL Server instance on a remote machine. This is how I connected to SQL Server instances since before it was a Microsoft product. You don't run a production environment on your laptop, so every SQL Server you use, except maybe a local development instance, is going to be remote.
"without having to administer the underlying OS"
I rarely have to admin the OS and I only have to do this when I don't have a Sys Admin around. So, again, you've just described what just about everyone already does.
"and without having to change the database code that you build against your local instance?"
I have never and I do mean never had to change my database code to deploy it to production. I develop against a SQL Server instance and I deploy to a SQL Server instance. This is just a full-blown SQL Server instance. I would hope that you didn't have to change your code before deploying it. Now, if you're trying to compare SQL Azure to a regular SQL Server instance, say so. Because what you describe doesn't happen right now.
"allowing you to developer and test the same code you will deploy to the cloud"
"The cloud" - a bunch of marketing BS. These are still machines, sitting in a data center, being managed by someone, that you deploy applications to. All "the cloud" means is that someone else owns the machines, the machines are VMs instead of physical machines, and the wire you connect to them on is a bit longer than if it was sitting in a server room down the hall from your desk. If your organization has already virtualized every machine in your environment, then "the cloud" does absolutely nothing that your organization hasn't already done. It just takes everything you built and sticks it in another data center. It's a bunch of marketing, BS hype. And again, if this is a SQL Server instance, of course, it is going to be the same code as I have locally, because, it IS A SQL SERVER INSTANCE.
"In a few minutes, you have an instance that you can connect to and use."
This has been true for almost 2 decades. It was only a few minutes to have SQL Server installed bare metal on a server before we could connect to it and use it. It's only a couple minutes to drop a clone of a VM that has SQL Server in it and use it. This is news, how?
"Specify a few parameters, and Amazon will handle the rest."
I specify a few parameters and my Sys Admins can install SQL Server for me. So, I just specified a few parameters to someone else. Just last night, I specified a few parameters to my hosting provider, which isn't Amazon, and I had a database that I could use for a website.
"We've tested the Red Gate Software tools against RDS and they work just like they work on any other instance"
Well, great. I would hope so. It would be pretty bad if the Red Gate tools randomly worked against SQL Server instances. Connect to instance A down the hall from your desk and they work just fine, connect to instance B running in your remote data center and they suddenly don't work. You said this is the SAME SQL Server code that someone would install on their own production servers. Why would you expect things to not work?
"And you can leverage your local SQL Server 2008 R2 Developer instance to develop code that will work, without worrying about the services in the cloud"
Same comments as above. An instance is an instance is an instance. This isn't SQL Azure, this is a regular SQL Server instance. So, I would certainly hope so.
"It's a little scary to me to think about letting go of the control of managing my own database"
I can see where this might be interesting if your only experience is having your hands wrapped around all of your SQL Servers with absolute control. But, you'd be in the tiny minority. Very few DBAs control the hardware their instances run on or even have access to RDP to or manage anything in the OS. You're also not giving up control of your database. You're giving up control of your INSTANCE. So, you can't tweak sp_configure, create jobs, or do things at an instance level, so what?
Almost 20 years ago, I spun up mssqlserver.com at Data Return. It had a SQL Server on the back end of the website. So, I had a hosting plan with a SQL Server database that I could do anything with. I could connect to it remotely and deploy anything I wanted into the database. I could even create an application that ran on my desktop, connected to my database at Data Return, and worked with the data. After all, Enterprise Manager and Query Analyzer, running on my desktop, connected to my database "in the cloud" just fine. I shared the instance with a bunch of other people who also had databases on that instance. If I needed the capacity, I could purchase a higher level plan with a dedicated instance. If I needed more storage, I could purchase more storage on the plan. If I needed even more capacity, I could purchase a plan with higher server specs.
So, again, the whole article reads as a marketing press release from Amazon. Congratulations Amazon, you've just caught up to what 1000s of hosting providers have been doing for almost 20 years.
Michael Hotek
May 9, 2012 at 10:17 am
hosting is not new, SQL on VM is not new, RDP and many other TLA is not new.
What's new is that Amazon is offering another product. For those whom this product makes sense, it's another example of Amazon identifying an audience and catering to a niche market. That's what Amazon has done well since they sold only books. Now they sell pretty much anything.
If the hardware lives onsite then I am responsible for power, cooling, backups, etc. That's about as fun to me as taking care of the circus elephant; for the few performance tweaks that come from hands-on the hardware it's not worth the maintenance concern (to me). With all this care-taking allocated to someone else, I don't have to worry about it. Is that any different than anybody else's hosted services? No, but Amazon is a trusted brand and I expect at their level of scale they are able to provide this service more efficiently than many smaller hosting companies.
I would be excited by on-demand resource allocation that might be possible in a "cloud" environment. It seems the current pricing strategy is to spec a VM as if it was a physical resource and pay a flat rate at each tier. I would like to see variable configuration allow a minimum configuration for normal operations then pay on-demand for more cores and more memory while doing huge ETL processing or intensive analytics. How many report/processes do we run that take double-digit hours to complete? We inform stakeholders that it'll take X hours to complete the request. Wouldn't it be nice to say, "it could be as quick as you are willing to pay for at this moment" and allocate resources to make that happen? I can't afford to keep that much resource on-hand all month for a few hours worth of peek utilization; Amazon (among others) can.
May 9, 2012 at 10:21 am
Steve Jones - SSC Editor (5/9/2012)
Aaron N. Cutshall (5/9/2012)
Does it have the same physical limitations as SQL Azure? If so, then what's the advantage of their approach?I don't have an exact comparison, but SQL Azure isn't SQL Server 2008 R2 or SQL Server 2012. It's a strange mix of features and limitations. So ultimately you need to test your code and develop in the cloud. The RDS offering is a standard SQL Server 2008 R2 database. The instance stuff is somewhat restricted since you can't access the host at all, but inside a database, it works just like Dev edition on your local machine. So development and testing can be done locally. That can be a big win.
. . .
The most significant difference between AWS and Azure is that AWS is Infrastructure as a Service (IaaS) while Azure is Platform as a Service, or PaaS.
AWS does not back up your database: they back up your VM which may have state.
Azure clones your stateless machines; for each machine that you create, Azure creates two fully maintained clones, one of them in a different location but under the same jurisdiction. (Meaning that if your primary site is in San Antonio, copies of your machines will likely be in Chicago.)
Azure's load balancers are invisible. If your have one SQL VM and it becomes overloaded, Azure activates one of your clones and creates another one. (And dinks you for an overage.)
If your business shoots through the roof, you can upgrade your subscription and get say 10 machines, automatically with 20 clones, in just a few minutes, and they will be load-balanced at the moment when they come online.
With AWS you have to set up those machines as well as load balancers. I have not tried but I guess that would not happen in minutes.
BTW, it looks that Azure is no longer Azure SQL but Azure but Azure Database, check http://www.neowin.net/news/microsoft-renames-azure-services.
May 9, 2012 at 11:07 am
I don't have any developers. I write the lot.
Viewing 15 posts - 16 through 30 (of 39 total)
You must be logged in to reply to this topic. Login to reply