And I scratched my head. Why would you want customers to upload their data to an Alteryx server? I don’t see how it’s anything like a Mongo database on Atlas. The data Alteryx analyzes isn’t “Alteryx data.” It’s the company’s payroll data…and accounting data…and CRM data…etc, etc.
Bear,
My Atlas comparison wasn’t about treating Alteryx as a data store – I meant that it is a server-side package that AYX could provide managed hosting of for its users, akin to what MDB does with Atlas (hosting MongoDB for users as the experts-on-call, simplifying the amount of IT expertise needed). Probably a bad company to use for the example if it made you think I was calling Alteryx Server a data store.
I just wrote about this a bit in the prior post but there I focused on scale. Here let’s talk about the proximity to data issue. You are not factoring in how proximity to the data works both ways. Thus far proximity has typically meant near to the on-premise data, but more and more companies have many or even all of their datasets in the cloud. There will be a tipping point PER COMPANY as to how much data is read local and how much data is read from cloud, and the cost balance for transfer rates will determine where Alteryx Server should lie. Your point about Alteryx Server not being a data store is correct - but the closer it lives to the data being analyzed, the faster/cheaper it becomes.
Let me amend your statement with today’s enterprise reality, and see if it changes your perspective…
EXAMPLE 1:
It’s the company’s payroll data [in local Oracle db]…and accounting data [in a local Oracle db] …and CRM data [IN SALESFORCE]…etc, etc.
So in that particular case, if the on-prem account data is massively larger than the other cloud-based datasets, then it makes perfect sense to have the Alteryx Server be on-premise.
EXAMPLE 2 (expanding their datasets):
It’s the company’s payroll data [NOW IN WORKDAY]…and accounting data [in a local Oracle db] …and CRM data [IN SALESFORCE]…and ADDING NEW DATASETS IN Marketing campaign data [IN MARKETO] and advertising pricing data [IN TTD] and company event data [IN CVENT] and travel data [IN CONCUR].
Here suddenly the balance shifts as the company then moved Payroll to a SaaS service, and added in a bunch more data sets from other SaaS services. Now perhaps 2/3+ of the data volume is data already in the cloud. At some point the company will decide that they shouldn’t run Alteryx Server on-prem but instead move it to a hosted cloud instance.
And this isn’t factoring in that some companies don’t run any software on-prem already, but instead rely solely on SaaS (assuredly an Okta customer in that case!). Suddenly they would need to pull all the data from the cloud onto on-prem to analyze it into Alteryx Server if they ran it local. In this case they would certainly only be using Alteryx Server in the cloud as a self-managed instance (the only option).
Start to make more sense why a managed cloud-instance of Alteryx Server might be useful (my EASY suggestion), instead of the customer having to put up and self-manage an instance? Hell, I bet there is already a consulting company just doing that. Many customers are opting to start running Alteryx Server on their own Azure or AWS Windows VM, as they don’t need to be pulling all the cloud data to on-premise. They are going to flip the scenario and start pulling their on-premise data (if any) up to the Azure/AWS instance for processing, perhaps into AWS S3 or Azure Blob first for easier ingestion. [Blob is a horrible name for a product but makes the dev nerds happy as that is what blocks of raw data are called.]
Hope that helps put the discussion on proximity in better perspective.
-muji
long AYX