Inside the Stack: “Where Do We Host?” Shouldn’t Be a Question You Ask 2 Months Before Launch

Welcome to Inside the Stack, where we talk through the real decisions, tradeoffs, and lessons behind running multiplayer games.

Today, we’re speaking with Andreas Pohl, VP of the GameFabric Platform at Nitrado. A developer from the start who has gathered his fair share of engineering scars, Andreas spent eight years at Microsoft across technical evangelism, solutions architecture, and Xbox strategy. Now, he hones his craft through a purpose-built orchestration platform designed specifically for multiplayer game studios.

Q: What was your first experience with gaming?

I actually can’t remember because I was too little! I do know back in the day seeing the Game Boy, I was like, “Yeah, I need that in my life.”

Around that same time, my dad surprised us one day and basically said, “Hey, jump in the car,” and we went to some weird store and he got us a PlayStation with Formula 1 (mainly because he wanted to play it!). We had no memory card, which was the most fun of it all, as this required you to start at the beginning every time you played. I wanted to drive a full season, and I think I did it once or twice, but we had to keep the PlayStation on for the whole night and continue the next day, if we were allowed to!

Those were the good old days. And I took my Game Boy everywhere. I had Pokémon Blue and my best friend had Red and he had invested in one of those link cables so we could actually trade Pokémon. I think that was the first multiplayer experience that I had, routing those cables between the Game Boys — not much has changed!

Q: You were a developer before you were anything else. Is there a moment from that time that still shapes how you think about what game developers actually need?

Everything did. In development, the scars you gather are the things that drive you further, and you gather a lot of scars in game development.

I went through all of it. I’ve clicked a button taking down production and costing the company I was at a pretty penny because players were unable to play! I slept under my desk waiting for a build to finish, and went into the office in the middle of the night in order to upgrade the build machine because, guess what, no one else was working and I didn’t want to interrupt anyone.

It’s these experiences that shape you, right? So, when you have a LiveOps game, it’s like performing open-heart surgery. When something breaks, it’s horrifying and humbling. You change how you work when you do that. And you never want to be in the same situation again. Trust me!

Q: You spent eight years at Microsoft, from Technical Evangelist to Solutions Architect and Advisor Lead. What made you want to leave and build something more focused?

Microsoft was a significant part of my life and gave me incredible opportunities to grow. One of its great strengths is the depth of expertise across the company. Whatever challenge a customer is facing, there is usually someone who helped build the underlying technology and brings a remarkable level of insight to help solve it.

Across all my roles, my missions remained largely the same: helping Microsoft better understand how to support game developers in the cloud and how to solve complex backend architecture challenges.

Over time, I realized that I wanted to work in an environment with a more focused product identity and a more direct connection between customer needs and product decisions. Microsoft and Xbox had built and acquired several multiplayer technologies, including PlayFab. Bringing these different services and their histories together was a significant undertaking. For developers, that sometimes resulted in overlapping options, unclear paths, or capabilities whose documentation had not yet caught up with their evolution.

Working directly with those developers made something very clear to me: I wanted to be closer to the customer and closer to the product. Large technology companies naturally have established strategies and strong perspectives on how their platforms should be used. I was looking for an opportunity where customer feedback could shape the direction more immediately and where I could help build something specifically around the realities of game developers.

I worked with many talented people at Microsoft who continue to do extraordinary work. My decision was not about rejecting that experience. It was about taking everything I had learned there and applying it in a more focused, customer-driven environment. That is what ultimately brought me to Nitrado.

Q: Is there a particular game or studio from your time at Xbox that you still think about when making platform decisions for GameFabric?

I obviously cannot talk about the specific titles I worked on. But I think about onboarding and friction, especially around the support network. I looked at the things competitors were really good at (for example, AWS as a cloud provider is really good at writing documentation), so the whole support experience and ecosystem is what I think about a lot.

At the end of the day, let’s be honest: these platforms share some foundational capabilities, but differ significantly in integration, infrastructure flexibility, portability, operating model, and production support. But at a first glance, they can look like they do the same thing: make sure servers stay online. So what actually differentiates you? What’s the appeal?

