Hacker News Reader

Comment by boxed | Hacker News Reader

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 a lot. And that code pretty much never changed anyway.

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

View on HN

That honestly seems like a reasonable use case for (what I call) auxiliary services serving the monolith. As I imagine, there's no real business logic, no data storage / transactions, no authentication/authorization (besides the service being hidden in the private network probably).

That's exactly what my team did at a former company. We generated reports through a legacy document engine because some customers cannot switch/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.

Moved the monolith to .NET Core, kept the report service on .NET Framework. A win for everybody.

I feel like it's a semantics thing. To me the meaning of microservices has undergone semantic drift to the antipattern in the article where every little component or database table is its own service with an associated "pizza team".

It's fine to just have plain "services" to do things like this where you need to leverage another OS/framework/whatever and just hive off something like PDF conversion while your core application remains a monolith.

This is absolutely the way to go in my experience. Keep related functionality together, that'll probably result in a big monolith, with maybe a few smaller services orbiting it with very specific roles, or dramatically different traffic patterns. One project I worked on consisted of two monoliths, because we were at the intersection of two business domains, and it didn't make sense to attempt to slap those radically different concepts into one model.

You can produce multiple docker images from the same codebase quite easily. You can deploy and scale them separately. None of that requires separate repositories or expensive RPC instead of local function calls.

Who said I have separate repositories?

What's the difference if they are in one or two repo if they produce two artifacts that are separated? You *will* have network calls between the two, unless you are marrying yourself with a deployment/operational platform that can run the two artifacts together. (ok, there could be a few but I really don't see how this is just using a "monorepo" instead of a "multirepo")

Doesn't Docker use cached image layers to solve that? Your PDF rendering could be in one layer that never changes, and the rest goes on top.

The problem is when you have more than one such service. Now when one of them changes, all of them need to be rebuilt. You can solve this with multi-stage builds, but those only work if your build result can be easily copied.

Is the issue here that images shouldn't be thought of as layers, but rather a tree of cached directory nodes? I don't quite follow what's meant by building here, are you referring to compiling or merging the resulting build artifacts into a final container image?

Non-copyable build outputs sound a bit wild - you're thinking of builds that encode absolute paths into the output binaries?

In theory yes, but that doesn't work well on github actions for example. The cache layering seems quite bad there for some reason.

I feel you - I worked on a project with pdf generation and the tool to generate it was quite heavy.

https://m.signalvnoise.com/the-majestic-monolith-can-become-...

Reply on news.ycombinator.com