3 ms·
As someone who has worked in this space, I would intuitively go with the decoupled tools every time. The toughest thing is matching a monolith of opinions with
by cgio 3y ago
As someone who has worked in this space, I would intuitively go with the decoupled tools every time. The toughest thing is matching a monolith of opinions with your requirements. Individual tools leave design space in their integration and thus allow proper engineering. That they allow it, does not mean it happens. If you go with a shopping bag architecture then you might be better off results wise with an integrated solution, but still, when the real engineers come along they’ll have an uphill battle to uproot an integrated solution vs redesigning the combination of individually good tools.
- CRConrad 3y ago> I would intuitively go with the decoupled tools every time. Seems to me that the problem is, each of these "decoupled tools" you mention isn't some specialised little awl or hacksaw ("the Unix philosophy..."), nor even a do-anything Swiss Army knife -- but a whole stack of cloud services, "integrations", and administration tools in its own right. A whole machine shop of machine shops. Building your own custom setup out of that is hard. You'll end up with something at least as unwieldy as a really big do-anything single-vendor mega-machine shop stack of cloud services, "integrations", and administration tools.