HN Explorer

Ask HN: How to decide whether to spin off a [micro]service?

3 points by koliber ↗ HN
Services. Micro, macro. Love 'em, hate 'em. The topic is not new on HN. A recent article prompted some good discussions ( [https://news.ycombinator.com/item?id=29379926](https://news.ycombinator.com/item?id=29379926) ). 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?

3 comments

[ 3.1 ms ] story [ 20.3 ms ] thread
koliber
To start the conversation, I want to share these questions:

- 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?

yakshaving_jgt
In all likelihood, you’ll never actually need to separate systems out in this way, so I think it’s a wiser business decision to kick that can down the road indefinitely.
maltalex
One of the biggest benefits of micro services isn't technical, but organizational.

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.