• 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.