I’m sad to see that microservices are falling in popularity among architects and developers.
However, many ‘do microservices’ (unintentionally) wrong, mimicking the external displays without harvesting the benefits. I’d say that thinking in microservices is the most useful design approach we’ve created as an industry and every software architect should adopt it.
Here I list 3 mistakes I often see that make some people dislike microservices.
Mistake 1: Confusing Microservices with Distributed Systems
When you chop your application into multiple servers/containers/lambdas, you haven’t created microservices.
Microservices require a lot of thinking about what logic should be together and what logic should be separate. The resulting areas form so-called Bounded Contexts (a term from DDD) that allow you to independently model that area’s problem. In each area, the same word (like User) has a different meaning so you need to be careful about translating from one context to another.
There is a lot of benefit in keeping these areas isolated and protected in a distributed system, so you bear with the increased complexity. Do not add complexity without that benefit.
Mistake 2: Independent Deployability over Design-Time Decoupling
It’s nice and efficient when you can make a production change in one service without deploying other services.
But if that change required synchronisation with other team(s) during development then only the last bit was efficient. I’m sure most developers would trade meetings and Slack messages with some difficulties during deployment any day of the week. There is a huge compounding payoff every time a team is free to develop features without hard dependencies.
Decoupling modules during design will help you make those modules independently deployable later; it doesn’t work the other way around.
Mistake 3: Unnecessarily Small Microservices
I think that the ‘micro’ in the name can mislead developers to create too many, too small microservices.
First, ‘micro’ does not mean the same as ‘atomic’: a piece of logic does not need its own service whenever you can draw some line around it. Second, let’s focus more on the final part: ‘service’. There should be enough functionality in a microservice that it would provide some useful, well, service. In my opinion, any need for distributed transactions is a strong indicator of too small microservices.
No simple rule (200 LOC, rewrite in two weeks, and even more reasonable ones like one-microservice-per-team) can replace a good, deep analysis of your system.
When you apply the microservices thinking and simultaneously avoid these mistakes you might come to the conclusion that your system needs only one microservice for now. That is fine and quite common. And yes, you end up with a ‘monolith’. Yet, you applied a powerful technique you can keep reusing. It was not a decision based on the fixed mindset of two competing patterns. Congrats.
When documenting APIs, developers often link to ISO 8601 as the standard for computer-readable date and date-time format. Dates and times (and time zones!) are complicated. There are so many edge cases and pitfalls. I’m sure every developer has a battle story about them. It’s good to delegate that hard work to somebody else. So when an international body that everybody knows and trusts publishes such a standard, it’s no surprise all the API designers start referring to it.
When I was working on my small side-project library, I needed to represent a missing value. In the past, I’d used the nullable approach in simple settings and Option (aka Maybe) when I wanted more control. In this case neither felt correct so I came up with a different approach I’d like to present.