“We need to create snapshot data that can capture not just the content, but also the applications and operating system structures that work alongside it.”
This thought has been particularly relevant in my work as I often deal with sharing game server source code and technical guides with game studios.
In the beginning, I only shared the source code. I thought that was the standard practice, and honestly, I couldn’t think beyond that at the time. However, one day, I had to review the game server source code that I had shared, and I received the code in the exact same way — just the source files. As most developers know, source code alone is rarely sufficient to get a server up and running. The reason is that integration with other external systems is usually required. Storage solutions and API connections to external systems are necessary, so when attempting to connect to missing systems, the application often crashes or fails to run altogether.
After dealing with these frustrations, I decided to add an embedded database, H2, to the server source code for the game studios. Previously, the database had to run on a separate machine to make the server source code work. However, by modifying the structure of the source code, the application could now operate independently of an external database. The interface remained the same as when using a database, and DDL (Data Definition Language) and some DML (Data Manipulation Language) commands were automatically generated when the app was launched.
The next time I delivered server source code, the feedback was significantly better. The provided package now included both the executable and the source code, allowing the studio to test and integrate the client much faster.
From my perspective, this wasn’t a complex or time-consuming task, but for the person receiving the code, it drastically reduced the time spent on analysis and guesswork.
This experience was my first encounter with the idea of delivering an entire snapshot of the system for easier integration. In fact, this concept can be applied to many other scenarios. For instance, a cloud service that needs to scale out in real-time, or complex environments and configurations that can be turned into a snapshot, are practical examples where repetitive tasks can be minimized.
These days, I’m also looking to actively apply this idea to mobile games. Mobile games typically require isolated horizontal or vertical zones. Testing and validation in isolated environments, such as for store reviews or local QA, require multiple services and configurations. The backend systems for mobile games are extensive — authentication, billing, social features, game servers, rankings, and so on. If we can think of these as portable and stateful snapshots, we can easily provide isolated experiences for users in different regions and environments.