It comes down to the personal connection, being taken seriously, and helping studios make the right choices. Because there are a lot of options, and teams are focused on building the actual game, infrastructure decisions are often deferred until close to launch, when architectural changes become that much more challenging. So it can quickly become like “Oh, where do we put our servers? We release in two months!” That makes things super hard for the studio, which is why having that personal connection and genuine support makes all the difference.

Q: What does a week actually look like for the person responsible for GameFabric?

My job is to make sure that the team has the room to actually get the stuff done that they need to get done.

Now, what does this mean for my week? A lot of meetings! It’s working with the teams who are actually implementing GameFabric, figuring out our product strategy, and aligning on our vision. It’s making sure our senior stakeholders understand what’s coming next, marketing and sales know what’s on the roadmap, and doing a lot of — I love this word — “cross-functional” work. That’s the core focus.

Q: Is there something you’ve changed your mind about since taking on this role?

That’s a good question, and it might not be the most obvious thing!

I’ll admit: being in a situation saying, “you know what would be a good idea for a product? The thing that ten others are already doing,” is a hard thing to do. It really is. It was certainly the right call, being differentiated in what we’re doing and in the quality that we’re delivering, but sitting there thinking “Yeah, everyone is doing it wrong,” is one thing. Realizing just how hard it actually is to do it right is another! From the outside, it always sounds easier than what it really is.

That realization directly shaped how we approach open standards. I still talk to high-profile developers today who have experienced production issues or became constrained by proprietary decisions. This understandably makes them cautious about adopting another platform.

So it sounds counterintuitive to build a thin integration layer on open standards, effectively giving studios a practical path to operate independently. But the reality is simple: if they really want to leave, they’ll leave anyway. Lack of control will stop them from joining in the first place. By keeping the integration layer for GameFabric as thin as possible, we minimize their risk. Even though we deeply believe in our platform, if a studio ever decides “this isn’t for us,” they can take it and do it themselves. That’s how you build real, lasting trust.

Q: After years helping studios succeed on a general cloud platform, what does a purpose-built platform do differently that studios may not be aware of?

A lot. There’s always this one example that I bring up: think about the biggest game developer that you can imagine. If they go to a general cloud provider and say, “I want something implemented,” they say, “Okay, that sounds like fun. We’re planning it in.” Three months pass by, then a massive retailer with 100x more spend than that big game dev comes along with a different idea. What happens? The retailer wins the attention. They’re making far more revenue for the cloud platform than a game developer ever will.

The competition for attention within general cloud providers is so high that even top developers are relatively small for that provider’s bottom line. It’s a totally understandable business perspective, and should bear no blame. But features get pushed back, or worse, platform changes get made for big enterprise clients that actually hurt a game developer’s workflow.

That’s what you get from a specialized, purpose-built platform: we have one job. Our job is to make sure the game developers are successful.

Q: And for the studios that make the build vs. buy decision early on, what do they discover later that changes the calculation?

That it’s hard, and those who don’t know cannot imagine how hard it is. If you look at the journey of a game, the best time to make a decision like where you host is in the concept or pre-production phase. When are studios usually making this decision? Two, three months away from release. And game dev cycles are getting longer. So you end up spending six or seven years building something that requires a different, and relatively scarce, area of expertise. Many studios simply cannot justify building and maintaining this internally alongside developing the game itself.. Game developers are very smart, but it’s a different type of skillset that you’re looking for to build a platform like GameFabric. It’s more commonly seen in high-scale industries like banking. It’s super hard to find the right people that are able to build and operate a platform like this.

And there’s another pattern we often see: testing on a single server can conceal architectural and economic problems until quite late in development. If you always test on one server and never even try to run two servers in parallel, three months before release you’ll realize your setup runs so poorly that you can’t operate more than one game server on a bare metal machine. The economics work because you can run multiple game servers on one bare metal machine. For many workloads, especially with suitable density, utilization, and performance characteristics, it’s the most cost-effective option, but if you don’t do parallel testing, you can lose a key benefit. This is what happens when you spend years building infrastructure without that specialized experience.

