[Ygg2]

> I started my career just a couple years ago. In my first company, they used 10+ year old tooling and imo it was terrible. A very old legacy mess monolith that made adding features pure torture. Trunk-based development with a "who needs tests" mindset, resulting in horrendously buggy code, 50:50 chance pulling newest version would break something.

Monkey paw curls.

My story is complete opposite. Three years ago joined a startup. We use relatively new Java, branches everywhere, microservice architecture, +85% branch coverage, integration tests, end-to-end, performance, you name it. CI/CD integrated and self hosted. Heaven, right?

It was an absolute shit show. Because of microservice architecture you had no way of running +50 necessary microservice on your machine.

Tests are mandated but brittle. Mocking libraries break whenever you refactor a method. Integration tests are flaky and inconsistent (behaves differently on local vs remote). End to end test takes hours to complete. There are 20 different environments, each with different configuration, each divided into dev/qa/prod.

In how long I was on we didn't have two successful deploys on main branch. But you have to keep adding features because one customer said it might. Oh security found that library is 20ms too old. Have to replace it asap, despite the convoluted nest of dependencies between microservices.

It had good pay though. Taught me to really hate mocks and that tests need to be applied at right level.

[ReflectedImage]

Microservices can't have dependencies between each other otherwise they aren't microservices.

I think the main issue is just the other engineers you are working with. If they are bad, they will screw anything up.

[kubanczyk]

Microservice is a module. A module that got separated by a network layer, most often due to somebody's momentary lapse of judgement.

It's encouraging that you forbid the next person to fall into identical trap (you effectively say: this kind of remote module must not use further remote modules). Alas... they can, and they will.

[Ygg2]

> Microservices can't have dependencies between each other otherwise they aren't microservices.

See Hyrum's law:

    Put succinctly, the observation is this:

    With a sufficient number of users of an API,
    it does not matter what you promise in the contract:
    all observable behaviors of your system
    will be depended on by somebody.

One example we bumped spring from 2.1->2.4 (not actual version numbers) Harmless, no? What's worst that can happen?

Failure when doing some but not all operations.

Why? Because some Python/Java micro-services down the operation chain expected null fields to be omitted and the default behavior was changed (between Spring versions) to write null fields instead. Which only occurred on those services that relied on null fields being omitted. Fix was easy but finding the bug was difficult.

[okr]

How would you design a microservice, that does not depend on another?

[tangjurine]

Microservice 1 <-> on call engineer copy pasting <-> Microservice 2

[williamcotton]

Send a JSON package with some HTML and dimensions, get back a JSON package with links to that HTML rendered as JPEGs at the requested dimensions.

[sseagull]

At some point you are going to have another service that uses this HTML->JPEG service though. That would be a dependency, at least in my view (ie, if the HTML->JPEG service goes down, something else will break).

Or are all microservices user facing?