June 26, 2018 at 12:09 am
Comments posted to this topic are about the item Azure DWH part 28: The ASDW enemies
June 26, 2018 at 4:49 am
Enemies?
June 26, 2018 at 5:59 am
Romac - Tuesday, June 26, 2018 4:49 AMEnemies?
Well, I think he just meant competitors.
Unless it has changed recently, Azure Data Warehouse still retains the data in it's own storage where Amazon Redshift does not. In meaning, you have to constantly read in the data from your S3 buckets everytime you start the service where Azure Data Warehouse retains it always.
The big thing about BigQuery is it operates similar to Azure Data Lake Analytics. They pretty much look and feel the same, but Azure Data Lake Analytics is not restricted to just one service. You can hook it up to Azure Data Lake Store, Azure Data Warehouse, and more. I view it as a beefed up BigQuery where you also only pay for the duration of the query.
June 26, 2018 at 11:08 am
Romac - Tuesday, June 26, 2018 4:49 AMEnemies?
It's just a headline grabber. He uses the more appropriate term "competitors" at the end of the piece.
June 27, 2018 at 3:39 am
Hi,
We (the data team) at my company actually just did a number of short Proof of Concepts (POC's) on this looking at SQLAzure, SQL Azure DW and RedShift and we concluded that none of them was right for us at this point in time.
We found that as we are a MS team now (both data and apps) that moving to anything else would be a huge undertaking and in our case the cost massively outweighed the benefit.
With regards to SQL Azure and AzureDW we found that limitations in functionality meant that the costs again outweighed the benefits (for now).
I'd be happy to share the POC documents if anyone wants them.
Thanks,
Nic
June 27, 2018 at 5:51 am
NicHopper - Wednesday, June 27, 2018 3:39 AMHi,We (the data team) at my company actually just did a number of short Proof of Concepts (POC's) on this looking at SQLAzure, SQL Azure DW and RedShift and we concluded that none of them was right for us at this point in time.
We found that as we are a MS team now (both data and apps) that moving to anything else would be a huge undertaking and in our case the cost massively outweighed the benefit.
With regards to SQL Azure and AzureDW we found that limitations in functionality meant that the costs again outweighed the benefits (for now).
I'd be happy to share the POC documents if anyone wants them.
Thanks,
Nic
Can you provide a high-level on why? Like what are the top reasons that really stood out the most?
June 27, 2018 at 7:10 am
xsevensinzx - Wednesday, June 27, 2018 5:51 AMNicHopper - Wednesday, June 27, 2018 3:39 AMHi,We (the data team) at my company actually just did a number of short Proof of Concepts (POC's) on this looking at SQLAzure, SQL Azure DW and RedShift and we concluded that none of them was right for us at this point in time.
We found that as we are a MS team now (both data and apps) that moving to anything else would be a huge undertaking and in our case the cost massively outweighed the benefit.
With regards to SQL Azure and AzureDW we found that limitations in functionality meant that the costs again outweighed the benefits (for now).
I'd be happy to share the POC documents if anyone wants them.
Thanks,
Nic
Can you provide a high-level on why? Like what are the top reasons that really stood out the most?
Sure,
RedShift's big con was it uses a new skill set so the team would all have to learn it, we would then have to change all of our code (app and DB) to make them work. That's over 1000 stored procedures, across 10 core servers for what benefit.
Azure (including DW) - We like AzureDW a lot but you couldn't do linked server queries or even cross database ones (at the time we tried - perhaps you can now). This would have meant a massive change to us.
In both cases the cost in time just outweighed the benefits, so for now we are going down the SQL2017 running on a VM route and we will port over to Azure(DW) in the future when we feel both fit our needs a little better.
At the end of the day its largely down to your environment, needs and problems. If we had the time and the appetite to do months of work or we were building from the ground up we possibly would have gone down the Azure road, but sadly right now we don't.
My advice would be don't do something just for the sake of doing it.
Hope that helps.
Nic
June 28, 2018 at 5:47 am
NicHopper - Wednesday, June 27, 2018 7:10 AMxsevensinzx - Wednesday, June 27, 2018 5:51 AMNicHopper - Wednesday, June 27, 2018 3:39 AMHi,We (the data team) at my company actually just did a number of short Proof of Concepts (POC's) on this looking at SQLAzure, SQL Azure DW and RedShift and we concluded that none of them was right for us at this point in time.
We found that as we are a MS team now (both data and apps) that moving to anything else would be a huge undertaking and in our case the cost massively outweighed the benefit.
With regards to SQL Azure and AzureDW we found that limitations in functionality meant that the costs again outweighed the benefits (for now).
I'd be happy to share the POC documents if anyone wants them.
Thanks,
Nic
Can you provide a high-level on why? Like what are the top reasons that really stood out the most?
Sure,
RedShift's big con was it uses a new skill set so the team would all have to learn it, we would then have to change all of our code (app and DB) to make them work. That's over 1000 stored procedures, across 10 core servers for what benefit.
Azure (including DW) - We like AzureDW a lot but you couldn't do linked server queries or even cross database ones (at the time we tried - perhaps you can now). This would have meant a massive change to us.In both cases the cost in time just outweighed the benefits, so for now we are going down the SQL2017 running on a VM route and we will port over to Azure(DW) in the future when we feel both fit our needs a little better.
At the end of the day its largely down to your environment, needs and problems. If we had the time and the appetite to do months of work or we were building from the ground up we possibly would have gone down the Azure road, but sadly right now we don't.
My advice would be don't do something just for the sake of doing it.
Hope that helps.
Nic
Yeah, that's normally the main reason not to as in the amount of time it takes for the conversion of old to new.
With Azure Data Warehouse, you would surely have an easier time of that conversion do the existing support of your code. But, not everything is supported either. The big thing is, while your code may be supported, a redesign is likely going to have to happen due to how MPP works versus how you have been functioning in the SMP world. The same may be true for Azure DB too. Thus, no matter what, you can't really escape more time for conversion.
Though, I will say that in our case, the time saved and the scalability power once we spent those hours converting, was going to be huge. That's not everyone though. Unfortunately, the cloud in a lot of cases for most people is just shifting their existing services to a VM in the cloud, not actually using new services.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply