Мы публикуем сессию вопросов и ответов о работе с AWS и другими поставщиками облачных услуг.
Сессия прошла в рамках вебинара «Создание эффективной инфраструктуры с использованием облачных решений».
Это на Ютубе записывать вебинар, и мы уже разместили в блоге текстовая расшифровка отчета .
Спикеры вебинара Александр Волочнев (Developer Advocate в DataStax Inc.) и Всеволод Севастьянов (TechLead в vene.io) ответили на вопросы о прайс-листе и правах в AWS, рассказали, как защитить данные и в каких ситуациях лучше выбирать российское облако провайдеры.
Зачем Openstack от %anyvendor%, если есть открытая ванильная версия, разработанная огромным количеством талантливых разработчиков?
Всеволод Севастьянов: Это классный вопрос, если вы уточните, что такое Openstack, поскольку есть 15 компаний, которые вносят своих разработчиков в разработку самого Openstack (HP, IBM и т. д.).А то, что они себе устанавливают, это по сути Openstack для своего облака с какими-то обертками, свистками от самих вендоров.
Что выбрать для себя? Вопрос.
Если вы используете Openstack для установки на свои серверы, берите Openstack, если вам больше ничего не нужно.
Если вы работаете с оборудованием HP или с тем, что они вам предоставляют для облачных вычислений, нейронных сетей или подключения к собственному облаку HP, используйте HP Openstack. Александр Волочнев: Здесь я должен сделать шаг в сторону и сказать, что не все знают, что такое Openstack, у нас проходит вебинар для начинающих разработчиков.
Openstack — это возможность сделать свое облако, то есть это система управления всем железом и всем остальным, где с одной стороны ты сидишь и пихаешь новые сервера, а с другой стороны люди используют его как облако.
Обычно это актуально для крупных компаний, где есть отдел, который делает все, что делает AWS, и есть отдел, который все это обеспечивает. То есть это домашнее облако, и провайдеров несколько.
Хороший вопрос, на который сложно ответить однозначно.
Это похоже на ядро Linux и Ubuntu. Несколько холиварная тема, которую я пока закрываю.
Почему все так сложно с ценообразованием в AWS? Сложно ли понять, сколько в конечном итоге будет стоить проект?
Александр: Это сложно, потому что AWS — это система, созданная инженерами для инженеров.И когда инженеры приступают к разработке системы, они думают о том, чтобы все было технически правильно, а не просто.
Большой проект иногда проще разработать и реализовать, чем рассчитать.
Потому что AWS пошла по пути сверхточных вычислений, плюс каждый сервис имеет отдельные классы, например, сервис хранения Simple Storage имеет несколько классов хранения файлов.
В одном классе файлового хранилища ваши файлы будут храниться немного дороже, но с вас не будут взимать деньги, когда кто-то их скачает; в других классах файлы будут храниться дешевле, но с вас будут взимать деньги, когда кто-то их скачает. Причем первые 100 ГБ будут взимать с вас одну сумму, следующие 100 ГБ — другую сумму.
При этом, чтобы окончательно всех запутать, существует еще и Intelligent Tiering, когда ваши файлы будут прыгать между слоями в зависимости от того, что для вас будет выгоднее, считают в AWS. И я говорю только о хранении файлов в одной конкретной корзине.
Если мы говорим об AWS Lambda, бессерверных приложениях, то там тоже красиво, потому что время считается отдельно, запуски считаются отдельно, а потребление памяти в ГБ/мс считается отдельно.
На самом деле, они хотели как лучше.
Они хотели предоставить вам оплату за потребление только того, что вы действительно потребили.
Но поскольку они отдельно считают подключения, отдельно потребление, отдельно то и это, пятое и десятое.
Когда вы рассматриваете проект, во-первых, посчитайте, что начисляется.
Нужно учитывать нюансы.
Если вы, например, храните небольшой файл в их AWS S3 Glacier, Glacier — это сервис долгосрочного хранения файлов на магнитных лентах, самое дешевое хранилище, но не самое быстрое, надо учитывать, что там минимальный размер файла составляет 100 с чем-то КБ, то надо учитывать, что если вы поместите туда файл размером 1 КБ, то вы заплатите за 100 КБ.
Нюансов много, расчет сложен.
Это типично для продуктов, созданных инженерами для инженеров.
В защиту AWS можно сказать, что у них есть очень мощные инструменты расчета затрат. Вы можете запустить расчет, ввести все свои данные, и вам с точностью до копейки скажут, сколько вы потратите.
И вы потратите ровно столько, при условии, что все будет работать именно так, как вы описали.
Всеволод: Я могу добавить? В защиту AWS хочу сказать, что есть данные о потреблении трафика, ресурсов и т.д. напрямую.
берутся с физического сервера.
И этот физический сервер может отвечать за несколько типов данных, и таких серверов может быть много, их можно объединить в дата-центр или колокейшн, разделить на зоны, вы этим всем пользуетесь, это все нужно собрать и доставить тебе в конце дня.
Это непростая задача сама по себе.
То есть причины задержек есть, и они вполне объективны.
Никто не хочет наживаться на бедных разработчиках.
Как избежать чека на $1000, когда ожидаешь максимум $100-200, и при этом не остаться с заблокированной услугой в час пик?
Всеволод: Ответ на этот вопрос кроется в Вашем предыдущем ответе, Саша.Дело в том, что, во-первых, вам нужно пользоваться калькулятором, а во-вторых, вам нужно четко понимать, что вы делаете в облаке.
Правильный ответ на этот вопрос приходит с опытом использования самого облака.
То есть условно говоря, с опытом ты знаешь, что для такого функционала нужны две машины С2 и миллион сообщений в SQS, ты закладываешь такие данные, калькулятор выдаёт тебе цифру, ты делаешь хардкап на свои сервисы, то есть нет более миллиона сообщений и отключите автомасштабирование.
Пожалуйста.
Ваш чек – это именно то, что вам нужно.
Используется ли это в реальной жизни? Еще не видел.
Все используют автомасштабирование и очень удивляются.
Александр: Вы всегда можете установить верхний предел для автомасштабирования.
Теперь мой ответ. Во-первых, все, что сказал Всеволод. Во-вторых, проблема общая, все приходят с этими вопросами.
Как избежать проверки? Вам нужно понимать, что вы потребляете, где находятся ваши точки траты, ведь есть, например, условно-бесплатные сервисы.
И для всех точек расхода можно установить верхний предел масштабирования.
Используете ли вы группы AutoScaling? Ну пожалуйста, вы можете установить максимальное количество серверов, после которого вы согласны на краш.
При создании группы автомасштабирования вы указываете минимальное и максимальное значение.
Не ставьте туда 100 серверов, поставьте 20, если у вас небольшой сервис и вы не монетизируетесь напрямую с входящих клиентов, и то же самое можно и со всеми остальными сервисами.
Устанавливайте ограничения, устанавливайте ограничения.
Это работает довольно хорошо.
Почему в AWS (IAM) так сложно управлять разрешениями? (Написание политики вручную, границы и т. д.)
Александр: Сначала я отвечу на вопрос почему, а потом на вопрос как.Представьте себе скутер на одной стороне сегмента и самолет, Boieng 777 или что-то подобное, на другой.
Самокат прост и интуитивно понятен.
На нем можно встать с первого раза, покататься, и через несколько минут справишься, а наехав пару раз на неровности, уже сможешь делать некоторые трюки.
Барьер входа низкий, возможности низкие.
Нельзя посадить на самокат себя, пьяного друга и два ведра лесных грибов.
Низкая мощность, простое управление.
Мы начинаем говорить о мощных системах.
Управление идентификацией и доступом (для тех, кто не знает) — это очень мощная система управления правами доступа в AWS. Он позволяет генерировать правила такие, что пользователю Васе будет разрешено использовать такой-то сервис с редактированием во время, не знаю, восходящей фазы луны в три часа ночи после крика петуха, но не будет быть доступной в остальное время и т. д. Любая мощная система не может быть простой.
Это закон природы.
Несколько хороших новостей.
Да, порог входа высок, но когда привыкаешь, все становится хорошо.
И все это нужно, хорошо и правильно.
Вначале вам не обязательно использовать границы.
Для небольших проектов они не критичны.
Начните с простого.
Вообще описание правил и политик доступа в IAM — очень крутая штука.
Это здорово настраивать.
Сложные системы не могут иметь низкий порог входа.
Всеволод: Я слышал, что есть определенные инструменты, которые позволяют вам отбросить ненужные границы и политики, которые вы никогда не будете использовать, сделать это на начальном этапе и прокачать это на своем аккаунте.
Но насколько я понимаю, AWS не рекомендует такие вещи, так как это прямое нарушение безопасности, и я их тоже не рекомендую.
Проще все это освоить, поковыряться и поехать.
Александр: Если вы работаете с простым приложением, вам не нужны эти навороты, используйте простой вариант. Если вы инженер, ответственный за это в серьезном проекте, потратьте день на изучение того, как это работает. Вам не понадобится больше одного дня.
Восемь часов и читай, читай, смотри, смотри.
А потом потихоньку реализовывать и понимать на практике.
Все.
Это не ракетостроение.
Немного теории и много практики и все получится.
Почему облачный биллинг до сих пор не работает в режиме реального времени? Всегда есть риск, что выйдет чек на тысячи долларов.
Всеволод: Мы уже ответили на этот вопрос.
Даже если вы соберете данные со всех серверов, это займет время.
Нет такой ужасной проблемы.
Единственное, следите за своими ресурсами.
AWS играет честно.
Александр: Биллинговая система, более сложная, чем велосипед, будет отставать, потому что она чертовски сложна.
Есть возможность сделать расчет быстрым.
Но за счет потребления ресурсов вашего сервера.
То есть ваш биллинг будет в реальном времени, а сервер будет работать медленнее.
Вы уверены, что хотите этого? «Всегда есть риск, что будет чек на тысячи долларов».
Есть.
Итак, вы устанавливаете границы.
Все.
Установите ограничения, кэширование и регулирование на шлюзе API. Всеволод: Справедливости ради стоит отметить, что эти группы AutoScaling сложно найти с первого раза, плюс они по умолчанию настроены очень широко.
Александр: Подведем итог: установите лимиты и у вас не будет чеков на тысячи долларов.
Как защититься от «политической» блокировки в облаке и насколько оправдано стремление к гибридному облаку?
Всеволод: Вам не обязательно делать вендорские замки.Придя в AWS и зная, что ваш сервис является политически спорным, вы должны знать, что привязка к поставщику — это плохо.
Если вы используете SQS, используйте его через какой-нибудь свой спейсер, который может переключиться на тот же Kafka, если вы используете что-то от Amazon, подумайте, как вы это быстро мигрируете, а еще лучше не используйте вообще ничего , устанавливать виртуальные машины, поднимать на них базы данных, никаких сервисов Amazon, все только свое и бэкапы всех данных в другое облако или к каким-то своим провайдерам.
Александр: Да, избегайте привязки к поставщику.
То есть жесткая привязка к конкретному поставщику.
Оправдано ли стремление к гибридному облаку?
Александр: Очень многое зависит от вашего проекта.Гибридное облако — это когда часть вашего проекта выполняется в AWS, а часть проекта — в вашем собственном дата-центре.
И они взаимодействуют друг с другом.
Насколько это оправдано? Для малых и средних проектов, я бы сказал, чаще всего это не оправдано.
Для более крупных проектов это может оказаться целесообразным, поскольку это лучший способ снизить затраты.
Все зависит от вашего варианта использования.
Если вы хотите создать максимальную доступность и пережить падение облака, это тоже возможно.
Но это очень сложно, и для этого нужны очень хорошие специалисты.
То есть опять же для большинства проектов это будет неактуально.
Проще, конечно, иметь одно чистое облако.
Любая интеграция всегда будет сложнее.
Всеволод: Также хотелось бы добавить, что решение о реализации гибридного проекта должно приниматься непосредственно техническим директором, поскольку это влечет за собой капитальные и накладные расходы, в том числе на человеческие ресурсы.
Александр: CAPEX (капитальные затраты) – подразумевается, что когда компания покупает новые серверы, она тратит много денег, устанавливая серверы в качестве основных средств.
А есть OPEX (операционные расходы), которые относятся к аренде, и если вы целиком в облаке, то все ваши затраты на инфраструктуру операционные, и списываются они по-другому.
Для некоторых компаний это может быть очень важно с точки зрения бухгалтерского учета и налогообложения.
Как организована защита критически важных для компании данных и интеллектуальной собственности в облаках? Или это исключительно проблема для потребителей облачных технологий?
Александр: Как AWS и, я полагаю, Azure тоже говорят: «Безопасность — это общая ответственность».Безопасность – это общая ответственность.
Это значит, что часть безопасности организована облаком, но как бы они ни старались, если вы не позаботились о безопасности со своей стороны, они не смогут вам помочь.
То есть это общая ответственность.
Хотите безопасности – научитесь организовывать охрану.
И второй момент, который нужно понимать, это то, что с GCP и Amazon работают очень серьезные американские государственные компании, у которых крайне строгие требования к шифрованию и хранению данных.
А облака регулярно проходят всевозможные аудиты, чтобы подтвердить, что в них есть все необходимое: все виды изоляции, все защиты, шифрование и сертификаты — все, что только может потребоваться.
А для совсем запущенных случаев можно использовать Outpost, то есть развернуть инфраструктуру AWS на базе собственного оборудования.
Всеволод: Добавлю, что есть готовые решения для шифрования и защиты ваших данных, в том числе баз данных.
Есть шифрование диска, которое даже бесплатно предоставляет, насколько я знаю, Google, насчет Amazon не уверен.
В конце концов, сможет ли какой-нибудь черный шляпа с улицы попасть в вашу базу данных, зависит только от вас.
Рекомендую организовать бастионы, то есть какие-то прокси-серверы, точки входа, изолировать базы данных внутри кластеров, настроить сервисы Kubernetes так, чтобы они не реагировали ни на что, кроме IP-адресов из белого списка или сервисов из белого списка и так далее, потому что это это большая тема.
Что вы думаете об отечественных облачных провайдерах, Яндексе, Селектеле? Только ваше мнение и опыт использования, если таковой имеется.
Александр: Здесь все просто.
Имею небольшое участие в разработке одного из облачных провайдеров в России, опыта использования у меня нет, так как я практически сразу после этого переехал из России и не могу говорить о Яндексе или Селектеле.
Всеволод: В последний раз, когда я изучал этот рынок, помимо Яндекса и MCS, все остальные провайдеры в том или ином смысле использовали решения openstack. И у них были очень крутые решения поверх openstack и очень крутое управление.
В общем, если вы ведете бизнес в России, возможно, это имеет смысл.
У Amazon, например, нет российского региона.
Александр: Да, я думаю, что GCP тоже.
Если вы храните данные своих пользователей в России, то Яндекс и Selectel могут быть для вас хорошим выбором.
Смогу ли я после вашего курса запустить свой (небольшой) проект в AWS с пониманием дела? Смогу ли я использовать необходимые абстракции и т.п.
? Александр: Да, конечно, для этого он и был создан.
Ниже прикреплю еще вопрос: «У меня уже есть AWS-SAA01, стоит ли покупать Курс Слёрма .
Насколько мне это будет полезно? Одним из ценных аспектов курса является возможность задать вопрос и быть услышанным.
У Amazon с этим проблемы; как правило такой возможности нет. Готов общаться и отвечать на вопросы.
Если вы хотите использовать какие-то сложные вещи, мы можем о них даже не говорить.
Например, Amazon предоставляет самые роскошные возможности для машинного обучения; там все автоматизировано, интегрировано и вообще великолепно.
А это в облаке на самом деле огонь.
Но в базовом курсе мы об этом не говорим, потому что где базовый курс, а где машинное обучение? Если вы планируете использовать Fargate, в базовом курсе мы рассматриваем не его, а все стандартные материалы: EC2, S3, AutoScaling, базы данных, Serverly, Lambda, API Gateway, инфраструктуру как код, который поможет вам управлять вашим проектом.
и т. д. - это все, что есть.
Почему большинство компаний в России по-прежнему косо смотрят на облака (в пользу собственной инфраструктуры), несмотря на все их преимущества? Когда мы можем ожидать изменения в мышлении?
Всеволод: Причина здесь — опыт 90-х годов, когда к вам в любой момент могли прийти за вашими данными.В гости больше никто не приходит, но привычка осталась.
Возможно, учитывая опыт политических блокировок, имеет смысл держать копию где-нибудь при себе.
Большинство компаний будут инвестировать в облако, если смогут оправдать затраты.
Александр: Вероятно, для смены парадигмы потребуется время.
Сколько времени нужно, чтобы получить опыт или эквивалентную сертификацию, необходимую работодателям для того, чтобы стать инженером Cloud DevOps?
Александр: Во-первых, я не знаю, какие сертификаты требуются работодателям для Cloud DevOps Engineer. Если говорить о стандартных позициях Junior, если вы не претендуете на Senior Cloud DevOps, то лично у меня подготовка и сертификация по GCP заняли ровно месяц.Мне нужно было перенести свой опыт в области архитектуры и разработки с AWS на GCP. Но это была большая работа, я серьезно посвящал ей много часов в день.
Что касается джуниорских позиций, то мне кажется, что в качестве сайд-проекта базовую сертификацию по направлению Cloud DevOps тоже надо пройти за месяц.
Если заниматься этим пару часов в день, то это возможно.
Это интересная работа, и во многих компаниях она очень хорошо оплачивается.
IAAS не всегда занимается проблемой рабочих мест. Существуют ли альтернативные способы реализации виртуальных рабочих столов, кроме RDS (негибкий) и VDS (дорогой)?
Всеволод: Честно говоря, я в основном использовал облака для разработки приложений, которые там размещались.По поводу организации рабочих мест со всеми RDS, VDS и т.п.
тут ответить сложно.
Я предлагаю подключиться к LinkedIn.
Аванпост Амазонки.
Почему и как его использовать? Александр: Это крутая возможность, когда вы сможете построить свой собственный дата-центр, и вы сможете запускать на своей стороне все программное обеспечение AWS, и вы будете использовать его как полностью интегрированное в инфраструктуру Amazon, но при этом это будет ваше оборудование, который у вас есть и который вы защищаете, который поддерживается вами и т. д. Вот что такое Amazon Outpost. Почему и как его использовать? Как им пользоваться, рассказывать не буду, так как мне пока не приходилось, это очень специфический случай.
У меня нет никакого опыта работы с Outpost, просто никогда не было необходимости.
За что? В некоторых ситуациях предъявляются сверхжесткие требования к аудиту, системам безопасности и т. д., то есть хранить данные должны только вы и они не должны никуда уходить, с точки зрения аудита.
В чем разница между курсами Slurm и обучением AWS?
Александр: Со своей стороны скажу так: я больше изучал AWS на практике и отдельно ознакомился с некоторыми курсами, которые у них есть.С точки зрения организации обучения мне очень понравилась Google Cloud Platform. Он на милю впереди AWS с точки зрения организации процессов, подготовительных материалов и т. д. Первое отличие курсов Slurm от AWS: AWS на английском языке.
Если у вас плохой английский, Slurm определенно лучший выбор.
AWS предлагает обучение практически по любой теме.
Не всегда полно, не всегда хорошо, но они есть.
В настоящее время у Slurm есть только один курс на AWS. Это базовый курс, охватывающий все основные варианты использования и наиболее часто используемые сервисы.
Но если вам нужен какой-нибудь умный случай, то этого может быть не в нашем курсе; опять же курс называется базовым.
И напоследок Slurm оказывает некоторую поддержку: можно написать, можно сказать, что на практике написано так, я не могу, что пошло не так? В AWS Training писать будет некому.
На сколько порядков отличается цена за единицу облачных ресурсов у Netflix и стартапа?
Александр: Цена за единицу ресурсов будет такой же.И это очень здорово.
Возможно, для Netflix как глобальной корпорации существуют какие-то секретные скидки.
Но деньги на потребление – это совсем другое.
Где границы между разумным использованием Iaas, PaaS, SaaS?
Александр: Все зависит от того, сколько у вас специалистов в этой отрасли и какие у вас мощности.Первое правило аутсорсинга: отдавайте на аутсорсинг то, что для вас не важно, то, на чем вы не зарабатываете, что не является ключом к вашей бизнес-модели.
Если вы делаете что-то, что для вас не является фундаментальным, это приблизит вас к SaaS. Saas и PaaS очень близки.
Вы разрабатываете бессерверное приложение: ваша база данных будет SaaS, а ваше приложение будет работать на PaaS. Об этом я рассказываю в восьмом модуле курса.
Если у вас много самых крутых специалистов, вы Apple и хотите иметь полный контроль над всем железом, то вам ближе IaaS или собственный on-premise дата-центр.
Теги: #selectel #Системное администрирование #облачные сервисы #Serverless #mcs #облачные решения mail.ru #aws #Amazon Web Services #облако yandex #облачные провайдеры
-
Ручной Привод – Как Он Появился?
19 Oct, 24 -
Тэлбот, Уильям Генри Фокс
19 Oct, 24 -
Iphone (1.1.1) И Ipod-Touch Взломаны
19 Oct, 24 -
Хакеры...
19 Oct, 24 -
День Рождения Бегуна
19 Oct, 24
