Overview

MicroPlode – A Microservices Experiment

No Comments

Content

The Idea: What the heck does the term MicroPlode mean and what is this all about?
The Architecture: A first sketch on a Microservice Architecture for the playground project.
Some Technical Stuff: Well, here comes some technical stuff, yeah :-).
Conclusion & Outlook Reflecting on the thoughts and results so far and what are the ideas for proceeding with this project.

The Idea

Microservices! For sure a term you can hardly dodge in the IT world these days. First time I heard about it I thought something along those lines of “nice idea, sounds really interesting”. But pretty quickly daily routine in the project took over again and washed me away from it. Then – quite recently – an idea materialised in my brain while I was reading more and more about it: Instead of only reading about it in theory, let’s do this in practice using a small – but somewhat meaningful – “playground project”. And puh, there are tons of blog posts out there to read on the topic. For example lately I was reading through this more skeptical blog post on DZone including roughly 100 comments discussion. It was really interesting as it was going from technical aspects to social aspects and back again. I really gained some insights from that. In the end this encouraged me in my idea to try the whole thing out in practice. And thanks to our company’s great working model that allows us to spend a decent amount of time exploring new technologies, I have the opportunity to start this little experiment here and now :-).

The playground project will be a game based on an old gaming idea. Unfortunately I forgot the name of the original game, so if someone recognises the original game it would be great to leave me a comment. Thanks to a colleague the name of the original game is no longer a mystery :-). We will do it here with a slightly different playing field that is more like a chess board to simplify things a bit.

The game is played in turns with two or more players on a playing field that for the beginning is assumed to have a fixed size of 10×10 fields. When starting a new game, all fields are unoccupied. Players can occupy one empty field when it is their turn or they can increase the load on one field already owned by them.

  • If a field is empty, the field will be occupied by that player with a load of one.
  • If a field is already occupied by that player the load on that field will be increased by one.
  • Players can only access empty fields or those already occupied by them.
  • If after increasing the load a field has a load that is higher than the amount of direct neighbouring fields it explodes and gives a load to each of those neighbouring fields.
  • A field getting a load this way is changing ownership to the one of the exploded field. A load already on such a field is increased by one no matter by whom that field was owned previously.
  • A field getting a load this way might explode itself again leading to nice chain reactions.
  • If after the first round a player does not own any field on its turn that player lost the game.

It is really fun playing and I implemented this already a long time back using Java with SWT. Unfortunately I lost all the sources. So this is a nice goal to implement and at the same time I know it is possible in a reasonable amount of time. And it is fun implementing computer players for this, but that is a later story.

Thomas Jaspers

Long-term experience in agile software projects using
Java enterprise technologies. Interested in test automation tools and concepts.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Comment

Your email address will not be published. Required fields are marked *