0 0 0 0 0 0
0 0
0forget pwd? | Join now
Online: Member 2 Guest 83

MSN: test104tw@hotmail.com
  • CISA Q & A 680 Questions. (2/1/2019)
  • ISC2 CISSP Q & A 1367 Questions. (1/31/2019)
  • CISCO 300-101 Q & A 579 questions. (1/29/2019)
  • CISCO 300-115 Q & A 391 questions. (1/28/2019)
  • CISCO 300-135 Q & A 213 questions. (1/28/2019)
  • Microsoft 70-740 Q & A 165 Questions. (1/24/2019)
  • Microsoft 70-411 Q & A 301 Questions. (1/18/2019)
  • Microsoft 70-333 Q & A 67 Questions. (12/25/2018)
  • Microsoft 70-332 Q & A 97 Questions. (12/19/2018)
  • Microsoft 70-414 Q & A 160 Questions. (12/7/2018)
  • Microsoft 70-764 Q & A 100 Questions. (12/5/2018)
  • Microsoft 70-743 Q & A 134 Questions. (12/3/2018)
  • Microsoft 70-743 Q & A 145 Questions. (11/27/2018)
  • Microsoft 70-765 Q & A 155 Questions. (11/22/2018)
  • EC-Council 312-49 V9 Q & A 517 Questions. (10/30/2018)
  • CWNP CWNA107 Q & A 192 Questions. (10/25/2018)
  • ISC2 CISSP Q & A 1175 Questions. (10/12/2018)
  • ISC CSSLP Q & A 210 Questions. (10/12/2018)
  • ISC GAP Q & A 235 Questions. (10/12/2018)
  • Microsoft 70-461 Q & A 304 Questions. (10/11/2018)
CheckCode: 0

Suggestions & Questions:





When (and why) to move SQL Server to the cloud[4/7/2010]
[TextSizeBig Middle Small][Print]
These days, the cloud is one topic that seems to be on everyone's lips. There's talk about email in the cloud, storage in the cloud, software in the cloud, and of course, SQL Server in the cloud.

We aren't talking about some generic database, mind you, but a full-fledged SQL Server like the one you already know and love. It's called -- as you probably know -- SQL Azure Database, a part of Microsoft's Windows Azure cloud computing platform.

There's a straightforward migration path to moving your data into the cloud, and in many cases your applications won't necessarily need a ton of rewriting to make them pull their data from there. Ignoring the application programming issues for just a moment, ask yourself this: "When is a move to the cloud right for my company?"

Cloud computing platforms - including Windows Azure, Amazon S3 and so on - have two primary benefits: ubiquity and elasticity. If either or both of these benefits are something you've had difficulty achieving through other means, then a move to the cloud can start to look attractive.

The ever-ubiquitous cloud

Ubiquity simply means that the cloud is everywhere. Even in countries where your company might have a tough time securing private WAN bandwidth, Internet bandwidth is often more readily available, faster, and less expensive. By moving your data to the cloud, you make it easier for any authorized user to access that data from almost anywhere on the planet. Heck, with today's new in-flight Wi-Fi services, employees could run their corporate applications on an airplane, accessing the cloud wirelessly.

This ubiquity can eliminate the need to mess around with one of SQL Server's more frustrating features -- replication. Today, globally-distributed companies are forced to either have a single SQL Server back end with expensive WAN links, or multiple distributed SQL Server installations that replicate data with each other. While SQL Server's replication capabilities are good, maintaining multi-server merge replication can test any administrator's patience and abilities.

With the cloud, on the other hand, there is no replication -- there is only the cloud. Your data is everywhere. The cloud itself takes care of replication through pure back-end magic, using techniques and technologies not available to mere mortals such as ourselves. The great part about it is that you pay nothing extra for that built-in, magical replication. Most cloud platforms charge by the amount of data you're storing and transferring, not by how distributed your data is across the cloud network.

Keeping an elastic database

Elasticity, in its simplest form, means scalability. If you have a really heavy-duty application that uses SQL Server as a back end, you may have struggled to create a SQL Server infrastructure capable of handling the workload. Once you've scaled a SQL Server up as far as possible using the biggest and baddest 64-bit hardware you can afford, you're then stuck with scaling out, which on SQL Server requires a lot of planning and expertise. Distributed partitioned views, partitioned databases, and special replication setups are all possible, but they require a lot of ongoing maintenance and typically some pretty serious re-architecting of your applications.

In the cloud, however, scalability is built-in. Using its ability to magically replicate your data across its internal network, the cloud can automatically assign more computing resources as needed, with no theoretical limit on how much additional power can be brought to bear on your application. You pay for what you use, meaning the bigger load you place on the cloud-based database, the more you pay. Still, that may be cheaper than continually upgrading and adding servers in your own data center.

The cloud offers a lot of promise for bigger, more available, and highly distributed SQL Server databases - you just need to watch for the right opportunity.