I'm really having a hard time finding the willpower to read articles that just even mention "microservices" in the title after working on such architectures (with Java) for a while.
Nice idea but most of the times horribly implemented, with no care about monitoring and logging as someone has already said.
It requires a degree of attention to details during design and development that few are willing to put in. It's easy to go for a prepackaged solution/framework thinking that you are building something that could be considered state of the art, when instead you end up with something that takes multiple tries to even boot correctly or 10 minutes or so to "stabilize" a garbled mess of inter-dependant components.
Designing these systems require a whole new set of skills that were not required when designing monoliths.
You really point out that you’re going to require a dedicated team to manage all the things you’ll need.
I you’re not at this scale there will be a lot of overhead to manage for the dev teams.
I’m in a team like this, supporting a bunch of developers - we build a CLI, an API (in our domain! It’s just another domain with the devs as consumers) and juggle approx. 16 different tools (monitoring, metrics, tracing, service discovery, etc etc).
Doing it through custom tooling that enforces conventions is, IMHO, the way to do it successfully.
This is precisely what the team I lead is responsible for as well. We’ve got a set of standardised libraries, deployment conventions, and a CLI which encapsulate almost everything needed to have a service coexist within the wider platform in a consistent manner.
We’re also responsible for wider reaching services within the platform such as an API gateway, authentication, and event ingestion from IoT devices. As the team that has an on-call rota we also give the final go/no-go on services going into production.
There is a lot of very interesting work to be done in this area (amazing books coming out lately from O'Reilly about these topics) but I feel there is still some piece of the puzzle missing. We need more tools/practices for the developers to guide their development and understand how an architecture behave while they are still building it, to drive design decisions (and also check/correct them along the way).
I worked for a company that had tried to adopt microservices (without a good reason to) and failed miserably. Over time we were able to re-architect it into a "happy medium" of a few large components. It was a huge, costly effort... and I've never learned so much.
Beyond technical concerns, I learned that you can architect a looming disaster and then leave for a higher position at a big company. Nobody watching your conference talk will know.
Nice idea but most of the times horribly implemented, with no care about monitoring and logging as someone has already said.
It requires a degree of attention to details during design and development that few are willing to put in. It's easy to go for a prepackaged solution/framework thinking that you are building something that could be considered state of the art, when instead you end up with something that takes multiple tries to even boot correctly or 10 minutes or so to "stabilize" a garbled mess of inter-dependant components.
Designing these systems require a whole new set of skills that were not required when designing monoliths.