Microservices are one of the hype topics I didn’t manage to have a look at. So this week I was lucky finding that the cover story of the Java Magazin (issue 5.16) is “Microservices – the hype in the reality check”. Also, the local JUG organized a talk about “The Otto microservice system – Build pipelines as code, Continuous Deployment and all the tools”. Yeay, perfect!
Of course this is not the first time I heard about microservices. For example, I read about them in the context of OSGI, where they are used to modularize the codebase. So in my mind microservices are an architectural tool that you can develop using code. Why not? In my world, which is the Java world, you can spend days arguing about how to implement service-classes. (Hint: In Spring, Use a factory that creates service-instances that are created using the fluent API of the builder pattern.)
Part 1: The Articles
So I began reading the articles in the Java Magazin. I was right with seeing microservices as a tool to modularize code, good. Microservices can be deployed independent from each other and don’t (necessarily) run in the same environment. So each microservice can be written in another language. Spontaneously, several projects come to my mind that would benefit from having a mathematical problem solved in something like Scala, logic in something like Clojure and … something else in Java. ;) The small units of code support the rewrite of code fragments because the interfaces between them are already well defined. How often I wanted to rewrite something just to realize how integrated this thing is into the puddle of brown, rotten code-mud around it …
The author also writes about how robust microservices are because of the independence between them, and how well they scale. If deployed in Docker containers, they are very easy to organize, configure and share. This was the moment I realized why everyone was talking about Docker the last months – it’s perfect for microservices! “Nice”, I think, “Let’s see how they get implemented!” Turning to the next page, expecting code listings, I just read about how fast these small microservices can be started and some other technical advantages.
Seemingly, there are also downsides. Microservices solve problems on the technical level (however I didn’t see any code yet), but the real challenge lies in the organizational changes microservices require. For example the acquisition of the necessary build pipeline that builds, deploys and monitors the services. And the change in the responsibility of the development team, which now should run the services they created instead of “just” programming them and letting someone from operations run them. Letting developers run things of course has a lot of unexpected consequences, like when they want to write their own monitoring applications.
And then, suddenly, I came to the end of the couple of articles about microservices. Wait, no code listings about how to implement them? Well, no. That surprised me. Can it be that microservices are only an architectural idea rather than a framework-supported thing you can just write down in your favorite IDE?
Part 2: The Talk
With that thought in mind, I went to the JUG talk. This one started like the articles ended: With a report about how the team of the speaker implemented their system in the organizational context. They were especially proud that they managed to build a pipeline that enabled them to deploy the latest code at any time. Even now. Or in one hour. Extremely fast, though. “Nice”, I thought again. This had another advantage for their customer, Otto, which is one of the big mail order companies in Germany. Being able to deploy real fast enables Otto to monitor the reaction of the customers to the changes and, if necessary, releasing another version real fast. When I think about what a huge problem each single deployment in my former projects can be, this is totally another world.
To deliver that ability, the author talked about what each member of the development team should know. Every coder should know and understand the tools and be able to deploy on his own. Also, “rock-solid, automated testing is what you want!” I cannot agree enough.
The major part of the talk went on about the deployment structure that the author and his colleagues wrote themselves, which is pretty impressive. Basically, the whole thing is code. You can very simply change things, version changes, roll them back and write your own special deployment process with it.
The talk closed with tips on how big microservices should be (begin with bigger scope and cut down if possible), that they should not depend on other microservices too much (because then they would not be robust) and a lot of very detailed questions from the audience.
Eating my cheese roll and talking to other coders after the event confirmed my feeling: Microservices are a relatively vague thing that can be very powerful, but need a lot of organizational change to work. The technical implementation is not subject of the concept itself.
TL;DR
Microservices are an architectural pattern that can be implemented in several ways. Microservices support small, independent code bases that together form an application, even when the different parts are implemented in different programming languages using different runtime environments. Microservices need a lot of organizational change to work.
