Well, the points you make are certainly valid and for sure microservices (the proper) way may not make sense for any project (or indeed for any team, depending perhaps on size or simply on experience in general).
Speaking from my own experience (as many of these challenges are familiar), I have some observations:
upgrading frameworks: only done per service as needed. I see no reason to do it all the time for all services. Usually on our projects we perform maintenance next time we need to touch a service (update framework / dependencies / perhaps some light maintenance)
common dependencies: unless it's a security issue, having to update all services that use a dependency on an update should be needed unless there's an all-around refactor / redesign. This can get complicated but once a dependency becomes shared it's critical that a service should be able to function on a tagged stable version of that library otherwise it's a deeper design issue there. Certainly you can't "freestyle"-it as a shared component inside a monolith.
debugging: sorry, but here I'm going to defer to what I call the Holy Trinity of microservice projects: logging/tracing/metrics. With OpenTracing embraced by major projects and with support across all languages there's no reason not to instrument your services from the get go. With Tracing in place, debugging becomes easier. With tools like Telepresence, live debugging with a local service is awesome.
There's something to be said about microservices though. In small teams it's hard to go for the proper approach. Between the need to have automated reliable processes in place for everything (DB dumps, for example). But in small teams you can go for an imperfect approach with larger services that could share some things, which is fine when communication lines are small. On the downside, it's not a good practice in the long run but it can be adapted if the team grows.
Also, DevOps. If you don't practice DevOps (in the proper meaning of the term), there's no way to grow into microservice adoption.
OpenTracing is a standard for defining methods of tracing (data structures, how tracing integrates across protocols, etc). It standardizes how tracing happens and how data is exposed to compatible client applications. Jaeger is a pretty well known CNCF project that implements OpenTracing (so does Zipkin). opentracing.io/
I'm a Solutions Architect/developer who likes to try new things and is always looking for some new side projects to work on (and drop the old ones 😬)
Help? https://calendly.com/adrianogalello
Let me reply a couple of points if you don't mind:
upgrading frameworks: Kind of true. You don't need to do it all the time, but sooner or later becomes technical debt and it just pile on top of everything else.
common dependencies: Same as above, it add up at the end.
debugging: I think your point is valid, there's a lot of good tools out there. But I'll argue that the complexity increases and dev cycle is more time expensive when working with a small team handling the whole app (more than three or four microservices). Also the learning curve needs to be taken into account.
The point that I was trying to prove is that, based in my experience, microservices adds complexity and as a team leader/product owner is hard to balance all the aspects of the system if you have a small team.
And just to be clear: I know I could have done things better, at the time I wasn't aware of some problems that I encountered later on, but I learned a lot from mistakes and maybe this could help someone else.
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.
Well, the points you make are certainly valid and for sure microservices (the proper) way may not make sense for any project (or indeed for any team, depending perhaps on size or simply on experience in general).
Speaking from my own experience (as many of these challenges are familiar), I have some observations:
There's something to be said about microservices though. In small teams it's hard to go for the proper approach. Between the need to have automated reliable processes in place for everything (DB dumps, for example). But in small teams you can go for an imperfect approach with larger services that could share some things, which is fine when communication lines are small. On the downside, it's not a good practice in the long run but it can be adapted if the team grows.
Also, DevOps. If you don't practice DevOps (in the proper meaning of the term), there's no way to grow into microservice adoption.
What's OpenTracing? Haven't heard
OpenTracing is a standard for defining methods of tracing (data structures, how tracing integrates across protocols, etc). It standardizes how tracing happens and how data is exposed to compatible client applications. Jaeger is a pretty well known CNCF project that implements OpenTracing (so does Zipkin).
opentracing.io/
Hey, thanks for joining to the converstaion.
Let me reply a couple of points if you don't mind:
upgrading frameworks: Kind of true. You don't need to do it all the time, but sooner or later becomes technical debt and it just pile on top of everything else.
common dependencies: Same as above, it add up at the end.
debugging: I think your point is valid, there's a lot of good tools out there. But I'll argue that the complexity increases and dev cycle is more time expensive when working with a small team handling the whole app (more than three or four microservices). Also the learning curve needs to be taken into account.
The point that I was trying to prove is that, based in my experience, microservices adds complexity and as a team leader/product owner is hard to balance all the aspects of the system if you have a small team.
And just to be clear: I know I could have done things better, at the time I wasn't aware of some problems that I encountered later on, but I learned a lot from mistakes and maybe this could help someone else.