metajiji, в принципе в большинстве пунктов поддерживаю, просто у нас, явно, были абсолютно разные пограничные кейсы. В моих были случаи когда люди считали лишние байты в пакетах даже, а число контейнеров по серверам иногда было довольно диким, поэтому, как говорится, все познается в сравнении
metajiji, ну, просто по тому что на самом деле это работает не так) NAT присутствует везде в сетевой адресации, просто в разном виде. Контейнер это тоже на уровне сети изолированная коробочка, какие бы настройки мы там не прикручивали)
metajiji, я это не взял, а получил на опыте в больших проектах. С ресурсами да, там не то чтобы много ест, просто немного поджирает, а что до сети то, все-же, надо знать не то как конфигурируется докер, а как работают сети и как работает сама контейнеризация и виртуалитзация в принципе + давайте не забывать про NAT. Увы, для подобных параметров rps/rpm это уже становится видимым
metajiji, докер во-первых это хоть какая-то, но дополнительная нагрузка на изоляцию ресурсов, но что важнее - добавляет задержки на сетевую адресацию, что очень негативно сказывается на latency. Увы, это правда. Докер хорош для изоляции, но не для сети, и, даже, не для безопасности
Хочу только добавить что нет большой разницы в "для разработчиков" и "не для разработчиков". Набор знаний +- одинаков для всех ролей, просто углубляться при практике приходится в разные части документации
Emily_Ravenhold, в большинстве случаев да, но надо не забывать ещё про паттерны обращения к данным - сегодня бд проектируется исходя из этого. И важно понимать что сегодня самый серьёзный перформанс можно получить только в облаках - они предоставляют уникальные решения, которые нереально дорого повторять
Emily_Ravenhold, в том что мемкэш не поддерживает шифрование по причине того что он in-Memory. Почти для любой сертификации, требующей шифрование тенантов это сразу неприемлемо
Хорошая идея, кстати, жаль только при масштабировании. Больно будет) ну и для всяких проектов где жесткие требования к безопасности не прокатит, но это я уже загоняюсь)
Emily_Ravenhold, в таком ключе самое простое - докинуть read replicas, выделить правильное число ресурсов под базу данных, не индексировать изменяемые поля.
Правильный способ - выбрать key-value или не реляционную базу данных с горизонтальным масштабированием и acid через кворум.
Если первые два варианта не сработали то вы - Netflix и вам пора писать свои базы данных и языки программирования
Emily_Ravenhold, говорить об эффективности не корректно без требований к системе (как функциональных так и не функциональных). Каждое решение строится на основании кучи факторов. "Не было больших задержек" это очень абстрактно без конечных цифр и в первую очередь относит нас к распределенным системам и не реляционным базам данных. Так же очень важно понимать где мы строим решение - в облаке или свой ДЦ.
Для примера: я прямо сейчас могу пойти и за вечер сделать решение для лайков на serverless и оно будет держать условно бесконечное число нагрузки с временем обновления до 200мс. Стоить будет как космос, но сделаю за вечер)
Иван Шумов
@inoise Куратор тега Amazon Web Services
Ivan Yakushenko, чисто теоретически - да. С другой стороны это просто привычка. Я вот из тех людей кто за 12+ лет работы в разработке так и не получил слово деплой. Я дико ненавижу конфигурировать веб-сервер, окружение, забыть какой-нибудь модуль, ... Serverless для меня снял подобные вопросы. Конечно, я лишился некоторых привычных инструментов, как и основного своего языка программирования, но со временем стало пофиг)
Иван Шумов
@inoise Куратор тега Amazon Web Services
Ivan Yakushenko, при равных прочих serverless выйдет дешевле по тому что масштабирование надо делать ручками, делать это хорошо и сверху к этому придется прикручивать довольно много сервисов чтобы получить результат. Так что я почти всегда за этот подход) ну и не забываем что если висе правильно делать то база данных тоже будет отдельным слоем, тоже будем за нее платить и толе поддерживать
Иван Шумов
@inoise Куратор тега Amazon Web Services
Ivan Yakushenko, ну Ваня, ну начинается) serverless подход нужен когда:
- нет желания платить за простой ресурсов
- хочется иметь горизонтальное масштабирование
- писать минимум кода
- иметь маленькую команду без 100500 тысяч работы девяпсам по администрированию
- latency не является критичным
По базам данных - тут человеку в чистом виде нежно сделать REST API: API GW + Lambda, за которой с высокой вероятностью будет сидеть DynamoDB (ибо опция на этот счет в AWS не очень много)
