%% date:: [[2023-05-09]] parent:: %% # [[Microservices vs Monoliths]] [[Microservices]] and [[Monolith]]s are types of software architecture that directly oppose each other in a fundamental way. While microservices-based architectures separate processes into [[Principle of Atomicity|atomic]] elements, monoliths combine them into a single, tightly [[Decoupling|coupled]] package. ## From monoliths to microservices The prevailing opinion is that monoliths are old-fashioned, and the industry in general has moved towards the thinking that microservices-based architecture are more efficient. ## From microservices to monoliths However, there have been recent instances of teams deciding to move to a monolithic structure from microservices, often after having begun with monoliths in the first place. - Segment [^segment] - InVision [^invision] ### Reasons teams switch back to monoliths #### Insufficient resources to handle microservices Segment mentioned that there was considerable effort to add a new service (rather than adding a few lines of code to a monolith). Their team ended up applying a single auto-scaling rule to every microservice, failing to take advantage of the increased level of customization due to the effort involved. [^segment] #### Difficulty in troubleshooting Microservices are more difficult to troubleshoot, due to their distributed nature. Monitoring must also be segmented to account for a segmented architecture, so an extra layer of complexity is necessary to make sure that the monitoring itself is [[Multi-tenant]]. [^simme] ## Which one is right for you? | Criteria | Architecture | | ---------------------------------- | ------------- | | Small team | Microservices | | Simple application | Monolith | | Complex application | Microservices | | No microservice experience | Monolith | | Little to no divisions within team | Monolith | | Smaller groups within team | Microservices | | | | ### Consider your team structure [[Conway's Law]] suggests that the structure your team has may affect which structure is better for you: ![[Conway's Law#Making the law proscriptive]] ### Microservices don't have to be micro ![[Microservices#^e45d5a]] Given this view, microservices may be the more flexible approach. Monoliths always mean 1 service, but microservices could mean 2 or more, which gives leeway for teams to decide how [[Principle of Atomicity|atomic]] they want to get. [^segment]: Betts, T. (2020). _To microservices and back again - Why Segment went back to a monolith_. Retrieved from [https://www.infoq.com/news/2020/04/microservices-back-again/](https://www.infoq.com/news/2020/04/microservices-back-again/) [[To Microservices and Back Again - Why Segment Went Back to a Monolith]] [^invision]: Nadel, B. (2018). _Why I've been merging microservices back into the monolith at InVision_. Retrieved from [https://www.bennadel.com/blog/3944-why-ive-been-merging-microservices-back-into-the-monolith-at-invision.htm](https://www.bennadel.com/blog/3944-why-ive-been-merging-microservices-back-into-the-monolith-at-invision.htm). [[Why I've Been Merging Microservices Back Into the Monolith at InVision]] [^simme]: Aronsson, S. (2021). _Intro to distributed tracing with Tempo, OpenTelemetry, and Grafana Cloud._ Retrieved from https://grafana.com/blog/2021/09/23/intro-to-distributed-tracing-with-tempo-opentelemetry-and-grafana-cloud . [[Intro to Distributed Tracing With Tempo, OpenTelemetry, and Grafana Cloud|My highlights]].