Azure DWH part 28: The ASDW enemies

  • Daniel Calbimonte

    SSCarpal Tunnel

    Points: 4712

    Comments posted to this topic are about the item Azure DWH part 28: The ASDW enemies

  • Romac

    Right there with Babe

    Points: 722

    Enemies?

  • xsevensinzx

    One Orange Chip

    Points: 25531

    Romac - Tuesday, June 26, 2018 4:49 AM

    Enemies?

    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.

  • RonKyle

    SSC-Dedicated

    Points: 31457

    Romac - Tuesday, June 26, 2018 4:49 AM

    Enemies?

    It's just a headline grabber.  He uses the more appropriate term "competitors" at the end of the piece.

  • NicHopper

    SSCrazy Eights

    Points: 8866

    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

  • xsevensinzx

    One Orange Chip

    Points: 25531

    NicHopper - Wednesday, June 27, 2018 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

    Can you provide a high-level on why? Like what are the top reasons that really stood out the most?

  • NicHopper

    SSCrazy Eights

    Points: 8866

    xsevensinzx - Wednesday, June 27, 2018 5:51 AM

    NicHopper - Wednesday, June 27, 2018 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

    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

  • xsevensinzx

    One Orange Chip

    Points: 25531

    NicHopper - Wednesday, June 27, 2018 7:10 AM

    xsevensinzx - Wednesday, June 27, 2018 5:51 AM

    NicHopper - Wednesday, June 27, 2018 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

    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 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply