How do you decide whether to spin off a service, and how will it connect and interact with the rest of the system?
A service is a capability. It's something that allows you achieve a behavior in a system. Functionality should be broken into a service only in places where it makes sense, and provides clear benefits to the system and the team. You can have good service-based architectures that are a pleasure to build and maintain. And yet, there are countless stories of teams breaking their system up into services, and then deciding to go back to a monolith.
How do you decide when to develop something as a service?
How do you decide when to refactor a system and split some functionality out into a service?
Are there any key questions that you must ask your team before deciding to do so?
What will make a service-based architecture pleasurable to build and maintain?
Can you share any short-form (articles, presentations) or long-form (books, courses) resources to learn how to do this well?
- Can this service be completely isolated from the other services, interacting only through well-defined interfaces? Does it need to share a DB? Do deployments need to be coordinated?
- If a service can be completely separate (DB, deployment, code), is now the time to spin off the service?
- If the service must share a common DB, what things should teams consider?
- If things should a team consider when deciding how the service will be deployed, relating to other parts of the system?
Micro services and service-oriented architecture in general can be a good fit for when you have separate teams working of different parts of a large product. It allows the teams a lot more autonomy in language and tool selection as well as releases and deployments.