3 ms·

I like the idea that services should mimic the people organization that maintain them[0]. Obtuse rule - Don't build a service smaller than a team. Probably 2 t

• throwaway984393 5y ago
  Services should not mimic the people organization, because the people organization sucks. Don't care how they're organized. No-hierarchy? Sucks. Top-down? Sucks. Balls of people with guns pointing at the other balls of people? Sucks. Two-pizza teams? How fat/skinny are the team members? Humans are dumb, they're bad at communication, and the bigger the group, the worse both get (it's done been scienced!). Software should not mimic those qualities; and it doesn't have to! We can have really smart people design the software, and have those people tell the organization how to build it and run it in a collaborative way, regardless of how the people are organized. Organization shouldn't dictate how we work together; that's like your filing system dictating how you write letters. What we always seem to forget is that humans are pretty much the most adaptable species on the planet. Give them criteria and they will fit themselves into it, like a cat in a really uncomfortable looking container. We should of course avoid shitty people organization because of its impact on software design (which is really just poor communication structures put into code). But we should also acknowledge that the design is only impacted by the organization because we're too lazy to reject the concept of "team X can only touch component X". And this isn't just woo-non-hierarchy, there's a simple middle ground: education. Teach your people how all the components work, teach them how to make changes, and unblock them / give them agency. They will flutter around like worker bees just knocking out problems everywhere. It's when people don't know what's going on with the components they never touch, and don't know how to change them, that they start to make bad decisions that then have knock-on effects. The org structure doesn't have to lead to people not knowing what's going on. It doesn't have to lead to poor communication. It doesn't have to lead to controlling who can do what. We just decided that's what we'd do, probably because standing up and saying "hey, can we do this differently?" causes some kind of social pain. That and of course, the more it changes, the more education is needed. But kind of like with TPS, I think if we focus more on those "boring things" like quality and waste, everything else will be naturally elevated.
• tyingq 5y ago
  Couldn't a team maintain some number of small services? I do see the team size issue with a service that's too big.
  • irjustin 5y ago
    It's easy to build and easy to maintain each service individually (most attractive selling points of services). Where it gets expensive fast is in multi-service issue debugging. It's not as simple as putting a break point and inspecting a bunch of variables. Specs also can become unwieldy. Does your test suite run all the services it needs to run? Does it connect to a test env? Everything is a trade off of course, but an obtuse/simple recommendation is the larger the service is the easier issues are to 'figure out'. If you've ever been part of an organization that drank the microservices koolaid and then had insane time trying to debug issues that spanned 4-5 services, you'll know the pain. It's not always super obvious which service is manipulating the data such that downstream it breaks.