Далеко не все системы требуют доработки новой функциональности, а где-то это даже вредно

Ну, мне вот интересно, зачем вообще Oracle на Amazon поднимали. Т.е. откуда изначально такую БД ставили.

Грубо говоря у меня 5 эндпоинтов и мне не нужно больше, а вот оптимизировать по процу, памяти, данным это даёт выигрыш в оборудовании.

я так понимаю что был винегрет - там ниже рассказано, использовали как data warehouse - 20 тб в одном отделе, 30 тб в другом, итд…

Далеко не все системы продаются напрямую пользователям и т.п.

Ну и там очень странные примеры (так как то, куда мигрировали - мягко говоря не очень быстрые БД и откуда там может вылезти экономия по ресурсам - нефига не понятно)

Странный кейс и слишком мало данных для выводов (

Хм, а реальный пример такого бизнеса знаешь? Где есть разработка, но она работает не на новую функциональность, а на оптимизацию железа? В теории - оно понятно, а на практике?

Я работаю в такой компании. У нас есть какие-то инфраструктурные вещи, которые не продаются напрямую пользователям, и не требуют новых фич, но оптимизация может значительно сократить стоимость оборудования, которая равна или больше ЗП инженеров.

Э, когда я вижу "у нас для кошельков использовалось 60 instance oracle", то дальше можно уже не читать. Ну нет у Amazon такого числа транзакций и кошельков, чтобы было нужно столько железа при сколь-нибудь разумном его использовании.
Остальные миграции, боюсь, такого же уровня....

(https://aws.amazon.com/ru/solutions/case-studies/AmazonWalletService/?sc_channel=sm&sc_campaign=DB_Blog&sc_publisher=TWITTER&sc_country=DynamoDB&sc_geo=GLOBAL&sc_outcome=awareness&trk=ddbamazonwallet_100319_TWITTER&sc_category=Amazon+DynamoDB&linkId=74640271)

Хм, и реально этих инженеров нет смысла направить на что-то более эффективное, нежели улучшение оптимизации оборудования? И это не одноразовая оптимизация раз в 10, а постоянная попытка уменьшить на 5-10%?

Т.е. прибыль на зарплату настолько мала?

Про миграции БД. Мы только за последние три года дважды мигрировали: аналитику событий с Редшифта на Кликхаус (https://habr.com/ru/company/funcorp/blog/433346/) и хранение и агрегацию счётчиков с Кассандры на Монгу. Вторая вообще по красоте прошла: на счёт раз начали писать параллельно в две базы, потом где-то месяц работал скрипт по перетаскиванию сырых исторических данных, на счёт два переключились на чтение из новой базы, на счёт три - старую базу отключили и погасили. Всё без единого разрыва.

А почему счетчики на монгу переводили? Странный выбор...

Мы научились её хорошо готовить, масштабировать и в ширину, и в высоту. А к Кассандре накопились вопросы, там какой-то внутренний типа GC время от времени клал её на несколько минут в сутки, мелочь, но бесило.

Ну и интересно, зачем вообще все это разворачивать в Амазоне (где очень дорого с дисками и IOPS, а объемы у вас не очень запредельные, насколько я вижу).

Эээ, гм, понятно.

Потому что пилить фичи было выгоднее, чем экономить на AWS)

Ну, в результате все равно пришлось экономить...

Сейчас мы почти целиком уехали в свои стойки в ДЦ, да. Выросли, наняли больше людей, бешеный рост сменился плавным, стало экономически обоснованно.

При сильном росте, кстати, всё равно нет особо выбора, на своём железе просто не успеешь докупать оборудование, и будешь вынужден постоянно что-то в облако масштабировать.