Ой, он премизес это такой ДБА дроч, что ты на голову не натянешь. Так же если у тебя проблемы, всё зависит от твоих спецов. Если у авс проблемы, то ты уверен, что там челики умные этим занимаются. А тебе, чтобы хайрить спецов уровня амз надо будет очень долго моргать перед CFO почему да как. Платят за манагед, да, есть проблемы и с манагед, как раз чтобы не платить в 3-5 раза больше за команду ДРЕ. 20 тысяч € в месяц за рдс это херня по сравнению со штатом SRE/DRE в 10 человек в месяц

Какой неожиданный вывод по картинке :)

Знал одного средней руки предпринимателя, у него была мечта - всех уволить и заменить подрядчиками. А самому сидеть и рулить. Даже пытался.

Из крайности в крайность, как обычно. А решений нуль. Называть ребят из амз подрядчиками, думаю это точно моветон.

А что есть сомнения? :) Может еще и контракторы дешевле штатных сотрудников, поэтому их и заменяют? :)

Моветон - это думать, что перенос БД в облако как-то решить проблемы с проектированием, администрированием и поддержкой. Ну, вот разве что с поддержкой будет по-другому :)

Я думаю что оч наивно такие вещи утверждать вне контекста

В прочем я ничего другого не ожидал

Так же как рассуждения на тему "языка для выборок" никак не влияют на необходимость модель данных грамотно выбирать

А как ее ещё интерпретировать - с одной стороны "шо хочу то верчу" а с другой стороны более жёсткие требования к модели данных

Только не к модели данных, а к модели базы данных. Это раз. Если язык запросов неявно запрещает помещать искомые данные ниже 1-2 уровня вложенности - это проблема языка, а не модели данных. Это два. Использование схем в документо-ориентированных моделях данных мгновенно приводит к необходимости проектирования и чистки данных, что и в реляционных БД. И тогда, ввиду "это два", выбор совершенно не в пользу.

Документные базы выбирают не для того что бы хранить "свалку".

На тему "схемы" - документы надо как-то мэпить на структуры приложения - значит схема будет или шот странное

Везде вижу "шот странное". По ID выбираются нужные "сырые" документы из даталейк-помойки, потом они обрабатываются и используются приложениями или витринами

Ребят подскажите про межсервисную аутентификацию. Какие есть подходы валидации токенов? Я вот не хочу каждый раз идти в auth сервис и проверять валиден ли токен. То есть речь идет именно о том когда сервис А пришел в сервис Б. Но при этом сервис А должен понять, чтоб это именно сервис Б, и понять что ему что то разрешено а что то нет.

валидация по пкбличному ключу же
зачем куда то ходить?

так я узнаю что это пришел именно сервис Б, но как понять что ему разрешено и что нет?
В таком подходе ключи не динамические? Их не надо перегенерить раз в какое то время? И что потом будет с логированием? То есть в логе я увижу неподписанный запрос с referer и должен поверить что он от сервиса Б ?

речь про ssl ключи? Или про то что часть JWT подписи провалидировать?

Как угодно хоть оба срузу.

если ты знаешь, что это сервис Б, то у тебя внутри сервиса А есть прописанные разрешения "сервису Б можно это и вот это", тогда смотришь на разрешения внутри сервиса А и решаешь можно или нет

Ключи не динамические
Передавайте в подписанном запросе что ему разрешено или просто зраните у себя еслиу вас ыентральная система
и пусть она вам эти права скидывает в случае из изменений