Что вам непонятно в клаудах? (AWS, GCP, Azure)  Публичный пост ✋️ АМА

Привет, клуб!

Я в бытность излишне активным участником всяких русско-язычных AWS-тусовочек настолько задолбался отвечать на вопросы про управление доступом, что бахнул бесплатный дип дайв по IAM.

Потом выяснилось, что люди ну никак не могут в NoSQL кей-валуе и бахнул такой же дип дайв, но про динамудб.

И вроде поток стремных вопросов отпал, но НЕТ - на этот раз люди про лямбды и серверлессы не понимают. Пришлось и для них бахнуть материал 101-ого уровня причем аж по-русски (Господь свидетель, писать русскоязычный контент все сложнее).

И вот вроде тишина кругом, но нет-нет да иногда проскакивают вещи, которые мне - облакоебу со стажем - кажутся элементарными.

Так что я тут думаю зайти к Уважаемой Администрации с челобитной на проведение АМА по клавдам, но прежде чем выйти на рыночек с предложением, стоит понять есть ли спрос.

Итак - что лично вам в 2к21 до сих в пор непонятно в публичных облачных технологиях (т.е. AWS/GCP/и-прости-меня-шива-Azure)?

Возможно я излишне драматизирую и ищу промблему там, где ее и нет.

Связанные посты
44 комментария 👇
Egor Suvorov, Программист/преподаватель C++ 18 июня в 11:59

Работают ли жёсткие лимиты хоть где-то? Как не попасть на $100500 из-за включенного автоскейлинга или случайно продолбанного лимита на размер загружаемого файла?

  Развернуть 1 комментарий

@yeputons, мониторинг настроить... :)
Илии пользоваться системами типа CloudHelath.

  Развернуть 1 комментарий

@DenZalman, Мониторинг реактивен.

Конечно же лучше прочитать письмо на следующее утро после чего-то эдакого и пойти руками все выключить чем узнать что что-то пошло не так когда в конце месяца придет счет.

Но хотелось бы иметь возможноть установить лимит на траты и не волноваться (а то мониторинг то именно в этот раз может и не сработать).

  Развернуть 1 комментарий

@Mykola, ты имел в виду, на следующую минуту после чего-то эдакого

  Развернуть 1 комментарий

@Mykola, лимит на траты я себе слабо представляю... что-то пошло не так и у тебя отключился продакшен среди ночи? пох на бизнес - экономим бабки! :)
плюс в амазоне многие сервисы расчитываются не в ту же секунду как были потреблены, а с заметным лагом, иногда в несколько дней. так что песекундный мониторинг трат еще и с принудительной остановкой сервисов - это разве что будет полезно для тех кто петпроджекты гоняет.

  Развернуть 1 комментарий

@DenZalman, ровно так. Гипотетически, если за ночь потрачено уже $500 вместо привычных $2, а заказы обычно маленькие, то лучше уж сайт положить, чем потратить ещё $500 на сайт и получить заказов на $200.

  Развернуть 1 комментарий

@DenZalman, посекундный необязательно, но чтобы были какие-то денежные гарантии. Например, забыл поставить лимит на загружаемый файл на S3 (тут и дальше не уверен в терминологии). Кто-то злой решил загрузить мне терабайт. Загрузил, а мне платить за трафик и хранение, пока не обнаружу. А хочется какой-то глобальный лимит на любые траты, чтобы даже если я забыл про конкретные лимиты в конкретном сервисе или какие-то сценарии атаки - ничего страшного.

  Развернуть 1 комментарий

Как в них вкатится? С чего лучше начать (продукт, провайдер)? Стоить ли сразу браться за IaC решение или начать сперва ручками?

  Развернуть 1 комментарий

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

  Развернуть 1 комментарий

@DenZalman, резонно! Тогда перефразирую. Когда стоит браться за IaC?

  Развернуть 1 комментарий

@roandudel, Когда задолбаешься с команднострочной утилитой и захочется того же самого, но не руками.

  Развернуть 1 комментарий

Стоит ли пользоваться AWS обычным смертным (не компаниям) в принципе?, или лучше всякие Digital ocean с фиксированной стоимостью?

