The media conversion service, detector service and aggregation service can indeed be maintained as separate code bases and certainly independently deployable. I would argue that each of those microservices independently are NOT a business capability. They are utilities that individually provide little value to the business but collectively orchestrated – provide a business capability.
It is likely also true the same team that worked on or owned all three of those services – I cannot state for fact – but I doubt three separate teams maintained the code bases for these three components.
This defect detection service or tool is a microservice in the larger Amazon Prime Video ecosystem – that has been implemented as a distributed application. An important distinction.
I am not trying to get into a semantic debate and play sharpshooter on the AWS team. The point I believe the author was trying to make is that a monolithic process is not always bad, and I agree with him.
As the author states:
Microservices and serverless components are tools that do work at high scale, but whether to use them over monolith has to be made on a case-by-case basis.
This is so true. Just like speed cannot be the only thing we measure “good” or “bad” – as in software development – distributed vs. single process applications (or monolithic vs. microservice) need to consider factors such as scale, extensibility, observability, cost and even team capability. Gaining scale and extensibility while losing the ability to easily observe and troubleshoot may not be worth it. Especially if you must hire new skills for the increased complexity.