Where I work at the moment loves microservices, I think there's one for every 3 devs, it's interesting to think about (puts a lot of stress on the infrastructure team).
Lots of the things we use microservices for, it seems a well-defined library would do just as well; if the contract between the different bits of code is well defined, it doesn't need to be a microservice, there are other ways of splitting up code. (That also doesn't make the deploy system complicated.) There isn't the independent scaling benefits from microservices (they're all deployed on one server and one fall-back each), everything pretty linearly dependent, so if one goes down everything stops, and there's a lot of excess code floating around configuring the endpoints on top of the business logic itself.
One benefit is microservices force the devs to think about split responsibilities and obey interfaces, but I don't think microservices as a way to enforce discipline is sensible.
(There are two distinct products, and having them as largely independent services make a lot of sense - they don't rely on the same code base.)
Where I worked before, my main project wasn't a web-service, it was a batch-processing pipeline, we needed to split our code base up but we'd never consider using microservices, was 4 libraries. Sometimes the devs broke the interfaces in not-sensible ways, but that was fixed with code review.
Used to do DevOps before they even called it that way: Linux. Python. Perl. Java. Docker. For fun and profit. CTO level generalist working for a mid-sized tech-centric company.
Dresden, Germany
Yes, completely agree; this pretty much reflects my experience too. That's what I am pondering these days - step off the "microservices train" for a while and figure out which problem they actually solve, and whether they solve more problems than they create.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Where I work at the moment loves microservices, I think there's one for every 3 devs, it's interesting to think about (puts a lot of stress on the infrastructure team).
Lots of the things we use microservices for, it seems a well-defined library would do just as well; if the contract between the different bits of code is well defined, it doesn't need to be a microservice, there are other ways of splitting up code. (That also doesn't make the deploy system complicated.) There isn't the independent scaling benefits from microservices (they're all deployed on one server and one fall-back each), everything pretty linearly dependent, so if one goes down everything stops, and there's a lot of excess code floating around configuring the endpoints on top of the business logic itself.
One benefit is microservices force the devs to think about split responsibilities and obey interfaces, but I don't think microservices as a way to enforce discipline is sensible.
(There are two distinct products, and having them as largely independent services make a lot of sense - they don't rely on the same code base.)
Where I worked before, my main project wasn't a web-service, it was a batch-processing pipeline, we needed to split our code base up but we'd never consider using microservices, was 4 libraries. Sometimes the devs broke the interfaces in not-sensible ways, but that was fixed with code review.
Yes, completely agree; this pretty much reflects my experience too. That's what I am pondering these days - step off the "microservices train" for a while and figure out which problem they actually solve, and whether they solve more problems than they create.