I started my software career as a Unity developer. Today I work at Red Hat on KubeVirt, an open-source project that lets Kubernetes manage virtual machines alongside containers.
Written as one sentence, that change sounds abrupt. It was not. Each step expanded the part of the system I worked on, from what appeared on the screen to the services and infrastructure behind it.
Starting with games
In 2016, I joined Junglee Games as a contract Unity developer on EatMe.io, an online multiplayer game.
I worked on gameplay features and production bugs, but one project reached beyond the game itself: porting the mobile client to the browser. That meant working with WebGL and adding WebSocket support to the networking layer. The game still had to feel like the same game, but it now had a different runtime, a different way to connect, and a different path to the player.
That work gave me an early look at the parts of a product that sit outside the visible client.
Beyond the Unity client
After Junglee Games, I began building MapleFighters.io, a small multiplayer game inspired by MapleStory.
The first goal was simple: let players enter the same world, move around, and fight monsters together. Making that work required much more than a Unity scene. A server had to keep the shared world consistent. Players and monsters had to appear, move, collide, and disappear at the right time. The client had to feel responsive even though every player saw the world through a network connection.
I kept rebuilding it alongside my work over the following years. Later versions expanded into backend services, browser builds, automated releases, and deployment. The project also became too complicated for its size, so I eventually removed several services and returned it to a simpler design.
Alongside the game, I helped develop a .NET Standard port of Box2D and later used it for server-side physics. That was another step away from working only inside a game client and toward building reusable software that other parts of a system could depend on.
The project made that wider boundary clear. The game was not finished when it ran in the Unity editor. The server, build process, deployment, and operation of the public version were part of it too.
Backend became the work
The next professional step came in 2018, when I joined KintoHub as a contract backend engineer. KintoHub was a platform for building code from a Git repository and deploying it to Kubernetes.
This was the clearest change in direction. Instead of working mainly on what a player saw, I worked on the backend services that a platform depended on. The focus shifted to service boundaries, automated tests, and making the system easier to extend.
At KintoHub, Kubernetes was part of the product itself rather than only a deployment detail behind it.
From applications to infrastructure
I joined Red Hat in 2021 on the KubeVirt CI team. My first work there was on an OpenShift-based platform that built, tested, and delivered OpenShift Virtualization from upstream KubeVirt projects to Red Hat enterprise customers.
This introduced another layer. I was no longer responsible only for an application or its backend. I was working on the infrastructure used to validate and deliver a large open-source project across different environments.
I later moved to the KubeVirt Infrastructure team and began working directly on Go-based virtualization features, Kubernetes operators, and workflows for creating and delivering virtual machine images.
KubeVirt brings two worlds together. It extends Kubernetes so virtual machines can be managed through the same kind of APIs and automation used for containers. The work also brings together much of the path that came before it: application behavior, networking, backend systems, deployment, automation, and infrastructure.
Some of that experience later flowed back into MapleFighters.io. I packaged the game’s services and added a Kubernetes deployment, applying infrastructure practices to the Unity project that had helped move me toward backend work in the first place.
A wider view of the same system
Unity and KubeVirt look far apart. One is used to build games; the other runs virtual machines on Kubernetes. My path between them was not a single decision or a clean break.
The browser port required work beyond the game client. A multiplayer side project required a backend and a way to operate it. KintoHub made backend and platform work my main responsibility. Red Hat moved that responsibility deeper into open-source infrastructure.
I did not leave one kind of engineering behind and start again. At each step, the part of the system I needed to understand became wider.