На продакшен сервере железном оно крутится на 16 ядерном интеле, EC2 такой же выбирается, я ж говорил про аналогичное железо.
5к$+ это мой аргумент против облаков — не должна зп специалиста по обслуживанию облачной инфраструктуры быть в разы больше чем экономия от перехода с железа к облаку в случае близком к идеальному. Грубо говоря, сейчас тратим 1000$ в месяц на железо и админ за 2500$ следит за ним. 5000$ в месяц человеку, который сумеет на облаке выжать пускай даже 500$ в месяц на те же задачи, выглядит несколько нерационально. Равно как и переход в облако силами имеющегося админа, если затраты с 500$ вырастут до $1500$ при той же за админа
Да какая разница какие запросы и индексы? Есть приложение, успешно работающее на, например, bare metal или VDS. Но принято решение перевезти его на облако Amazon c целью сокращения операционных или капитальных (следующих периодов) затрат. Необходимости переписать всё приложение под cloud native не обозначено. Максимально использовать сервисы самого облако вместо уже развернутых self hosted тоже.
С какого перепугу техспециалист должен делать что-то больше чем перевод с вручную созданных дроплетов DO на вручную созданные инстансы on-demand EC2, если первые почти полные аналоги вторых, только дешевле? Кто должен уточнить задачу?
Из ваших постов создаётся впечатление, что облако не выгодно только тем, кто не умеет его готовить по причине идиотизма. ) Ну или в каких-то совсем граничных случаях.
А некоторые идут свято веря, что принцип "платишь только за то, что используешь" уменьшит их расходы, не вдаваясь в нюансы того, что облака считают использованием и использованием чего.
Вы передергиваете. Тут речь о том, что, скорее всего, подобная задача будет недостаточно полно описана, а если исполнитель не мотивирован развиваться в этом направлении, считая подобный переезд очередной блажью начальства, поддавшегося на сказки маркетологов, то глубоко, особенно в личное время, рыть он не будет и пробелов в задаче объективно заметить не сможет.
Формально задача будет решена, но, скажем так, лучшие практики в области экономической эффективности применены не будут, потому что ни постановщик, ни исполнитель о них не знают: для постановщика переезд означает автоматическое уменьшение затрат при автоматическом увеличении надежности, а для исполнителя — просто смена поставщика VDS, причём на объективно более дорогого
Помню как завис знакомый mysql когда в России отменили переход на летнее время. В смысле, когда настал день. когда должны были перейти, но с новым законом не стали. Обновления tzdata в ОС стояли, но у мускуля свои отношения с tz
В конце-концов эффективность программиста в коммерческой организации определяется тем, сколько его код приносит или экономит денег компании или "енэйблид" возможность другим это делать.
Причём включено даже когда ты один арендуешь и на 100% уверен, что ещё 100 тебе понадобятся разве что через сотню лет, по одному в год. И то, если повезёт с бизнес-идеей
На продакшен сервере железном оно крутится на 16 ядерном интеле, EC2 такой же выбирается, я ж говорил про аналогичное железо.
5к$+ это мой аргумент против облаков — не должна зп специалиста по обслуживанию облачной инфраструктуры быть в разы больше чем экономия от перехода с железа к облаку в случае близком к идеальному. Грубо говоря, сейчас тратим 1000$ в месяц на железо и админ за 2500$ следит за ним. 5000$ в месяц человеку, который сумеет на облаке выжать пускай даже 500$ в месяц на те же задачи, выглядит несколько нерационально. Равно как и переход в облако силами имеющегося админа, если затраты с 500$ вырастут до $1500$ при той же за админа
365.24 же по феншую
Особенно если "местное" для них по жизни синоним "по Москве"
Это если она дату календарную записывает, а не количество тиков от старта
Да какая разница какие запросы и индексы? Есть приложение, успешно работающее на, например, bare metal или VDS. Но принято решение перевезти его на облако Amazon c целью сокращения операционных или капитальных (следующих периодов) затрат. Необходимости переписать всё приложение под cloud native не обозначено. Максимально использовать сервисы самого облако вместо уже развернутых self hosted тоже.
С какого перепугу техспециалист должен делать что-то больше чем перевод с вручную созданных дроплетов DO на вручную созданные инстансы on-demand EC2, если первые почти полные аналоги вторых, только дешевле? Кто должен уточнить задачу?
Ок, не техдокументацию, а финансовую: биллинг, тарифы и т.п.
Не гендирское же это дело изучать техдокументацию
Из ваших постов создаётся впечатление, что облако не выгодно только тем, кто не умеет его готовить по причине идиотизма. ) Ну или в каких-то совсем граничных случаях.
А некоторые идут свято веря, что принцип "платишь только за то, что используешь" уменьшит их расходы, не вдаваясь в нюансы того, что облака считают использованием и использованием чего.
Вы передергиваете. Тут речь о том, что, скорее всего, подобная задача будет недостаточно полно описана, а если исполнитель не мотивирован развиваться в этом направлении, считая подобный переезд очередной блажью начальства, поддавшегося на сказки маркетологов, то глубоко, особенно в личное время, рыть он не будет и пробелов в задаче объективно заметить не сможет.
Формально задача будет решена, но, скажем так, лучшие практики в области экономической эффективности применены не будут, потому что ни постановщик, ни исполнитель о них не знают: для постановщика переезд означает автоматическое уменьшение затрат при автоматическом увеличении надежности, а для исполнителя — просто смена поставщика VDS, причём на объективно более дорогого
Помню как завис знакомый mysql когда в России отменили переход на летнее время. В смысле, когда настал день. когда должны были перейти, но с новым законом не стали. Обновления tzdata в ОС стояли, но у мускуля свои отношения с tz
Для мотивированного и имеющего время на это
Кто ради экономии, а кто готов переплачивать за отказоустойчивость.
В конце-концов эффективность программиста в коммерческой организации определяется тем, сколько его код приносит или экономит денег компании или "енэйблид" возможность другим это делать.
Причём включено даже когда ты один арендуешь и на 100% уверен, что ещё 100 тебе понадобятся разве что через сотню лет, по одному в год. И то, если повезёт с бизнес-идеей
Тоже могу сказать "глупости": за несколько лет SQL SaaS могут сжечь на порядок больше чем тройка дедиков и пара толковых админов
А у функций и понятия разные в случае одного аргумента и в случае двух.
Ещё может быть, что не код и API должны быть эффективными, а программист
Вот вы сами говорите, что эквивалентные понятия — разные, одни удобны в одной ситуации, другие в другой
Да, облака про богатый энтерпрайз, госов или стартапы, тратящие деньги богатых инвесторов :)