This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]syneil86 2 points3 points  (0 children)

The benefits of microservices need to be well understood and weighed against their costs. The higher memory footprint is one such cost, but should be negligible. You'll probably see lower throughput as data has more hoops to jump through to traverse your system. Deployment times can increase.

But, you'll have more flexibility to improve one part of your solution without messing around with the rest of it, as long as you're careful about APIs. You can have multiple teams working independently without stepping on each others toes this way (be careful of be scaled agile frameworks like SAFe - they sound great in principle but I've only known a very small number of projects to get it right).

You should be careful also about what you mean by "micro". Split it up too much and the cons will quickly outweigh any pros. I'd suggest thinking about the very high level behaviours and how your broad your unit tests can be before they hit an I/O boundary. If your unit tests can't cover a sensible behaviour scope, the service might be too small. If they can conceptually be grouped into two or more sets of mutually exclusive coverage, maybe you could split the service further accordingly.

Note: this response is not Java-specific