Собственно, я сказал AWS гудбай, когда получил первый счет в 200$... а я всего лишь хотел потестить EKS...просто прикоснуться к прекрасному =)

  Развернуть 1 комментарий

@obabichev, стоит. Для фиксированной стоимости нужно использовать зарезервированные инстансы EC2, все остальные сервисы трогать с большой осторожностью. Желательно также настроить billing alarms, которые будут предупреждать о превышении бюджета.

Плюс AWS в том, что сервисы все-таки есть и что-то критичное можно закинуть на них, при небольшом использовании траты тоже выйдут минимальные. Например, нужно чтобы какой-то файл был железно доступен даже если весь сервис лежит - положить его в S3 (который, правда, изредка тоже лежит).

Еще под AWS заточено много удобных инструментов и библиотек, просто из-за того что он самый популярный.

  Развернуть 1 комментарий
Egor Suvorov, Программист/преподаватель C++ 18 июня в 12:02

Зачем в облако маленьким проектами вроде Вастрик.Клуба? А при условии очень предсказуемой нагрузки — например, внутренний сервис в интернете под паролем? Что так в БД ходить и питон с зависимостями ставить и мониторинг и логирование руками пытаться настраивать, что так. Бэкапы на VPS тоже парой кнопок делаются, а стоят копейки, причём копейки предсказуемые.

  Развернуть 1 комментарий

@yeputons, Если PaaS, то скорость разработки. «Небольшой проект на питоне» на каком-нибудь, прости $deity, Heroku или App Engine делается сильно быстрее, чем без него: не нужно вручную поднимать мониторинг, логирование, бэкапы (парой кнопок не обойтись: нужно их периодически тестировать), мучаться головной болью из-за зависимостей или секурити-апгрейдов оси.

Если IaaS, то обычно это какой-то вкусный сервис, которого нет у традиционных провайдеров, и который самому разворачивать долго или дорого, а обычные VM — это просто обычные VM, только рядом со вкусным сервисом.

  Развернуть 1 комментарий

@yeputons, добавлю корпоративный взгляд: экономия ресурсов. Вот сделал ты маленький, но гордый и нужный сервис. Можно деплоить на bare metal: минимум по две коробки в трех дц, плюс стейджинг и песочница для разрабов. 8 коробок на крохотный сервис - чудовищный оверкилл, отдай их лучше кому-то ещё! А сам - деплой в облако. Там у тебя тоже будет по инстансу в трех дц (и по второму в момент выкатывания нового релиза), стейджинг и песочница. Но это будут поды на пол-ядра!

Про лёгкость разворачивания все сказали в соседнем комменте.

  Развернуть 1 комментарий
Anton Markelov, Тимлидю (тимлижу?) инженеров инфраструктуры 18 июня в 12:07

Как тестировать описание облака в коде, кроме того как линтить и молиться, что нигде не ошибся в ноликах и не породил 1000 инстансов вместо 100?
Вопрос из той же категории - как порождать тестовые среды в облаках (имея в виду серверлесс и прочие managed сервисы) также легко, как в кубере? Кажется это выходит очень дорого.

  Развернуть 1 комментарий

@strangeman, terraform plan + infracost.io...
хотя и просто план тебе покажет что он собирается создавать. а если у тебя план сильно большой и его долго/сложно читать - то ты скорее всего что-то делаешь не так...

  Развернуть 1 комментарий

@DenZalman, ну нет, я немного про другое.

Приближенный к реальности пример, чтобы не абстрактно рассуждать. Допустим, у нас есть 50 пользователей в AWS, с самыми разными наборами ролей (ну и, соответственно, с разными наборами политик, привязанных к этим ролям).

Как мне убедиться, что изменения в одну политику/роль не проинтерферируют с другими политиками/ролями и пользователям не откроется/закроется лишнего?

