The Shotgun Event Daemon is an interesting tool but you’re unsure if you should deploy it internally in your facility or in the Cloud. Is one direction better than the other?
Both running the Shotgun Event Daemon internally and in the Cloud are viable options, it all depends on what the daemon will be doing.
For this discussion, let’s define terms.
- On bare metal or internally means inside your facility’s firewall with access to local resources and the local network
- In the Cloud means external to your facility’s firewall without access to local resources or the local network.
The advantages of cloud computing are the usual: maintainability, offloading of hardware, scalability, etc. However, one of the strengths of the Shotgun Event Daemon is allowing you to automate tasks on your local network based on activity in Shotgun. These types of automation are something you can’t do with the Cloud (because you don’t want to open up your firewall) and an advantage that an internal installation on your hardware provides you.
For example: imagine you’d like to have a process whereby the creation of a Delivery record on your Shotgun server will convert and package files on your filesystem for delivery based on Versions attached to the new entry. Such a process would not be possible in the Cloud for a lack of access to your filesystem.
I generally suggest that people deploy the Shotgun Event Daemon internally as it confers more flexibility in what the system can automate.
I should note that the Shotgun Event Daemon itself isn’t very resource-intensive and should require a great deal of expensive hardware. The processes you implement with the daemon might resource-intensive. If that is the case, then I’d also suggest that the daemon, in turn, offload most of its heavier work to another system such as your render farm infrastructure or other servers to keep it processing events promptly.
I sure hope this helps you decide which route, internal or Cloud, you should take.