Комментарии 49
Бо́льшая часть примеров привязана к определённым вендорам, но это не помешает рассмотреть причины перехода на бессерверную архитектуру.
Т.е. если бизнес не устраивает "определённый вендор", ему придётся помимо непосредственных затрат на переезд потратиться на переписывание всего куска кодовой базы вокруг БД (поскольку совместимость API запросов к БД у нового вендора может быть, а может и не быть).
Вопрос переездов, конечно острый, и не везде возможен. В самом плохом случае прийдется слой работы с данными переписать, в лучшем это произойдет бесшовно.
Смотри есть пара примеров. Первый, Amazon Aurora Serverless по сути это MySQL и PostgreSQL и переезд из одного облака в другое неприятное дело но не страшное. Второй, Amazon DynamoDB и Yandex Database в Serverless варианте, тут за счет поддержки промежуточного слоя практически бесшовный переезд.
Термин serverless — бессерверные, уже прижился и мы будем с этим жить. По факту это «managed database service» с моделью оплаты «pay as you go» развернутый на стороне облачного провайдера.
В том-то и дело, что у тебя в распоряжении сервера нет. Ты не управляешь им, не обновляешь, не следишь за его секьюрностью и т.д. И в этом смысле, сервера у тебя нет. И в этом смысле, это очень осмысленный термин.
Рекомендую почитать про IaaS, PaaS и SaaS.
Суть термина serverless - не про отсутствие сервера как такового, а про то, что его можно выкинуть из головы и перестать думать о количестве памяти, ядер и т.п., потому что всё это подбирается под текущую нагрузку и управляется автоматически - не клиентом.
Когда переезжаешь из онпрема в ИааС, тебя всё ещё заботят такие вещи как подбор оборудования, просто становится гораздо легче "выкинуть и заменить" при росте нагрузки, потому что "железо" стало виртуальным. А на уровне ПааС ты уже не думаешь даже об этом, тебя волнует только схема БД и данные в ней, но не "железо". Сервера больше "нет".
Еще подумалось, что с таким же успехом можно прицепиться к термину "облако". Знаем мы, как же - пар тут ни при чём! На самом-то деле это автоматически масштабируемая виртуальная инфраструктура, управляемая провайдером. Но всем приятно называть это сказочным облаком, где за туманом скрыты вещи, которые больше не должны волновать клиентов. Ровно так же и с серверлесс - сервер накрыло тем же сказочным туманом.
на удивление даже с точки зрения конечного пользователя сервер есть - настройки доступа регулируются пользователем именно на его уровне (в Azure - как минимум; в AWS это вынесено типа на уровень БД - хотя, понятное дело, что регулируется все же серверная часть).
Вангую лет через 10-15 начнется абсолютно новый тренд в IT: "Купите свой собственный сервер! Не надейтесь на облака! Свое железо - самое надежное и прогнозируемое! Контроллируйте свои данные сами! Прогнозируйте свои затраты (а не получайте сюрпризы от облачных тарифов)" )))
Сама по себе AWS RDS Mysql/Postgres serverless отличная база, с автоматическим вертикальным масштабированием, но предоставляемый по умолчанию интерфейс взаимодействия RDS Data API - это не просто недостаточно некачественный сервис, а абсолютно мусорного уровня, включая перепутывание запросов с ответами, бесчисленные недокументированные сервисные ошибки, наполовину работающие транзакции и так далее, и абсолютно наплевательное отношение техподдержки (Если интересно ознакомиться, в этом посте AWS Postgresql Serverless - tricks and caveats : serverless (reddit.com) мной рассказывается вся история с начала до текущих дней :)
Набредал на тред, давненько это было. Скажи, что-то поменялось за прошедший год? На сколько помню там было все утыкано значками «beta».
Ситуация вышла интересная: в течение года часть проблем с RDS Data API была решена со стороны aws, часть проблем заткнута набором workaround-ов и эвристик с нашей стороны, и в принципе, все работало довольно стабильно
Но 27 мая этого года, без объявления войны, aws намертво все разломал - внес без предупреждения breaking changes в API (которые до сих пор не задокументированы), а запросы с ответами снова стали перепутываться случайным образом - весь stage, использовавший Rds Data API, развалился фактически без возможности починки
Поэтому было предпринято срочное решение по переезду в VPC - сейчас пользоваться Aurora Postgres Serverless можно с подключением к СУБД напрямую, минуя сломанное Rds Data API, но из приватной VPC-сети - что в конечно итоге было сделано, и с тех пор проблем больше лет - все летает и вертикально масштабируется
Мимо меня прошло, а можно где-то почитать подробнее?
Что именно почитать? Если про инцидент с перепутыванием запросов, то я больше не публиковал на reddit, поскольку это довольно бессмысленная операция - только немного попинал их в твиттере (1, 2, 3), но фактически тоже безрезультатно - если год назад, когда Data API было в бета-версии и они предпринимали какие-то шаги (к примеру, можно было пообщаться с PM-ом этого сервиса), то сейчас стало понятно, что единственный вариант - это съехать с Rds Data API на VPC
Если про БЧ в API, то здесь BeginTransaction - Amazon RDS Data Service разломали протокол - теперь поле transactionId не ограничено 192 байтами, а могут прислать и 240, при этом БЧ внесли на горячую в работающем кластере, и нигде не заявили об этом, да и документация как видно до сих пор не правленная
Если про доступ через VPC, то толком это нигде не описано, но схема рабочая - краешком это упоминается здесь Using Amazon Aurora Serverless v1 - Amazon Aurora и здесь Best practices for working with Amazon Aurora Serverless | AWS Database Blog
И конечно важная ремарка касательно всего вышесказанного - все описанные проблемы возникают стабильно при нагрузке >500 одновременных соединений, а при нагрузке >100 соединений могут проявиться с некоторой вероятностью (за 24 часа вероятность хотя бы одного инцидента стремится к 100%)
Но рассматривать и использовать условно-бесконечно-масштабируемый сервис без нагрузки, конечно, смысла никакого нет - хотя на малой нагрузке все работает терпимо
К вопросу о бета-версии ситуация еще интереснее - они вроде как вышли из беты, но работать так ничего толком не стало. В итоге они сейчас в процессе выпуска Aurora Serverless 2.0 - учитывая предыдущий опыт ошибок, они выкинули в нем RDS Data API, обещают прямое подключение к СУБД и хорошие нагрузки, правда доступен только MySQL 5.7
Плюс хитрецы-маркетологи переобулись на лету и откровенно пишут Amazon Aurora Serverless | MySQL PostgreSQL Relational Database | Amazon Web Services , что Aurora Serverless 1.0, то есть текущая версия, вообще предназначен для малых нагрузок или тестирования, а если хотите настоящую нагрузку, то переходите на 2.0 и ждите, когда она выйдет из бета-тестирования
Прочитал пост на Reddit, выглядит как fake news. По пунктам
Mixed results выглядит как попытка использовать коннект к БД в разных потоках. Характерно, что вылезает на нагрузке.
Timeout error это проблема любой БД, а не только serverless. Если случилась ошибка сети, то вы знаете, что стало с транзакцией.
Too many connections и прочие ошибки вам нужно обрабатывать в любом случае, если у вас high-load.
Предьявить AWS можно за документацию. Остальное выглядит как столкновение с реальностью распределённых и нагруженных систем.
К сожалению, все на реальных событиях - давайте внимательно рассмотрим исходную архитектуру RDS Serverless Aurora+ Rds Data API по пунктам из статьи на reddit:
1) База данных Postgres serverless лежит спрятанная в приватной VPC-сети, Амазон сам управляет вертикальным масштабирование сервера СУБД, сам перезапускает его и т.д. - физического доступа к серверу у вас нет, возможности покдлючения по TCP тоже нет
2) Амазоновский сервис с незамысловатым названием Rds Data Api - это именно сервис, а не библиотечка, и представляет он собой HTTPS-сервер, в который можно отправлять stateless HTTP-запросы с SQL-запросами и получать в ответ строчки из СУБД. Этот сервис имеет публичный хост+порт + авторизацию по aws secret manager, и это единственный способ общаться с serverless-базой
3) Набор однопоточных лямбд на nodejs, каждая из которых общается с сервисом Rds Data Api, и условно говоря, случайным образом делает "SELECT 0" или "SELECT 1" из СУБД. Если этих лямбд достаточно много, то ответы начинают перепутываться - условно тем, кто запросил "SELECT 0" приходит ответ "1" и наоборот
Конечно же, Вы правы в том смысле, что это проблема highload и многопоточности, только вот нюанс в том, что у лямбд вообще нет соединений с базой данных, и все однопоточные и stateless, а запросы перепутываются **внутри** амазоновского сервиса Rds Data Api, поскольку его разработчики, в отличие от нас с Вами, видимо никогда с настоящим highload-ом в жизни не встречались :)
То же самое и по остальным пунктам. Конечно же, при нагрузке СУБД и сеть могут отбиваться с разнообразными ошибками, и необходимо правильно их retry-ить по смыслу и с правильным дрожанием времени (jitter) между попытками. Однако здесь между вами и СУБД есть многострадальный сервис Rds Data Api, который сам внутри падает с неопределенными ошибками, список которых нигде не задокументирован.
Список ошибок удалось составить только эвристически за несколько недель синтетической нагрузки на сервис. При этом эксперементальным путем было выяснено, что Rds Data Api написан на Java, поскольку часть сыпавшихся ошибок - это необработанные исключение с соответствующим стектрейсом из JDK :)
Как минимум амазоновцы должны были не допускать необрабобанных исключений, и обернуть их в какой-то набор осмысленных error-ов - что в итоге и было сделано, только не амазоновцами, а мной - составлен огромный список приходящих исключений и их обертка в осмысленные ошибки, на основании которых можно предпринять какую-то бизнес-логику
Только в чем тогда вообще задача AWS, если они не могут ни структуризировать ошибки, ни работать с многопоточностью, за что им платить денежку, причем немалую? :)
Единственный приятный момент во всей этой истории случился после обнаружения способа прямого подключения к СУБД в приватной VPC-сети и работы с Postgres-ом напрямую. Rds Data Api был успешно выключен и выкинут, а его разработчики (мысленно) отправлены учить матчасть highload сервисов
Простите, но утверждение "и это единственный способ общаться с serverless-базой" кажется неверно:
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.html#aurora-serverless.requirements
обычное подключение например по 3306 и все дела. Код понятия не имеет с чем он работает, RDS Serverless, RDS или c Maria в контейнере EKS кластера. Так работает несколько нагруженных MySQL Serverless в продакшен. Data API не используем, ну кроме как "побыстрому сделать запрос через вебморду AWS", которая работает через Data API.
Великолепный сервис, как по мне. И альтернатив не очень то и видно в RDBMS, а NoSQL не для всего подходит. Ждем v2 release...
Насчет RDBMS абсолютно плюсую, ACID-база имеет отличные гарантии и консистентность, и функционал на порядки шире новомодного Nosql
Насчет подключения к Rds serverless V1 - там же только два варианта - или VPC, или Rds data api, а еще в относительно недавнем прошлом класть лямбды в VPC имело множество неприятных последствий - лямбды имели медленный холодный старт из VPC, и после перехода в VPC переставали работать с некоторыми другими AWS-сервисами
Сейчас когда лямбды быстро стартуют из VPC и отлично привязываются к HTTPS через Lambda@edge proxy, собственно и было принято выкинуть Rds data api и работать с базой через нативный драйвер посредством TCP-соединения на порт 5432 (Ну или если был бы mysql, то 3306)
Плюс под нагрузкой возникает нюанс, что лямбды периодически аварийно падают, а tcp-соединения к базе висят до tcp timeout , что создает их переизбыток и невозможность подключиться из новых лямбд - но это конечно все дело техники и давно решено (Есть даже готовые npm-пакеты вроде postgres-serverless и mysql-serverless)
С транзакциями вообще отдельная история - из-за общения с СУБД через Stateless REST API, которым фактически является Rds Data Api, единственный способ организовывать транзакции - это передавать их в специальном HTTP-заголовочке, чтобы SQL-запрос был ассоциирован с транзакцией
При этом транзакции именуются специальным guid-ом (не имеющим ничего общего с xid/virtualxid в postgres), который видимо под капотом Rds Data Api использует, чтобы знать, в какую транзакцию направлять поступивший по HTTP SQL-запрос
Так вот, при определенной нагрузке Rds Data Api в лучших традициях начинает обманывать - при отправке "commit" он отвечает, что все ок, а на самом деле транзакция откачена. Из-за этого пришлось заводить специальные служебные таблицы по схемам, чтобы хранить в них глобальный журнал примененных guid-ов транзакций
Очередная реклама "облаков". Ну и навязывание новых смыслов старым терминам, заодно.
Бессерверным что-то бывает только тогда, когда сервера нет. А когда он есть, но называют его маркетинговым словечком "облако", то это опять всё тот же безумный маркетинг.
>> Такой подход позволяет более точно рассчитать экономику проекта в условиях невозможности спрогнозировать масштабы.
А вот это есть просто наглая ложь. Но, как всегда, слово "ложь" проплатившая рекламу контора возмущённо заменит на "маркетинг". Только замена слов на смысл не влияет. Прогнозировать что-то в ужасно глючных и практически неконтролируемых разработчиком решениях невозможно по определению. Ошибки и отсутствие возможности понять, где нам опять насчитали лишние десятки тысяч долларов - вот реальность "облаков". И как в таких условиях "точно рассчитать экономику проекта"?
>> Снимается боль бизнеса — оплата мощностей за время простоя.
А это откуда выросло? Во время простоя сервер БД потребляет, например, 100 ватт. За сутки - 2400 ватт. Один киловатт-час стоит 6 рублей. То есть в сутки имеем 14.4 рублей. В месяц не более 450 рублей. Да, это адская боль бизнеса!
>> Аргумент по части NoSQL такой, что бессерверные приложения по большей части в стартапах, когда нет истории, нет понимания будущей модели данных, прогнозов трафика.
А это очень правильное замечание - когда нет понимания (модели данных, прогнозов трафика и т.д.), тогда выбирают "сердцем", то есть покупаются на убогую рекламу "облаков".
>> Компания Pokémon Company первоначально выбрала NoSQL и столкнулась со сложностью поддержки бесперебойной работы узлов. Выбор SQL-решения позволил сократить узлы с 300 до 30 и свести к нулю время простоя и снижения производительности.
А это уже, видимо, что бы развеселить читателей. Компания покемонов решила "делать бизнес". Ничего не понимая, выбрали "облака". В результате получили 300 попгуаев нагрузки. Потом пришёл кто-то немного слышавший про нормальную разработку и в результате нагрузка уменьшена до 30 попугаев. Браво, в рекламе "облаков для дураков" такой пример очень выигрывает! Приходите, делаете адски тормозящий продукт на "облаке", а потом, возможно, вы даже найдёте способ сократить нагрузку на "облако" не менее чем в 10 раз. Но ради чего это всё? И это уже вопрос к недуракам. Ради больших затрат на разработку того, что будет в 10 раз медленнее, чем в случае выбора более проверенного временем решения? А есть ведь ещё одно проверенное временем решение - вообще отказаться от облаков, а не просто поменять NoSQL на SQL.
У вас пиковая нагрузка такова, что вам нужно 300 машин. Но 99% времени вам хватит 30. Так и получается экономия на serverless - за счёт автомасштабирования. Можно его сделать на основе API облака и пачки костылей, но работать будет хуже и поддержка будет дорогой.
Это единственный кейс где serverless рулит, если система под него заточена. Но на практике скачки нагрузки в десятки раз именно на базу редко где встретишь. А там где они есть можно пошаманить и данные хранить в Redis, а писать в БД пачками.
>> Это единственный кейс где serverless рулит, если система под него заточена.
Если вы готовы потратить большой бюджет на адаптацию ко всем косякам "облаков", тогда, возможно, вы как-то сумеете реализовать предложенный вариант масштабирования.
Но есть ещё традиционный подход. С ним не нужно тратить большие деньги на адаптацию. Хотя да, масштабироваться без заметных для пользователя тормозов сразу в сто раз будет непросто. Если бюджет ограничен и железом проблему не закидать, то в традиционном решении пользователь будет ждать, например, 10 секунд вместо одной. Опасно ли это для бизнеса? Скорее всего нет, поскольку это пиковая нагрузка, она затрагивает малую часть пользователей, остальные её не заметят, или заметят один раз из нескольких десятков посещений сервиса.
Но тут важнее другое - если у вас денег на железо нет, то значит и на облака у вас денег гарантированно нет. И характер этих денег отличается. Железо - одноразовые капитальные вложения, которые можно частично вернуть посредством продажи. Вложения же в адаптацию к убогости облачных решений являются постоянными. Облачные вендоры постоянно что-то меняют, а нормальных инструментов для анализа не предоставляют, поэтому выход один - постоянно держать дорогую команду ради этой самой адаптации. Такой вариант, очевидно, ни разу не подходит для экономии.
Но если с точки зрения экономии нет выгоды, то где же тогда она есть?
В целом вопрос сводится к оценке вложений в железо против оценки вложений в постоянную адаптацию. На мой взгляд выбор здесь очевиден. Хотя на взгляд бюрократа из толстой конторы, выделяющего деньги на вечно неэффективные проекты, особой разницы нет, оплачивать ли ими адаптацию как к косякам облачных сервисов, так и к косякам управления в большой конторе, или оплачивать ими одни только косяки управления в большой конторе, потому что последние стоят на порядок больше, чем косяки облачных решений.
То есть облака - для богатых и ленивых. Для тех, кто деньги всё же считает, облака в принципе не подходят. Никак. Никогда. Ни при каких условиях (кроме перехода на модель "богатый и ленивый").
Со многим согласен. Но не понятно как на своём выделенном железе отмасштабироваться в 10 раз, пусть даже на это уйдёт 10 и более минут.
Железо берут с запасом. Разве вы про это не знали?
Расчитывать строго на среднесуточную нагрузку и выбирать железо ровно по этой планке - очевидный признак идиота. Поэтому выбирают что-то более производительное, например раз в 10. Экономически это очень дёшево, поскольку железо окупится примерно за месяц на одной только рекламе, была бы нагрузка (посетители).
Второй момент - архитектура и реализация должны обеспечивать близкую к линейной деградацию времени отклика при перегрузке.
Если два обозначенных критерия выполнены, то при выбросах до 10 раз деградации не произойдёт. А при выбросах более 10 раз начнёт копиться долг, под который требуется память. Памяти на один запрос обычно требуется немного, поэтому узким местом при нагрузке *10max память станет лишь при большой длительности пика. Но "длительный пик" даст существенный прирост средней нагрузки, а потому такие варианты мы не рассматриваем, поскольку они предполагают нашу ошибку в расчёте средней нагрузки (что маловероятно в давно работающей среде, ну либо результат экспериментов всё тех же идиотов).
Понятно, что по среднему никто не берет. Поэтому если для средней нагрузки нужно 30 машин, то вы возьмете 300, чтобы выдержать прыжок в 10 раз. Мы тут считаем, что архитектура хороша и 300 машин действительно нужны.
В облаке вы 350 дней в году используете 30 машин, а 15 дней в году 300. В своем дата центре вы 365 дней в году используете 300 машин на 1% в среднем. Вот в такой ситуации и возникает экономия, а serverless упрощает масштабирование, но имеет свои нюансы.
Есть другие нюансы. В большой организации вы можете ждать сервер по полгода и больше, пока отдел закупок тендер сделает, пока привезут. Если та же организация использует облако, то вы просто заказываете сервер. С другой стороны компания где я сейчас работаю платит AWS миллионы $ в год за железо, которое никому не нужно. С третьей стороны, найти и отдать это железо AWS задача на несколько дней, что регулярно происходит. А отдать лишнее железо производителю не получится. И это лишнее железо, скорее всего, будет привязано к конкретному отделу/команде, а сделать так, чтобы лишнее железо можно было найти и переместить из отдела в отдел это та еще организационная задача.
Также IAM - то есть возможно управлять доступом. В облаке это встроено и работает на любом масштабе, будь то 10 или 10 000 разработчиков. С своим железом и в большой компании вы будете иметь отдел админов, которые будут пилить правила контроля доступа. Обыденные штуки, вроде перешел человек из команды в команду и ему нужны доступы, могут стать целой задачей, с тикетами, менеджерами, админами-исполнителями.
Свое железо - хорошо, облако - тоже хорошо. Просто есть нюансы где одно и другое работает лучше или хуже. Я сначала мигрировал свой небольшой бизнес из AWS на bare metal в OVH и сэкономил несколько тысяч USD в месяц. А сейчас думаю над обратной миграцией, потому что подрос и хочется IAM, ECS, Secrets Manager, Systems Manager и RDS. Делать все это руками на своем железе очень долго и дорого.
>> В облаке вы 350 дней в году используете 30 машин, а 15 дней в году 300. В своем дата центре вы 365 дней в году используете 300 машин на 1% в среднем.
Посчитайте снова. Ваш расчёт должен дать коэффициент использования 10%, а не 1%. И такая ошибка сильно повлияет на выбор технологии.
>> В большой организации вы можете ждать сервер по полгода и больше
Это тоже искажающее картину соображение. Если бизнесу что-то реально надо - они найдут сервера за один день (ну поусть неделю). А если не надо, то вы по сути выдаёте стремление к каким-то личным достижениям за истину. Ваши личные достижения на самом деле интересны только вам лично. И хорошо, если контора готова иплачивать ваши игры даже через пол-года после их начала. Но к выбору технологии удовлетворение ваших потребностей не относится, потому что это совсем другая область оптимизации с кардинально отличающимися целями.
>> А отдать лишнее железо производителю не получится
И это не проблема. Вспомним, как сбербанк нашёл мощности для тренировки сети GPT-3. Или вы думаете они все 100% этого железа купили под одну единственную задачу? Нет, они нашли способ утилизировать коэффициент простоя оборудования. То есть если бизнесу надо - всегда найдётся способ загрузить или ещё как-то окупить мощности.
>> Также IAM - то есть возможно управлять доступом
А что не так с доступом? Я не спец по деталям настройки толстых серверов, но я отлично знаю, как выделяют виртуальные сервера и как нарезают для них ограничения по ресурсам. Так же и вы - выделяйте виртуалку и нарезайте ресурсы кому нужно. А если проблема в бюрократии, то значит вы опять подменяете реальные проблемы бизнеса своим представлением о них. Бюрократия всегда там, где бизнесу что-то не надо. Хотя вам может показаться, что ваше решение принесёт миллионы и т.д., но это всего лишь мираж. Для этого вы должны стать руководителем, тогда ваши идеи прорастут, даже если они ошибочные. А пока бизнесом рулят другие - прорастают их идеи, даже если они ошибочные. И вам не стоит убиваться по их проблемам, особенно если это следствие принятия ими ошибочных решений.
>> А сейчас думаю над обратной миграцией, потому что подрос и хочется IAM, ECS, Secrets Manager, Systems Manager и RDS. Делать все это руками на своем железе очень долго и дорого.
Я вам не подскажу конкретные инструменты такого плана, но я очень сильно сомневаюсь в том, что их нет для обычных серверов, но есть исключительно для облаков. Обычные сервера развивались многие десятки лет, а облака всего где-то десяток. Скорее всего вы просто не в курсе существующих решений, ну а реклама вам подсказывает - в облаках всё есть! Или вы познакомились с облачным решением и увидели там какие-то инструменты, которые никогда не использовали с обычными серверами, потому что обчные сервера админят обычные админы, а не вы. А теперь, не зная про инструменты для обычных серверов и обладая только лишь представлением об облаках, вы делаете неверный вывод.
В целом я соглашусь, что если сами хозяева облачных решений сильно захотят, то они для каких-то нишевых решений обеспечат реальные преимущества. Но пока хозяева не хотят. Их бизнесу это не надо. Они приняли вот такое решение. И судя по тому, что постоянно находятся желающие им заплатить, возможно это решение вполне правильное для сложившейся ситуации. А вы же пытаетесь доказать, что на самом-то деле хозяева не бизнес ведут, а благотворительностью занимаются, раздавая всем лучшие в мире технологии. Раздают, да ещё и бесплатно, только некачественные решения. Бесплатно заманивают и обещают обещать. Обычный бизнес, ничего личного.
>Посчитайте снова. Ваш расчёт должен дать коэффициент использования 10%, а не 1%. И такая ошибка сильно повлияет на выбор технологии.
В моем расчете нет никакого коэффициента использования. Есть пиковая нагрузка, для которой нужно 300 машин, которая бывает 15 дней в году. Что изменится если она бывает 100 дней в году? Только то, что облако станет менее эффективным с точки зрения денег. А если 300 машин надо 365 дней в году и никаких всплесков нет, то облако вообще пролетает. Предсказывать всплески на этапе выбора архитектуры так себе занятие.
>Это тоже искажающее картину соображение. Если бизнесу что-то реально надо - они найдут сервера за один день (ну поусть неделю).
Бизнес это не человек, ему ничего не надо и он ничего не чувствует. Как по вашему "ему надо" должно работать? Железного сервера нужной комплектации от нужного производителя может не быть в России или в вашем городе. Можно закупать что есть и получить зоопарк железа, каждое с своими особенностями. А еще договор на поставку нужно с юристом обсудить, а затем в фин. дирктором. А он в отпуске. А затем менеджер со стороны поставщика ушел в отпуск или заболел. А затем поставщик не ту конфигурацию прислал или не те реквизиты выслал. И пошло поехало.
Пусть менеджер проекта сам закупает технику без лишнего контроля и процедур? И вот у нас откаты менеджеру от поставщиков и полный бардак с тем, кто кому сколько должен, какой товар уже пришел, какой к возврату, а какой получили, где все это находится и в каком состоянии.
И пример закупок из практики - купить и вернуть полотенцесушитель за 20 тыр. - 50 писем поставщику и обратно, пара рабочих дней времени. И это ИП покупает для себя, без процессов и контроля. Боюсь реальность закупок чего-то сложнее еды в магазине или книги на озоне вас может очень разочаровать.
>> А отдать лишнее железо производителю не получится
>И это не проблема.
Предлагаете все тренировать GPT-3 на свободных мощностях? Вот только как инициатор этого проекта вообще узнает о том, что есть свободные мощности? Сколько людей и ИТ систем должно слажено работать вместе, чтобы появилась таблица с свободными серверами, чтобы к ним был доступ у кого надо, чтобы на них можно было запускать GPT-3 и так далее. Все можно, но это не просто так дается.
>Так же и вы - выделяйте виртуалку и нарезайте ресурсы кому нужно.
Это очень упрощенное представление о правах доступа и сценариях с ними. Дело не в виртуалках совсем.
>Я вам не подскажу конкретные инструменты такого плана, но я очень сильно сомневаюсь в том, что их нет для обычных серверов, но есть исключительно для облаков.
Есть конечно. Для каждой задачи есть какой-то отдельный тул, который ее решает. Связывать и настраивать все это для совместной работы - фул тайм работа для нескольких, далеко не дешевых, человек.
Например, взяли вместо AWS Systems Manager альтернативу, которая на самом деле даже круче - RunDeck. А еще у нас есть Active Directory где юзеры живут. И в RunDeck тоже есть юзеры, с какими-то правами на запуск тех или иных скриптов. И вот кто-то сидит и пилит интеграцию Active Directory <-> RunDeck чтобы из AD можно было рулить тем, кто что может и не может делать.
Или хотим логи - подняли ELK, интегрировали его с AD. Но как теперь разделить права юзеров, кто может видеть логи проекта А, а кто нет? И опять кто-то сидит и пилит интеграцию. Можно забить и в каждый проект свой приватный ELK развернуть. Теперь у вас N источников проблем с обновлением софта и починкой сломавшихся индексов.
Бекапы БД, ну да, есть open source тулы, но их надо настроить, а они еще могут ломаться. А затем нужно права доступа для бекапов настроить. И вот опять AD и интеграция. И так далее до бесконечности.
>> В моем расчете нет никакого коэффициента использования.
Есть, и он занижен в 10 раз. Это к вопросу о вашей объективности, если что.
>> Бизнес это не человек, ему ничего не надо и он ничего не чувствует.
Ну ладно, если вам так понятнее, то пусть будут хозяева бизнеса. Но связь здесь неразрывная, жаль, что вы её не видите.
>> И пример закупок из практики - купить и вернуть полотенцесушитель за 20 тыр. - 50 писем поставщику и обратно
Смысл здесь такой - вы находитесь на самом дне бюрократического болота, которое из себя представляет ваша контора. Вы видите вокруг много развесистых деревьев (трудностей), но не видите леса (причины проблем). Ваш взгляд из глубины искажён непониманием общей картины. А картина всё та же - бизнесу это не надо. Далее вам нужно объяснять длинную цепочку причинно-следственных отношений, которые приводят к вашему положению, но это долго, поэтому кратко скажу - это называется кусочная автоматизация (погуглите на досуге). Следствием такого подхода является неизбежный бардак и соответсвующее ему болото, в которое вы и погрузились, и похоже других (нормальных) условий обитания не представляете (иначе не указывали бы на следствия бардака как на причину "выгодности" облаков). На самом деле в вашем положении находятся, скорее всего, большинство работников IT-сектора, то есть в большинстве контор царствует бардак той или иной степени тухлости. И когда везде бардак - давление среды становится недостаточным, что бы бизнес захотел что-то исправить. Ну и далее попробуйте довести короткую цепочку выводов до "бизнесу это не надо".
>> Для каждой задачи есть какой-то отдельный тул, который ее решает. Связывать и настраивать все это для совместной работы - фул тайм работа для нескольких, далеко не дешевых, человек.
Здесь опять не то. Опять взгляд из подземелья. Вы видели некую интеграцию в каком-то из вариантов "облака", но не видели аналога в своей конторе, поэтому вам кажется, что нигде в мире нет ничего лучше "облака". Но ситуация почти противоположная. Облака писали постоянно подглядывая решения у взрослых, то есть в норамльно работающих цепочках обработки данных. И эти цепочки не могли быть ни в каком другом месте, кроме обычных серверов. То есть всё давно и основательно придумано и реализовано, но конкретно вы просто не встречались на своём жизненном пути с нормально построенными системами. Здесь "нормально" следует понимать как "не хуже, чем в облаках". И к тому же у вас задачи довольно мелкого уровня (все эти RunDeck-и и ELK-и). Проблемы логирования должны решаться на этапе проектирования, но разумеется, в вашей конторе никто и никогда не занимался серьёзным проектированием, а потому никто эти небольшие проблемы не решил, всё свесили на вас, видимо разработчика одной из подсистем. И вы с энтузиазмом принялись строить свой велосипед, но поняли, что на его строительство нужно много времени, ну и от безысходности начали выть на луну (на облака), мол вот там всё есть, а здесь меня мучают логами. Но нет никаких причин для неповторения ситуации один в один в случае, если вы перейдёте в облака. Бардак достанет вас и там. Так что не надо возлагать необоснованные надежды на сырую и от того убогую технологию, и тем более, выдвигать ваш бардак в качестве аргумента "за облака", потому что это лишь аргумент в доказательство отсутсвия у вас опыта работы в условиях с существенно меньшим бардаком.
в контексте redis речь про "appendfsync always", или о "In the case of a complete system failure on default settings, only a few seconds of data would be lost."?
если о первом варианте, то будут ли преимущества при обработке скачков относительно dbms с wal-ом?
Если append fsync always то разница будет только на чтении, запись может быть даже медленне чем в БД. У Redis есть ещё кластер, можно смириться с возможной потерей данных, можно организоваться свой WAL на уровне app server. Вариантов много, зависит от профиля нагрузки. Основная идея в том, чтобы использовать очень быстрый, специализированный storage, который позволит пики проходить, не упираясь в БД.
Какому бизнесу хорошо от того, что в один день счёт за облако 3 цента, а в другой $30 000 мне не понятно. Хотя AWS такая ситуация точно нравится.
Тому, который понимает и оценивает стоимость бизнес транзакции. Вот допустим ты на транзакции клиента зарабатываешь X, а с serverless решениями ты можешь посчитать сколько это будет тебе стоить — обсчитать стоимость бизнес-процесса по обработке именно этой транзакции равна Y. Вот у тебя трафик ты заработал X - Y на каждой транзакции, если разница положительная то профит очевиден. Гоним трафик, зарабатываем. Трафика нет, не зарабатываем, но и не тратим.
Поделюсь опытом использования Managed PostgreSQL в Azure. Всё хорошо, но производительность в 100 (прописью: сто) раз хуже того же Постгреса, поднятого в докер-контейнере на моём ноутбуке. Одна и та же база (восстановленная из бэкапа), один и тот же запрос, идентичный результат, но у меня 1 секунда, а в облаке полторы мать её минуты. В последний раз я видел такую потрясающую производительность в начале 90-х на DBF файлах в 486-м компьютере.
Короче, дурят доверчивых граждан поставщики облачных сервисов.
Тут бы конечно позвать ребят из Azure и совместно попрофилировать/подебажить, может быть это какая-то локальная проблема?
Ну да, позвать. Когда мы нашли баг в ажуровском датафактори, через 2 месяца удалось-таки пообщаться с индусом, который баг признал и сказал типа не делайте так, а мы когда-нибудь исправим.
Не надо никого звать. После того, как наши [censored] девопсы полтора месяца кормили меня завтраками и футболили тикет друг другу, я психанул и со словами "горбатого могила исправит" поднял Постгрес на запасной виртуалке в Digital Ocean.
Я предполагаю, что все эти прекрасные Managed заманухи хранят свои данные в облачных же хранилищах, которые по-любому медленнее, чем железная SSDшка, подключённая через железный PCI-Express. Вот и получается, что ты, дорогой клиент, можешь наслаждаться бесконечным объёмом хранимых данных, но всё будет работать нормально и не вставать колом ровно до момента, как база перестанет целиком помещаться в кэш. Для демок и прототипов такое прокатывает, а для настоящего использования... да кому оно нахрен интересно это настоящее использование?
А планы исполнения одинаковые?
Стоит упомянуть еще и про вендорлок. Как только сядете на одного "бессерверного" провайдера, слезть с него будет крайне проблематично.
Посоны пытаются деньги из воздуха делать, а вы тут сразу срач развели))
Было бы интересно попробовать интеграцию нашей платформы с serverless решением
Бессерверные БД: зачем переводить Stateful-сервис в Serverless