6 ms·

Mmmmyes and no. Depending on the size of your project, that may not be the case. I've had to work with two titans of monoliths, maintained by relatively small t

Mmmmyes and no. Depending on the size of your project, that may not be the case. I've had to work with two titans of monoliths, maintained by relatively small teams(anywhere between 2 and 6-7 people for several million lines of code). At some point managing a codebase this big within a single project becomes a huge burden, for both developers and even more so for those who develop and do code-reviews(first hand experience right here). At times I've spent 3 weeks straight doing code reviews with 2 notebooks filled with notes and diagrams of the different components inside the code. And at that point, the easiest and most sensible thing to do is chunk out large parts of the project and put them aside as a microservice with the adequate amounts of tests. For small projects, microservices make little absolutely no sense. But in the case of something the size of AdWords(which my two such experiences can be compared to), you are playing with a raging lion if you decide to go monolith. My argument here is that it's not so much the size of your team but rather the size and scale of your project that needs to be taken into consideration.

BareNakedCoder 7y ago
Good monoliths are highly modularized. But it's a whole different thing to package up a module as a separately deployable unit for external "public" use (external to your app, that is, not your company). I'm just curious to know, when you said "the easiest and most sensible thing to do is chunk out large parts of the project and put them aside as a microservice" ... were these chunks separately deployable units for external "public" use.
- joshdick 7y ago
  You're right, and I think you've highlighted what makes a good monolith so hard to build and maintain. You need to be disciplined to keep a monolith highly modularized. For microservices, in contrast, their architecture encourages modularization.
  - tinkertamper 7y ago
    I don’t know that you need to be much more disciplined to write a large application in a module way vs writing any application in a modular way. A monolith could definitely get messy though if you write them how I see people write microservices.
- fennecfoxen 7y ago
  I think this is actually one of the reasons that microservices became a thing to begin with: teams wouldn't actually apply engineering best practices. Microservices actually make you encapsulate your code, at least within the microservices, because you can't call out to it directly. They don't necessarily force you to implement the single responsibility principle, but they do a good job of pushing you. Microservices implement a service-locator pattern through DNS or web routing, one form of the dependency inversion principle. Microservices make you pass data around as entities, instead of Active Record instances. The price for this sort of thing is very steep, though; distributed systems are inherently icky, harder to trace, and more prone to failure, and besides this, you've added network overhead to each service call. I wish more engineering teams would consider spending half the effort of microservices on simply disciplining their monoliths. They might get somewhere...
  - momokoko 7y ago
    > They don't necessarily force you to implement the single responsibility principle, but they do a good job of pushing you. In my experience, if your services are developed by the same people, and not separated by teams, engineers will often tightly couple the services with fragile and opaque dependent changes regardless. While in monolith this is painful, at least you have a complete stack trace and the ability to run things through a step debugger you orient yourself. In a distributed system tribal knowledge tends to be your only savior. When we design systems, we need to spend more time thinking about what is most likely to happen as opposed to what we feel should happen.
  - goostavos 7y ago
    >I wish more engineering teams would consider spending half the effort of microservices on simply disciplining their monoliths 100%. This is an uphill battle, though. I've encountered so many engineers who equate "real engineering" with "building giant machines." You just can't convince them otherwise. I've watched people build giant, real-time stream processing pipelines compromising tons of moving pieces (lambda, sqs, s3, sns, stepFunctions, etc..) to build... a reporting table, and all for... 1.3gb of data. Literally. Ultimately, despite the "sell," I don't think microservices as a forcing function for good practices works in practice. If the team lacks the skills to build a disciplined monolith, then they 100% lack the skills to build a distributed one.
- axegon_ 7y ago
  Oh, all of those were heavily modularized to begin with. But that wasn't enough to keep them manageable. So at the end what we did is figure out which are the core components between the different modules, isolate what they did and put them aside in a smaller microservices, which were easier to track, maintain and monitor. What was once the monolith is now arguably just an interface/API for all the heavy lifting which is done by microservices. Again, my point is that all this must be done depending on the scale and complexity of your application. If you are going to make an authentication microservice for an application that has 50,000 users which simply fetches a username and compares a hash in a database, obviously you are doing it wrong. I am talking about applications which in the simplest of times operated on 24 different databases located in completely different geographical locations(the case of my first such monolith). Some of those databases used different engines. And due to the nature of the infrastructure and the requirements we couldn't simply ditch everything and start over from scratch. So splitting everything into microservices was the only option. And this is something I was working on back in 2012 iirc so back when microservices were considered witchcraft by most people. And yes, I'm talking about several million lines of code and 2 developers - my inexperienced out of uni ass, and an utterly conservative dev twice my age. Took us around 6 months but the project was extremely successful. There is this trend in technology - every few years everyone changes their minds about everything: * 2012 - sql is the best. * 2016 - sql sucks, nosql is the future * 2020 - nosql suck, sql is the best. * 2024 - {fill in the blank}. The same thing is happening with microservices. But in addition docker, kubernetes and recently unikernels have joined the party. The concept is the same though. What I am trying to say is that either of those can be good or bad in different scenarios. It's a question of picking the most appropriate one for the situation.
  - pjmlp 7y ago
    The fun is that we have seen this so many times. Sun RPC, CORBA, DCE, DCOM, XML-RPC, SOAP, REST, gRPC,....
