Great post! I already have an SOA-ish architecture with a few dozen services, some fairly large, some small... All try to encapsulate a specific business function. They use HTTP and RMQ to communicate.
I've been trying to determine how to move to microservices, thinking I need to figure out how to make the services smaller. But maybe that's not the point, I should break them up when I reach the point that I see an obvious seam to break on?
So don't take a business requirement and try to determine how many services I can turn it into, but determine how few services I can turn it into and then add more when necessary?
That seems to make sense to me.
Instead maybe I'll focus my efforts on migrating our existing services to Docker and Kubernetes or Service Fabric to get our system into an easier place to deploy, manage, and debug. Which would also make it easier to break up existing services when I need to.
Any thoughts?
Thanks!
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.
Great post! I already have an SOA-ish architecture with a few dozen services, some fairly large, some small... All try to encapsulate a specific business function. They use HTTP and RMQ to communicate.
I've been trying to determine how to move to microservices, thinking I need to figure out how to make the services smaller. But maybe that's not the point, I should break them up when I reach the point that I see an obvious seam to break on?
So don't take a business requirement and try to determine how many services I can turn it into, but determine how few services I can turn it into and then add more when necessary?
That seems to make sense to me.
Instead maybe I'll focus my efforts on migrating our existing services to Docker and Kubernetes or Service Fabric to get our system into an easier place to deploy, manage, and debug. Which would also make it easier to break up existing services when I need to.
Any thoughts?
Thanks!