Deployment Considerations for Driving Enterprise-Scale Analytics - Inspire 2017

Do you know the best configuration options to optimally scale your Alteryx deployment? If not, this session is for you! We'll discuss best practices for when and how to scale out Alteryx in your organization and address the top five concerns and needs for IT when scaling.



Video Transcription


Matt Braun:
Great, thank you everyone for joining. I'm Matt Braun. I'm Product Manager. I focus on Alteryx Server, been with the company for just about nine months. I'm really enjoying it. I wanted to thank you guys for attending this session, and I just want this to be the start, if not already, the start of kind of two-way communication. Please... hopefully you find this helpful, but also feel free to grab me afterwards in the Solution Center or email me. I'll have my contact information up there. But I want to just keep the dialogue open, because it's customers like you that really help us define a roadmap and make sure we're on the right path, and we're delivering great products for you.

Before I joined, a quick comment about the forward-looking statements. Now that we are public, I just have to add the legal verbiage. I may get into some forward-looking statements. Basically in summary, please don't make any purchasing decisions based off of something I say. It may change.

By a show of hands, who has Alteryx Designer and has been using it at least a couple of times? Okay, so most folks. All right, great. I'm gonna go through this just real quick. The idea here if you remember when you got Alteryx, you purchased it, you opened it up, you had that blank canvas, and a bunch of tools. You go, "Where do I begin? What do I do", right? Just essentially unlimited possibilities. You start thinking about what you can do, what you can solve with Alteryx, right? Some things like where should we open up our next retail location. We're thinking maybe we want a location in Texas, thinking in Austin. Let's back it up with data. Let's show people that Austin makes sense for our next location, right? You've heard maybe in some of our sales pitches or some of our market material. Okay I can take that three day report, bring it down to three hours, is that really true, right? But you start to test Alteryx; you really push it.

What are other people outside of my group trying to solve? What are they working on? Are they working on the same things I'm doing? I know a few other folks have Designer, what are they trying to solve? What's going on within our organization? How can we work together to further drive insights? And some people might just have fun with it too. Again, it's unlimited possibilities. Maybe try to cut down your commute from 40 minutes to 35 minutes? You can use our Drivetime data to figure it out. Just some of the possibilities, right? You can keep going with it too. Just keep having fun with it. There's plenty of things you can try to solve. Not sure you can solve world hunger, just some of the possibilities. So as you start to leverage Designer, you're going to run into situations where it might make sense to push it further into your organization, get further with options and drive more insights out of it. That's time when Alteryx Server might make sense for you.

For the agenda, I want to cover a few things. I want to cover when to scale to Alteryx Server. Some indicators of when it makes sense, somethings you might ask yourself or you might hear it within the organization of when to scale. And then we got some feedback from our last year's presentation that we wanted to make it slightly more technical to answer some of the questions that IT wants to know. I'll get into the top five questions that are kind of common concerns, questions that IT wants to know. After that, I'll dive into how to scale. I'll talk about scaling the different components and when it makes sense to scale a certain component versus another and why. We'll have questions at the end, and then I'll try my best, I have a lot of content, but I'll try my best to do some questions. If I do happen to run out of time for any reason, again, please don't hesitate to reach me afterwards, schedule a meeting or call or anything.

All right, so when to scale to Alteryx Server? Before I do that, real quick too, how many people have Server installed and are actually using it? Great. Okay, excellent. All right, so I'll go through this section a little quick too since most of you're hopefully understanding the value of it, but I'll try to hit home some of the key points. One example that might come up... Let's say Linda of the Data Analytics team. She has this Market Insights report. As of right now, she has to go and manually schedule it. She runs it out the night before or the morning of... She schedules it... or not schedules it actually. She's just running it directly from her Designer instead of just sending it out, right? So how can we improve upon this?

A couple of things. First of all, remove the dependency on Linda herself but also on that personal machine. What if she wants to run it at four o'clock, but then starts to drive home at five? She doesn't want to be tied to that laptop. By default, or by design, laptops are meant to be portal and mobile. They're not highly available like server infrastructure. Why not take that workflow, that report itself and move it into a highly available server infrastructure at a data center? So take advantage of what servers are meant for. They're meant for that 24/7, the uptime, the faster compute, the backups are done instantly with everything. So you can leverage Alteryx Server to run that workflow that she's used to doing herself.

Also, while you're doing that, you can take advantage of the schedule with Alteryx Server, which you may have just caught in Julia's presentation before. She went a little deeper into the schedule or features that we released with version 11.0. But in summary, she can take that rather than scheduling herself locally. She can push that into Alteryx Server and take advantage of the scheduler from Designer and Server, so that she can also see all the different schedules that she's running, and she can know for sure that it's going to run at 7 A.M. in the morning, and it doesn't have to depend on her. She knows that report's going to go out... running it on a server infrastructure, it's going to get to the folks that are needed.

