Working Microservices into Minecraft

Minecraft has been out for quite a few years now (I’ve been here since the start), but the architecture behind it hasn’t changed a whole lot. You could argue it doesn’t need to. But, then you just have to look at what some people are doing with it to realise potential for change here. Minecraft-specific hosting companies were formed in the early years of the game, and soon the large scale servers began taking shape. Hypixel for example, has roughly 30,000 players online at any given time. They dwarf the competition in the active player base, and I can’t imagine that hardware costs are particularly cheap either.

Since the collapse of the CraftBukkit, we’ve seen crowds of developers tackling the lack of an up-to-date system (see Sponge) – but it doesn’t come close to what enterprise software is capable of. Having worked for an insurance software house for over a year and a half now, I’ve seen things I never dreamed of 7 years ago. Companies are utilising tools that scale amazingly well, leading to reliable systems with little to no downtime. They’re easy to deploy, and require very little maintenance. We can’t say the same for Minecraft. The majority of server owners probably still SSH into a terminal window, or use their Control Panel provided by the host. It’s fiddly, hard to migrate, and hard to maintain. This game has expanded well beyond the realm of a video game. People are using it in schools for teaching, building communities; and even visualising real world data. Without a doubt, now could not be a better time to move this game up a Notch (pun entirely intended).

As annoying as the term is to some people, a microservice architecture could be exactly what large server owners are looking for. It provides the ability to scale the parts of the game which are the most taxing, thus closing the issue of slow performance once and for all. What if it was all automatically scaled, with no interaction from the developer or sysadmin? Wouldn’t that be amazing?

Well, this is kind of where the shameless plug comes into things. Right now I’m working on something very experimental. JungleTree, is an event-driven Minecraft server that has been a pet project of mine for quite some time. In fact, since I started programming for Minecraft it has existed in one form or another. As I’ve expanded my knowledge of Java and surrounding architecture, my design principles have shifted – leading to the current state of things over on my GitHub repository. As of tonight, I’ve started tinkering with messaging queues (ActiveMQ) – as well as Docker and Kubernetes. I’ve spent a bit of time drafting up how I want the architecture to look, and so… here it is.

JungleTree Architecture, taken straight out of my project book.
JungleTree’s architecture, taken straight out of my project book. Click image to see full scale. Left: The layers of the system. It really doesn’t explain things. No, the storage is not accessible from the Internet. Same with processing and plugins. This is what late night drawing does to me. Right: Where the magic happens. Those layers from the left can be seen in use here – indicating where the services should be partitioned away from each other.

I hope people get the jist of what I’m going with here. The diagram could be simpler, but I wanted to present the fact that there is not a single point of failure in the application.

Anyway, that’s all for this post. I’ll throw more of these up here as I get deeper into development.