# Volunteer Down: How COVID-19 Created the Largest Idling Supercomputer on Earth
## 4 Discussion of Technological and Architectural Opportunities for Future Volunteer Computing
### Standardization of Deployment Units  
Therefore, this perspective paper proposes in Figure 10 an evolved and container-based master-worker architecture extending the typical VC master-worker architecture (see Figure 6).  
The marked grey components are extending or changing specific parts of the VC reference architecture explained in Section 2.2. First of all, the proposed architecture considers more than one VC project. All master nodes provide a standard Service Registry component that is shared by all VC projects to enable a complete VC project awareness for worker clients. Thus, a worker can choose which project it would like to provide its computing resources. Therefore, all VC projects must provide their workload in a standardized but flexible deployment format to make this freedom of choice possible. Therefore, the architecture proposes to make use of container images as deployment format.  
Figure 10: Proposal of an evolved and container-based VC master worker architecture model.  
Figure 9: Transformation of VC networks to avoid project boundness of worker nodes.  
Signed images are provided via public **Image Registries**. A VC project can operate a project-specific image registry. Alternatively, public image registries (like DockerHub [[https://hub.docker.com](https://hub.docker.com)]([https://hub.docker.com](https://hub.docker.com))) would work as well.  
Thus, the worker client can be minimized to a standardized container runtime engine (for example Docker or any other OCI conform container runtime engine) that fetches provided images and executes them as **Worker Functions** in a FaaS-like style (see Figure 8). However, worker functions are accompanied by a so-called side-car container [67] (**VC proxy**) that handles common VC communication patterns and can be called by the **VC Runtime Environment** (a lightweight wrapper around an OCI conform container runtime environment). VC proxy and the VC Runtime Environment are designed to be standardized components that must be not adapted by a VC project. The VC proxy provides a standard interface furthermore for worker functions. Obviously, the worker function is a VC project-specific part that realizes data processing. However, because the proposal makes use of container technologies, it can be provided as a standardized deployment unit. Container technologies enable furthermore polyglot programming, so there is a freedom of programming language choice for implementing worker functions. Current VC platforms like BOINC often enforce to include specific libraries which are written very often in C/C++.  
Table 2 summarizes the selected and discussed cloud-native technologies and explains how these technologies can be used to realize the proposed architecture (see Figure 10) to mitigate mentioned VC open issues reported in the literature. To do this, well-tried technologies that form the backbone of modern cloud-native architectures could be adopted: Containers, even more fine-grained (but container-based) functions, image registries, and distributed service registries seem very promising here. Thus, like the BOINC-approach, a middleware-based approach is proposed to share resources between different VC projects. However, most parts of this middleware are already existing (the technologies mentioned above and listed in Table 2). Thus, the proposal does not require a complete new middleware or framework. Still, the proposal requires a VC-specific integration of these technologies that go beyond the BOINC-approach (dating back to the early 2000 s, so to a pre-cloud era). This VC-specific integration is called **VC Runtime Environment** in Figure 10.