# Why I've Been Merging Microservices Back Into the Monolith at InVision ![rw-book-cover](https://bennadel-cdn.com/resources/uploads/2020/thanos-inserting-the-last-inifinity-stone.gif) URL:: https://www.bennadel.com/blog/3944-why-ive-been-merging-microservices-back-into-the-monolith-at-invision.htm Author:: Ben Nadel ## Highlights > A **Technical problem** is one in which an aspect of the application is putting an undue burden on the infrastructure; which, in turn, is likely causing a poor user experience (UX). For example, image processing requires a lot of CPU. If this CPU load becomes too great, it could start starving the rest of the application of processing resources. This could affect system latency. And, if it gets bad enough, it could start affecting *system availability*. ([View Highlight](https://read.readwise.io/read/01fddp98k3ptknct7j9bk9p2dy)) > A **People problem**, on the other hand, has little to do with the application at all and everything to do with how your team is organized. The more people you have working in any given part of the application, the slower and more error-prone development and deployment becomes. For example, if you have 30 engineers all competing to "Continuously Deploy" (CD) the same service, you're going to get a lot of queuing; which means, a lot of engineers that *could otherwise be shipping product* are actually sitting around waiting for their turn to deploy. ([View Highlight](https://read.readwise.io/read/01fddp9dm39nf3cvhw4y5xyzf5)) > As I mentioned above, having a lot of people all working in the same place can become very problematic. Not only were the various teams all competing for the same deployment resources, it meant that every time an "Incident" was declared, several teams' code had to get rolled-back; and, *no team could deploy* while an incident was being managed. As you can imagine, this was causing a *lot of friction* across the organization, both for the engineering team and for the product team. ([View Highlight](https://read.readwise.io/read/01fddpan3sqv418j61gmndsc9h)) > And so, "microservices" were born to solve the **"People problem"**. A select group of engineers started drawing boundaries around parts of the application that they felt corresponded to *team boundaries*. This was done so that teams could work more independently, deploy independently, and ship more product. Early InVision microservices had *almost nothing to do* with solving technical problems. ([View Highlight](https://read.readwise.io/read/01fddpaqt9a96w83sfhtd6ftjn)) > If you work with microservices, you've undoubtedly heard of ["Conway's Law"](https://en.wikipedia.org/wiki/Conway%27s_law), introduced by [Melvin Conway](https://www.melconway.com/) in 1967. It states: > > Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. > This law is often illustrated with a "compiler" example: > > If you have four groups working on a compiler, you'll get a 4-pass compiler. > The idea here being that the solution is "optimized" around team structures (and team communication overhead) and not necessarily designed to solve any particular technical or performance issues. ([View Highlight](https://read.readwise.io/read/01fddpbmq3zy4wqdz6s1m1s6zc)) > In short, all the *benefits* of Conway's Law for the organization have become **liabilities** over time for my "legacy" team. And so, we've been trying to "right size" our domain of responsibility, bringing balance back to Conway's Law. Or, in other words, we're trying to alter **our service boundaries** to match **our team boundary**. Which means, **merging microservices *back* into the monolith**. ([View Highlight](https://read.readwise.io/read/01fddpd9kcqd4a6cxc4a4wc5ax)) > Perhaps the worst thing that's ever happened to the microservices architecture is the term, "micro". Micro is a *meaningless* but heavily loaded term that's practically dripping with historical connotations and human bias. A far more helpful term would have been, "right sized". Microservices were never intended to be "small services", they were intended to be "right sized services." ([View Highlight](https://read.readwise.io/read/01fddpdnhg6vhyz5z2wj02fhx5)) > Service don't run in the abstract: they run on servers and talk to databases and report metrics and generate log entries. All of that has a very real dollars-and-cents cost. So while your "lambda function" doesn't cost you money when you're not using it, your "microservices" most certainly do. Especially when you consider the redundancy that you need to maintain in order to create a "highly available" system. ([View Highlight](https://read.readwise.io/read/01fddpfc9bfsyjhxem3zvecxms)) --- Title: Why I've Been Merging Microservices Back Into the Monolith at InVision Author: Ben Nadel Tags: readwise, articles date: 2024-01-30 --- # Why I've Been Merging Microservices Back Into the Monolith at InVision ![rw-book-cover](https://bennadel-cdn.com/resources/uploads/2020/thanos-inserting-the-last-inifinity-stone.gif) URL:: https://www.bennadel.com/blog/3944-why-ive-been-merging-microservices-back-into-the-monolith-at-invision.htm Author:: Ben Nadel ## AI-Generated Summary Ben Nadel explains why his team has been hard at work merging "microservices" back into the "monolith". His team is not anti-microservices. And, in fact, both the expanding and the contracting of services have been driven by the same underlying point-of-friction. ## Highlights > A **Technical problem** is one in which an aspect of the application is putting an undue burden on the infrastructure; which, in turn, is likely causing a poor user experience (UX). For example, image processing requires a lot of CPU. If this CPU load becomes too great, it could start starving the rest of the application of processing resources. This could affect system latency. And, if it gets bad enough, it could start affecting *system availability*. ([View Highlight](https://read.readwise.io/read/01fddp98k3ptknct7j9bk9p2dy)) > A **People problem**, on the other hand, has little to do with the application at all and everything to do with how your team is organized. The more people you have working in any given part of the application, the slower and more error-prone development and deployment becomes. For example, if you have 30 engineers all competing to "Continuously Deploy" (CD) the same service, you're going to get a lot of queuing; which means, a lot of engineers that *could otherwise be shipping product* are actually sitting around waiting for their turn to deploy. ([View Highlight](https://read.readwise.io/read/01fddp9dm39nf3cvhw4y5xyzf5)) > As I mentioned above, having a lot of people all working in the same place can become very problematic. Not only were the various teams all competing for the same deployment resources, it meant that every time an "Incident" was declared, several teams' code had to get rolled-back; and, *no team could deploy* while an incident was being managed. As you can imagine, this was causing a *lot of friction* across the organization, both for the engineering team and for the product team. ([View Highlight](https://read.readwise.io/read/01fddpan3sqv418j61gmndsc9h)) > And so, "microservices" were born to solve the **"People problem"**. A select group of engineers started drawing boundaries around parts of the application that they felt corresponded to *team boundaries*. This was done so that teams could work more independently, deploy independently, and ship more product. Early InVision microservices had *almost nothing to do* with solving technical problems. ([View Highlight](https://read.readwise.io/read/01fddpaqt9a96w83sfhtd6ftjn)) > If you work with microservices, you've undoubtedly heard of ["Conway's Law"](https://en.wikipedia.org/wiki/Conway%27s_law), introduced by [Melvin Conway](https://www.melconway.com/) in 1967. It states: > > Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. > This law is often illustrated with a "compiler" example: > > If you have four groups working on a compiler, you'll get a 4-pass compiler. > The idea here being that the solution is "optimized" around team structures (and team communication overhead) and not necessarily designed to solve any particular technical or performance issues. ([View Highlight](https://read.readwise.io/read/01fddpbmq3zy4wqdz6s1m1s6zc)) > In short, all the *benefits* of Conway's Law for the organization have become **liabilities** over time for my "legacy" team. And so, we've been trying to "right size" our domain of responsibility, bringing balance back to Conway's Law. Or, in other words, we're trying to alter **our service boundaries** to match **our team boundary**. Which means, **merging microservices *back* into the monolith**. ([View Highlight](https://read.readwise.io/read/01fddpd9kcqd4a6cxc4a4wc5ax)) > Perhaps the worst thing that's ever happened to the microservices architecture is the term, "micro". Micro is a *meaningless* but heavily loaded term that's practically dripping with historical connotations and human bias. A far more helpful term would have been, "right sized". Microservices were never intended to be "small services", they were intended to be "right sized services." ([View Highlight](https://read.readwise.io/read/01fddpdnhg6vhyz5z2wj02fhx5)) > Service don't run in the abstract: they run on servers and talk to databases and report metrics and generate log entries. All of that has a very real dollars-and-cents cost. So while your "lambda function" doesn't cost you money when you're not using it, your "microservices" most certainly do. Especially when you consider the redundancy that you need to maintain in order to create a "highly available" system. ([View Highlight](https://read.readwise.io/read/01fddpfc9bfsyjhxem3zvecxms))