[atleta]

It still depends on the organization size (or the size of the user base, or the complexity of the product). So you may only have experience with services where it was the right choice.

I did see two instances where it wasn't. (I mainly work with/for small companies, startups.) In one instance I was called in as a tech lead/expert for a small startup having a kind of a product/software crisis. They've been working on their service for a year or too (yes, way too long) and 2-3 months before the planned release at some random conference (Slush, TNW or whatnot) one of the developers figured out that the whole codebase was a piece of shit and there was no way they could be ready in time, but they should rewrite it as a collection of node microservices and that could work. The monolith they had was PHP, just to add to the fun, so switching over would mean switching languages too.

The guy, he was a smart and motivated chap, even started implementing one service in his free time, the user registration/user handling I think (the least important and least complex one, of course) which somehow screwed up the monotlith and made it start crashing. (Or so they said, I don't know what was up with that.)

Obviously, it was a 100% stupid idea and we went on with fixing their development process (starting to do scrum and teaching the stakeholders that they need to stop phoning the developers directly and asking for features, fixes, introducing automated testing, etc.) Oh, and it was a team of 2-2.5 people. (With the group manager doing some backend work too, but also managing another, totally unrelated project for another client.)

The other one was a bit different story, where I just shared my insights over a call. A guy I've known took over a project that was built by a small team (2-5 people, can't remember) for a startup and wanted some external opinion for himself and the founder. That one was built as a set of microservices but they did have all kinds of stability issues. The idea was that it had to be very-very-super scalable. Because, you know you launch and they will come and there's nothing worse than not being able to handle the load. Except, there is: they had been building the thing for over 2 years back then.

It was an online medical consultation solution (you describe your problem, pick a doctor, do a f2f call and pay by the time). The funny thing is that I've built a very similar system, as a startup cofounder, 3-4 years earlier for psychology consultation with the help of 2 other guys, who didn't even work full time (one of them came after the first one quit). The MVP was up in, I think, 2 maybe 3 months. Ours was a monolith-ish thing and theirs definitely looked better, maybe scaled better and would have been cheaper to operate at scale (we used an external service for the video calls). But ours was a lot cheaper to build and launch and we could test (validate) our solution a lot earlier with real customers.

If it worked out, we could have started breaking it down into multiple services as/if/when needed.

[arinlen]

> (...) The monolith they had was PHP, just to add to the fun, so switching over would mean switching languages too.

Why do you feel this is relevant, let alone detrimental to the idea of microservices? It looks to me that it's one of the primary positive traits.

> The guy, he was a smart and motivated chap, even started implementing one service in his free time (...) which somehow screwed up the monotlith and made it start crashing.

This statement makes no sense at all.

> Obviously, it was a 100% stupid idea (...)

I saw no stupid idea in any of your statements.

You stated the legacy codebase was crap, and that a team member took up to himself to do the strangler's vine thing and gradually peel responsibilities out of the monolith. What leads you to believe this is stupid?

[atleta]

> Why do you feel this is relevant, let alone detrimental to the idea of microservices? It looks to me that it's one of the primary positive traits.

I did explain at the end of the sentence, why it was relevant: because rewriting in JS would have also meant switching to a completely new language. Which the team, as a whole had less experience with and which would have made it a complete rewrite without being able to reuse anything.

> This statement makes no sense at all.

I'm sorry you didn't understand it. If you asked a clarifying question I may have been able to explain.

> You stated the legacy codebase was crap,

No, I said one team member stated that the code base was crap. I didn't say it was crap. I didn't evaluate it, because I don't know (and don't like) PHP and because I didn't have to work with it anyway. The other two team members said the code was of acceptable quality for them to work on.

> and that a team member took up to himself to do the strangler's vine thing and gradually peel responsibilities out of the monolith. What leads you to believe this is stupid?

Because this is not what was going to happen and because they had been working on the thing for about 2 years back then without releasing it and because their planned release would have been in about 2 months. It's almost never about only the technology, these products and services serve a business purpose or provide value through other means. If it didn't matter, you can of course take all the time in the world, start over 10 times just to come up with what you think the best solution is for the problem. It's totally fine, this is the artistic approach. If you follow the engineering approach then you have to factor in the time and the investment too. Because in that case you have to deliver value.

Regarding peeling away gradually, this wasn't really what I said. The person pushing for the microservices solution said they needed to rewrite. So stop the world, rebuild the thing without having a working system during that period. (Because they didn't have a working system to start with.)