RuckZuck backend-Services V2...
The V2 Architecture will look like the following diagram:
The V1 backend services of RuckZuck have used InMemory caching of Authentication tokens with the following side effect:
- lost tokens after a service restart
- scale-out to multiple instances of the web-services was not possible because the instances did not share the tokens
So the next Version of the backend services (currently in testing) is using Azure Redis to cache the authentication Tokens for the duration where the tokens are valid (in RuckZuck, authentication Tokens are valid for 1 hour).
Multiple Web-Service Instances can now access the Redis Cache, so the limitation with scale-out is also fixed (for the case that performance becomes to a bottleneck :-)
To simplify the Client Tools, the V1 Web-Service (SOAP) will be migrated into a REST based Web-Service which can save a few Kbytes on the Client Tools because they do not need the WSDL Proxy Classes.
The most load of the V1 Web-Service was generated from the method to detect Software-Updates (Clients are sending the installed Versions and the Service returns the Product-Updates). There are currently over 30'000 Product-Versions in the Database but most of them are used very rare. Azure Redis Cache will also help here to cache the Results for the most used Requests.
Additionally: the full list of all installable Products will be cached in V2 because the List is requested from the RuckZuck-Tool (and RZ4ConfigMgr) on every startup and the List does only change if new Versions are published.
The Web-Service will log all activities to a Service Bus Topic. Services like a Log-Monitor can subscribe a Topic to receive the Messages in Real-Time. It may also be possible to trigger activities based on Results, e.g. if a "Hash failure" is reported over the Web-Service, a download service will be notified over Service Bus to download and validate the reported files...
Because V1 (and my Home-Automation Project) are using a Node Red Workflow based on MQTT Messages, some of the Service Bus messages will be forwarded to a MQTT Gateway hosted as an Azure Cloud Service.
An Azure Scheduler will trigger every 8 Hours a method on the Web-Service to export all "installable Software Products" as an XML. The Files are accessible for all RuckZuck PRO Users.
Schedule
Azure Redis caching is already implemented in the current SOAP Web-Service because it was so simple to implement.
All the RuckZuck Tools will be migrated (with the next Major release) to use the new REST Web-Service wit the following Priority: