Our number is closer to 1,700 now, but yes this means 1,700 distinct applications. Each application has many instances, some have thousands of instances.
But since asking the question I've realized that if your application already needs a huge amount of servers because it simply gets that much traffic, then putting something like this in its own docker instance is probably the simplest way (it might even use postgres inside it), if those boundaries change now and then.
But most companies aren't near that scale.
- Select(db, somekey, someparameters) [return some db object]
- http_get_query(http://service.com/somekey/someparameters [return some JSON]
They are external (micro)service:
- they both need the target system to be available.
- they both may fail in weird and unexpected ways.
- they both need to handle failure gracefully.
Their usage have different properties:
- A database call need to have a permanent connection pool to the database, usually requiring db user and password.
- A http call is just call and forget. It's a lot easier to use, in any applications, at any time.
A better question would be why not write a module or class? There a pros and cons to either, but advantages include: better monitoring and alerting, easier deployments and rollbacks, callers can timeout and use fallback logic, you can add load balancing and scale each service separately, it's easy to figure out which service uses what resources, it makes it easy to write some parts of application in other programming languages, different teams can work on different parts of the application independently as long as they agree on an API.
E.g. I can't think of a REST service doing this; something like a direct socket connection (over a HA / load-balancing level) with a zero-copy serialization format like Cap'nProto might work.
I would love to hear a breakdown. This sounds like a nightmare to maintain and test.
Time to forbid adding more stuff and start cleaning.
(12) [...] perfection has been reached not when there
is nothing left to add, but when there is nothing
left to take away.
What number is that?
Anecdotally, I've worked on services that ran tens of thousands of instances across the world. You build the tools to manage them and it works very well.
Microservices can go to far. I'm very thankful for this video.
People talk about interpreted languages being slow sometimes, now your program is divided over 1700 separate servers and instead of keeping variables in memory you have to serialize and send them over the network all the time.