What's great about this scheduler feature in version 11.0, it also gives IT more visibility into what's going on with the server environment. They can come into the Gallery Admin section and see what's going on with those schedules. They can see what's running within the Alteryx Server environment. They can see which ones are taking too long, which ones are hung up. They can have that dialogue with the users but really get better visibility and control of the schedules within Alteryx Server.

Another question or indicator that may make sense on moving to Alteryx Server, how can we collaborate? Let's say Tim has a long workflow. I'm not sure who has the highest tool count in the room, but it may be a complex workflow, put a lot of work into it. Now he wants to iterate on it. He wants to further collaborate within folks in the organization. How can he do that? You might be passing around workflows, might be just passing it around on the email, but then you might run into challenges like the data cache doesn't work or the user credentials don't work or this specific piece is missing a driver. How can we approve upon them?

One of them is you can use a collaboration within a studio. In this example here, you can see I have an Analyst Studio, and I published the Alteryx Server users report into that studio. Now anyone within that analyst studio... let's say, for Tim. He's in the Sales team. We put all the Sales team in this studio. They can see his work. They can pull it down. They can run it from the Gallery. They can also iterate upon that and further collaborate.

Let's say Tim wants to reach beyond the Sales team. He can utilize the collection feature on Alteryx Server. This is essentially a way to bundle together a set of workflows for a defined set of users at studios, so he can push it out beyond the Sales team to again kind of get a greater adoption and greater involvement in working on that workflow.

One slightly understated but very important benefit of Alteryx Server is to become that single source of truth. This again goes back to Linda too where- What if she had that very important version running on her laptop? What is she left the company or her laptop was corrupted? Where did that go? The single source of truth right here as you can see I have three different versions. I'll zoom in for you to make sure you can see that from the back of the room. You can see the three different versions. You can see when they're created, and you can also see which one's published.

Let's say we put out version three, but it failed for some reason. We want to compare it to version two. Version two is there, version two is there. There's no thinking about it. I can go back, and I can check the differences. I can also set up some kind of approval process. You can see by the "P" there that I have published version two, so maybe version three when I publish it, it goes through some kind of approval process you set up internally so where they have to approve, and then they can say, "Okay, version three is published." A lot of possibilities there. Again just one indicator, one that makes sense.

Now one more question is once you've created that complex workflow, that very helpful report, how can you empower your stakeholders to slightly customize it, to make some tweaks to it, and also remove the dependency from yourself so that you can spend more time on creating other insights? To do that, you can take advantage of our interactive analytic apps. On this example here, you can see Predict Visits. This was just a workflow where they were just trying to determine which hospital location to open based off of geographic area and the number of visits.

In this case, maybe one of Jessica's stakeholders... She is not necessarily concerned about patients with poor health condition, so she can run this, and she can run this whenever she wants too, maybe 9 P.M. After she got home from work, she was just curious. She can pop into the Alteryx Server, go in here, do the Predict Visits workflow, but tailor it to her by saying, "Well I'm not interested in the patients with poor health condition. I just want to know about the average and excellent." So she can go in here, do a couple of toggles, and get that report or insight based off of what she wants to know, and it's great because Jessica doesn't necessarily know about it. She set up it up, and it enables them to get those insights when I really want. This is just an example. There's a bunch of different tools that you can do to get that interactivity.

Now one last indicator... Again, this is not an exhaustive list. These are just some things to think about where it makes sense to get those people to use Alteryx Server. The last one is you have the Marketing team. They just want to focus on those insights, focus on creating those reports or whatever they need. They don't want to bothered with the datasources, the connections or credentials and all those little details, really just get me access to my data so that I can focus on building my workflow.

So one of the features that we announced in version 11.0 is the Data Connection Manager. This is something I'm particularly proud of, because I worked on it with the Development team, and I would feedback on it too later. For Data Connection Manager, what's nice about this is it allows IT to maintain control of those data connections. They can pop into the Gallery Admin section. They can create a data connection such as SQL. They can put in all those complex details like the host, the ports and any other information like that. They can test the connection, make sure it works on the server side, so it verifies your drivers you set up, for example, and then they can determine who it's shared out to.

By default, it's not shared to anyone, but they can then share it out to a set of users and studios. What's great about that is IT maintains control. They know who's using it too. It's not being passed around behind the scenes, and then when a Designer user comes in, they'll see something like this cloud icon right here, which indicates it came from a Gallery like the top on the list, this ShippingInfoSQLdb. They're going to go to Input Data tool and just pull down this connection. Say I want access to this shipping info, they just pull down that connection to their workflow. They're up and running. They don't have to bother with any of the details. It just works, so another feature, kind of a possible reason of why it makes sense to Alteryx Server.

