Modules, not microservices

>they force alignment on one language or at least runtime

A sane thing to do.

>they force alignment of dependencies and their versions

A sane thing to do. Better yet to do it in a global fashion, along with integration tests.

>they can require lots of RAM if you have many modules with many classes

You can't make the same set of features build in a distributed manner comsume _less_ RAM than the monolith counterpart. Given you're now running dozens of copies of the same java vm + common dependencies.

>they can be slow to start

Correct.

>they may be limiting in terms of technology choice

Correct.

>they don't provide resource isolation between components

Correct.

>they take long to rebuild an redeploy, unless you apply a large degree of discipline and engineering excellence to only rebuild changed modules while making sure no API contracts are broken

I think the keyword is the WebLogic Server mentioned before. People don't realise that monolith architecture does't mean legacy technology. Monolith web services can and should be build in Spring Boot, for example. Also, most of the time, comparisons are unfair. In all projects i've worked im yet to see a MS instalation paired feature-wise with his old monolith cousin. Legacy projects tends to be massive, as they're made to solve real world problems while evolving during time. MS projects are run for a year or two and people start to compare around apples to oranges.

>they can be hard to test

If other team's component break integration, the whole building stops. I think Fail-Fast is a good thing. Any necessary setup must be documented in whatever architectural style. It can be worse in a MS scenario, where you are tasked to fix a dusty, forgotten service with an empty README.

If anything, monolithic architecture brings lots of awareness. It's easier to get how things are wired and how they interact together.

But of course team scaling is determined this way. Merely releasing a library version has zero business impact. To have impact, library teams must go around to every consumer team and beg them to accept a version bump. This is a) shitty work for which it is impossible to retain people, and b) intractable without an enormous labor force once the number of consumers is big enough.

Services can be continuously deployed by small owning teams.

Wear shoes that fit; not shoes you think you'll grow into.

Dynamic typing + Microservices + Unit Tests just blows everything out of the water on Development Speed / Time to Market.

Most important thing for lots of startups and companies is Time to Market.

Traditional static typing based approachs are just a bad joke (3 times slower on average) in comparsion.

That's why we have the whole microservices and dynamic typing thing going on, because businesses that use it beat up businesses that don't. It's pretty simple really.

I love Carmack but I always thought his conclusion there was unsatisfying. I think the issue with really long functions is that they increase scope - in both the code and mental sense.

Now your MinorFunction3 code can access all the local variables used by MinorFunction1 and MinorFunction2, and there's no easy list of things that it might access which makes it harder to read.

Separate functions do have a nice list of things they might access - their arguments!

Of course this technically only applies to pure functions so maybe that's why it doesn't matter to Carmack - he's used to using global variables willy nilly.

Also sometimes the list of things a function might need to access gets unwieldy, which is when you can reach for classes. So no hard and fast rule but I think increased scope is the issue with it.