Hacker News Reader

> Often, these are before built as libraries and imported into multiple projects which is the wrong approach. Offering up an API for these instead can help decouple.

This assertion - that it is a wrong approach - is false. And an API call that involves RPC is not necessarily more decoupled than one that doesn't. Coupling is another word for correlation of changes over time. RPC has no necessary implication of reducing this.

What makes the library approach awkward is usually persistence, error recovery and asychronisity, not coupling. The need for things like retries that survive restarts, which means they need persistent queues, even if that's just files in a directory. But none of these things necessarily require service implementation rather than library implementation, not even sandboxed attachment screening - that's a subprocess (potentially farmed out to another box container style, which is a service), not a service in itself.

People have been doing versioning with libraries for decades; there are a lot of different ways to crack that nut, and ignorance isn't an argument either way, because it cuts both ways.

When you have the same job that needs the same kind of queuing, same error recovery, same resource management across different applications or areas of a single big application, that's when it makes more sense to try and package it into a service. Something that is stateful and long running, and not just some code at the end of an RPC. Something that might need very different resource consumption requirements than the calling application - e.g. a CPU intensive operation in an otherwise lightweight app. Something that needs to be scalable independently of other components in the system. That kind of thing.

I'm not sure what the author does or does not understand, but many of the people going full-steam down the microservice road don't know those things either, and so end up often creating at least as big of a mess as they would with a monolith, despite lots of zeal and hype.

Coordinating a complex architecture IS hard. Microservices are often used as a way to wish away all that hard coordinating because... decoupling or something... and stuff.

Meanwhile what actually gets built is a tangled mess of tightly coupled (but separate) libraries as "services", with many-to-one relations between those services and developers, unnecessarily complex deployments, and... a big, fat, crappy HTTP layer slathered on top, just to add insult to injury. The next step is usually to pour on generous helpings of graphql.

> coordinating a complex architecture is hard, I only build easy stuff

If this had been the actual title of this submission, I would have been much more receptive to it. Let's expand on that: "Coordinating a complex architecture when you do not need it is needlessly expensive, so I recommend not doing so." This blog post coming from a contract software firm tells me that they're willing to sacrifice billable hours to instead write just enough software to solve the client's problem.

Yah funny you say that about versioning and breaking changes. The side effect of the CMS one for example is its been around for 7 years now and I want to kill it off but there are clients depending on it. I don't even update the code anymore so I guess its ok but from that lesson learned, making the other "microservices" as I've defined them you should build a microservice so it can also be used individually for a client as well as multiple clients where the work of doing one or many is the same so you could easily walk away from the responsibility of hosting it if you wanted.

It’s good that you want to update it and make it better. However, it it works fine for the clients and they are happy, you should be too.

We all look back on our previous work and see room for improvement, that’s a good thing. However, spending too many cycles trying to achieve perfection where it’s not desired will prevent you from moving on with your life to bigger and better pursuits.

Be really happy that you have a software project which survived for 7 years. Many fail in far shorter time and provide no value.

The way I've had teams stay sane in the face of old versions is to always reimplement v1 as a facade to v2, while keeping the same interface. Otherwise the amount of running code and code paths becomes a quagmire.