Moving to this section, "What does it want to know?"... It is this guy right here in the sweet cape, the bright curly orange hair, [inaudible 00:11:37]. Sorry, just sounds fun to read it like this, but what does IT want to know? By a show of hands real quick, who's actually in IT? I don't know, a group here. Okay, got about half. Okay. All right, so we're going to dive into some of the details that IT might want to know about Alteryx Server environment but again don't be intimidated by it if you're not in IT. These are just some good things to know and some recommendations on what you can do with Alteryx Server and how it runs.

First, by far the most common question, how secure is Alteryx Server? Before I go into the tips, I just want to do a quick walkthrough just in case you don't know about the different server components. The first one is your front-end. In this case, we've configured our data as lovedata.com. I made sure it didn't exist, has a domain. Lovedata.com. This is that entry point. This is that front-end, that self-service portal that you know as Alteryx Server where people will come in that don't necessarily have Designer. They will come in to take advantage of the workflows and apps that exist in there. So they'll access that through a web browser. They can go over a standard port 80 connection, which is normal web, normal webpage, or they can use a 443 for a secure connection from their browser. That will take them into the server infrastructure.

Now they have this central component right here called the Controller. This is essentially... If you think about a hub and spoke model, this is your hub. This is the center of your Alteryx Sever infrastructure. This will receive the jobs coming down from Gallery that are being executed like a workflow run or an app run, go to the Controller. It will maintain a queue of jobs, and then the workers as you can see down here below are going to check in and pull down those jobs. Depending on how you have it defined, there could be a certain amount of engine processes as you can see by the blue icons. They will process those workflows in their entirety, process them, send them the information back to the Controller, which will update this status in between the database and provide the results.

For the database connection here, we do use MongoDB, and it's a standard TCP connection. For the Designer to schedule into the server environment, that's a standard port 80 connection, but they're all internally encrypted, which I will mention in just a second. You have internally encrypted connections between the server components, and then you have the ability to configure a secure 443 connection from your- hopefully a modern web browser, depending on your company, into the server environment.

So a couple of things to point out. First the web browser to the Gallery connection, we do want to recommend if possible to use 443 so use that HTTPS where you see that lock secure icon in your connection to the server. That just helps take care of all that browser into the server communication. One thing to point out, at the moment we don't generate a self-signed certs. It's not the best practice anyways, so you will need to talk with IT and make sure how to purchase a SSL certificate or generate one via your internal Private Key Infrastructure, so just a heads-up when you're planning on enrolling our server.

For the internal server components, like I said they're internally encrypted, just to make sure you're at ease in terms of security. We do a salt and time-based information. By doing that it makes those connections more secure and don't worry about time-based essentially to make it unique, so that all that communication within the server components is encrypted and secure.

Now for the database, the passwords are encrypted by default. They're not sent or stored in clear texts, so you shouldn't have to worry about that. At the moment, we do not support having a MongoDB encrypted itself, however you can have MongoDB reside on an encrypted volume, so it's going to give you that one extra layer of security.

Now talking a little bit more about the security, I want to highlight our server API. We have a RESTful API. We use OAuth v1.0A with key and secret. That will give you access to some of the items you see here, for example, on the top left. Now I could go a little more in detail. I don't have enough time, so I highly recommend checking out the session tomorrow. It's on Wednesday, and it's called, "Unlocking the Secrets of API and SDK", so they're going to go in more detail about the API, a lot of benefits that can come from that, highly recommend checking it out.

Moving to user authentication, we have a few options as you can see here. We have the Built-in auth, which is essentially local credentials. That's not tied to anything, just local credentials, [inaudible 00:16:14] and password, for example. You can start with that. That's fine. You can also leverage Integrated Windows authentication. This will use the standard NTLM, the NT LAN Manager credentials, so this will allow you to use your normal Active Directory credentials that you use to log into your Windows laptop. You can do that, however we recommend that you take advantage of Integrated Windows Auth with Kerberos. You will need to check with IT to make sure that Kerberos has been set up in the infrastructure, and if it has, definitely go ahead and leverage that here to make sure you have the highest security that we have available for the authentication piece.

Workflow/App security. You'll see a few modes in here as default or items you can choose. By default, it is unrestricted. What it essentially means is there's no restrictions. That's what it says, unrestricted. But you can dial it back just a little bit. Maybe you want to take a more secure stance out of the box with Alteryx Server and see how it plays out. You can take it back one step to semi-safe. What that essentially is doing is preventing the read and write from same network locations. And then you can take it even further to safe mode, which is going to prevent the use of certain tools such as the Download tool, so it's going to prevent people from downloading- making the API called, let's say, Google Maps or something like that and pulling down that information.

