Hacker News Reader

Comment by 0x445442 | Hacker News Reader

Yeah, I've not seen much in the way of definitions about what the bounds of a "micro" service are or how much scope each one includes.

It sounds like you're saying that a single micro service maps to a team. Do you think each team should manage many micro services and how many do you think each team should manage?

I'm generally interested but having been the guy on dev teams to handle most of the configuration management stuff I've not really been willing to listen to micro service advocates.

Depending on runtime environments/architectures the CM costs sound prohibitive at best.

View on HN

One per team sounds about right, unless there are some components that don't fit together in the same runtime (e.g. a data lookup with a little business logic might not fit with a module sending out emails). That said libraries go a long way to reduce the dependency graph and prevent developers from creating unnecessary edges by randomly autocompleting code.

IME we had multiple services for each team. But we were in the process of carving several mutually incompatible whales into common, shared services, YMMV. So we had one team maintaining each whale, and our senior engineers would collaborate to identify pieces that could be cut from each and replaced with a common service. If the innards of one whale matched our service better than the others, that whale's team got to write the service. Eventually all the teams would port their products to the new, resulting service.

This meant, for example, that my team, had our whale, an audio transcoding service, an automated transcription service, a post-phone-call messaging service, and several data integrations.

If you need a whole team to do nothing but maintain a service, it seems to me like you built it to do too much.

So you would hard couple your architecture to your current org structure?

Software architecture always mirrors org structure anyway. That’s Conway’s law.

and boy if it doesn't mirror org structure. you get pain :)

multiple services per team are trickier. also depends on their complexity. sometimes you can't get around it.

it also depends on your infrastructure to manage services. if setting up, managing, deploying and monitoring a service is cheap it can make sense.

Reply on news.ycombinator.com