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?
Top-level
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? 6 comments
@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. |
@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 ...