You may want to start with the safe mode as the default. Let users run into that problem of, "Oh, I can't publish it, because it's deemed unsafe. Why?" It starts that conversation with IT, and you can maybe set up some kind of approval process. Then if it becomes too cumbersome or... or however. You can always change that setting later. You can also do it on a per workflow basis.

Moving to the Alteryx system settings, what do I set? If you remember when you got Alteryx Server and you installed it, this is the first thing you'll see. Right after you've done the install, you're going to see the system settings. Earlier in the presentation I talked about the different components. I'm going to go ahead and dive in to each of those, for the environment, controller, worker, Gallery and so forth. I'm not going to go over every setting, but I'm going to go over some of the things that we most commonly talk to with customers to get that extra little performance benefit out of Alteryx Server and to give you an idea of what we recommend and you commonly hear customer support say.

Before I dive into that though, I do want to highlight that it's important to check out our Tech Specs. You can find that at the link there. Just in summary in case you don't know, we only run on Windows server only. We recommend a minimum of four cores, 16GB of RAM, and for the disk, 500GB to 1TB. That's the dependent on how you use it. For example, if you want to store the data package on Alteryx Server, you might want to put that on an SSD, for example, so that you have quick access to that data bundle, and you're not providing any extra delay. Those are the recommendations out of the gate, but please try to stick to those, because if you meet some of these recommendations, it's going to lead to pretty terrible performance.

We'll start off with the Controller. For the logging level, we recommend- so I added- By default out of the box, it's set to high. We recommend leaving it there. This is essentially good for both our customer support and for you guys. It basically gives you all the messaging possible that we have, in terms of error message and logging, to really allow you to understand what's going on in your environment. If possible too, make sure you get disk space monitoring in place. I used to be in IT, and I'm guilty of this. I said I would get it in place, forgot about it, and then something crashed three months later, so just try to get that disk space monitoring in place, and then if you can, avoid the system drive. As you can see on my screenshot, I used the D: drive there. The idea is, just in case your C: drive fills up, it's not your operating system drive. You're not bringing down the Alteryx Server node itself.

Moving to the Database persistence options, this is going back to the MongoDB. By default, these three options right here are not checked, so we do not purge any data. However, if you have certain policies defined by IT, to say... You may have a policy for your email or anything, but basically a policy that says, "We don't want to hold onto data any more than one quarter, about 90 days." You want to make sure that you match that policy you have within your company within Alteryx Server. You have a few different options, for example, clear out uploaded files or delete the results. However, I do want to caution though. If you put these settings in place, please make sure your customer base, the folks know that their results might disappear at day 91 but definitely nice to have this match your IT policies, so that you have it cleaned up and also your MongoDB, so it doesn't get too large over time with stuff you don't care about.

One more option of this- the Worker section I'd like to talk about. One definitely important section is the simultaneous workflows. What this essentially comes down to, if you remember on my diagram on the Worker node, there were those blue icons, those Worker processes, essentially the engine processes. Those are those concurrent engine processes running on each physical Worker node. By default, we recommend that you start with "workflows = cores / 2". In this example, if you have the standard four-core machine that I talked about, just divide it by two. That gives you two simultaneous workflows. This is a great starting point. However, feel free to tweak it later. You can always pop back into this and maybe increase it. Maybe you have a 16-core machine. Your OS is running fine. Workflows are processing through fine. Maybe... capture that metric before and maybe play with this and bump it up a little bit and see like, "Was it a total net gain or was it an actual performance hit?" But this is where you would want to start with, workflows divided by two, so you get a good performance out of the gate.

Another piece of the Worker section is the sort and join memory usage. This is essentially the memory that is being used on Alteryx server for any sort and join operations. What we're trying to do here and what we're recommending is that you set it max out of the gate. We're not allowing one of those engines processes to steal essentially all the memory available on that server. We want to ensure we have a good user experience out of the gate. What you can do is follow this equation right here. Go through the example real quick. You have 16GB of RAM, so our tech spec on this server. Pull away 4GB for the OS, so you just want to make sure that the OS itself, the Windows OS, can run fine. Pull that away and divide by the number of simultaneous workflows. This example here, that would result in about 6GB of RAM per engine process. You're making sure that at most each engine process on that box can use 6GB. This is a great way of making sure that you have those resources available, but you're not necessarily stealing it from other engine processes.

One other important piece on the Worker section is the run-as user. This is the context that Alteryx Server itself runs under, so by default it is local system. However, as you start to again push further into the organization, you might need access to things like network shares or certain database aliases that reside on the server. You're going to want to use an actual Active Directory and network account. You might have the tendency to use your own account, put your own name and username and password. That's fine, but most companies might have a 90-day password rotation policy. You don't want Alteryx Server to die on day 91. If possible, reach out to IT, get a Windows service account and make sure the password is set to never expire. Set that on day one, you know for sure Alteryx Server is going to remain up and running, and you have the appropriate access that you need to do things like those network shares.

