4 ms·

> This becomes a huge cost in the form of cognitive overhead for the team in addition to the time and resources it takes to set up, manage and maintain it The

> This becomes a huge cost in the form of cognitive overhead for the team in addition to the time and resources it takes to set up, manage and maintain it The problem with using one system that you know well for everything is it becomes necessary to build (usually suboptimal) systems that emulate well known ones. In the end you trade one snowflake for another. That being said, there really ought to be standardized approaches to auth, backup and operations as various services today do things very differently and this does indeed increase cognitive load.

Too 3y ago
This. If it weren’t for auth and backups, “docker run prometheus” could be 100 times easier than coming up with your own schema and setting up foreign data wrappers in your already running postgres. Faster too, row vs column storage, etc. Prometheus integrates with every other tool in existence so there is very little reason to wrap it and loose those integrations. With FDW you don’t get off the hook of operating the backing data store anyway. You only get a consolidated query frontend. Kubernetes has solved a lot of the operational hassle of running multiple services. Standardized storage is still a nirvana, if you want to care about consistency, knowing if your database has a WAL or if you need to flush before snapshots, point in time, delayed replication and all that. Getting better, with many new databases connecting straight to S3 or equivalent. Standard auth was supposed to be solved but oauth2 is still a fragmented, difficult mess, often only part of the enterprise version.