The ethel design tries to work with these high level assumptions:
- Most jobs will involve sources and/or targets in a LAN. Some will include internet accessible sources and/or targets.
- Many customers will require ethel run on a Windows server with no internet access within their LAN.
- Docker will generally not be available and sometimes explicitly not allowed.
This gives us these flavours of ethel, being developed in roughly this order:
- NestJS solution that can be installed on an offline Windows server
- Web client - Angular based on our experience with the framework
- Windows agent receiving tasks from internet accessible ethel deployment - TBD
- Public cloud ethel deployment using mix of PaaS and docker accessed by the Windows agent - TBD