Greg, Awesome response firstly.
Secondly, The intent of its use is to essentially provide a continuum strategy to moving legacy (Asp.net webforms) towards the cloud. The first part of the strategy is to move on-prem hosting into VM instance based hosting (cloud). In doing this there is a residual database(s) that on-prem cannot be moved into the cloud itself. Example. OnPrem there are two databases first being "Financial" and second being "Employee". There is also a website that reads/writes to both of these databases depending on a variety of contexts. However, the Financial database is quite large but the website only uses say 10% of its total structure for a specific set of needs (think of it as being 100 tables but only 5 get actually used). One can move the Employee/Website from OnPrem into Cloud-Based Hosting and therefore remove the residual hosting of these two from OnPrem. One can also create a copy of the "Financial" Database (initial creation is empty) based on the actual used "parts" of the said database (5 tables). The website gets its Connection context updated to point at the VM. The intent then is to use Data Sync to essentially push/pull data from onPrem to the cloud as data either is populated real-time or based off a scheduled interval (either option). An objective for Azure SQL Data Sync is that its role in this strategy is to act as a transport to ensure OnPrem data is kept up to date in the cloud so that website(s) can look at the Azure SQL instance for read/writes as if the OnPrem were also moved. Constraints on writes can also easily be avoided by using a background agent that manually feeds writes to the database, so one could also just assert that the Data Sync takes a volatile database onPrem and just pushes "snapshots in time" of said data into the cloud. >From what i've read this looks like its in Azure SQL wheel house... but given the volatility in Azure's weekly product management its important to not assume :) --- Regards, Scott Barnes http://www.riagenic.com On Mon, Jul 10, 2017 at 8:34 PM, Greg Low (罗格雷格博士) <g...@greglow.com> wrote: > Hi Scott > > > > Up to a few months back, I would have said “run away fast”. But now not so > sure. > > > > This was a “product” that stayed in “preview” mode for so very long. Blog > posts had long ago stopped and many of us for years had been asking if it > was another product that was just silently dropped without actually being > put to death. > > > > But I met with Lindsey Allen last year and when we were discussing it, she > said that it was going to GA. I was not expecting that. And sure enough, > there has been some life back in the blog, etc. lately, and some updates > did occur to the code. It’s moved across into the new Azure portal. > > > > It’s still quite a distance from being what I’d really consider a strong > product but I hope it succeeds as there is a real need for it. One of the > biggest limitations is the number of replicas involved. > > > > What are you looking to use it for? Often there are better alternatives. > > > > Regards, > > > > Greg > > > > Dr Greg Low > > > > 1300SQLSQL (1300 775 775 <1300%20775%20775>) office | +61 419201410 > <0419%20201%20410> mobile│ +61 3 8676 4913 <(03)%208676%204913> fax > > SQL Down Under | Web: www.sqldownunder.com |http://greglow.me > > > > *From:* ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-bounces@ > ozdotnet.com] *On Behalf Of *Scott Barnes > *Sent:* Monday, 10 July 2017 2:25 PM > *To:* ozDotNet <ozdotnet@ozdotnet.com> > *Subject:* AZURE SQL Data Sync > > > > Anyone have experience using Azure SQL Data Sync? Any "If they only put > this on the back of the brochure" moments that left you with buyers remorse? > > > --- > Regards, > Scott Barnes > http://www.riagenic.com >
