> And they have over 1000 microservices. And its normally to rewrite them often.
> To me that seems like a bad architecture.
I don't know, the part about it being "normal to rewrite them often" is worrying, but having fleets of microservices managed like Erlang processes or supervision trees sounds interesting and possibly pretty good — assuming that's how they're architected, I've no idea about that. And rewriting a service might be less of an issue if each service is just a small processing loop.
The idea about microservices is that they are small and self-contained. This makes them easy to rewrite completely. Now I wouldn't say it is the goal to rewrite them all the time, but it is not a bad sign if some of them get rewritten occasionally. Microservices are somewhat new and a lot of architecture and infrastructure is being built around it. Companies like Netflix and Uber take the lead in this. Susan Fowler wrote a book about this during her time at Uber, you can find it here:
I've been programming a while now and it definitely is a bad sign if you're rewriting any code often.
Firstly, it takes a lot longer than just making the necessary change. It's a waste of time.
But more fundamentally, I can understand getting it wrong the first time. Throwing what should have been a prototype up without rewriting it. Whatever.
But how the hell did you get it so wrong the 2nd time? And the third time? And the 4th, etc., etc.
Now I'm not afraid to do refactors, massive ones if needed. But there's a big cost to doing it. The big problem with constantly rewriting stuff is that you almost always introduce new bugs. Or you misunderstand the reason behind some of the edge cases and cut them out.
Sounds like the actual problem here is classic NIH syndrome with new programmers coming in, not liking the old programmer's style and rewriting the whole thing.
Part of the appeal and one of the advantages a microservice architecture gives you is that you no longer have to do massive refactors. The services should be small, focused and easy to reason about. Part of me likes the idea of never having to deal with legacy code written 10 years ago in Java 6. Constant rewrites of the same microservice might raise a flag due to unnecessary churn, but I welcome this new era of "immutable" code.
Not trying to sound like a wise guy, but I can see another option: the state of the system is in flux, constantly trying to improve, finding new ways to do it, using new and updated technologies etc.
On top of that, microservices are supposed to be self-contained, but they do depend on each other to some degree.
> To me that seems like a bad architecture.
I don't know, the part about it being "normal to rewrite them often" is worrying, but having fleets of microservices managed like Erlang processes or supervision trees sounds interesting and possibly pretty good — assuming that's how they're architected, I've no idea about that. And rewriting a service might be less of an issue if each service is just a small processing loop.