ArcGIS in Azure and local clients

[MikeWieggers]

Was wondering if anyone has already setup their ArcGIS environment in Azure and how they deal with connectivity from on-prem ArcGIS clients. E.g. any bandwidth issues or considerations? Any info is welcome.

Thanks,

MM

[ZacharyHart]

Very similar situation here. We keep unearthing small issues with security and configuring the environment, so heavy testing has yet to occur.

My primary issue I've yet to test-out and determine a path forward for is dealing with our current need for multi-user editing for our local team (onprem ArcGIS Desktop) while still having an enterprise GDB (and therefore SQL Standard instance) in Azure for publication of map & feature services [without needing 2 ArcGIS Enterprise licenses and 2 SQL Server instances].

My ideal is that our local connections to the enterprise GDB on Azure will magically have sufficient speed/drawing times. If that doesn't work out I'll have to rethink our data model/data flow. This could leave us in a situation where each workstation has an SQL express instance to host 2-way GDB replicas and then implementing scripts run via task scheduler that keep everything synced up. Its far from ideal, but that may be the reality I'm facing depending on how testing works out.

There are a number of other factors at play here; I'm happy to compare notes with you. I'm a bit surprised there isn't more discussion about this yet but I suspect most organizations have well-funded GIS infrastructure which takes care of many of these issues.

[LourdesSuman]

I have the same problem with the ArcGIS Desktop and Azure SQL Database, still looking for a solution.

[PaulBrandt]

Has anyone looked into whether the new Branch Versioning workflows could work for this scenario. From what I understand (as of 10.6) this would require editing feature services which could be hosted in the cloud via ArcPro (not yet/ever? available for desktop). I haven't tried this yet, just doing some research of my own as we plan for helping clients upgrade.

[BugPie]

I'm also looking for info on this topic. We are about to start our move to Enterprise 10.6 and putting it in Azure.We spec'd out an instance of Azure SQL to host our enterprise gdb. But I'm reading  here in geonet as well as this doc under limitations http://enterprise.arcgis.com/en/server/latest/cloud/azure/database-requirements-azure-sql-database.h... that we will run into trouble when our users fire up arcmap/pro from their laptops and try to make db connections/work with features in the e gdb.  

Is this true? Any recomendations? 

I'm wondering if we need to scrap our plan of moving to Azure SQL and stick with an instance of SQL server. 

Any insight, rec's or stories are welcomed. Cheers. 

[JohannaKraus2]

Just out of curiosity, how did you end up setting up your Enterprise 10.6 environment?

[JohannaKraus2]

Hi - We are also considering using Azure for a GDB, but I think it's really important to be able to connect in arcmap/pro for editing and analysis.

I'd love know what other people have learned/discovered/decided.

[ZacharyHart]

Collin Johnston‌ Johanna Kraus‌ Lourdes Suman‌

UPDATEish:

Lots of testing has been done and we're now moving forward with implementation.

To be clear: We're not using Azure SQL (Paas) but are instead migrating all of our company DB resources ( currently in a datacenter and this is not just GIS) to an SQL Server instance (on a VM) in Azure (IaaS), and our (current) onprem SQL Standard instance which hosts our eGDB is along for the ride.

We will have a separate VM hosting ArcGIS Server federated with ArcGIS Portal (so Base ArcGIS Enterprise Deployment).

Previous testing related to eGDB issues revealed the following:

• 'Local' access of the eGDB/RDBMS over-the-wire to Azure was simply too slow.
• An eGDB/RDBMS accessed by ArcGIS Enterprise and hosting services all in Azure worked great and services are easily consumed via the web.

The only viable solution here in order to continue to support multi-user editing on-prem is to stand-up an ArcGIS Workgroup instance (this sits on SQL Express)**. We will then use a 2-way DB replica to sync changes between the two environments. 

Now, if you want to talk about handling file data...that's a whole other can of worms....

**If you do not need to support multi-user editing ArcGIS (Desktop) Database Server may have some value to you.

***EDITED: Lots of points of clarity. Happy to provide more details.

[JohannaKraus2]

So, you are hosting your eGDB on in house instance of SQL so that users can access it through arcmap/pro - correct?  Do you also publish services from this DB or do you publish them from the ArcGIS Workgroup instance?

[ZacharyHart]

I'll try to clarify:

The local SQL Express/ArcGIS Workgroup instance is only there to support local multi-user editing for our core GIS staff. This is a DB replica.

The parent of this replica resides in SQL Standard/ArcGIS Enterprise in Azure. From Azure is where our feature & map services will be created/hosted.

Does that help explain things better?

Again, if you do not have the need for multi user editing, the following are potential options you could use in order to still support local editing but have your eGDB reside in Azure:

• ArcGIS (Desktop) Database Server ; in this scenario you could still have a 2-way replica with your local copy/replica sitting on SQL Express.
• Check-out a local copy from your eGDB as you need it. If you're doing this often and/or have to sync your changes often you'd grow tired of this quick.
• Depending on the gradient of editing needs from your user base, you may be able to offload some or most of your editing to feature services

This may help illustrate a few different scenarios you could implement.