Services. Micro, macro. Love 'em, hate 'em.  The topic is not new on HN. A recent article prompted some good discussions ( [ ). Let's continue this conversation.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?