<story><title>Scaling up the Prime Video audio/video monitoring service and reducing costs</title><url>https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90</url></story><parent_chain><item><author>boxed</author><text>I built a little microservice on the side of my monolith for PDF creation. It used headless chrome and ghostscript to render html to a nice PDF. The problem I had with having that code inside the monolith was that it increased my docker image creation for deploys by &lt;i&gt;a lot&lt;/i&gt;. And that code pretty much never changed anyway.&lt;p&gt;I did feel a bit embarrassed having to make a microservice after having argued against them so much over the years. Hopefully I can stop producing PDFs soon so I can delete the entire thing :P</text></item><item><author>The_Colonel</author><text>I agree, my intuition would put it to 1% vs. 99% (difficult to quantify of course).&lt;p&gt;I haven&amp;#x27;t yet seen a project&amp;#x2F;product which would need microservice architecture for technical reasons. If you need to scale, you can just scale monoliths (perhaps serving in different roles).&lt;p&gt;The use case for microservice architecture is IMHO an organizational &amp;#x2F; high level architecture driven. I&amp;#x27;ve worked in a big company (20K employees) which was completely redesigning its back-office IT solution which ended up as a mesh of various microservices serving various needs (typically consumed by purpose built frontends), worked on by different teams. There monolith didn&amp;#x27;t make sense, because there was no single purpose, no single product.&lt;p&gt;But if I&amp;#x27;m building a product, I will choose monolith every time. Maaaaybe in some very special cases, I will build some auxiliary services serving the monolith, but there needs to be a very good reason to do so.</text></item><item><author>bawolff</author><text>I&amp;#x27;m pretty convinced that microservices are one of those things that make sense 5% of the time and the other 95% is cargo culting.</text></item></parent_chain><comment><author>The_Colonel</author><text>That honestly seems like a reasonable use case for (what I call) auxiliary services serving the monolith. As I imagine, there&amp;#x27;s no real business logic, no data storage &amp;#x2F; transactions, no authentication&amp;#x2F;authorization (besides the service being hidden in the private network probably).</text></comment>
<story><title>Scaling up the Prime Video audio/video monitoring service and reducing costs</title><url>https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90</url></story><parent_chain><item><author>boxed</author><text>I built a little microservice on the side of my monolith for PDF creation. It used headless chrome and ghostscript to render html to a nice PDF. The problem I had with having that code inside the monolith was that it increased my docker image creation for deploys by &lt;i&gt;a lot&lt;/i&gt;. And that code pretty much never changed anyway.&lt;p&gt;I did feel a bit embarrassed having to make a microservice after having argued against them so much over the years. Hopefully I can stop producing PDFs soon so I can delete the entire thing :P</text></item><item><author>The_Colonel</author><text>I agree, my intuition would put it to 1% vs. 99% (difficult to quantify of course).&lt;p&gt;I haven&amp;#x27;t yet seen a project&amp;#x2F;product which would need microservice architecture for technical reasons. If you need to scale, you can just scale monoliths (perhaps serving in different roles).&lt;p&gt;The use case for microservice architecture is IMHO an organizational &amp;#x2F; high level architecture driven. I&amp;#x27;ve worked in a big company (20K employees) which was completely redesigning its back-office IT solution which ended up as a mesh of various microservices serving various needs (typically consumed by purpose built frontends), worked on by different teams. There monolith didn&amp;#x27;t make sense, because there was no single purpose, no single product.&lt;p&gt;But if I&amp;#x27;m building a product, I will choose monolith every time. Maaaaybe in some very special cases, I will build some auxiliary services serving the monolith, but there needs to be a very good reason to do so.</text></item><item><author>bawolff</author><text>I&amp;#x27;m pretty convinced that microservices are one of those things that make sense 5% of the time and the other 95% is cargo culting.</text></item></parent_chain><comment><author>foepys</author><text>That&amp;#x27;s exactly what my team did at a former company. We generated reports through a legacy document engine because some customers cannot switch&amp;#x2F;update their report templates and so we moved the logic out of the monolith into a service to get rid of a large portion of our dependencies.&lt;p&gt;Moved the monolith to .NET Core, kept the report service on .NET Framework. A win for everybody.</text></comment>