I understand your point, but mine is not about the technical part and only on the human aspect.
Since you've checked my Linkedin, you might saw that I'm coming from a business formation, I studied and worked with HR and things like that.
If you check the Stackoverflow surveys on the last years you see that some languages started paying more and more, while others, like JS pay on average less and less.
Why? As Uncle Bob says, every 5 years the number of programmer doubles (I'm not sure how valid this is, but I gonna assume this as true).
When people learn, and I'm using myself and people near me as references. We don't go learning C, Perl or Ruby. Many universities are even dropping from teaching C/Pascal to Python.
New people will learn the "new" and the "hot" languages and frameworks, and they will want to work with that.
AngularJS was released around 12 years ago and there are companies that still haven't let go of it, even as it hit the end of official support. (I know of a low code platform where it's components and everything that is offered is based on AngularJS, if you want to design custom components, you have to make it in AngularJS even.)
Angular2 is another approach and other frameworks appeared and died in between.
Their application is a "monolith" (even if it isn't really), if as time progressed they embraced the new frameworks, new components and features could have been done on other frameworks.
I know it's a nightmare to have multiple frameworks and other crazy stuff instead of one big monolith where you have all the groundwork, utils and everything else you need already done and ready to use.
(And you can mess up in one way or another, so let's just assume equivalent levels of mess.)
But, 5 years from now, let's say they continue with AngularJS, their costs will only rise, as people with the knowledge of it will only dwindle. It will also kept harder and harder to maintain, after all, now you even have to probably have a internal fork that you have to maintain.
Either that, or they would have to bear costs to train people in a framework that's 'dead', having people with lower levels of experience with a framework that will be harder and harder to learn and maintain.
I know people that used to program in COBOL, and they just don't want to work with it anymore. Companies might pay their weight in gold, but they don't want it.
So either you have people who have to start learning it from whatever source that is or you have to pay a premium to people who are able to work with it.
But now, let's say they embraced the nightmare that is to have smaller "services", the AngularJS part would be just one small part of the whole and years ago, probably even before the end of life of it, they would already had migrated it.
Or maybe, not even that! Maybe it's consistent enough to still work without problems, so there's not even a need to think about rewriting it.
Hiring people who know the new and hot stuff is easier and cheaper, the developer's themselves probably appreciate being able to use the fresh stuff than to learn some arcane framework.
People change jobs as often as they change cars, and being familiar with new technologies is something most developers want because that's the bulk of what the positions are after.
And of course, things like micro front ends is one solution for this problem.
It's now easier than ever to have multiple different frameworks in one project.
And before I diverge more, basically my whole point is about the human factor of the equation.
What about the human aspect? Complexity always increases as project evolves. You cannot avoid that. You can only make things worse if your architecture is inadequate.
I checked your linkedIn profile to get some idea how much experience you have in designing and maintaining software. Your business experience may give you some perspective what the business needs, but not how software works and how much effort is required to maintain the codebase and what are the downsides of some architecture decisions.
Every project has it's lifespan - this is true, so your observations on "we cannot keep using the old COBOL systems indefinitely" are correct. However it's not because we cannot find competent people to maintain them, nor because all new hires don't want to work with old programming languages, but because it's more efficient to use the new tools. As I mentioned before - money is king - if you have to pay a monthly salary to someone to create some functionality using COBOL, while using Python the same can be developed within a few hours - it's obvious what the business will prefer.
Every project reaches some state where maintaining some portions of it (or the entire project) are too expensive, so a re-do may be the better option. I'm are not talking about design flaws here (although this is a common case) but rather about the business needs outgrowing the original design. For example if we originally designed a car we may attach a trailer, we may upgrade the suspension and engine, but we cannot make a train no matter how much we upgrade the car. You cannot build a freightliner from a car although both use regular roads.
I think you get my point - if you NEED - you may redo some portion of the monolith by splitting it into a microservice and you can do that using whatever language/framework/etc. you want. Just don't do that "because it's fancy and the new hire prefers to use this instead of learn how to patch the existing code".
Nobody likes working on someone else's code. It seems easy to start over from scratch and it all looks clean, however if you go that path soon you will end with "Peter's project, Hanna's project, Joshua's project" and everyone will insist on working on their own project and not touching someone else's. The fun part starts when you get into a problem and you need to figure out where this is and apparently Joshua is on vacation and Peter left the company last year. Trust me - I've been there and done that over the past 30 years (yeah, I am a software engineer since 1992).
You want to keep the code as unified as possible and split microservices ONLY if you NEED to do that. Not because you want to do it or because "we can do it better". You should do that only if you have no other choice or if maintaining the old code is proven to be really ineffective.
As someone with about 6 years of software dev experience, I'm curious to know what your opinion is on when a microservice should be used. I've mostly worked on monolithic backends. Are there any resources you've found that are helpful when determining when to use one over the other?
The best rule to judge if you need them is: Don't unless you don't have any other option (or the costs of not doing so are multiple times higher).
Here are some valid use cases:
Scalability and redundancy - obviously it's easier to have multiple small EC2 instances that perform some computation. Smaller VMs are easy to start on-demand. For example a food delivery company (Grubhub, Takeaway, Ubereats, Doordash etc) has a few "rush hours" when customers order, then it gets back to near zero. Another good use case is when you have a slow operation (CPU-intensive or communicating with external APIs) it makes sense to have multiple instances of a microserice instead of spinning off the entire monolyth.
Partial redo of an old system - when you have a big old system, created over a decade ago, usually it's maintenance gets harder and harder over time. It's perfectly ok to rewrite portions of it as microservices in order to decrease maintenance costs, improve performance and implement new functionality.
Memory and cache - if you have some processing that requires a lot of memory or caching (although we have distributed cache like Redis) - it makes perfect sense to extract this as a separate microservice. Implementing custom cache if you need it is ok. Multiple instances using less memory is cheaper to create than a bit less instances using much more memory. Here applies the second part of the rule - it's cost.
Please note that for all of the examples the main rule applies - you don't have any other option or it will cost you much more if you keep the monolyth.
PS: I'm sure that we can come up with more good examples, this is just what came to my mine for the brief time I decided to answer.
I understand your point, but mine is not about the technical part and only on the human aspect.
Since you've checked my Linkedin, you might saw that I'm coming from a business formation, I studied and worked with HR and things like that.
If you check the Stackoverflow surveys on the last years you see that some languages started paying more and more, while others, like JS pay on average less and less.
Why? As Uncle Bob says, every 5 years the number of programmer doubles (I'm not sure how valid this is, but I gonna assume this as true).
When people learn, and I'm using myself and people near me as references. We don't go learning C, Perl or Ruby. Many universities are even dropping from teaching C/Pascal to Python.
New people will learn the "new" and the "hot" languages and frameworks, and they will want to work with that.
AngularJS was released around 12 years ago and there are companies that still haven't let go of it, even as it hit the end of official support. (I know of a low code platform where it's components and everything that is offered is based on AngularJS, if you want to design custom components, you have to make it in AngularJS even.)
Angular2 is another approach and other frameworks appeared and died in between.
Their application is a "monolith" (even if it isn't really), if as time progressed they embraced the new frameworks, new components and features could have been done on other frameworks.
I know it's a nightmare to have multiple frameworks and other crazy stuff instead of one big monolith where you have all the groundwork, utils and everything else you need already done and ready to use.
(And you can mess up in one way or another, so let's just assume equivalent levels of mess.)
But, 5 years from now, let's say they continue with AngularJS, their costs will only rise, as people with the knowledge of it will only dwindle. It will also kept harder and harder to maintain, after all, now you even have to probably have a internal fork that you have to maintain.
Either that, or they would have to bear costs to train people in a framework that's 'dead', having people with lower levels of experience with a framework that will be harder and harder to learn and maintain.
I know people that used to program in COBOL, and they just don't want to work with it anymore. Companies might pay their weight in gold, but they don't want it.
So either you have people who have to start learning it from whatever source that is or you have to pay a premium to people who are able to work with it.
But now, let's say they embraced the nightmare that is to have smaller "services", the AngularJS part would be just one small part of the whole and years ago, probably even before the end of life of it, they would already had migrated it.
Or maybe, not even that! Maybe it's consistent enough to still work without problems, so there's not even a need to think about rewriting it.
Hiring people who know the new and hot stuff is easier and cheaper, the developer's themselves probably appreciate being able to use the fresh stuff than to learn some arcane framework.
People change jobs as often as they change cars, and being familiar with new technologies is something most developers want because that's the bulk of what the positions are after.
And of course, things like micro front ends is one solution for this problem.
It's now easier than ever to have multiple different frameworks in one project.
And before I diverge more, basically my whole point is about the human factor of the equation.
What about the human aspect? Complexity always increases as project evolves. You cannot avoid that. You can only make things worse if your architecture is inadequate.
I checked your linkedIn profile to get some idea how much experience you have in designing and maintaining software. Your business experience may give you some perspective what the business needs, but not how software works and how much effort is required to maintain the codebase and what are the downsides of some architecture decisions.
Every project has it's lifespan - this is true, so your observations on "we cannot keep using the old COBOL systems indefinitely" are correct. However it's not because we cannot find competent people to maintain them, nor because all new hires don't want to work with old programming languages, but because it's more efficient to use the new tools. As I mentioned before - money is king - if you have to pay a monthly salary to someone to create some functionality using COBOL, while using Python the same can be developed within a few hours - it's obvious what the business will prefer.
Every project reaches some state where maintaining some portions of it (or the entire project) are too expensive, so a re-do may be the better option. I'm are not talking about design flaws here (although this is a common case) but rather about the business needs outgrowing the original design. For example if we originally designed a car we may attach a trailer, we may upgrade the suspension and engine, but we cannot make a train no matter how much we upgrade the car. You cannot build a freightliner from a car although both use regular roads.
I think you get my point - if you NEED - you may redo some portion of the monolith by splitting it into a microservice and you can do that using whatever language/framework/etc. you want. Just don't do that "because it's fancy and the new hire prefers to use this instead of learn how to patch the existing code".
Nobody likes working on someone else's code. It seems easy to start over from scratch and it all looks clean, however if you go that path soon you will end with "Peter's project, Hanna's project, Joshua's project" and everyone will insist on working on their own project and not touching someone else's. The fun part starts when you get into a problem and you need to figure out where this is and apparently Joshua is on vacation and Peter left the company last year. Trust me - I've been there and done that over the past 30 years (yeah, I am a software engineer since 1992).
You want to keep the code as unified as possible and split microservices ONLY if you NEED to do that. Not because you want to do it or because "we can do it better". You should do that only if you have no other choice or if maintaining the old code is proven to be really ineffective.
As someone with about 6 years of software dev experience, I'm curious to know what your opinion is on when a microservice should be used. I've mostly worked on monolithic backends. Are there any resources you've found that are helpful when determining when to use one over the other?
Here are my .2c:
The best rule to judge if you need them is: Don't unless you don't have any other option (or the costs of not doing so are multiple times higher).
Here are some valid use cases:
Scalability and redundancy - obviously it's easier to have multiple small EC2 instances that perform some computation. Smaller VMs are easy to start on-demand. For example a food delivery company (Grubhub, Takeaway, Ubereats, Doordash etc) has a few "rush hours" when customers order, then it gets back to near zero. Another good use case is when you have a slow operation (CPU-intensive or communicating with external APIs) it makes sense to have multiple instances of a microserice instead of spinning off the entire monolyth.
Partial redo of an old system - when you have a big old system, created over a decade ago, usually it's maintenance gets harder and harder over time. It's perfectly ok to rewrite portions of it as microservices in order to decrease maintenance costs, improve performance and implement new functionality.
Memory and cache - if you have some processing that requires a lot of memory or caching (although we have distributed cache like Redis) - it makes perfect sense to extract this as a separate microservice. Implementing custom cache if you need it is ok. Multiple instances using less memory is cheaper to create than a bit less instances using much more memory. Here applies the second part of the rule - it's cost.
Please note that for all of the examples the main rule applies - you don't have any other option or it will cost you much more if you keep the monolyth.
PS: I'm sure that we can come up with more good examples, this is just what came to my mine for the brief time I decided to answer.
Thanks for the detailed answer! Much appreciated!