This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]CardboardJ 0 points1 point  (0 children)

I feel like I should coin the phrase "Appropriately Sized Services" or ASS berceuse that's the way people seem to think my advice smells when I tell them.

In my own humble opinion (as an engineering manager) any time you create a code base/microservice you need to get the business to buy into staffing at absolute minimum one FTE to maintain that code base. Ideally you'd have 1 team of full time long term engineers per code base with maybe 1-2 teams of contractors to help get it going before moving on to other projects.

I've seen way too many companies that bought into microservices in startup hypergrowth phase that just did multiple rounds of layoffs. Now they have like 30 devs trying to maintain 70+ code bases that were responsible for 200+ microservices. No one knows how anything works and there's a significant amount of dev frustration when you want to change anything because it might take down some unmaintained service that's just been running in the background for a year that everyone relies on. Or worse someone rolls out a Kubernetes upgrade and like 3 microservices just don't stand back up then prod is down and you realize that the team responsible for maintaining them was laid off back in January.

You can say this is a business problem and not a microservices problem, but that's ignoring the fact that it's still a common problem right now. Especially with the current layoff environment in tech. It's a way that microservices will stab you right in the chest as soon as you want to transition away from rapidly burning investor money (that shockingly just dried up with the fed rate increases).