> The worst part is that these "fake team microservices" tend to have a barely working or even a non-working development environment.
That's far from my experience. In all the projects I worked with that involved services, the very first thing that was setup was a working local test environment and at least a non-prod stage. With tools like Docker compose and any of the myriad local kubernetes clusters this is outright trivial.
If your team failed to setup a dev environment, that problem is on you, not on a type of software architecture.
Once I worked on a legacy desktop application project that didn't even had debug builds. Would it be fair to pin this failing on how awful desktop apps are?
I've never worked anywhere that was deeply invested in microservers and had a workable development environment.
n=3. All small companies. I'm sure this isn't representative of all companies, but I also never claimed that's the case. Smaller companies tend to have worse dev tooling in general, so not a surprise this extends to this, too.
> If your team failed to setup a dev environment, that problem is on you, not on a type of software architecture.
Running 15 servers is harder than running 1 servers. These things are certainly related. It's not "trivial" to run any of this.
It's not "on me"; I joined long after all of this was set up. Usually there seems little interest in getting anything going, it's all pretty complex and often undocumented, so not so easy to "just" fix it by myself either, and after a few weeks or months of basically getting fuck all done I've ended up leaving (
> It's not "on me"; I joined long after all of this was set up.
Except it is. It's bad form to go down the "everyone else sucks and I'm flawless" path that plagues software development circles. You work on the project, and it's on you to get it in working order. Setting up a basic local software dev environment is step #0. Just because your predecessors failed to set one up that does not mean you're not to blame for failing exactly like your predecessors failed, except your predecessors didn't tried to throw you under the bus.
Also, it is a collosal red herring to talk about dozens of services. You can and should fake services you consume to isolate the services you actually work on. It's also bullshit to pretend that nowadays there is no way to launch and shutdown dozen of services in one go. It's trivial to launch them locally with multiple technologies to choose from and trivial to setup cloud environments for development purposes. These are all lame excuses, and one that illustrates problems caused by the developer's inability to go through the very basics.
I have not talked to anyone before – including many enthusiastic proponents of microservices and some developers of things like k8s that I've met over the years – who claimed that the operational story of microservices was "basic" or "trivial". It's widely recognized this can be complex and takes time to manage well. Is this worth the trade-off? Opinions clearly differ on that. But the trade-off is very real.
> It's bad form to go down the "everyone else sucks and I'm flawless" path
Except I never said anything like that.
> It's also bullshit to pretend that nowadays there is no way to launch and shutdown dozen of services in one go
I never claimed "there is no way" to do this.
> These are all lame excuses, and one that illustrates problems caused by the developer's inability to go through the very basics.
I'm not going to join an organisation and tell them "you're all doing it wrong!" in my first week. I might make suggestions, and if they're received with "meh, I don't see the issue" then I'm not going to press the issue to an unreasonable degree, or work on things I find important regardless, especially if they don't directly contribute to the product that's being built.
> I have not talked to anyone before (...) who claimed that the operational story of microservices was "basic" or "trivial".
You somehow failed to read what I actually said, and proceeded to go off on a non-sequitur.
I repeat what I said: it is trivial to launch and shutdown multiple services in a local software dev environment. It's trivial with Docker, it's trivial with minikube, it's trivial with microk8s, etc. It is a solved problem. Why is anyone trying to pretend that this is impossible?
Enough excuses and scapegoats.
> Except I never said anything like that.
Except you did. You tried to claim that the small teams you were involved failed to setup working software environment because reasons, and that was the reason why you also failed. Bad form. You own your work.
> I'm not going to join an organisation and tell them "you're all doing it wrong!" in my first week.
Bullshit. It makes zero sense to forego setting up a working dev environment as the very first onboarding task, and excuses like "being able to debug would make team members pissed" is absurd. Either you can do your job or you can't, and throwing your team members under the bus like this is bad form.
That's far from my experience. In all the projects I worked with that involved services, the very first thing that was setup was a working local test environment and at least a non-prod stage. With tools like Docker compose and any of the myriad local kubernetes clusters this is outright trivial.
If your team failed to setup a dev environment, that problem is on you, not on a type of software architecture.
Once I worked on a legacy desktop application project that didn't even had debug builds. Would it be fair to pin this failing on how awful desktop apps are?