dasil003 7y ago
If you've got 7 people maintaining millions of lines of code, you're going to have a heavy burden no matter what you do. Extracting a service does not a priori simplify anything. It can encapsulate and enforce a more strict boundary, and optimize compile time or test suite throughput and operations for the extracted logic, but it always comes with overhead, and if the interface between the services is not well-defined and stable it can easily be a net-negative in terms of productivity as you are now giving up your in-language tools for distributed systems tools. Now if you have large swathes of code stable functionality, then it's easier, but at that point why not just isolate modules within the same codebase?

BareNakedCoder 7y ago

Good monoliths are highly modularized. But it's a whole different thing to package up a module as a separately deployable unit for external "public" use (external to your app, that is, not your company). I'm just curious to know, when you said "the easiest and most sensible thing to do is chunk out large parts of the project and put them aside as a microservice" ... were these chunks separately deployable units for external "public" use.

joshdick 7y ago
You're right, and I think you've highlighted what makes a good monolith so hard to build and maintain. You need to be disciplined to keep a monolith highly modularized. For microservices, in contrast, their architecture encourages modularization.
- tinkertamper 7y ago
  I don’t know that you need to be much more disciplined to write a large application in a module way vs writing any application in a modular way. A monolith could definitely get messy though if you write them how I see people write microservices.
fennecfoxen 7y ago
I think this is actually one of the reasons that microservices became a thing to begin with: teams wouldn't actually apply engineering best practices. Microservices actually make you encapsulate your code, at least within the microservices, because you can't call out to it directly. They don't necessarily force you to implement the single responsibility principle, but they do a good job of pushing you. Microservices implement a service-locator pattern through DNS or web routing, one form of the dependency inversion principle. Microservices make you pass data around as entities, instead of Active Record instances. The price for this sort of thing is very steep, though; distributed systems are inherently icky, harder to trace, and more prone to failure, and besides this, you've added network overhead to each service call. I wish more engineering teams would consider spending half the effort of microservices on simply disciplining their monoliths. They might get somewhere...
- momokoko 7y ago
  > They don't necessarily force you to implement the single responsibility principle, but they do a good job of pushing you. In my experience, if your services are developed by the same people, and not separated by teams, engineers will often tightly couple the services with fragile and opaque dependent changes regardless. While in monolith this is painful, at least you have a complete stack trace and the ability to run things through a step debugger you orient yourself. In a distributed system tribal knowledge tends to be your only savior. When we design systems, we need to spend more time thinking about what is most likely to happen as opposed to what we feel should happen.
- goostavos 7y ago
  >I wish more engineering teams would consider spending half the effort of microservices on simply disciplining their monoliths 100%. This is an uphill battle, though. I've encountered so many engineers who equate "real engineering" with "building giant machines." You just can't convince them otherwise. I've watched people build giant, real-time stream processing pipelines compromising tons of moving pieces (lambda, sqs, s3, sns, stepFunctions, etc..) to build... a reporting table, and all for... 1.3gb of data. Literally. Ultimately, despite the "sell," I don't think microservices as a forcing function for good practices works in practice. If the team lacks the skills to build a disciplined monolith, then they 100% lack the skills to build a distributed one.
axegon_ 7y ago
Oh, all of those were heavily modularized to begin with. But that wasn't enough to keep them manageable. So at the end what we did is figure out which are the core components between the different modules, isolate what they did and put them aside in a smaller microservices, which were easier to track, maintain and monitor. What was once the monolith is now arguably just an interface/API for all the heavy lifting which is done by microservices. Again, my point is that all this must be done depending on the scale and complexity of your application. If you are going to make an authentication microservice for an application that has 50,000 users which simply fetches a username and compares a hash in a database, obviously you are doing it wrong. I am talking about applications which in the simplest of times operated on 24 different databases located in completely different geographical locations(the case of my first such monolith). Some of those databases used different engines. And due to the nature of the infrastructure and the requirements we couldn't simply ditch everything and start over from scratch. So splitting everything into microservices was the only option. And this is something I was working on back in 2012 iirc so back when microservices were considered witchcraft by most people. And yes, I'm talking about several million lines of code and 2 developers - my inexperienced out of uni ass, and an utterly conservative dev twice my age. Took us around 6 months but the project was extremely successful. There is this trend in technology - every few years everyone changes their minds about everything: * 2012 - sql is the best. * 2016 - sql sucks, nosql is the future * 2020 - nosql suck, sql is the best. * 2024 - {fill in the blank}. The same thing is happening with microservices. But in addition docker, kubernetes and recently unikernels have joined the party. The concept is the same though. What I am trying to say is that either of those can be good or bad in different scenarios. It's a question of picking the most appropriate one for the situation.
- pjmlp 7y ago
  The fun is that we have seen this so many times. Sun RPC, CORBA, DCE, DCOM, XML-RPC, SOAP, REST, gRPC,....

dasil003 7y ago

If you've got 7 people maintaining millions of lines of code, you're going to have a heavy burden no matter what you do. Extracting a service does not a priori simplify anything. It can encapsulate and enforce a more strict boundary, and optimize compile time or test suite throughput and operations for the extracted logic, but it always comes with overhead, and if the interface between the services is not well-defined and stable it can easily be a net-negative in terms of productivity as you are now giving up your in-language tools for distributed systems tools. Now if you have large swathes of code stable functionality, then it's easier, but at that point why not just isolate modules within the same codebase?