I’ve seen small teams with microservices succeed but not in the speed at which these things promise to return value. I’ve also seen developers fail when they’ve churned out microservice after micro service and couldn’t keep up with the deployment and infrastructure overheads. As an architect I’ve recommended against some of these but what do I know. I’ve just recently asked for a service on a project and they said microservice, and then suddenly I need Orchestration and scheduling. Btw I think k8s has its place I’m not against.
I have seen services architected and deployed beautifully, http, tcp, MQ based, event driven, Ive designed and deployed services as windows services, and Linux based web services, http, API. Seen WCF, XML, rest, json, MQ, messaging across multiple stacks and technologies but I won’t back 90% of new apps feauturing microservices, more like 1 or 2 service endpoints, when what we actually need is governance and thought in these designs. Sometimes a service is a service but doesn’t need early optimisation. Think about decoupling and domains by all means but don’t jump into the next framework marketed at you.
Microservices are usually a bad idea for software unless your whole business model depends on lots of people using your software down the line. It's certainly not good for internal software.
What people really need to do is follow SOLID principles, use interfaces appropriately, and just generally practice good architecture.
The real benefit is the separation of concerns, which microservices promises to deliver. But well designed software does that too, and you don't have the headache of coordinating all that hardware.
I guess it's easier to sell something trendy to upper management (we're doing the new, hot thing) than to sell a code rewrite (we're not going to ship new features for a while as we opaquely push around code).
I have seen services architected and deployed beautifully, http, tcp, MQ based, event driven, Ive designed and deployed services as windows services, and Linux based web services, http, API. Seen WCF, XML, rest, json, MQ, messaging across multiple stacks and technologies but I won’t back 90% of new apps feauturing microservices, more like 1 or 2 service endpoints, when what we actually need is governance and thought in these designs. Sometimes a service is a service but doesn’t need early optimisation. Think about decoupling and domains by all means but don’t jump into the next framework marketed at you.