Alteryx and Alteryx on the Cloud: Why?
I’m a rather impatient person, so for me, the answer can be summed up in three simple words: Get shit done. Nothing more, nothing less.
I want to ask questions and get answers, and I don’t want to wait too long before I start. I can do that with Alteryx Designer.
But if I want to take it further? What if I want to share my insights or maybe track where all my data assets (Databases, Tableau Workbooks, Alteryx Workflows, etc) are?
I can add in Alteryx Server and Connect.
And again, the mantra is G.S.D: I don’t want to wait too long for that first taste of success. Don’t have hardware available? I’ve got The Cloud. I can create a first class, scalable, and highly secure analytics environment by myself. You can too. That’s what this series of posts is all about. Do it. Try it out. Play.
We’re going to stand up all the parts of Alteryx on the cloud and get a feel for how they should be run.
But before embarking on a project, we should try to have some sort of a map. Here’s what I’ll start setting up today on AWS:
At the highest level:
- I’m creating a distinct Virtual Private Cloud to host everything Alteryx
- My public network doesn’t contain anything of value
- The private subnet is where the good stuff is. None of these resources are directly available via the internet.
- I’m running Apache Guacamole as an RDP gateway so I can remote into my Alteryx Server and Connect as necessary to do configuration work in the short term
- I have a small Linux bastion host (jump box) running in order to hit any of the three Promote nodes
- Once I have all my services running, I’ll configure an ELB or ALB to move traffic into the private network from “outside”.
- I want my Windows and Linux machines to be domain-joined, but I don’t want to bother with setting up Windows Active Directory. So, I’ve used AWS’s Simple Directory Services as an AD stand-in.
- I’m not bothering with multiple Availability Zones since I don’t care (yet) about being resilient or highly available.