Moving to the Gallery section, this is that self-service portal, that front-end of Alteryx Server, or folks that don't necessarily need Designer, they can come in and run. One thing that I now forget about is to configure the email, the SMTP. This is helpful or necessary I should say for things like sharing a collection, workflows additions or certain events. There's about a dozen out of the box that are very helpful for you as an admin but also the users of your front-end. Another important reason is required for "Reset Password". We send an email when you click "Reset Password" for local credentials. We send that email, so we need this to work in order to get that email to your user.

Switching to the engine section, when I talked about the sort and join, I defined or I recommended for the max, to set the setting at max. You also want to make sure that you set a certain minimum. While this is default here, it's actually a minimum. It's the minimum amount of memory you want to make sure that that sort or join has to run. This may improve the performance of those large sorts and joins. You can always increase this value. However, we recommend leaving it at the default, and actually customer support will tend to dial it down just a little bit further below that to 1GB. You can start at the default, but also maybe bring it down to 1GB, again, as a starting point, giving it at least a minimum of 1GB for that engine process to run.

Default number of threads. This is used for some of the multi-threaded tools. I have the example here, CASS, Drivetime and a few of our tools take advantage of multi-threading to some extent. This is what you're defining the number of threats for those multi-threaded processes in this section. By default, it will default the cores+1. However, one of the other sessions, maybe you have a 16-core box. You wouldn't want this to be set to 17 threads. That's too much. It's actually probably going to lead to worse performance, so you want to stick with the max of 8 to 10. Going back to customer support in terms of their recommendation, they typically recommend you start with three or four, so I put that in the screenshot. Again, start there, see how things are going, take the before and after metrics if you want to change this.

For the engine, there's another piece there at the bottom. It's kind of hard to see, but there's a run engine at lower priority. We actually recommend this for most configurations. I would actually start with this out of the gate, go ahead and check that box, run engine at a lower priority. But what this is doing is making sure other processes such as this Alteryx Gallery, so that the front-end of your server is responsive. When you have users come into Alteryx Server, you want them to get a good experience right out of the gate. You don't want them to come in, have that lag between kind of going through the different Alteryx Server pieces. So go ahead and set the engine run at a lower priority, so you make sure your front-end is responsive. Essentially you would definitely require it for single-node. That's where everything is running on the same box. We also recommend it for multi-node configurations.

So I covered everything on Alteryx system settings, but I do want to highlight that it's a GUI you can always open up later. You can come in and make further tweaks to this. I do want to note though, just be careful. There's a couple of settings in there that we recommend you don't actually change at will, and one of those is that authentication, so changing it from, say, built-in Windows Active Directory, that will get really messy. So if you can, have that conversation with IT early on and say, "Hey, we want to leverage Windows Active Directory. Can we do that out of the gate?" That's one of them, and there's certain other things like controller token. You wouldn't want to change that after the facts, but I'm happy to talk about that later too, just a couple of things to note. But aside from that, for the most part, you can change everything else at will and really get further performance out of it.

Moving to another common question from IT is what's in the logs. We have three different logs. One of them is the service log. This is an example of what you can see, very common log to check out. You also have the gallery logs, and then you have the engine logs there. What's cool too with the engine logs, you can see the tool run timestamps, so say you have a 10-minute long running workflow. You can go in there, and you can see when the tools of that workflow actually hit, so you might find out that one of your tools is taking nine minutes itself, and everything else is running at one minute. Again, it kind of helps you see what's going on in your environment. I put in the right frame there, which appears to be cut off, an example of what the naming is for the logs. If you're curious where they are, you can pop up in Alteryx system settings, and you'll see the locations of these logs. By default, it's C:\ProgramData.

Now, why not use Alteryx to read the logs? Through the help of Steve Ahlgren, he's one of our server gurus. You might have seen him in the training yesterday. He actually published to the community a workflow to help you dive into the logs, so he has a log parsing... essential workflow. In this example here, you can see that you run this workflow on your Alteryx Server box. It will pull in all of those service and gallery logs, so you'll see here the different Alteryx service logs, so basically getting all those logs into Alteryx so that you can further dive into it.

He also included a few examples. One of them is find jobs that failed. What's nice about this one- This is just an example of the possibilities, but this one helps you... If you find a job that appears twice, which meant it ran, for example, on two different workers, that's actually a problem, because that job should finish in its entirety on a worker. So if it ran on two workers, that actually indicates there was a network blip or your MongoDB died or the worker itself died. So it helps you understand there's a problem, and I need to figure out what's going on.

