An easy mistake to make with Microservices is simply choosing to use them in the first place, when the context calls for a different solution. Microservices have become “trendy”, all the cool kids are using them, leading to what Thoughtworks call “Microservices Envy”. The benefits of using Microservices can be really powerful, particularly in alleviating certain categories of problem – but this isn’t for free. There’s a significant complexity cost to implement Microservices, which is easily underestimated. What can happen all too often is that a project pays the high cost, but didn’t have the problems that Microservices solve, so the benefits don’t materialize.
Closely linked to this is the decision to build Microservices, when it is a good potential match to the problem, but with insufficient information. What can happen here is that the services that are built end up causing a lot of friction, because their boundaries are poorly defined, leading to problems and eventually rework. One suggested approach when tackling an unfamiliar problem is to use a “sacrificial architecture”. You choose an architecture that is cheap and fast to build, that you expect to then throw away later, but the point is to learn quickly about the problem without overcommitting. In some cases the result is that the “sacrificial” architecture works out just fine and doesn’t even need to be replaced. If you take this approach, it’s important to know what you’re looking for; in this case you’re trying to find areas of the whole solution that are separate and could become independent services. You may go into the exercise with an idea of what these will be, in which case try to avoid confirmation bias and objectively judge the results! Another common outcome from this approach is to find that there are some areas of the system that would benefit from being split out into separate services, but splitting apart the whole solution would offer diminishing returns.
To give yourself the best chance of success with Microservices, make choices that are backed by evidence. Build a simple system first, and when you experience specific pain that would be solved by introducing a service, that’s the time to do so. Be conscious of friction around service boundaries; if there’s two things that seem too closely connected, consider putting them together rather than trying to force them to be separate. Remember that Microservices is just one approach, and don’t get attached to it if the evidence points in a different direction.