
Ask HN: At what size do Microservices make sense? - stephenheron
I like the idea of Microservices, however I have yet to have a project of the size where I felt the benefits of them outweighed the drawbacks. However I am going to meetups and conferences and seeing 1 - 2 people startups start with a microservice architecture.<p>I am wondering if I am missing something and microservices are perhaps more suitable for smaller projects &#x2F; teams that I had originally thought.<p>Any advice would be fantastic.
======
itamarst
Microservices are mostly an organizational tool: how do you get 500
programmers to work on one website?

Solution: one service per team, aka microservices.

(Occasionally there are technical reasons to have multiple services, e.g. one
for loading data and one for processing data. But that's not really the same
thing.)

------
codeonfire
I thought managers would give up on talking about "microservices" about 2
years ago I thought they would latch onto "blockchain" and "crypto." The are
still talking about "microservices" but just mean that they want each team to
have their own hardware and communicate over the network. Look, this stuff is
three decades old at least. When someone says "microservices" I know they are
a clueless idiot manager. They can't explain what they are talking about in
terms of build, deployment, versioning, networking, processes, etc. They try
to enforce mistakes that explode performance. They say "monolith bad." The
can't really say anything beyond that because they are faking it.

Don't like monoliths? here's a "microservice architecture" for you, Java
servlet API, circa 1997. Everyone can package their micro-service into a WAR
file and deploy it to a service environment. That's right, Companies were
doing this shit in the 90's. It probably amazes these same people to know
there were servers and computer networks in the 1980's as well. Http was not
even the first popular protocol of its kind.

What I hate are these managers who pretend they know what they are talking
about saying, "microservices", but they are fucking faking it every step of
the way.

~~~
codeonfire
Oh, and to answer OP's question, no microservices are absolute shit for
startups. You want all your code in the same address space so there is zero
communication overhead between different parts of the code. Hosting small
services all over the fucking place was only due to small hardware in the
past. Today, we can get 128 core machines with multi-terabytes of RAM if it is
needed. It becomes a problem of how do we deploy code independently in small
units. Well, any platform that can hot swap code does just that.

------
indogooner
Visibility of benefits depends on how your engineering organization is
structured. Once you have a lot of teams working with monoliths becomes very
painful. Having independently deployable unit starts making more sense then.
Each service owner has to expose APIs for their users and that forces them to
think more about how their service is supposed to be used and what problem is
it solving. This also gives autonomy to teams in developing/maintaining their
services (tech choice/programming language). Services also help in isolation
and QoS. For example if you have different services handling order execution
and order listing, the service handling execution has to be highly available
and responsive while you can be a bit lax with other one.

With services you do need to have a good monitoring system in place. Also
having ability to trace a request across services is a great boon. Helps in
proper communication across teams.

These are of course only some of the reasons I could think but one thing
should be clear that going Microservices route involves buy-in from the
engineering org and a good enough developer population (I feel ~30+ is good to
start)

------
bjourne
It's a buzz word with no content. "Microservice architecture, or simply
microservices, is a distinctive method of developing software systems that
tries to focus on building single-function modules with well-defined
interfaces and operations." That is the normal way of developing software
systems.

In practice, it can mean responsive web sites that relies on AJAX end points
or a collection of REST api:s. But you can never know that any two people mean
the same thing when they speak about "microservices."

------
BjoernKW
In my opinion your perceptions are correct. Microservices aren't a cure-all to
be applied indiscriminately. They're a design pattern that's useful in some
contexts and less so in others.

In order to really benefit from the use of microservices your organizational
structure has to be non-monolithic as well (Conway's law), i.e. ideally you'd
have cross-functional teams that take end-to-end responsibility for single
microservices.

------
borplk
If you have to ask the question you don't want to do it :)

