[dpix]

This is a great article - One thing I always try and vouch for is that you don't need to go "all-in" on microservices. There is nothing wrong with having a main monolithic application with a few parts separated out into microservices that are necessary for performance or team management.

The author hits the nail on the head at the end:

  If I could go back and redo our early microservice attempts, I would 100% start by focusing on all the "CPU bound" functionality first: image processing and resizing, thumbnail generation, PDF exporting, PDF importing, file versioning with rdiff, ZIP archive generation. I would have broken teams out along those boundaries, and have them create "pure" services that dealt with nothing but Inputs and Outputs (ie, no "integration databases", no "shared file systems") such that every other service could consume them while maintaining loose-coupling.

[gizzlon]

yeah, but is that microservices? This is what we did the first place I worked, 15 years ago.

[rusticpenn]

It was called modular design. I think the main difference with micro services is the accessibility on the network. I would like to be corrected if I am wrong.

[gizzlon]

My question was rhetorical, to be honest :) point being that the only new thing, if any, with microservices is that they should be micro and you should have a lot of them.

People have been running >1 services for a long time. Sometimes calling it SOA and sometimes calling it nothing, just doing it because it made sense.

[dpix]

Totally agree, I find a lot of tech is like fashion - leaving and returning again later with a new cooler name.

  just doing it because it made sense.

This ^^. Call it what you like - if it works, it works

[ArloL]

Microservices are indepently deployable modules. Thus the same principles of modular design in a monolith apply. So, yes, you're correct with the network part.

[bakedbeanz]

> One thing I always try and vouch for is that you do need to go "all-in" on microservices

Did you mean "don't need"? I agree with the rest of your post, but this first sentence confuses me

[dpix]

You are right! Sorry typo fixed

[tsss]

In my experience, this will result in a ton of unneeded extra complexity. Microservices are very heavy and should be cut along domain boundaries and not technical boundaries so that they are as independent as possible and you reduce the need for synchronous communication. In the example above, I would probably use cloud functions or a distributed actor system.

[dpix]

This seems quite subjective - I have worked with services like these and would probably call that SOA where you need to split code concerns along domain boundaries.

In the example above, I would probably use cloud functions or a distributed actor system.

Perfect, a microservice (perhaps just service?) can be whatever you want it to be, and I don't see any reason why you shouldn't split code along technical boundaries if it somehow improves your software

[CincinnatiMan]

I've done similar batch processing with Spring Batch before (Java).