HN Explorer

Ask HN: How many developers should you have before you switch to micro services?

14 points by drbojingle ↗ HN
I've been under the assumption (and feel free to correct me) that microservices are primarily for team scaling. Yet whenever I look around the internet I fail to find good data showing me the size of a team when they switched to microservices vs how successful/how much they liked it or w/e.

So, feel free to provide any commentary but, if you've worked on a team that switched to microservices I would appreciate it greatly if you could tell me: - how many people worked on the back-end simultaneously when you made the switch - your feelings about it at the time - amount of time passed since then - how many people work on the back-end simultaneously now - how you feel about it now

I want to see if there are any trends. I'm expecting that anyone who tried it with a team of 5 had a hard time and anyone that tried with 50 had a good time but I'm curious to see if there's a clear cut off which dictates that "if you try micro-services while your team only has x team members you can't hope to have a positive experience with it" and what x approximates to.

Greatly appreciate any input, corrections, insights, or comments!

25 comments

[ 0.29 ms ] story [ 69.6 ms ] thread
smt88
> microservices are primarily for team scaling

I've never heard this before or thought about it this way. If you need to restructure your code because of your team size, you have a bigger problem with your code than whether it's separated into microservices or not.

"Let's do everything as microservices" seems like a trend from a few years ago that has now somewhat died down. My suspicion is that it was PaaS companies like Heroku pushing people to do this because it made more sense for their products, but I don't have any evidence for that.

Since then, it seems that people have remembered not to solve a problem you don't have. If your code works and it's easy enough to work on it, you don't need to radically change its structure.

Keep in mind that several companies have tens of thousands of employees working on a mono-repo.

> I'm curious to see if there's a clear cut off which dictates that...

There's no clear cut off for anything in managing a software team. It's not a science, and individual situations vary too much to create hard and fast rules.

drbojingle
Thanks, I appreciate your feedback!

> There's no clear cut off for anything in managing a software team. It's not a science, and individual situations vary too much to create hard and fast rules.

Intuitively, I disagree. There's a lot of nuance for sure but, but there are still patterns that can be noticed.

smt88
There may be patterns, but who says they're good patterns? I see more badly-run teams than well-run teams.
drbojingle
Out of curiosity, from your perspective, is there anything that the bad teams share that the well run teams don't and vice versa?
karmakaze
> If [...] easy enough to work on it, you don't need to radically change its structure.

This is precisely the point. When you have a large number of developers all working on the same deployment unit, it isn't easy to work on. A mono-repo is orthogonal to microservices.

scirocco
And being difficult to work on means dependencies with other teams, making changes slow. This slows down innovation speed and enables competitors to launch competing services faster. So there's the business need of microservices :)
closeparen
Monorepos and monoliths are completely separate concepts. There are monoliths that import hundreds of separately versioned components from separate repos. And there are monorepos from which hundreds of different services are deployed, which do not directly link against each other at all. Monorepos are about library versioning, not architecture.
sebmak
Rather tell you how many developers i think you need before you should switch to microservices i will instead tell you about my team and why we use microservices.

I am currently leading a team of 7 (including myself) and we currently operate a Monolith Rails application with several small to medium microservices.

Our philosophy is essentially, is what we need part of the core functionality of our application, and does it rely on other core functionality. If so then it goes in the monolith. But if it is independent of the other core features then we build it as a standalone service.

We started moving to microservices ~2 years ago when our team was only 2 (me and 1 other). It was much more difficult to maintain at the time, but the flexibility in being able to rewrite certain things when necessary was greatly beneficial. Things like automating our build and great documentation for how things interconnect has alleviated alot of the trouble we had running our microservices.

drbojingle
Thanks for sharing! I like your approach. I've often seen the 'do everything as a microservice' idea get tossed around. I get the feeling that your approach is pragmatic.
_shadi
I don't think it has to do with team size alone, although it is much easier to work with in large teams, first time I used microservices I was in a team of 6 developers, main pain point for us was deployments, it would take sometimes 2 days to do a full deployment of the 10+ old years that was not always well-maintained monolith we were working on, we decided that any part of the functionality that makes sense to be independent from the rest and can be updated/deployed alone to extract it into a microservice instead of refactoring it when we touched it, at the beginning the process was even slower and we had to learn a lot, but with time and after we built a good knowledge base on the different aws services and had a better set of Jenkins job it became much smoother.
drbojingle
I agree that it's not team size alone. Team size is just the variable I'm most interested in.

Thanks for sharing your perspective!

You reference AWS services and Jenkins jobs making things smoother. Is there anything, in particular, you would say should be considered a pre-requisite before adopting microservices, based on what you've learned?

_shadi
most of us had experience with traditional development only, so we had to adopt devops mentality to be really effective, the company had ~4 system engineers who were working on the monolith full-time, so we had to take care of the microservices we built ourselves.

by AWS services I meant things like cloudformation, packer, ansible, consul, the nitty-gritty of ELB, EC2, S3, docker, hardest part for me was IAM and vpc/subnets, dealing with multiple caches instead of a big one, also distributed sessions(in the end we got rid of sessions and used identifiers and a key-value store).

Jenkins jobs to deploy and test every single service on its own, and for deploying everything to a test environment and run integration tests.

UAT for testing all services on test environment.

There is much more than that but these are the things I remember from the top of my head.

drbojingle
Sounds pretty complex! What are you making if you don't mind me asking?
_shadi
I'm no longer at that company, I would rather not share more personal information, but the product was a sort of a marketplace implementation.
drbojingle
That's cool, I'm not interested in personal info. I am curious how many developers were working on your back-end at any given time and how many services you had at any given time.
closeparen
If there are 50 commits in every release, and a 2% chance of a given commit breaking something, then in expectation every monolith deploy gets rolled back. As release engineering gets harder, time between deploys grows, so number of commits per deploy grows, so release engineering gets harder still.

Microservices are one way out of that cycle. But then you need teams to run a distributed scheduler, service discovery and load balancing, RPC standards and libraries, IDL registry, central build system, time series metrics collection and reporting, distributed tracing, a standard framework per language, etc, etc. My employer has at least one person working full time on each of those list items. Some have more than 50. And I wouldn’t dream of doing microservices without them.

At least whatever’s in Martin Fowler’s article [0], and more.

A word of caution: any microservices you do before you’ve actually productionized and standardized all that stuff become very painful tech debt.

https://martinfowler.com/bliki/MicroservicePrerequisites.htm...

lastofus
> If there are 50 commits in every release, and a 2% chance of a given commit breaking something, then in expectation every monolith deploy gets rolled back.

> Microservices are one way out of that cycle.

Is the implication that microservices lead to fewer bugs, or that microservices allow you to roll back one service instead of the monolith app as a whole?

I would argue the former implication is a dubious claim, and the later doesn't make sense if other services depend on a given service running the latest version, which is often the case when implementing new features.

If you are releasing bugs with every rollout that require a rollback, then perhaps a simpler solution is to do smaller releases with an improved testing/QA cycle.

atmosx
> the later doesn't make sense if other services depend on a given service running the latest version, which is often the case when implementing new features.

Properly designed microservices should take this into consideration and support versioning, fallbacks, circuit breakers, etc.

dlahoda
1. Start coding in something which is Dotnet Orleans and Scalaz ZIO at same time. Tell me where you have found that techno.
drbojingle
Sounds like the actor model. Erlang? Elixir? Not really sure where you're going with this :P
MrTortoise
You don't need team of X for microservices.

It's an approach with trade offs.

Made it work with 2 devs

drbojingle
Thanks for sharing! How did you find it compared to a monolith?