Monolith shouldn't be confused with non-modular/modular code. Even with a single large project, everything is divided properly and easily. We can onboard a developer easily and that new person just needs to know their specific area.
OTOH I see so many companies who picked up microservices for the reasons you outlined, struggle. At first it's fun. But things get messy quickly. You need to move a developer between teams and it's tough. Getting a holistic view of the system is almost impossible. You can't move an inch without a dedicated DevOps.
Reproducing an issue with microservices becomes a nightmare. For me and my employer (Lightrun) this is good since our product is perfect for debugging these sort of failures. But as an engineer I feel this is a bad choice.
Don't get me wrong. I like Microservices. When they are the right fit.
But as Martin Fowler said you should go Monolith first. I can't think of a single case where this doesn't make sense.
Finally about Java. I think your view of Java may be out of date. Java 17 is already pretty powerful as a language/API and getting more so. The ability to instrument, IDEs and entire ecosystem is at least a decade ahead of its closest rivals. I've done a lot of work in other ecosystems recently and I have good things to say about them (especially in the getting up and running phase where Java does suck) but when it comes to real world high scale... There's literally no alternative.
The advantage of having a single team aligning around a single language/platform (regardless of the language) is huge. We can move developers around instantly. Do full stack PRs that are aimed at vertical features. Review faster and scale easily. Java isn't Beatles it's a Mac truck. Heavy, destructive and you need some skills to drive it. But it gets the job done if you have a good developer at the wheel.
I don't! I wholeheartedly hate them. Yes I use them a lot when I have to. And over the years I had to use them for different reasons, but willingly going for microservices architecture because of the reasons outlined in the article above is just outright stupid. I can only assume the person writing the article never had to deal with microservices in the long run. Only a junior developer can get excited about having to deal with small chunks of codebase and this is understandable. Dealing with 1 small chunk however is one thing. Dealing with 10 different chunks each running a different version is another.
You might have mistaken the Java part... I know Java is a powerful comprehensive language, especially the newer versions... but my example was "Java 7 without frameworks".
But I totally agree with Martin Fowler on the technical side, what he says makes sense and in a rational world it would be the way to go.
But we're dealing with programmers here. Ten smaller "mountains" would seem much easier to conquer than one single big one, even if those 10 would amount to X times the big one.
I believe that, more and more, we should start considering the human part of the equation, not just the technical side of it.
I think you need to revisit Java with someone who really knows what they're doing... Unfortunately, there's a lot of outdated nonsense out there that gives the wrong impression about it. You might have gotten a wrong impression early on.
The human element is actually my concern. It isn't hard to write code or get developers to write code. Maintenance is 95-98% of what I do for a project. I don't think I'm an outlier in that regard. In our industry people change jobs faster than they change socks. We need to write code that won't go down the garbage drain because the person who wrote it got a better offer.
At Lightrun they actually take it to the extreme and force people to work on each others code. So a person get an issue assigned that's in an area code they're unfamiliar with. This prevents code rot and forces people to work as a team. It's terrible in terms of merges and code reviews, but on the plus side: the code is good. I think that's a bit extreme but I'm familiar with a company that did microservices "free style". Their product never launched.
This is obviously anecdotal but I think it also makes more sense.
I really don't have a problem with Java.
And you're right, we most read and maintain code than we write it.
But today, people getting into the industry are learning about the newer versions and frameworks, as do current developers, as to not get "outdated".
And then you get into into a new team and see it using "Java 7" (just an example). As maintained as it is, it's not what you've been learning, you're unfamiliar, you probably have to do stuff that is already core on newer versions.
Not only that, as time passes, to upgrade the whole thing can be difficult, maybe even impossible. And you keep with it and the new LTS goes to Java18, Java19, Java20...
To maintain a small part made in Java 7 would be a lot easier if new stuff is being made in Java 17. Even with stuff here and there in Java 8, Java 11, Java 15 each with their own frameworks.
If it was built in a SOLID way, it gonna persist longer and be easier to maintain. The developers might see it as a chore to change the things in something so "outdated", but it would be a "break" from the normal flow, and not the norm.
Meanwhile the new stuff is being made with the shiny new toys that everyone is already learning and enjoying, coming with new tools that might even justify the rewrite of an old service because it can make a real impact there.
I updated COBOL systems and even wrote some COBOL myself on a PDP in my youth ;-)
I agree, systems should be more "fresh". But newer isn't always better and there's reality of stability. Imagine the millions of small microservices with outdated languages and toolchains the world forgot. 1 year old NodeJS projects are already old news and "horrible" can you imagine a 10 year old NodeJS project?
Java 7 is just over 10 years old by now.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I have a different take.
Monolith shouldn't be confused with non-modular/modular code. Even with a single large project, everything is divided properly and easily. We can onboard a developer easily and that new person just needs to know their specific area.
OTOH I see so many companies who picked up microservices for the reasons you outlined, struggle. At first it's fun. But things get messy quickly. You need to move a developer between teams and it's tough. Getting a holistic view of the system is almost impossible. You can't move an inch without a dedicated DevOps.
Reproducing an issue with microservices becomes a nightmare. For me and my employer (Lightrun) this is good since our product is perfect for debugging these sort of failures. But as an engineer I feel this is a bad choice.
Don't get me wrong. I like Microservices. When they are the right fit.
But as Martin Fowler said you should go Monolith first. I can't think of a single case where this doesn't make sense.
Finally about Java. I think your view of Java may be out of date. Java 17 is already pretty powerful as a language/API and getting more so. The ability to instrument, IDEs and entire ecosystem is at least a decade ahead of its closest rivals. I've done a lot of work in other ecosystems recently and I have good things to say about them (especially in the getting up and running phase where Java does suck) but when it comes to real world high scale... There's literally no alternative.
The advantage of having a single team aligning around a single language/platform (regardless of the language) is huge. We can move developers around instantly. Do full stack PRs that are aimed at vertical features. Review faster and scale easily. Java isn't Beatles it's a Mac truck. Heavy, destructive and you need some skills to drive it. But it gets the job done if you have a good developer at the wheel.
I don't! I wholeheartedly hate them. Yes I use them a lot when I have to. And over the years I had to use them for different reasons, but willingly going for microservices architecture because of the reasons outlined in the article above is just outright stupid. I can only assume the person writing the article never had to deal with microservices in the long run. Only a junior developer can get excited about having to deal with small chunks of codebase and this is understandable. Dealing with 1 small chunk however is one thing. Dealing with 10 different chunks each running a different version is another.
You might have mistaken the Java part... I know Java is a powerful comprehensive language, especially the newer versions... but my example was "Java 7 without frameworks".
But I totally agree with Martin Fowler on the technical side, what he says makes sense and in a rational world it would be the way to go.
But we're dealing with programmers here. Ten smaller "mountains" would seem much easier to conquer than one single big one, even if those 10 would amount to X times the big one.
I believe that, more and more, we should start considering the human part of the equation, not just the technical side of it.
I think you need to revisit Java with someone who really knows what they're doing... Unfortunately, there's a lot of outdated nonsense out there that gives the wrong impression about it. You might have gotten a wrong impression early on.
The human element is actually my concern. It isn't hard to write code or get developers to write code. Maintenance is 95-98% of what I do for a project. I don't think I'm an outlier in that regard. In our industry people change jobs faster than they change socks. We need to write code that won't go down the garbage drain because the person who wrote it got a better offer.
At Lightrun they actually take it to the extreme and force people to work on each others code. So a person get an issue assigned that's in an area code they're unfamiliar with. This prevents code rot and forces people to work as a team. It's terrible in terms of merges and code reviews, but on the plus side: the code is good. I think that's a bit extreme but I'm familiar with a company that did microservices "free style". Their product never launched.
This is obviously anecdotal but I think it also makes more sense.
I really don't have a problem with Java.
And you're right, we most read and maintain code than we write it.
But today, people getting into the industry are learning about the newer versions and frameworks, as do current developers, as to not get "outdated".
And then you get into into a new team and see it using "Java 7" (just an example). As maintained as it is, it's not what you've been learning, you're unfamiliar, you probably have to do stuff that is already core on newer versions.
Not only that, as time passes, to upgrade the whole thing can be difficult, maybe even impossible. And you keep with it and the new LTS goes to Java18, Java19, Java20...
To maintain a small part made in Java 7 would be a lot easier if new stuff is being made in Java 17. Even with stuff here and there in Java 8, Java 11, Java 15 each with their own frameworks.
If it was built in a SOLID way, it gonna persist longer and be easier to maintain. The developers might see it as a chore to change the things in something so "outdated", but it would be a "break" from the normal flow, and not the norm.
Meanwhile the new stuff is being made with the shiny new toys that everyone is already learning and enjoying, coming with new tools that might even justify the rewrite of an old service because it can make a real impact there.
I updated COBOL systems and even wrote some COBOL myself on a PDP in my youth ;-)
I agree, systems should be more "fresh". But newer isn't always better and there's reality of stability. Imagine the millions of small microservices with outdated languages and toolchains the world forgot. 1 year old NodeJS projects are already old news and "horrible" can you imagine a 10 year old NodeJS project?
Java 7 is just over 10 years old by now.