0

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?

2
  • Do you mean splitting numbers 1-4 into 4 micro services, or grouping numbers 1-4 into a single micro service? May 7, 2021 at 18:10
  • Trying to evaluate each idea. Or use three microservices a, b and c where a:1&4, b:2, c:3 May 7, 2021 at 18:14

1 Answer 1

3

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.

2
  • Thanks. A couple of clarifications: My idea was to put them up on Azure Kubernetes Services, so they would all run on the same cluster on the cloud. The uploads are images in the sense of jpg and png files and should be restricted to 5MB by the client. May 7, 2021 at 18:46
  • @NeutralHandle: never assume the client will follow your rules. Especially the malicious ones. May 7, 2021 at 23:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.