This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
Key areas that I'm hoping we can learn and become self sufficient:
- Sizing our server infrastructure - how many; how to size; the different server roles (workers / web server / load balancers)
- Setup considerations (co-location vs. multi-location; partitioning; business continuity / fail-over; load balancing) and implementation tradeoffs
- Guide to securing the servers (using LDAP/Kerberos passthrough preferrably)
- reference / best practice setup for dev/test/prod environments
- how many environments do people usually have (dev/prod or dev/test/prod) - what is the recommendation?
- what is the recommended access for each environment? Should we let people run their own canvasses in Dev / test, or does that leave us open to people running their flows forever in Dev/test in stead of going to prod? What is the recommendation about procedural controls for this?
- What is the recommended setup for districts
- Recommendations for access & usage of prod. For example, should we allow people to run jobs on-demand in prod, or only allow shedules. How about interactive apps; apps with Run /download tools; etc
- what is the recommended way of managing promotion from dev -> test -> prod - is this something that should always be managed by a central team, or is it recommended to allow users to self-serve. What are the tradeoffs, and best practices / recommendations
- Monitoring; management; etc
- How do you recommend managing scheduling choke-points (where due to human psychology people schedule canvasses on the hour (08:00 or 09:00 or 10:00), so every hour we have a rash of canvasses kicking off)
- How about overly aggressive scheduling - e.g. a canvas that is scheduled to run every 2 mins, but which is taking huge amounts of resourcing
- what are the standard monitoring / server admin team responsibilities (daily / weekly responsibilities like re indexing; monitoring performance; looking for resource hogging jobs; etc)
- How do you recommend that the server team manage driver versioning so that drivers are alwasy up to date on the server
- Newer capabilites
- best practice around server pooling;
- database access (do you recommend a generic login for "Alteryx server" or can we do pass-through kerberos from the logged in user, etc)
- Can we set up connection pooling so that if many different jobs are hitting the same server using the same connection details, it pools connections rather than opening / closing etc
- Is there any way to scan Alteryx jobs to look for bad practices before allowing them to promote to prod? For example, look for data fields that are never used after the input control.
Very keen to find out what is available because right now we're figuring this out as we go along, and I strongly suspect that we're not using the server to it's best capability because of our level of knowledge (or lack thereof).
If this is not yet available, we'd be more than happy to work with the Alteryx team to be the guinea pig for the first drafts and provide comprehensive feedback on any initial versions.
I'm not sure if the Alteryx team have created this material yet, so unfortunately I don't have anything to share - if this would be something useful and important for your team then it may be worth adding your specific needs to this thread to help guide the Alteryx team through their material creation.
I just stumbled on this thread and was glad to see it wasn't just me.
The infrastructure overview & installation/configuration steps were great; we had our gallery up & running in no time. After that though, it feels like we're flying by the seat-of-our pants. We opened the floodgates & everyone is using our gallery but not sure we're using it 'right'...I'm afraid we'll have to deal with difficult change management after users are set in their ways.
Would be great to have some 'rules of the road' covering the topics Sean pointed out.