Do microservices scale down?

Question

I've been reading up on microservices architecture, which gained a lot of recognition in recent years. As a big fan of UNIX philosophy, I find it very clean and sensible. However, exisiting publications as well as libraries/frameworks seem to treat microservices as solution to "big data", "web scale" and similar buzzword problems. When talking about scaling an app, the context is always scaling it up to work on multiple servers in distributed, networked environment.

Does it make sense to use microservices on a much lesser scale? I.e. I want to write a hobbyist application deployed on single VPS instance and used in total by few hundred people at most. Architectural benefits of microservices are obviously retained, but what about performance when compared to traditional, threading servers and frameworks?

Answer 1

Microservices incur a penalty in both performance and complexity that is usually traded off in order to be able to scale out more easily (adding more instances of various microservices independently). If you're building a small system, avoid the runtime and cognitive overhead by just building out your app as a "monolith". (a terrible word that people now unfortunately attach a negative connotation to)

Answer 2

I'd say a solid no. Microservices more or less inherently need a 24/7 devops support team; an alternative name for the approach is monitoring-driven-development. That's the thing that takes a novel error case and intelligently limits the scope of the failure to something that 99.99% of customers will never be aware of.

A hobbyist project won't have that, and also won't have the millions of customers that mean 1% of them will do more and better testing in an hour than a building-full of QA teams could do in a week. And they certainly won't have a vast system that would be less bad as several huge ones, many large ones, and a few dozen small ones.

Without any of those, microservices are just a way to take a small system and turn it into several slightly larger, slower and buggier systems.

No-one implementing unix cat ever said:

ok, I need to read input and then write output. So I need two main processes, and then another that connects the two together...

Answer 3

Using microservices in your context may still be useful in your context if the system is large enough so that it makes sense to:

• Make the parts of the system be maintained by different developers or even teams,

• Or write the different parts using different languages; for instance, you can have a service written in Python and hosted on a Linux VM interacting with a service written in ASP.NET MVC and hosted on Microsoft Azure servers.

• Or be able to maintain or even completely replace a part of the system without affecting at all the other parts.

If the system is not large enough, using microservices may not be that useful. Probably, you would be better with a single service, while putting proper abstractions and interfaces to make it easier to maintsin the application later.