Microservices

Quick takeaways Start with a monolith - don’t create microservices from day one; the overhead isn’t worth it until you have real pain points Microservices solve human problems, not just technical ones - they help teams work independently, not just scale systems Tight coupling over HTTP is still tight coupling - separating services doesn’t automatically give you isolation Watch for signals - lots of calls between services or frequent changes across multiple services suggest wrong boundaries Sometimes joining services is the answer - merging tightly coupled microservices back together can be the right move Introduction We talk about splitting software: when to do it, how to avoid common pitfalls, and why microservices aren’t always the answer.

Do you know the rare feeling when you develop a new application from scratch and can cover all lines with proper tests? I said “rare” because most of the time, you work with software that has a long history, multiple contributors, and a less-than-obvious testing approach. Even if the code uses good patterns, the test suite doesn’t always follow. Some projects have no modern development environment set up, so there are only unit tests for things that are easy to test.

If you’re here for the first time, this post is part of our Business Applications in Go series. Previously, we introduced Wild Workouts, our example application built with modern tools but containing some subtle anti-patterns. We added them on purpose to show common pitfalls and how to avoid them. In this post, we begin refactoring Wild Workouts. Previous articles will give you more context, but reading them isn’t necessary to understand this one.

Nowadays we can often hear that monolithic architecture is obsolete and responsible for all evil in IT. We often hear that microservices architecture is a silver bullet which helps to kill all this monolithic evil. But you probably know that there are almost no silver bullets in IT and every decision entails trade-offs. One of the most favored advantages of microservices architecture is good modules separation.