MicroPlode – A Microservices Experiment
This blog post will differ quite a bit from the previous ones of this series. Now that even two codecentric colleagues have joined this experiment (hello Jonas and Bastian) we will take the chance to simply mix up our ideas and experiences in this blog post. It is great that we are a team of three now working on this. It enables a lot of interesting ideas and discussions and at the same time is of course better “simulating” working on a Microservices project as a team.
First of all an update on our “architecture” as it has evolved again. Especially a new presentation-service microservice has been added. This is definitly the source for some interesting discussions as we decided to go for one service doing all the GUI implementation and not spreading that responsibility to the individual services.
At the end of this blog post there are the links to the tagged versions of the code representing the current snapshot of the project.
Thomas: Well, of course this cannot be compared to a real customer project in complexity of the requirements and thus the needed interfaces, but still for me it felt very easy to get Jonas and Bastian on board in the project. After a short discussion on the content of the interfaces (the different messages we are sending back and forth) there are not really a lot of things to agree on. We are working in separated (Java) projects for now.
Jonas: And now I am in. All I did was to read Thomas’ blogpost. Ok, and we gabbed about our experiences regarding microservices. Then these idea came into our minds and I took over the game service, where one doesn’t need much experience with Hexplode. It started out, that I won’t go for Python – but at least I thought about it 🙂 SpringBoot was already set up and highly appreciating, so I stuck with it. But there was one more thing, we had to agree on – the underlying messaging infrastructure. And I appreciated RabbitMQ, too – although not really fancy, but working for our needs.
One of my first impressions: If you use the same language for 2 or more microservices and u have a common interface-format (which you simply need), than maybe copying Pojos for that would be ok 🙂 I know, sharing domain objects is evil. But we don’t share anything else in the future, I swear!
Second impression: Starting all microservices on your local machine will make you fan of a Terminal with tabs. Without that you will get in trouble trying to stay on top of things.
Third one: Oh my… We need a messaging infrastructure! It’s obvious, but funnily enough I forgot. Well that reminds me of something… What was it called…?!
Thomas: The discussions about the frontend/UI are really interesting as they go back and forth. There is this kind of paradigm that a microservice contains everything it needs. This would include UI elements. But what if there are UI elements that are shared by two microservices? Then it cannot be really included into one of the services. Maybe this might indicate that your services are not sliced properly, but somehow I doubt that and otherwise things would probably become more monolithic again.
We did not make this an easy decision for us, but for the time being we introduced an additional service for this, namely the presentation-service. That one will one the one hand side communicate to the other services via messaging, but will also contain the complete UI. What I like about this is that the kind of technology used to communicate between frontend and backend is encapsulated this way in this service.