Q: GameFabric is built around open standards, with Nitrado itself contributing to projects like Agones. When a studio moves from proprietary infrastructure to this kind of model, where does all the engineering overhead go?

The engineering overhead isn’t just going away because you move from a proprietary setup to an open-source-based solution. I look at it a bit differently.

It’s like standing on the shoulders of giants: you take what is proven, what actually runs and works, and refine it instead of trying to recreate the wheel. (Now, there are always exceptions, because remember I said everyone is doing it wrong!) But generally, with open standards, you get an open community and a platform that is more battle-tested than anything proprietary in any way, shape, or form.

Where does the work actually go? I wouldn’t differentiate between going from proprietary to open-source-based, but rather going from building it myself to buying with a vendor. Talent acquisition is hard, game development time is getting longer, focus is getting more and more important. If you look at the industry right now, it’s tough. Especially around multiplayer, LiveOps, and service games. You have the opportunity to focus on your game if you find someone that you can trust.

Q: What does GameFabric deliberately not do? Is there a reason for it? And is holding that line harder than just building more?

All the other things!

Like we joked earlier (and at the risk of overgeneralizing) you give us a server, and we make sure that server runs. Don’t get me wrong, there’s a lot of quality of life systems, and I don’t want to make the impression that it’s simple, it’s not! It’s hard work with hard lessons learned over a long period of time working at a very high standard. But there’s so much else you could do: user accounts, matchmaking, inventories, or even expanding into verticals like blockchain or iGaming. We don’t do any of those things.

We want to keep ourselves hyper-focused, and everything else pulls that focus away. We have a dedicated multidisciplinary organisation spanning multiple teams doing nothing besides focusing on game server orchestration and DDoS protection. We don’t need to look at other things in parallel. We want to build the platform that orchestrates games for game developers. That’s what we need to focus on.

And it is super hard to keep the attention because there are all these fun things that you can do all the time, running around and building things. You have the urge to do more, but our focus is what makes the platform work.

Q: You’ve been in game infrastructure for a long time and have no doubt watched the industry get things wrong in a few different ways. What do you think is currently the most pressing issue?

It’s the same as it always has been. I’ve gotten pushback on this before because people say, “Oh, everyone knows that,” but it’s still the reality: backend development and orchestration are not what game developers want to focus on, because it's not “sexy.”

Working on 3D graphics? Awesome. You’re tweaking combat design? Making physics realistic? People love this. But if you stand on a stage and click a button and in the background you get 120,000 game servers spinning up out of nowhere and you have a little counter going from one to one-hundred thousand…. yay, right? It’s not sexy. And therefore, there isn’t a lot of focus on it.

What ends up happening is that netcode and simulation engineers get tasked with building orchestration on the side. You end up with what I call “snowflake solutions” built by people who either don’t have access to specialist support to help validate at production scale, or simply don’t have the time.

Then, the game launches and the backend infrastructure fails. It almost never fails because you can’t source enough server capacity. It fails because if you spend five years on something that you cannot put on two different servers, it doesn’t matter how many servers you are able to theoretically get.

That’s why we made GameFabric a highly distributed system. It’s designed around distributed clusters so that it scales horizontally, avoiding a single centralized scaling bottleneck. It’s fault-tolerant, meaning GameFabric will keep your game servers online even if GameFabric itself becomes unavailable. We went through a lot of trouble to build it that way, but that’s what actually solves the problem.

Q: What’s the most underrated game?

I’m a huge Kojima fan and Metal Gear Solid fan. So, for me, the most underrated game is Death Stranding.

People always laugh when I say it: “Oh, it’s just a package delivery simulator!” But it’s just Kojima unique!

Andreas Pohl is VP of the GameFabric Platform at Nitrado. Leading the platform, he focuses on developer-first solutions for multiplayer studios. Connect with him on LinkedIn.