Start with the exercises, not the number of vCPUs
A hardware specification without a syllabus says little. An editor and a few Git commands have different requirements from a local cluster, compiling a large project or data analysis. For each module it is worth noting which processes run at the same time, how much data is produced and whether the participant changes the system configuration.
On that basis you can choose CPU, memory, disk and topology. You need to allow for the moment of peak load, when the whole group performs the same step. A profile tested on a single machine may need adjusting when images are pulled, code is compiled or data is imported in parallel.
Repeatability requires a base configuration
Every workstation should contain the same version of the operating system, runtime, libraries and materials. The configuration is best described in a way that can be rebuilt, and then the whole scenario should be run through on a clean copy. Manual fixes made after the image has been cloned create differences that are hard to spot.
It is worth pinning dependency versions, keeping the lockfile and specifying package sources. If the workshop needs internet access, check the repositories and rate limits. If it is to run without an external network, all artefacts must be in the image, a cache or a local repository.
The connection method should suit participants' devices
A remote desktop in the browser makes it easier to join from a company laptop, because no client needs to be installed. It works well with IDEs and graphical applications. SSH uses less bandwidth and suits terminal-based sessions. Both methods can lead to the same VM.
The decision must be verified on the target network. Ports, proxies, address filtering, keyboard layout and how the session behaves after a break all matter. A short technical test before the training is more reliable than a statement that the organisation “allows the browser”.
Isolation depends on the kind of changes
A separate VM for each participant is the right choice when exercises change services, packages, the network or data. With a shared cluster you can separate namespaces and roles, but participants still share nodes and global resources. In a database lab, a separate schema may be enough for SQL, whereas server administration needs a dedicated instance.
The environment should be separated from production, and network traffic limited to what the scenario needs. Root access on a private, temporary VM can be justified, but it should not automatically mean access to other workstations, the management panel or company secrets.
Materials and data must be designed together with the workstation
Starter files should be available inside the lab and read-only. Each participant needs their own directory for results. Production data should be replaced with a synthetic or anonymised dataset that keeps the cases important to the exercise.
The instructions must state the initial state, the first command, the expected result and how to recover the workstation. A large number of tools does not make up for the lack of this path. Participants should know where to start without hunting for information across several channels.
Support and reset are part of the choice
With a larger group, the instructor needs a way to identify a workstation, check the state of services and give help with the participant's consent. An instructor panel can shorten diagnosis, but it does not replace a procedure. You need to distinguish an access problem, a faulty image and an error that is part of the exercise.
Reset should work on a single VM and lead to a verified state. A snapshot speeds up recovery after system changes, while a versioned bootstrap shows more clearly what the configuration consists of. The mechanism should be tested many times before the group arrives.
Compare the cost of the whole event, not just the price of the machine
A cheap workstation that needs several hours of manual configuration and support on the day of the training may cost more than a ready-made temporary environment. The comparison should include image preparation, testing, distributing access, spare capacity, support, backup, exporting results and a safe shutdown.
A permanent lab makes sense with frequent use and a team responsible for maintaining it. For a one-off workshop or a changing syllabus, an environment reserved for a set period may be the better option. The example scenarios show how the topology changes between Kubernetes, Docker, databases, testing and application development.
A short pilot resolves most of the unknowns
One VM and one participant account are enough to check the material, the connection, resources and reset. The pilot should be run by someone who did not build the configuration. That person will more quickly notice a missing instruction, a hidden credential or a dependency present only on the author's computer.
After the trial you can make an informed choice of environment model and scope of service. Klasa w chmurze prepares both sets of identical VMs for groups and individual sandboxes. The difference comes from the number of users, the way support is provided and the work cycle, not only from the machine's specifications.