Если проводить аналогию с тестированием кода, я не понимаю чем мне организовать юнит-тесты (протестировать одну конкретную политику на предмет того, что она делает ровно то, что ожидается) и интеграционные тесты (породить кучу пользователей с самыми разными сочетаниями ролей и убедиться, что все эти наборы ведут себя корректно)? Естественно, всё это хочется делать автоматически по коммиту и без порождения реальных сущностей в AWS.

Аналогичный пример можно придумать и про бакеты S3 - как мне убедиться что права, корсы и прочее-прочее соответствует моим ожиданиям, кроме как создать этот бакет и протыкать его ручками/скриптом?

Если для серверов и даже для кубера я понимаю как это организовать, то для того же AWS у меня такого понимания нет.

  Развернуть 1 комментарий

@strangeman, А как это делать для серверов и кубернетеса?

  Развернуть 1 комментарий

@dottedmag, ну сервера мы наливаем ансиблом, у него есть свои тулзы для юнит-тестирования (если надо тестировать свои роли/модули), плюс есть модули для тестирования конкретных тасок (assert например).
Для интеграционного тестирования (проверить целый плейбук с совокупностью тасок и ролей) есть фреймворки типа molecule.
Puppet и Chef имеет аналогичный инструментарий. С помощью этого всего можно проверить, будет ли результат на реальной среде соответствовать ожидаемому без необходимости наливать всё это на эту самую среду.

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

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

  Развернуть 1 комментарий

@strangeman, терраформом так же генерируешь планы с разным набором переменных и сравниваешь. можно даже разницу в цене узнать между одними переменными или другими.
есть еще checkov, который много всего проверяет в твоих терраформах, как по готовым планам так и просто по коду.
так же во время плана ты всегда видишь что и как ты будешь изменять. а если ты своим терраформом хочешь изменить что-то что этот терраформ не создавал - то он просто упадет или создаст другой ресурс с теми же параметрами что ты от него просишь.
Есть один воркараунд с подключением IAM полисей и ролей. Но он большими буквами обозначен в терраформ доках.

aws_iam_policy_attachment
aws_iam_role_policy_attachment

можно одним ударом отключить полиси от всех ролей и терраформ в плане об этом ничего не скажет. но это пожалуй и все что я могу вспомнить из возможных конфликтов.

  Развернуть 1 комментарий

Я уверен что где-то на просторах интернета есть какие-то уже подобные сравнения, но мне часто не хватает up-to-date переводчика с языка одного клауда на другой. Типа вот AWS Redshift это примерно GCP BigQuery, а у Azure это как? Или вот в AWS есть SQS, а как это называется в GCP и какие различия? Что-то такое вот общее и в идеале с кукбуком в плане "поднял инстанс не могу достучаться до него, где тут ваш аналог Route53?"

  Развернуть 1 комментарий
  Развернуть 1 комментарий

@libfitz, йее кайф, спасибо)))

  Развернуть 1 комментарий

@libfitz, почему-то он не точно передаёт ситуацию с GCP, а может давно не обновлялся @shrimpsizemoose, есть ещё ресурс https://cloud.google.com/free/docs/aws-azure-gcp-service-comparison, но это с позиции GCP

  Развернуть 1 комментарий
Сергей Саможён, Front-end разработчик 19 июня в 17:39

Насколько FaaS актуален для мелких/пет-проджектов? Дешевле или дороже минимальной впс?
К примеру для какого-нибудь тг бота

  Развернуть 1 комментарий

@drevnii, нужно считать. Какая средняя длина запроса у бота? Сколько ему нужно памяти? Если это примитивный бот, который даже не лезет в базу - выйдет несколько центов в месяц. Если же это бот, который шлет много запросов (например собирает данные для аналитики с разных сервисов), да еще и перемалывает всё на ходу - скорее всего выйдет очень дорого.
Примерные данные для расчетов можно взять здесь https://aws.amazon.com/lambda/pricing/

  Развернуть 1 комментарий
Захар Кириллов, Амбассадор ЕРАМ в Клубе 19 июня в 11:31

