Oh Microservice Architecture!
The number of roles asking for developers to be experts in microservices architecture is a little baffling to me. There are a lot of roles asking for this though, microservices are popular. However when one asks the interviewer why they use them over other architectures, say SOA for example, the responses often seem to get a little confused. It isalmost as if the microservices architecture itself has acquired a mythical status as engineering snake-oil.
Consider the architect I.K. Brunel. Yeah sure his bridges, tunnels and railways are great. Would you want your garden shed to be designed in the style of the Greenwich foot tunnel?
Microservices are great for what they are great at. Breaking down a big thing into smaller things works well. But it also adds complexity at the devops stages. The cost of maintaining the model of the project in ones head increases, and therefore the cost of upgrading things becomes large as the number of smaller projects increase.
I made my CV as a SOA MVC website a few years ago. and it was nice. Everything was nicely bundled into a django website, it worked well. Then I wanted to learn ASP.Net MVC, so I converted it. After a while I thought I’d change my data layer to a seperate project. It worked nicely. Except then when I updated the entity framework in one project I had to do it in the other. This wasn’t a problem, they were all in one solution.
Then they were not in the same solution anymore. I split my CV into two solutions. One a web service, and one a web page. I could update my web page independently of the web service, this was nice. However then I wanted to update NewtonSoft Json, this meant updating in two solutions, not hard, but slightly harder than doing the job in one solution.
I then noticed that the models for both projects were repeated, so I created a thrid solution for the data models, which ere presented to both the web service and the web site in a single nuget package. This meant that whenever I Updated the model I then had to update both the web service and the web site solution.
I have also worked on “fully — microserviced” products in other areas. The complexity of processes and tools one has to use in order to maintain the smaller software packages in the whole system does not always make sense.
I have no idea what I might do to my CV project next, but the pattern repeats itself, that the smaller parts I break the software down into, the harder it becomes to maintain. I know there are tools out there to manage this, but when a simple monolith does the job, it can be cheaper than following the herd to the temple of microservices.
