
Ask HN: How many developers should you have before you switch to micro services? - drbojingle
I&#x27;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&#x2F;how much they liked it or w&#x2F;e.<p>So, feel free to provide any commentary but, if you&#x27;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<p>I want to see if there are any trends. I&#x27;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&#x27;m curious to see if there&#x27;s a clear cut off which dictates that &quot;if you try micro-services while your team only has x team members you can&#x27;t hope to have a positive experience with it&quot; and what x approximates to.<p>Greatly appreciate any input, corrections, insights, or comments!
======
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...](https://martinfowler.com/bliki/MicroservicePrerequisites.html)

~~~
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.

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

~~~
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 :)

------
qualsiasi
Sorry for just posting a link, but I find this to be very relevant (and I
think has been discussed on HN).

> [https://nickjanetakis.com/blog/microservices-are-
> something-y...](https://nickjanetakis.com/blog/microservices-are-something-
> you-grow-into-not-begin-with)

~~~
drbojingle
I liked it! This article is very much along my line of thinking on the
subject.

Thanks for sharing!

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

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

