January 2, 2011 at 9:21 pm
Comments posted to this topic are about the item Clouds Are In our Future
January 2, 2011 at 11:18 pm
I'm navigating the cloud issue at this very moment. My biggest concern is that the tools that are currently available fall short when one is faced with managing sql hosted in a cloud. Microsoft should overwhelm the community with information regarding the subject of sql hosted in clouds. Configurations that yield desired results in a dedicated cluster scenario should also have counterparts in the cloud space.
BTW...Sql Server Central Rocks!!!! I am a more informed .Net DEVELOPER as a direct result of my participation here. Every data-driven application I've ever worked on has benefited from informed decisions. Solid data stores and data access layers have left several challenges solved in my wake. Its a great feeling knowing that something will work and the only issue will be how much gold plating can I get on the application!
January 3, 2011 at 12:56 am
There is one additional major concern to bring up (and it has been done frequently already in other articles/threads): data security.
Currently, most companies have a strict regulation who has direct access to the data the company's dealing with. The people having direct access to the data (including domain admins) usually are known by name and (hopefully) trustworthy. There are firewalls to protect the data from unauthorized access from the "outside" and usually even within a company. And both for very good reasons.
In "the cloud" the data are some sort of "public". Not only you need to take of the securitiy issues at your cloud host. You also need to pay attention to the way you connect to the cloud.
January 3, 2011 at 5:48 am
There are a myriad of problems including security. What about accountability? IMHO service bureaus and ASPs aren't as reliable as need be as the more common utilities like electricity and water. What happens when your cloud provider outsources? Or downsizes their technical staff to increase their bottom line at your service quality expense? How do you audit them?
January 3, 2011 at 6:36 am
Heh... we found out how to guarantee hard disk capacity being available for the next 5 years... all we had to do was cleanup the crap the old "DBAs" left behind. So far and in a very brief period, we've recovered nearly 15 Tera bytes (NOT a typo!) on the SAN and that was just for 4 rather small application servers. It only took us 20 minutes to find the first 4.6 Tera Bytes of wasted space.
Guess what such wasted space on the cloud would do to bill you receive?
I realize the cloud is available for other reasons but the primary goal is to make money with cloud services. There are a whole lot of people who will help them meet that goal when they really don't need to. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2011 at 6:43 am
If someone doesn't already have enough reasons to avoid the cloud, here is a recent post that may contain some additional reasons you may not have been aware of...
http://www.sqlservercentral.com/Forums/Topic1041653-392-1.aspx
Rumor also has it that you can't do a SELECT/INTO on a Temp Table in Azure. Does anyone happen to have a convenient list of all the things you can't do in Azure that you can do in a real instance of SQL Server?
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2011 at 8:23 am
Lutz, totally agree that security is a concern, especially if the physical implementation of the cloud is in a different country. Not arguing that it fits all cases, just that we should look at it in much the same way we consider Standard vs Enterprise Edition, or internal hosting vs a colo.
January 3, 2011 at 8:27 am
Jeff, I think the corollary to your point is that if you get a bill for something each month, you're more likely to manage it! Plenty of ways to do dumb things regardless of where the data is hosted.
Absolutely the cloud is a paid service and designed to deliver a profit to whoever is hosting it. Just as in my earlier reply, if we just put this on the menu of options where each has pros and cons, there are times when the cloud will - eventually - make sense. I thinking having a cost associated is healthy for businesses over the long term, and each business can decide to stay local, go cloud, or some sort of hybrid.
Their bet on the cloud is that the economies of scale/automation leave sufficient margin to be interesting to both sides. If we can see some competition in that space then we might wind up with some very interesting pricing options.
January 3, 2011 at 9:06 am
Jeff Moden (1/3/2011)
If someone doesn't already have enough reasons to avoid the cloud, here is a recent post that may contain some additional reasons you may not have been aware of...http://www.sqlservercentral.com/Forums/Topic1041653-392-1.aspx
Rumor also has it that you can't do a SELECT/INTO on a Temp Table in Azure. Does anyone happen to have a convenient list of all the things you can't do in Azure that you can do in a real instance of SQL Server?
The cloud fits in places, but there are limitations right now. The SQL Azure team is enhancing it quickly, and I believe that all future tools, i.e. SSMS, will work seemlessly with Azure and non-cloud databases.
Here's a list of some limitations: http://msdn.microsoft.com/en-us/library/ee336245.aspx
January 3, 2011 at 9:53 am
Andy Warren (1/3/2011)
Lutz, totally agree that security is a concern, especially if the physical implementation of the cloud is in a different country. Not arguing that it fits all cases, just that we should look at it in much the same way we consider Standard vs Enterprise Edition, or internal hosting vs a colo.
It seems like we're in a perfect "it depends" situation. I'm not ignoring Azur. But all I'd store there would be at the same security level like the stuff I would post on twitter/facebook ( = only stuff I'd allow to be known in public). Not even my stamp collection would go there (What if I had a "Blue Mauritius"? For sure that wouldn't go public!) ...
As a brief review of the history of data security as I see it right now (using a picture from the middle age):
We started with timber castles (database with limited security options, hosted on servers with no real firewalls).
Now we have castles with moat (multi-layer security from a firewall down to row -level encryption).
And if it's trendy right now to build cloud castles, then let it be. :-P:-P 😀
January 3, 2011 at 10:10 am
One issue I never see mentioned are leagl requirements for auditability. There are many types of database-centric applications that are legally required to keep data on premises; for example, pharmacies. The first thing pharmacy auditors do is that they lock the door and then they disconnect the computer. Brokerage systems must keep their databases within the jurisdiction that licensed them.
Like or not, for tyhese apps you would have to change the law before you would even consider security.
January 3, 2011 at 6:13 pm
Steve Jones - SSC Editor (1/3/2011)
Jeff Moden (1/3/2011)
If someone doesn't already have enough reasons to avoid the cloud, here is a recent post that may contain some additional reasons you may not have been aware of...http://www.sqlservercentral.com/Forums/Topic1041653-392-1.aspx
Rumor also has it that you can't do a SELECT/INTO on a Temp Table in Azure. Does anyone happen to have a convenient list of all the things you can't do in Azure that you can do in a real instance of SQL Server?
The cloud fits in places, but there are limitations right now. The SQL Azure team is enhancing it quickly, and I believe that all future tools, i.e. SSMS, will work seemlessly with Azure and non-cloud databases.
Here's a list of some limitations: http://msdn.microsoft.com/en-us/library/ee336245.aspx
Good link. Thanks, Steve.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 3, 2011 at 8:13 pm
Below is the official Microsoft doc on limitations. It seems like every which way I turn, I bump up against SOME limitation. Then there's the lack of tooling. R2 FINALLY adds object browser support to SSMS for Azure DBs, but with MANY limitations. Moving db's around between Azure and production/qa servers is very frustrating as well. Although, I came across the SQLAzureMigrationWizard, which is a wonderful (free) tool. I'm trying to talk my company down. SQL Azure feels like a "toy". Personally, I think MS rushed SQL Azure out the door before it was ready. I think SQL Server "as a service" is proving much more difficult than MS thought.
And to Steve's point, my company was wondering why we are getting $1000.00 bills for Azure. Very simple all our developers/testers are using the cloud db as if it was local... jeez. $1000.00 per month buys some pretty nice REAL SQL Server space somewhere!
.
January 10, 2011 at 6:51 pm
BSavoie (1/3/2011)And to Steve's point, my company was wondering why we are getting $1000.00 bills for Azure. Very simple all our developers/testers are using the cloud db as if it was local... jeez. $1000.00 per month buys some pretty nice REAL SQL Server space somewhere!
When you change the way you host and deploy applications, you need to change the way that you develop them. There are a number of tools that your developers can use to mimic an Azure environment on their local machines instead of burning through company money in production. There are going to be some growing pains, it stinks that yours ended up costing money.
Jeremiah Peschka
Microsoft SQL Server MVP
Managing Director - Brent Ozar PLF, LLC
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply