Slicing into microservices

Question

I'm extracting an image [jpg/png etc] server project from a larger solution.

1. Images are uploaded via an API by authenticated users. The same application also serves the images.
2. The file is validated: It is inspected to make sure it is the type of file it claims to be.
3. The file is processed: If it is too big in spatial dimensions or in terms of file size it is processed and compressed.
4. The processed image is stored in a blob store on Azure with some metadata.

I'm trying to evaluate whether it's better to slice each of these parts into a microservice, or just keep them in their own libraries to be used in a single application (but still separated from the original much larger solution).

I see two applicable benefits of microservices to my situation:

1. Far more choices for swapping in a mature open source solution in place of my basic implementations for 2 and 3 in the above list, as I wouldn't be restricted to libraries for the same framework.
2. I can update 2 or 3 without any downtime or worrying about any effects on the images actually being served.

Other benefits of microservices do not seem applicable. I don't expect to scale one of the parts independently. I'm the only maintainer of the solution.

Therefore I'm thinking a logical way of slicing it would be to put 2 and 2 into separate services and leave 1 and 4 as part of the same application.

Alternatively I could just use a monolithic approach with a view to migrating it if I decide I want to use something from a different framework for 2 or 3, or if the software gets so popular that avoiding any downtime at all becomes a priority. But I think it would be a useful exercise for myself so I will probably go ahead with it so long as it makes sense to do so.

I'm only getting to grips with microservices so I'm probably missing some things and possibly drawing wrong conclusions. Are there more things that I should consider?

Answer 1

I'm trying to evaluate whether it's better to slice each of these parts into a microservice, or just keep them in their own libraries to be used in a monolithic application.

Neither option is a good idea. All four responsibilities belong in one micro service. Imagine someone uploads a 4GB image. The "uploader" micro service determines 4GB is larger than the 10MG maximum, so it blasts 4GB of data at the "resizer" micro service, and the "resizer" service sends a 10MB image back to the "uploader" service so it can send the 10MB image up to the cloud.

The main goal of a micro service is to create the smallest application that can be independently deployable and scalable. That doesn't mean create the smallest application. All the image processing needs should be handled by a single micro service.