Agreed. In fact batch jobs are, in at least one dimension, more decoupled than strict microservices.
Current client is a photobooth. Photos all can be shared from client app and web, each "share" is just a REST post containing "shareType:string" and "meta:json"; all share types (email, mms, twitter, etc) go through the same endpoint. Web api simply adds these to message queue for the corresponding "shareType" job to process. This way new types of sharing options can be added just by changing the client and adding the new batch worker; no updates to the web/api server app itself are necessary.
Proper "microservices" are usually described as being directly coupled to each other. They're just the new hotness so everyone wants a piece.
As most of the comments are saying, choose the shoe that fits.
Current client is a photobooth. Photos all can be shared from client app and web, each "share" is just a REST post containing "shareType:string" and "meta:json"; all share types (email, mms, twitter, etc) go through the same endpoint. Web api simply adds these to message queue for the corresponding "shareType" job to process. This way new types of sharing options can be added just by changing the client and adding the new batch worker; no updates to the web/api server app itself are necessary.
Proper "microservices" are usually described as being directly coupled to each other. They're just the new hotness so everyone wants a piece.
As most of the comments are saying, choose the shoe that fits.