Gregory's Server|
17 comments
 Well, I guess the server underneath isn't adding much to the complexity any more. I thought modern admins do that through config management, thus that's no overhead anymore and necessary anyhow. The APIs you will need if you want to scale, anyhow. does "one service" instead of 12 mean the one does the tasks of 12 ? Then complexity is only hidden inside, isn't it? I agree about the APIs, but how do you replace those "inside" the one blob server? @tux0r the map is simple, you have the same layout, just internal or external, so there's only one square that is resized to fit the model ...  @callionica @tux0r Yeah but as size & scalability comes in, complexity becomes a beast... I totally agree that ms dont seem best for small tasks. @mfeilner @tux0r The OP was talking about small projects. But also there’s different ways of looking at scalability. For example, you can scale an app on a single machine to meet a workload of thousands of requests per second by writing efficient code within a single process and buying more RAM/disk/CPU whatever. Start going to out-of-process or cross-machine too early and you limit the capability of your dev org as they spend more time working on infrastructure and ops than feature code. @mfeilner @tux0r If there’s no security boundary and there’s no resource contention and there’s no way your app can still run if one of your services goes down, these are indications that you don’t need to separate out your services. Plus when you do need to scale out, routing/sharding based on user or user group or geography works for a bunch of apps/services and is simple to implement. You don't need to replace APIs if your server only needs to talk to itself. One server that performs 12 tasks is still less complex than 12 servers with one task each. "Readable code" and "low complexity" are not the same thing. "Config management" is not required if you don't have oversized environments. That said, overhead won't go away if you add more overhead to mask your overhead. ;-) |
@mfeilner
Not complex:
- One service.
Complex:
- Twelve services which communicate over sophisticated APIs with each other.
I wonder how this is an "interesting view". Just try to draw a map of both models.
@tante @dragotin