12 ms·

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 h

by boxed 4y ago

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

The_Colonel 4y ago
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).
foepys 4y ago
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.
jon-wood 4y ago
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.
mike_hearn 4y ago
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.
- franga2000 4y ago
  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.
  - mike_hearn 4y ago
    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?
- boxed 4y ago
  In theory yes, but that doesn't work well on github actions for example. The cache layering seems quite bad there for some reason.
Guid_NewGuid 4y ago
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.
dontlaugh 4y ago
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.
- boxed 4y ago
  Who said I have separate repositories?
- darkwater 4y ago
  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")
pnt12 4y ago
I feel you - I worked on a project with pdf generation and the tool to generate it was quite heavy.
manicennui 4y ago
https://m.signalvnoise.com/the-majestic-monolith-can-become-the-citadel/ https://m.signalvnoise.com/the-majestic-monolith-can-become-...

by boxed 4y ago

The_Colonel 4y ago

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).

foepys 4y ago

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.

jon-wood 4y ago

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.

mike_hearn 4y ago

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.

franga2000 4y ago
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.
- mike_hearn 4y ago
  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?
boxed 4y ago
In theory yes, but that doesn't work well on github actions for example. The cache layering seems quite bad there for some reason.

Guid_NewGuid 4y ago

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.

dontlaugh 4y ago

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.

boxed 4y ago
Who said I have separate repositories?
darkwater 4y ago
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")

pnt12 4y ago

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

manicennui 4y ago

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