February 23, 2017 at 11:34 am
Jeff Moden - Thursday, February 23, 2017 11:26 AMEric M Russell - Thursday, February 23, 2017 11:07 AMThe cloud is just somebody else's data center. The tools are essentially the same as what you've always been using on-premises.Not when it comes to the former differences between Azure and "regular" SQL Server. Not when it comes to latency differences. And certainly not when it comes to price and possible security differences... especially when you think of it as "just somebody else's data center". At least not for me. 😉
So, somebody moved the T-SQL cheese and now we must learn some new keywords and rules? :rolleyes:
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 23, 2017 at 12:49 pm
What do the security problems have to do with "the cheese"?
--Jeff Moden
February 23, 2017 at 1:07 pm
Jeff Moden - Thursday, February 23, 2017 12:49 PMWhat do the security problems have to do with "the cheese"?
What security problem specifically?
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
February 23, 2017 at 3:07 pm
Eric M Russell - Thursday, February 23, 2017 1:07 PMJeff Moden - Thursday, February 23, 2017 12:49 PMWhat do the security problems have to do with "the cheese"?
What security problem specifically?
What cheese" are you talking about, specifically. 😉
As I'm sure you'll agree, any system connected to the internet can be attacked. As you stated, the "cloud" is just someone else's data center. "Data Center" also means that other companies have their data there. So, to answer your question, there's nothing specific. Instead, there's a raft of possible problems. We do quarterly penetration tests. What tests do they do an how often? What guarantees are there that they won't make a mistake and expose our data to one of the other companies? What guarantee is there that if one company is hacked, that the rest of us won't be as a result? They say they have redundant hardware. Is the data on that redundant hardware protected as well as it is on the main hardware? How do they screen their system admins? Do they encrypt all data at rest including backups? What are they using for such backups and where are those geographically located. What recourse do we have if they fail? How are the employee laptops protected if stolen? The list of questions goes on and on and if we disagree with any of those, we have no recourse. That includes changes behind the scenes which they protect in their contracts, if there is a contract.
It's not just me being a paranoid ol' DBA either. I've worked with companies that used 3rd part data centers and I've witnessed some pretty nasty things. One company did full backups once per week and only did transaction log backups once per day. They also expected the company to pay for all the extra hard disk usage that caused never mind the risk of losing more than 24 hours of data. They had no clue that doing more backups would actually keep the log file size down, or ... maybe they did and that's why they didn't do the backups more often.
Another company had a 3rd party data center that bragged about how "sure" their backups were. Then, they actually caused an incident where a whole server's worth of databases were lost. Despite their claims of doing SAN replication to a remote server and having tape backups and, and, and... they couldn't recover the data for the week before the incident that they caused. It took 40 people a bit more than a week going through other sources to try to reproduce the lost week's worth of data and transactions.
So... nothing specific as you ask. Rather it's more of a general disgust and total lack of trust.
--Jeff Moden
February 23, 2017 at 10:20 pm
I personally think it's a great tool. I'm currently migrating over to Azure Data Warehouse myself. I'm encountering the normal flux of learning new technologies and flows as I transition into Data Factory, Polybase and more. But, it's been fun and pretty rewarding because of the benefits. For example, one benefit for me is being able to load massive quantities of data to one location that can scale out as opposed to up -- allowing me to query a billion records pretty efficiently.
But yes, they are all tools, as they are on-premise too. They all have their pros and cons that help set them apart from one another.
I think another cool thing the cloud is offering is the ability to fully control my infrastructure. I'm in a large organization that has a global IT team. Most of what we do on-premise is through their control. These cloud platforms are becoming easier for those teams to put it in our control too. Having the ability to quickly spawn a VM from a list of approved images for a few hours is pretty killer. No tickets, no middle-men, no problem. Pretty awesome stuff if you ask me.
February 24, 2017 at 8:20 am
Eric M Russell - Thursday, February 23, 2017 9:55 AMRod at work - Thursday, February 23, 2017 8:04 AMVery interesting article. Even in state government, we're experimenting with using Azure. (Unfortunately I'm not involved. :crying: ) What I'm curious about is hybrid cloud solutions. I'm hearing that a lot. For those people with experience working with a hybrid, what's it like? Do you put some data in the cloud and leave the rest on-prem, that are all working with the same application? I'm envisioning it to be something like keeping ePHI data on-prem, because you feel like it would be better for regulation compliance. Then maybe putting pharmaceutical data into the cloud, where its more generic. Then whatever application you've got works against both data stores? Or is it the case that some data is in the cloud and the application(s) that work against it are entirely separate from other on-prem data with separate app(s)?A hybrid cloud architecture could by any of the above or more. One thing you don't want to do is have a functional dependency between on-prem databases and cloud databases. Virtually, a cloud hosted instance looks and functions just like an on-prem instance, but practically you will encounter issues with bandwidth usage charges and latency if you're retrieving mass amounts of data back to on-prem applications. The application and the database should be co-located, or have a service oriented architecture for more granular data exchange, or perhaps keep highly used data replicated between the two environments.
I hadn't thought of that Eric, thanks! I can see now how that would be very important. If your data center goes down or your cloud service has an outage, it would be best to have some functionality in place so that your users could still "get by" and do some useful work. Thanks again!
Kindest Regards, Rod Connect with me on LinkedIn.
February 24, 2017 at 9:36 am
Rod at work - Friday, February 24, 2017 8:20 AMEric M Russell - Thursday, February 23, 2017 9:55 AMRod at work - Thursday, February 23, 2017 8:04 AMVery interesting article. Even in state government, we're experimenting with using Azure. (Unfortunately I'm not involved. :crying: ) What I'm curious about is hybrid cloud solutions. I'm hearing that a lot. For those people with experience working with a hybrid, what's it like? Do you put some data in the cloud and leave the rest on-prem, that are all working with the same application? I'm envisioning it to be something like keeping ePHI data on-prem, because you feel like it would be better for regulation compliance. Then maybe putting pharmaceutical data into the cloud, where its more generic. Then whatever application you've got works against both data stores? Or is it the case that some data is in the cloud and the application(s) that work against it are entirely separate from other on-prem data with separate app(s)?A hybrid cloud architecture could by any of the above or more. One thing you don't want to do is have a functional dependency between on-prem databases and cloud databases. Virtually, a cloud hosted instance looks and functions just like an on-prem instance, but practically you will encounter issues with bandwidth usage charges and latency if you're retrieving mass amounts of data back to on-prem applications. The application and the database should be co-located, or have a service oriented architecture for more granular data exchange, or perhaps keep highly used data replicated between the two environments.
I hadn't thought of that Eric, thanks! I can see now how that would be very important. If your data center goes down or your cloud service has an outage, it would be best to have some functionality in place so that your users could still "get by" and do some useful work. Thanks again!
I was thinking more along the line that: you shouldn't remote join between on-prem tables and cloud hosted tables, because it would be verrry slow, so you need to have reference tables, person table, or whatever replicated to the cloud. The same goes for remote joining tables between on-prem instances, but with the cloud it's an even greater performance hit.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 7 posts - 16 through 21 (of 21 total)
You must be logged in to reply to this topic. Login to reply