[hamiltont]

> not because of how the code was structured but that was the only way the build tools allowed him to do it

Pretty sure that's the point OP was trying to make - they put in the effort to build microservices, and crappy tooling means they are instead stuck with an mangled over-engineered monolith

[staticassertion]

It sounds like the build tooling was forcing them to distribute a dependency across every lambda build, which was forcing a redeploy of all services, which is a code issue that maybe looks like a tooling issue. Just going off of context.

Regardless, it doesn't sound like microservices, it sounds like a distributed monolith.

Having built a product out of microservices and lambdas I definitely have not found that build tooling has ever forced a full redeploy. I suspect this is just a case of converting a monolith to a microservice being much more difficult than people realize.

[hamiltont]

> It sounds like the build tooling was forcing them to distribute a dependency across every lambda build, which was forcing a redeploy of all services, which is a code issue that maybe looks like a tooling issue. Just going off of context.

Yea, you are probably right on the money.

IME lots of folks struggle with DRY when trying to actually implement their services. In teams I work with, we frequently see attempts to build a shared library and have to re-hash the discussion every time

[rumanator]

Microservices are by definition stand-alone, independent, and self-contained. That's the whole point of microservices, and one of the reasons why people tolerate the pain that goes with a distributed system.

If your application does not meet any of those requirements then call it something else, as it clearly isn't a microservice.

[hamiltont]

> and crappy tooling means they are instead stuck with an mangled over-engineered monolith

Not sure you read my post. I called it a "mangled over-engineered monolith"