Ой, у меня сразу много вопросов!

  1. Почему ни в одном облаке (afaik конечно же) до сих пор нет поддержки PHP8 в продуктах типа PaaS/Functions, хотя с момента релиза прошло уже 8 месяцев, в то время как даже долларовые хостинги выкатили его ещё до конца 2020 года?

  2. Как быть микро- и малому бизнесу, неужели они все обречены вечно сидеть на этих самых долларовых хостингах со сраной CPanel 10-летней давности или вообще с кастомными админками без API? Пробовал микробизнес перевести в Azure, так ежемесячный счёт там был как годовой на предыдущем хостинге.

  3. В чём заключается уникальное предложение облаков от IBM и Oracle? Кому, когда и зачем нужно смотреть в их сторону?

  4. Поддержка Let's Encrypt: в Azure из коробки её нет, т.к. MS пытается всеми способами продать свои сертификаты. Добавить Let's Encrypt относительно не сложно, но всё равно замороченно и ты получаешь ещё один кусочек инфры, за которым нужно следить и платить. А как с этим в GCP/AQS?

  5. У амазона есть SES и он крутой. А как Azure живёт без его аналога и почему? А GCP — там-то хоть есть транзакционный почтовый сервис или тоже надо идти к 3rd party?

  Развернуть 1 комментарий

@zahhar, по поводу сертификатов - AWS умеет свои делать и автопродлять, следить вообще не надо, денег тоже не стоит (насколько я разобрался)

  Развернуть 1 комментарий

@strangeman, главное не стереть текстовый рекорд с подтверждением по ошибке... :)

  Развернуть 1 комментарий

@zahhar, никакого смысле смотреть в сторону IBM и Oracle для малого бизнеса нет. В России сейчас есть нормальные облачные предложение не такие роскошные но есть.

  Развернуть 1 комментарий

@khanton, а например? что-то есть с норм апи и поддержкой терраформа скажем?

  Развернуть 1 комментарий
Magistr, Пасу котов, системно архитектю, стратегически планирую, жму на кнопку фотоаппарата 18 июня в 12:40

Как тарифицировать каждый вызов функции и вообще есть ли что-то типа финансового трейсинга чтобы понимать какой твой кусок бизнес логики сколько стоил ? (в приложении к серверлесс и без)

  Развернуть 1 комментарий

@Magistr, infracost.io

  Развернуть 1 комментарий

@DenZalman, пасиб за тулу, но немного не то, хочется райнтайм цифры получать

  Развернуть 1 комментарий

@Magistr, быть может хватит возможностей AWS Cost Explorer

  Развернуть 1 комментарий

Ничего не понимаю. Есть какой-то курс 101?

  Развернуть 1 комментарий
Maximus, Электрический инженер 18 июня в 12:12

Как правильнее всего прикручивать облака к интерфейсам промышленных сетей от ABB, Schneider Electric, Siemens и пр.? :)

  Развернуть 1 комментарий

@Maximus, а можно немного подробностей? Вопрос звучит поездато, но контекста не хватает.

  Развернуть 1 комментарий
George K., Техноэнтузиаст 19 июня в 09:06

Есть ли инструменты для настоящей мультиоблачной IaC, то самое write once run anywhere? Терраформ хорош, конечно, но в итоге всё равно под каждое облако всё своё пилишь. Хотя бы для большой тройки, не считая всякие алибабы и прочие ораклы.

  Развернуть 1 комментарий

Ох, да тут поле непаханное!

Я оставил запрос на проведение АМА сессии (https://docs.google.com/spreadsheets/d/1c2q9dl--fOfHpQGtol5qdka4TedbnXub8kgkV4yf1l0/edit#gid=0), так что переходите по ссылке, ставьте лайки, подписывайтесь.

По всем вопросам могу ответить (а по тем, что не смогу - погуглить вместе с вами).

  Развернуть 1 комментарий

В следующий четверг Карен ответит на все вопросы на АМА встрече!

  Развернуть 1 комментарий

@MikhailKorobko, А запись будет? Доклад ждал, а тут жара под 40 и роутеру поплохело.

  Развернуть 1 комментарий

@yaroslav, Будет!

  Развернуть 1 комментарий
Alexey Buravov, Разработчик 18 июня в 18:46

😱 Комментарий удален его автором...

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб