[reader_1000]

If one part of the application needs to be changed frequently and/or is used by other applications, then it makes sense to separate it as a microservice. However, for other parts, I think it might be better to stay as a monolith since when you have a network in your calls, things get messier.

Networks are unreliable even if it is your local area network. In my career I saw some unrelated network equipment was sending a RST packet to load balancer with application servers IP address and resulting in service unavaiable errors. It took us weeks to find that out since it was happening very rarely and there were many layers between load balancer and application servers.

Network means slowness, connection errors, unknown results, etc all of which should be handled carefully.

[aflag]

Not sure if rate of change truly matters. In my opinion, microservices make most sense when dealing with multiple team. It's much easier to update core services when everyone depends on it through the network, rather than requiring people to redeploy their stuff. If you're a single team operation, it's not really a problem if all your stuff runs in a single process. It may even benefit you in terms of performance and scalability, to be honest.

[reader_1000]

Rate of change may matter when your monolith application takes too long to deploy (i.e a big war application with lots of initializations at start), although rolling updates may help here. It will also be easier to rollback if things go wrong.

On the other hand, I agree with your point of multiple teams. I tried to mean same thing with "used by other applications"

[aflag]

How long are you talking? I can't think of a process I've ever worked on that took more than a few seconds to start. As you say, if you have any sort of rolling deployment mechanism the start time of your application is somewhat irrelevant. Unless your application takes a massive time to start, it seems like the wrong thing to optimise for. Surely you only deploy things a few times a day, if that, and hopefully most deployments don't require rollbacks.

Also, with the current network speeds and memory availability, it's hard to imagine the war size to be a bottleneck in web development.

Depending on other services via a well defined network interface is good for decoupling teams. So it depends on the number of employees you have coding for the same platform, rather than on clients or anything like that.

[reader_1000]

> How long are you talking? There were some Spring applications that took more than 5 minutes to start in my old job. However, things are most probably improved now with lazy initializations of beans and maybe developers of that applications could have done better at that time. I don't know it is still the case now.

> Also, with the current network speeds and memory availability, it's hard to imagine the war size to be a bottleneck in web development.

Network speed was not the problem, decompression / expansion of the application was. There were war files about 100-150 MB size. Also I saw one with size of 1.5GB however it was an exception. These may or may not be a concern depending on your CPU utilization, disk speed, memory, etc.

Most decisions depends on environment. For some environments, as you said, deployments are not a concern for microservices, for some they are.

[aflag]

If networking is not a problem, why not deploy it already decompressed? I'm assuming the 5 minutes time included decompressing it? It seems a bit weird to take so much time to allocate some objects in memory and possibly establish a few connections.

Anyway, can you share which kind of environment even a 5 minute deployment would be a problem? Most places I worked at it took a lot more than 5 minutes to actually implement the change that's going to production, so deployment times were pretty much irrelevant overall.

[daxfohl]

OP here. The move is definitely needed in our case as it's to the point where IntelliJ won't even load anymore. But I had to laugh when improved testability was brought up as one of the benefits.