We can’t just assume that everyone has access to the standard of devices and connections that we’ve grown accustomed to as developers. Especially not us: we’re building a new web game platform for a global audience of millions, that will be all about frictionless access to the best and latest games.
Not just for us, but for everyone: our users come from all over the world, which means that for our new product, we’re optimizing for a wide range of devices and connectivities. …
At first, we thought that sticking with a familiar language was the responsible thing to do — we’re a small team, already engaged in two adventurous moves: a switch to microservices and a full rebuild of our legacy web application, a high-traffic game platform.
However, in the end we decided to go all the way and dropped PHP for Go. In this post we’ll explain why. We’ll also share some thoughts about databases within our microservices architecture.
Our familiar language was PHP. It powered our legacy application, and we had two vague arguments to stick with it:
The first step in the rebuild of our web platform is a proper foundation: the infrastructure. And our title has already given away the first decision that we’ve made: we’re going for microservices.
This post will explain our move to microservices, our choice for Kubernetes, and some other infrastructure-related decisions. For more context on our project and its objectives, check out our previous post on this topic, in which we explain why we’re rebuilding from scratch.
So why microservices? Many blog posts have been written about the pro’s and con’s of microservices in general, so we’re not going into that.