Hacker News Reader

Comment by chipdart | Hacker News Reader

> Invariably this is an ideal and does not match up in reality.

No, this does indeed match reality. At least for those who work with microservices. This is microservices 101. It's baffling how this is even being argued.

We have industry behemoths building their whole development experience around this fact. Look at Microsoft. They even went to the extents of supporting Connected Services in Visual Studio 2022. Why on earth do you believe one of the most basic traits of backend development is unreal?

> I work at ~50 ish employee company and we have layers of dependencies between at least 6 or 7 various microservices.

Irrelevant. Each service has dependencies and consumers. When you need to run an instance of one of those services locally, you point it to it's dependencies and you unplug it from it's consumers. Done. This is not rocket science.

View on HN

You can't compare Microsoft to your run-of-the-mill small (or even large) software shop, though. Maybe on HN, most people work on these amazingly designed systems, but in my experience most tech out there is shit and has no proper design or architecture beyond "we're doing microservices because everyone is".

> You can't compare Microsoft to your run-of-the-mill small (or even large) software shop, though.

True. Your run-of-the-mill shop should have a simpler and more straight-forward system.

But you seem to want the reverse.

No one wants the reverse, I would love if my microservices were perfectly isolated little boxes with known inputs and outputs! That would make my life easier. But I don’t have the ownership over the planning process and our sales person already told our customer we’d have the new feature they asked for that no one on the engineering team knew about delivered by next sprint. It would be nice if my company planned things well! But they don’t

So then it’s bad engineering being wagged by Sales, not some expected sane choice.

Just s/Sales/Management, because sales actually can't wag the development process. But yeah.

Most of the time it's bad engineering caused by other engineers.

> You can't compare Microsoft to your run-of-the-mill small (or even large) software shop, though.

I'm talking about how Microsoft added support for connected services to Visual Studio. It's literally a tool that anyone in the world can use. They added the feature to address existing customer needs.

Apart from the fact that not everyone uses Visual Studio, "connected services" appears to be something by which you can connect to existing cloud-based services.

How does that solve the problem of a mess of interconnected services where you may have to change 3 or more of them simultaneously in order to implement a change?

> Apart from the fact that not everyone uses Visual Studio, "connected services" appears to be something by which you can connect to existing cloud-based services.

Yes. That's the point.

> How does that solve the problem of a mess of interconnected services (...)

I don't think you got the point.

The whole point is that you only need to connect your local deployment to services that are up and running. There is absolutely no need to launch a set of ad-hoc self-contained services to run a service locally and work on it. That is the whole point.

Your whole argument boils down to "don't write shit software" which yeah, fair, but in the real world, the company that you just joined has shit code that evolved over 10 years and has accumulated all sorts of legacy cruft. The idea that there is "absolutely no need to launch a set of ad-hoc self-contained services to run a service locally and work on it" just doesn't match the reality of most places I've worked at. You either got very lucky or you didn't work on complex enough systems.

> Your whole argument boils down to "don't write shit software" (...)

No. My whole argument is open your eyes, and look at what you're doing. Make it make sense.

Does it make sense to launch 50 instances locally to be able do work on a service? No. That's a stupid way of going about a problem.

What would make sense? Launch the services you need to change, of course. Whatever you need to debug, that's what you need to run locally. Everything else you consume it from a cloud environment that's up and running.

That's it. Simple.

If there's something preventing you from doing just that then that's an artiicifal constraint that you created for yourself, and thus that you need to fix. We're talking about things like auth. Once you fix that, go back to square one.

Just FYI, you come across as extremely antagonistic in the way you're conveying your message. The underlying tone seems to be "you're stupid".

Shouldn't all systems be tested end-to-end regardless of if they are microservices or not?

You don’t have to test them all end to end before merging a PR. You should have multiple stable pre prod environments for e2e testing. But if most changes fail e2e testing then your sdlc is broken before then and that should be fixed first. You need better designs and better collaboration and better local tests and code reviews.

> You don’t have to test them all end to end before merging a PR.

You have to test the changes you want to push. That's the whole basis of CI/CD. The question is at which stage are you ok with seeing your pipeline build.

If you accept that you can block your whole pipeline by merging a bad PR then that's ok.

In the meantime, it is customary to configure pipelines to run unit, integration tests, and sometimes even contract tests when creating a feature branch. Some platforms even provide high-level support for spinning up sandbox environment as part of their pipeline infrastructure.

Reply on news.ycombinator.com