Another one for the security conscious folks, you can see what's going on. You can see people are even using it, or maybe you had a security incident tied to a certain IP. You can see if that IP, for example, was hitting your environment, and then you can see what they're doing. In this example, you can see what API endpoints they hit, and you can see where they're coming from, what's their user agent, so gives you somewhat of an idea of what's going on in your environment, and then kind of track that user activity.

If you want to go further, why not use our MongoDB input tool? You can take that MongoDB input tool that we have and actually connect to the MongoDB that's running Alteryx Server, and then you can crack that open. You can see the different databases that we have. You can see all the connections and again dive further into what's going on with your Alteryx Server environment. Just some of the possibilities, seeing some great stuff coming out of using our own Alteryx tools, [inaudible 00:30:36].

Moving to the fourth common question I think we want to talk about IT, how do I monitor the server health? I'm actually going to use the example of what we do with our public gallery, what you find on gallery.alteryx.com. We use a combination of tools. We use New Relic, so that's the monitor at the front-end nodes, and then we use Amazon's CloudWatch, so we do run everything on our public gallery and Amazon AWS. We use CloudWatch to monitor that machine health, to kind of see what's going on with the CPU, the gallery processes and so forth. For MongoDB, we use MongoDB's Cloud Manager to really give us insights on what's going on with that MongoDB.

We have Nagios on the right there. Nagios is actually pulling from those tools and doing things like sending us email alerts if there is an issue in our environment. This is just an example of what we do. I definitely recommend having that conversation with IT to see what you guys have. For enterprise apps, you may have SolarWinds or CaTECH or AppDynamics... just essentially leverage those tools, make sure they're in place that you can start getting those alerts and then start to get those trend lines forming to see how your Alteryx Server usage is going.

I talked there about kind of monitoring the server health. Now, what about the server itself, the Alteryx Server itself? What's going on? A great tool to use is the Alteryx Server Usage Report. You can find that on downloads.alteryx.com. This is essentially a way to connect to Alteryx Server to see what's going on, certain things like the content metrics, the schedules and so forth and dumping into Tableau or PDF to really give you insights more into the usage.

I have a long list here that I can show you after the class of what's possible. A lot of things are covered. Here's just a couple of the possibilities. One of them is here is logins by time of day, so you can see when are people logging in. In this example, you can see with the dark blue that more folks logged in at 3:20 than they did at 3:25. Again, you can kind of see are people using it during business hours only? Are they using it on weekends, nights? What's going on?

In this example here, you can see all the different contents you have. You can see, for example, that the Sled Trail Finder app is to set to public, so that's available to everyone in the community. Maybe you don't necessarily want to be set to public. Anyways, gives you an insight of what's going on at Alteryx Server.

In this case too, the scheduled runs, which is really nice. You might have a bunch of schedules running but might not really know how they're doing. In this case, you see all that red tied to the CleanseWorkflow. You can reach out to the owner and say, "Did you know your scheduled run has failed every single time?" And just have that conversation with them to figure out how to fix it, so it gives you some more insights into your environment.

What's great about 11.0, we released another feature that allows you to configure all the Designer sessions, or I should say Designer applications on all the various laptops and PCs, to send their data to phone at home to Alteryx Server. You can see in this example here, that second row there, I went to Global Search. I queried for Mongo, and I dragged it into the canvas. It actually logs that as an event, so I can see what's going on with Global Search, and I can see what's going on every time they click the run button. What's great about this is- Oh, and I should say, it's just a small tweak in the runtime settings XML file, and I have a link at the end of the day to show you how to do that.

You configure that. It sends it to Alteryx Server, and what's great about that is once you run this usage report again, there will be a new tab, a Tableau for example, that will show you what's going on with the Designer usage. It will actually show you, for example, what tools are being used, so we can see like, "Hey, we paid for this spatial data, but then no one's using it." Or predict it. We only have maybe five users using it, but we're supposed to have 20 users using it so to really go and see what's going on with your environment and see if you should buy more Designer license or maybe less, not that I want you to buy less, but you can just see what's going on with your server environment. I'll save some time for questions at the end, sorry.

For scheduling the report too, a bit of recommendation, why not leverage the scheduler itself? Go ahead and set to the scheduler. You can see it on the example here. I set it to weekly. You don't necessarily need to check it every week but just set the scheduler for once a week, so that maybe once a quarter or once a year when you review it with IT or folks that are interested in understanding what's going on, you have those metrics. You can crack them open. You can see like, "Hey, our usage has been great for these couple months. What happened to it? How was the adoption?" Or, "Even if we made a change to the architecture, did we see a benefit from it?" So just go ahead and set it on that schedule.

One last question that we hear from IT too is how and where can I deploy it? You have a lot of different options. You're thinking like this guy, cloud, on-premise or should I just follow IT's policy, just have a couple of thoughts here and there. On-premise, just in case you don't know, that essentially means Alteryx Server itself, everything's contained within the four walls, so it's nothing in the cloud. You can use physical hardware, or you can use virtual machines. We don't have a recommendation either way. That's up to you guys, to have virtual machine policy first only, totally fine. Do whatever works for you guys. One thing to note, if you do want folks to access that Gallery, that front-end, you will need things to set up, such as the VPN access, Virtual Private Network, so they can access that Gallery that's within your four walls.

One option to kind of counter that, an alternative, you could take the Gallery component, so within the Alteryx Server setup, you can take Gallery component, and you can put it on its node within your DMZ, so basically exposing it to the Internet so that folks could access it from anywhere. But then when they make those calls, the Alteryx Server environment, that's still contained and secured within your walls, which is one option.

Now, if you want to go cloud, so this is essentially 100% in the cloud, so maybe everything on Azure for example, nothing in your four walls. Just a couple of things to think about. It will require things such as a Virtual Private Cloud. What this essentially is a dedicated pipe, so you will need to work with maybe Azure and your IT to set up that dedicated pipe back to your network. You're going to need that for things such as the datasources and Active Directory, so it does require some setup, not too difficult, hundreds of customers have done it.

What's great about that too is that if it's in the cloud, you can start to use more of the features and benefits of the cloud things, such as Redshift or Azure Data Warehouse, and start thinking about- Maybe I want to move some of my data warehouse, my data link, out into cloud. I'll leverage that so some possibilities there.

Now if you're not sure about going full cloud, you can stick with more of a hybrid model. The hybrid model, which is most common, people would just take that Gallery component and put that in the cloud, so then it's highly available through Azure, Amazon or whatever your cloud provider is. So you have the highly available front-end, but then you have all your server components protected within your walls. Just some of the ideas there.

So now moving to how to scale. There's a few options. You have Alteryx Server up, [inaudible 00:37:43], you're like, "What do I do?" Do I expand out or which component do I expand out? What's going to be giving me the most value in my situation? First, you can scale out the workers. I'll show you a quick little animation here. If we bring in two workers- so those are two physical nodes, so we want to add two- I shouldn't say physical. Two servers. [inaudible 00:38:04] You're bringing that, and what you're doing is you're taking that Worker process and moving it out to those two nodes. What this is doing is it's allowing those workflows to be processed simultaneously, so you're taking that extra RAM and CPU and processing from that component, putting it in your environment to handle more simultaneous workflows. This is by far the most recommended method that we promote and say to get the most value out of scale out strategy.

What's nice about the possibilities of Alteryx, you can automate this too. We even do this to some extent within our Alteryx Analyst Gallery, our public gallery. We have, for example, from our DevOps, it published some chef cookbooks, so you can grab those in our community, and you can see how they automate the deployments of a server. You can take it as far as you want. You can take it all the way to an extent of where it recognizes certain thresholds and spins up a Worker, spins down a Worker, based off of your environment. A lot of possibilities there, just want to highlight on what you can do.

The next thing you can scale out is the persistence layer. This is that MongoDB. One way to do that is to leverage MongoDB's replica set. This is just a default or a function of what MongoDB offers. In this example, I've taken rather than maybe the embedded MongoDB that we offer, and you want the user-managed MongoDB, you're going to run it with three nodes. In here, this is a typical set from Mongo replica set. You can always configure it if you want, but you'll have your primary and two secondaries. What this is essentially doing is giving you a disaster recovery plan and also taking care of data redundancy. If that secondary goes down, Alteryx Server remains up and running, no data loss, so something to think about as an option. This is what you would do if you want to scale up a persistence layer.

The last thing you can scale out is the Gallery itself by adding Gallery nodes. In the animation you can see here, I've added two Gallery nodes and thrown them behind a load balancer. What this is doing is it's sharing that load, and then it's allowing for failover and redundancy. So if node two goes down, no one knows the difference. They'll just automatically redirect to node one. You're up and running. We've even seen some people, which I think it's actually a great approach, just start with that load balancer and the Gallery node out of the gate. Even if it's just one node, you're still having people hit that load balancer, so their experience will never change. I could add three or four or five Gallery nodes behind the scenes. No one knows. It's been the same experience. It's the same URL they accessed. Another nice feature about the server itself, because we use that RESTful API that I mentioned, it can tolerate failure and it's stateless by default. Again, it just leads to a highly available front-end experience.

Now you may be wondering, we have the three components, what do I scale out? We put together a little guide to scaling, put together this checklist format. This is also online too. These are some kind of points of when it makes sense of which components to scale out. If you want redundancy, redundancy actually goes across the whole platform, so you scale out all three components. But if you have a bunch of backend jobs increases so a bunch of stuff in the queue, you need to process those more quickly, you would add Worker nodes. You see that only the Worker box here is checked, because if you add a Gallery node or a Database, that's not going to help with backend jobs. So definitely check this out when you're thinking about how to scale out.

Lastly, I wanted to throw together a scaling checklist. I realize I'm a little low on time. I'm just going to go through this quick. Basically in summary it kind of pulls together some of the recommendations that I had. Couple of things though, do what you can to get an idea what's going to be going into your Alteryx Server environment but anticipate future growth. You might want to start off with one or two extra Worker nodes out of the gate, so you get that best experience for you as an admin but also for your users. Because with more Workers, you're going to get higher throughput rate, so you get better final runtimes on all your workflows that might be running. Get that monitoring in place and start to track those before and after metrics. Before and after metrics are necessary, again, to drive that conversation on when it makes sense to scale out or invest more in Alteryx or to dial back usage.

So hopefully that was helpful. I wanted to make sure though. I captured some of the things that I talked about, so if you want to dive into more detail on them, you can. These are some great articles to start with, and then if you miss a session or can't attend it, you can always check out the recording of the presentation afterwards. Yeah, hope that was helpful. I'd like to go quickly on questions for the last few minutes we have.

Crowd question:
[inaudible 00:42:50]

Matt Braun:
Oh yeah. Okay. I wasn't aware of that actually, but I'll make sure to follow up. At the moment, we have Tableau and PDF, but you'd like to be able to output to Power BI?

Crowd question:
Yeah.

Matt Braun:
Okay. Yeah. Great, thank you, yeah. Give the mic.

Crowd question:
First, thanks for your explanation about the server and architecture, because, in the site, they concentrate mostly on the Designer, so it was really helpful to see. One of the questions is the MongoDB. We're having recurring issue. It is not able to record when there's a failure, and it stops the whole scheduling. I got to understand about that. What is the coding in MongoDB when there's a problem in the server? The other question is the private gallery. It can schedule, but everybody [inaudible 00:43:56]. There is no roles available in private gallery, so I got to see that one, and then the other one is that OAuth 2.0 was released out on 2012. We're still using OAuth 1.0, which has so much security issues I heard. These are the multiple questions I have. We can answer it now, or I can fix an appointment later with you.

Matt Braun:
Yeah, there's a lot that I would love to talk to you afterwards, so if you don't mind, just grab me afterwards. It's going to do it. Thank you.

Crowd question:
Hi. Quick question, dev production setup, impact on the server licensing. Just one is production. I need multiple servers in our enterprise deployment.

Matt Braun:
Yeah, we've definitely seen that too, and we do have, depending on how you define dev, we have a sandbox kind of test system server pricing too. It's at a reduced price than the normal server price and issue, so you can maybe buy that license and apply to that dev environment too, and then have kind of a process to set up to where it goes from dev to production.

Crowd question:
A question from licensing point of view. If we deploy a server [inaudible 00:45:09], do you consider the VM cores or do you consider the bare metal cores?

Matt Braun:
Yeah, so at the moment it's the bare metal cores. Yeah, so if you had hyper-threading turned on, we wouldn't be charged for this extra course.

Crowd question:
Hi. In terms of I guess high availability, is there anything in the roadmap to kind of reduce the risk of the Controller being the single point of failure?

Matt Braun:
Yes... I can leave it there, but we are where that it can be seen as a single point of failure, while it's very rare that it goes down... For example, with our public gallery, I think in the two years it's been running it hasn't gone down, that specific component, but we do want to address that.

Crowd question:
For the access logs you were showing, is there like a prebuilt workflow that we could download that will just connect to our logs and output something, or do we have to do that on our own?

Matt Braun:
For the logs, there were, at the moment, the two options. You can use the server usage report itself, or you can also use that workflow from Steve Ahlgren. Yeah, so it's in the references here too. You'll see it in the second one, "A deeper dive into Server logging".

Crowd question:
Also, for the saved data things that you said someone else could like manage and they would just pop up, are those customizable for different users, or if someone puts a safe data connection in there, it's just everyone's going to see that?

Matt Braun:
Oh sure, yeah. I'm going to get into that more later too, but you can set that to specific users or studios. By default, it's not shared with anyone, but you can determine who wants to get access to it. You can be very granular, and it's totally secure. Not everyone that goes in Designer is going to see it unless it's been intentionally shared to them.

Speaker:
Thank you all. That ends today's session, want to remind you to please take your surveys after the session. This helps us customize our offerings for next year and make sure that they are most relevant for you and make sure that Inspire is of value to you when you guys go home. So thank you. It's now lunch.

^Top

ERLEBEN SIE
DIE WELT VON ALTERYX
SELBST.

Los Gehts