Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest.
The familiar software project, at least as seen by the nontechnical manager, has something of this character… But, we see no silver bullet.
During the last decade, Microservices have been very popular. It seems that a lot of people believe they will solve each of the issues in their applications. They indeed provide several benefits, but you have to carefully analyze their pros and cons to unleash their full potential. In other words, Microservices are great, but only if you know when they make sense.
In general, every technology decision has multiple trade-offs. There’s no such a thing as a perfect solution. Almost always, you have to conform with a good enough one. Which one should be? Well, that’s one of the hardest things about developing and designing information systems. For instance, Microservices add a lot of complexity to your system to improve scalability, agility and robustness.
Bear in mind that Microservices are just a way to achieve your goals. Before adopting them, you should consider alternatives that could be less expensive in terms of costs or/and time. If you finally decide to migrate your system to Microservices, you must constantly monitor what is happening and see if you are accomplishing your goals.
I recently read a couple of books about this topic, such as Microservices Patterns by Chris Richardson and Monolith to Microservices by Sam Newman. These are great books with many considerations to keep in mind when implementing Microservices. In particular, Sam Newman wrote about a few things to consider before deciding to adopt this architecture. I find them very interesting, so let’s see what he thinks about it.
- What are you hoping to achieve ?
- Have you considered alternatives to using microservices?
- How will you know if the transition is working.
- Improve team autonomy
- Reduce time to market
- Scale cost-effectively for load
- Improve robustness
- Scale the number of developers
- Embrace new technology
- Unclear domain
- Customer-Installed and managed software
- Not having a good reason