Good post!
A microservices approach is hard. We are somewhere in the middle right now, we run multiple backend services because the scale of our app is large, and some services are request/response from a client while others are running continuous processes based on other inputs.
The multiple services helps a lot with smaller, faster deployments, more specific responsibility, and being able to load balance more intensive services.
But it does add complexity to debugging, and isolating run-time issues. It is also harder for new developers to get up to speed if they are used to just executing a monolith with a web app attached to it.
We considered moving closer to a pure microservice solution but complexity immediately ratcheted up as we experimented with things like Docker, Kubernetes/ServiceFabric, total isolation of the service by using data redundancy.
All of the microservice concepts make a lot of sense, but they all introduce trade-offs. Our current plan is to use microservice patterns to solve specific issues that our existing architecture has instead of trying to be a microservice purist.
You said something in your post here that really stuck out to me btw. You mention that you’re “considering moving closer to a pure microservice solution”. I think that’s really key ... folks (myself included) write about microservices as if it’s an all or nothing thing. But in reality, you can partially adopt microservices where it makes sense, and not where it’s doesn’t. I suspect the place where most folks should start, is shove their monolith in a container, and add microservices around it slowly as needed, rather than going through a huge rearchitecture.
Ethan brings up a good point about it not being an all or nothing effort... In fact, there's recommended patterns about refactoring monoliths into separate services over at microservices.io/refactoring/index...
Docker is mostly the tip of the iceberg, in my mind, and Kubernetes is not the only option for running those containers. For example, k3s or Swarm are a more simple mental model to run in a small environment.
As far as observability and debugging are concerned, if you clearly define the scope of each services and their dependencies, and additionally decouple them with the help of message brokers rather than all point to point communications, it should be possible to easily inject log gathering, metrics, and distributed tracing on almost each component as part of a "chassis" for which each component of your infrastructure runs. Once you define the build pipelines and runtime environments for each service, and document and distribute knowledge about those decisions, it'll ultimately help democratize the deployments and development of each business unit, whose cost is amortized over the time it takes to gain knowledge in these areas.
And of course, there's companies available that'll teach or otherwise make that burden more manageable.
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.
Good post!
A microservices approach is hard. We are somewhere in the middle right now, we run multiple backend services because the scale of our app is large, and some services are request/response from a client while others are running continuous processes based on other inputs.
The multiple services helps a lot with smaller, faster deployments, more specific responsibility, and being able to load balance more intensive services.
But it does add complexity to debugging, and isolating run-time issues. It is also harder for new developers to get up to speed if they are used to just executing a monolith with a web app attached to it.
We considered moving closer to a pure microservice solution but complexity immediately ratcheted up as we experimented with things like Docker, Kubernetes/ServiceFabric, total isolation of the service by using data redundancy.
All of the microservice concepts make a lot of sense, but they all introduce trade-offs. Our current plan is to use microservice patterns to solve specific issues that our existing architecture has instead of trying to be a microservice purist.
You said something in your post here that really stuck out to me btw. You mention that you’re “considering moving closer to a pure microservice solution”. I think that’s really key ... folks (myself included) write about microservices as if it’s an all or nothing thing. But in reality, you can partially adopt microservices where it makes sense, and not where it’s doesn’t. I suspect the place where most folks should start, is shove their monolith in a container, and add microservices around it slowly as needed, rather than going through a huge rearchitecture.
Ethan brings up a good point about it not being an all or nothing effort... In fact, there's recommended patterns about refactoring monoliths into separate services over at microservices.io/refactoring/index...
Docker is mostly the tip of the iceberg, in my mind, and Kubernetes is not the only option for running those containers. For example, k3s or Swarm are a more simple mental model to run in a small environment.
As far as observability and debugging are concerned, if you clearly define the scope of each services and their dependencies, and additionally decouple them with the help of message brokers rather than all point to point communications, it should be possible to easily inject log gathering, metrics, and distributed tracing on almost each component as part of a "chassis" for which each component of your infrastructure runs. Once you define the build pipelines and runtime environments for each service, and document and distribute knowledge about those decisions, it'll ultimately help democratize the deployments and development of each business unit, whose cost is amortized over the time it takes to gain knowledge in these areas.
And of course, there's companies available that'll teach or otherwise make that burden more manageable.