[Системное администрирование, IT-инфраструктура, Amazon Web Services, Облачные сервисы] Почему в AWS все так сложно с прайсом и правами? Как избежать «политических» блокировок и защитить данные в облаке?
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Публикуем сессию вопросов и ответов о работе с AWS и другими cloud-провайдерами. Сессия прошла в рамках вебинара «Создание эффективной инфраструктуры при помощи облачных решений». На Youtube есть запись вебинара, а в блоге мы уже размещали текстовую расшифровку доклада.
Спикер вебинара Александр Волочнев (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 Kernel, есть Ubuntu. Несколько холиварная тема, которую я пока что закрываю.
Почему в AWS все так сложно с прайсом? Сложно понять, сколько в итоге будет стоить проект?
Александр: Сложно, потому что AWS — это система, которую инженеры создавали для инженеров. А когда инженеры берутся разрабатывать какую-то систему, они думают о том, чтобы все было технически правильно, а не просто. Большой проект иногда бывает проще разработать и внедрить, чем просчитать. Потому что AWS пошло по пути сверхточного вычисления, плюс у каждого сервиса есть отдельные классы, например, у сервиса хранения Simple Storage есть несколько классов хранения файлов. На одном классе хранения файлов у вас файлы будут храниться чуть подороже, но с вас не будут браться деньги, когда их кто-то скачивает, на других классах файлы будут храниться подешевле, но с вас будут браться деньги, когда их кто-то скачивает, причем первые 100 Гб с вас будут брать одну сумму, последующие 100 Гб с вас будут брать другую сумму. При этом, чтобы окончательно всех запутать, есть еще Intelligent Tiering, когда у вас файлы будут прыгать между слоями в зависимости тот того, как будет вам выгоднее, по мнению AWS.
И это я только про хранение файлов говорю в одной конкретной корзине. Если мы говорим про AWS Lambda, бессерверные приложения, там тоже красиво, потому что отдельно считается время, отдельно считаются запуски и отдельно считается потребление памяти в Гб/мс. На самом деле они хотели как лучше. Они хотели предоставить вам оплату потребления только того, что вы действительно потребили. Но поскольку они отдельно считают коннекшены, отдельно потребление, отдельно то-се, пятое-десятое… Когда считаете какой-то проект, во-первых, посчитайте, что тарифицируется. Надо учитывать нюансы. Если вы, например, храните маленький файл в их AWS S3 Glacier, ледник – служба длительного хранения файлов на магнитных лентах, самое дешевое хранилище, но не самое быстрое, надо учитывать, что там минимальный размер файла считается 100 с чем-то Кб, то есть надо учитывать, что если вы туда положили файл в 1 Кб, платить вы будете как за 100 Кб. Много нюансов, обсчет сложный. Это характерно для продуктов, разработанных инженерами для инженеров.
В защиту AWS скажу, что у них есть очень мощные инструменты для калькуляции. Вы можете запустить калькуляцию, ввести все ваши данные, и вам скажут с точностью до цента, сколько вы потратите. И потратите вы именно столько при условии, что работать будет все именно так, как вы это описали.
Всеволод: Я могу добавить? В защиту AWS хочу сказать, что там данные потребления непосредственно трафика, ресурсов и т.д. берутся с физического сервера. И этот физический сервер может отвечать за несколько типов данных, и этих серверов может быть много, они могут быть объединены в датацентр или колокейшн, разделены по зонам, вы это все используете, все это надо собрать и в конце дня вам доставить. Это непростая задача сама по себе. То есть причины для задержек есть, и они достаточно объективны. Никто не хочет нажиться на бедных разработчиках.
Как избежать чека в $1000, когда ожидаешь максимум $100-200, и при этом не остаться с заблокированным сервисом в час-пик?
Всеволод: Ответ на этот вопрос кроется в твоем предыдущем ответе, Саша. Смысл в том, что, во-первых, надо пользоваться калькулятором, а во-вторых, надо четко понимать, что вы в облаке делаете. Правильный ответ на этот вопрос приходит с опытом использования самого облака. То есть, условно говоря, с опытом вы знаете, что вот для такого функционала вам нужно две машинки С2 и миллион сообщений в SQS, вы ставите такие данные, калькулятор вам выдает число, вы делаете хардкэп на своих сервисах, то есть не больше миллиона сообщений, и отключаете автоскейлинг. Пожалуйста. У вас чек ровно такой, какой вам нужен. Пользуются ли этим в реальной жизни? Не видел еще. Все используют автоскейлинг и очень удивлены.
Александр: У автоскейлинга всегда можно задать верхнюю границу. Теперь мой вариант ответа. Во-первых, все, что сказал Всеволод. Во-вторых, проблема общая, все приходят с этими вопросами. Как избежать чека? Нужно понимать, что вы потребляете, где у вас точки расходов, потому что есть, например, условно бесплатные сервисы. И во всех точках расходов можно задать верхний предел масштабирования. Вы используете AutoScaling groups? Ну, пожалуйста, можно задать максимальное количество серверов, после которого вы согласны падать.
Создавая AutoScaling group, вы задаете минимальное и максимальное значение. Не ставьте там 100 серверов, поставьте 20, если у вас маленький сервис и вы напрямую не монетизируетесь с пришедших клиентов, и то же самое возможно для всех остальных сервисов. Ставьте ограничения, ставьте лимиты. Это вполне себе работает.
Почему так сложно управлять правами доступа в AWS (IAM)? (Прописывание policy вручную, boundary и т.д.)
Александр: Я сначала отвечу на вопрос почему, а потом на вопрос как. Представьте себе на одной стороне отрезка самокат, а на другой – самолет, Boieng 777 или что-то подобное. Самокат прост и интуитивно понятен. Вы можете с первого раза встать на него, поехать и через несколько минут с ним справиться, а пару раз набив шишки уже делать какие-то трюки. Порог вхождения низкий, возможности низкие. Вы не можете на самокат посадить себя, своего пьяного друга и два ведра грибов из леса. Мощность низкая, простое управление.
Мы начинаем говорить про мощные системы. Identity and Access Management для тех, кто может быть не знает, это система управления правами доступа в AWS, очень мощная. Она позволяет вам генерировать такие правила, что пользователю Васе разрешено будет использование такого-то сервиса с редактированием при, не знаю, восходящей фазе луны в три часа ночи после крика петуха, но не будет доступно все остальное время, и т.д. Любая мощная система не может быть простой. Это закон природы. Из хороших новостей. Да, порог вхождения высокий, но когда привыкаешь, все становится хорошо. И все эти штуки нужные, хорошие и правильные.
Boundaries в начале можно не использовать. Для небольших проектов они не критичны. Начинайте с простого. В целом описание правил и политики доступа в IAM – это очень классная вещь. Ее здорово настраивать. Сложные системы не могут быть с низким порогом вхождения.
Всеволод: Я слышал, что есть определенные тулзы, позволяющие выкинуть ненужные boundaries, policy, которыми ты никогда не будешь пользоваться, сделать это на начальном этапе, накатить это поверх своего аккаунта. Но насколько я понимаю, AWS такие штуки не рекомендует, поскольку это прямой секьюрити брич, и я их тоже не рекомендую. Проще все это освоить, потыкать и поехать.
Александр: Если вы работаете с простым приложением, вам эти навороты не нужны, используйте простой вариант. Если вы инженер, ответственный за это на серьезном проекте, то потратьте один день на то, чтобы изучить, как оно работает. Там не нужно больше одного дня. Восемь часов и читать, читать, смотреть, смотреть. И потом потихоньку внедрять, разбираться на практике. Все. Это не рокет сайнс. Немножко теории и множко практики, все получится.
Почему биллинг облаков до сих пор не работает в реальном времени? Всегда есть риск, что выйдет чек в тысячи долларов.
Всеволод: Мы уже на этот вопрос отвечали. Даже если собрать данные со всех серверов — на это уже надо время. Нет такой страшной проблемы. Единственное, следите за вашими ресурсами. AWS играет честно.
Александр: Биллинг любой системы сложнее велосипеда будет отставать, потому что это чертовски сложно. Есть возможность сделать биллинг быстрым. Но ценой потребления ресурсов с вашего сервера. То есть биллинг у вас будет риал-тайм, а сервер будет работать медленнее. Вы точно этого хотите? «Всегда есть риск, что выйдет чек в тысячи долларов». Есть. Так вы границы задавайте. Все. Ставьте ограничение, кеширование, тротлинг на API Gateway.
Всеволод: Справедливости ради стоит отметить, что найти эти AutoScaling groups с первого раза сложно, плюс они по умолчанию настроены очень широко.
Александр: Резюмируя: ставьте ограничения, и не будет у вас чеков в тысячи долларов.
Как подстраховаться от «политической» блокировки в облаке, и насколько оправдано стремление к гибридному облаку?
Всеволод: Можно не делать вендор-локов. Приходя на AWS и зная, что ваш сервис спорный в политическом плане, вы должны знать, что вендор-лок — это плохо. Если вы используете SQS, используйте её через какую-то прокладку вашу, которая может переключиться на ту же Кафку, если вы используете что-то амазоновское, думайте о том, как вы это будете быстро мигрировать, а лучше не используйте ничего вообще, ставьте виртуалки, поднимайте на них базы данных, никаких амазоновских сервисов, все только свое и бэкапы всех данных в другое облако или на какой-нибудь свой собственный провайдер.
Александр: Да, избегайте вендор-лока. То есть жесткой привязки к какому-то конкретному поставщику.
Насколько оправдано стремление к гибридному облаку?
Александр: Очень зависит от вашего проекта. Гибридное облако — это когда часть проекта у вас запущена в AWS, а часть проекта запущена в вашем собственном датацентре. И они взаимодействуют друг с другом. Насколько это оправдано? Для небольших и средних проектов, я бы сказал, это не оправдано чаще всего. Для больших проектов это может быть оправдано, так как это может быть оптимальным способом уменьшения расходов. Все зависит от вашего юзкейса. Если вы хотите создать максимальную доступность и пережить падение облака, такое тоже возможно. Но это очень сложно, и для этого нужны очень хорошие спецы. То есть снова для большинства проектов это будет неактуальным. Проще, конечно, одно чистое облако. Любые интеграции буду всегда сложнее.
Всеволод: Хотел еще добавить, что решение о внедрении гибридного проекта должен принимать непосредственно технический директор, так как оно несет CAPEX и накладные расходы, в том числе на человеческие ресурсы.
Александр: CAPEX (capital expences, капитальные расходы) — подразумевается, что когда компания покупает новые сервера, она тратит много денег, ставит сервера себе как основные средства. И есть OPEX (operational expences), которые относятся к аренде, и если вы целиком в облаке, у вас все расходы на инфраструктуру являются операционными, и они списываются по-другому. Для некоторых компаний это может быть очень важно с точки зрения бухгалтерии и налогообложения.
Как в облаках организована защита критичных для компании данных, интеллектуальной собственности? Или это целиком забота потребителей облачных сервисов?
Александр: Как говорят AWS и, полагаю, Azure тоже: “Security is a shared responsibility”. Безопасность — это разделенная ответственность. Имеется ввиду, что часть безопасности организовывает облако, но как бы они ни старались, если вы со своей стороны о безопасности не позаботились, они вам ничем помочь не смогут. То есть это общая ответственность. Хотите безопасность, изучайте, как организовать безопасность.
И второй момент надо понимать, что с GCP, с Amazon работают очень серьезные американские правительственные компании, у которых сверх строгие требования по шифрованию и хранению данных. И облака регулярно проходят всевозможные виды аудитов, чтобы подтвердить, что у них есть все необходимое: все виды изоляции, все защиты, шифрования и сертификаты — все вообще, что может только потребоваться. И для совсем Advanced-кейсов можно использовать Outpost, то есть можно разворачивать инфраструктуру AWS на базе вашего собственного железа.
Всеволод: Я добавлю, что существуют готовые решения для шифрования и защиты ваших данных, в том числе и баз данных. Существует шифрование дисков, которое даже предоставляется бесплатно, насколько я знаю, Гуглом, насчет Амазона я не уверен. В итоге, сможет ли какой-нибудь блэк хэт с улицы залезть в вашу базу данных, зависит только от вас.
Я рекомендую организовывать бастионы, то есть некоторые сервера-прокси, точки входа, изолировать базу данных внутри кластеров, настраивать сервисы Kubernetes так, чтобы они не отвечали ни на что, кроме white-listed IP или white-listed services, ну, и так далее, потому что это большой топик.
Что вы думаете насчет отечественных cloud-провайдеров, Yandex, Selectel? Просто ваше мнение и опыт использования, если есть.
Александр: Здесь все просто. У меня есть небольшое участие в разработке одного из околооблачных поставщиков в России, опыта использования нет, потому что я почти сразу после этого переехал из России и ни про Yandex, ни про Selectel не могу рассказывать.
Всеволод: Последний раз, когда я изучал этот рынок, помимо Яндекса и MCS все остальные провайдеры использовали в некотором смысле openstack-решения. И у них были очень классные решения поверх openstack и очень классный менеджмент. В целом если вы держите бизнес в России, наверное, имеет смысл. У Амазона, например, нет региона Россия.
Александр: Да, у GCP, по-моему, тоже. Если вы держите данные ваших пользователей в России, то Yandex и Selectel могут быть для вас хорошим выбором.
После вашего курса смогу ли я запустить свой проект (небольшой) в AWS c пониманием дела? Смогу использовать нужные абстракции и т. д.?
Александр: Да, безусловно, он для этого и разработан. Я прицеплю сюда еще вопрос ниже: «У меня уже есть AWS-SAA01, стоит ли покупать курс Слёрм. Насколько он будет мне полезен?» Один из ценных моментов курса — возможность задать вопрос и быть услышанным. У Амазона с этим сложно, как правило, такой возможности нет. Я готов взаимодействовать и отвечать на вопросы.
Если вы хотите использовать какие-то сложные вещи, про них мы, может быть, в курсе и не говорим. Например, Амазон предоставляет роскошнейшие возможности для machine learning, у них там все автоматизировано, интегрировано, вообще супер. И это в облаке – вообще огонь. Но про это мы не рассказываем в базовом курсе, потому что где базовый курс, а где machine learning? Если вы планируете использовать Fargate, про него мы не рассказываем в базовом курсе, но все стандартные вещи: EC2, S3, AutoScaling, базы данных, Serverly, Lambda, API Gateway, инфраструктура как код, которая помогает вам управлять вашим проектом, и т. д. — это все есть.
Почему в России большинство компаний все еще косо смотрит на облака (в пользу in-house инфраструктуры) при всех их преимуществах? Когда ожидать сдвига в мышлении?
Всеволод: Здесь причиной является опыт 90-х годов, когда к тебе в любой момент могли прийти за твоими данными. Уже никто в гости не приходит, но привычка осталась. Возможно, учитывая опыт политических блокировок, держать копию где-то при себе имеет смысл. Большинство компаний будет инвестировать в облака, если вы сможете обосновать их стоимость.
Александр: Нужно время на сдвиг парадигмы, наверное.
Сколько требуется времени для получения опыта или равноценного сертификата, который требуют работодатели для Cloud DevOps Engineer?
Александр: Во-первых, я не знаю, каких сертификатов требуют работодатели для Cloud DevOps Engineer. Если говорить про стандартные младшие позиции, если вы не претендуете на Senior Cloud DevOps, то у меня лично подготовка и сертифицирование для GCP заняла ровно месяц. Мне надо было перенести опыт архитектуры и разработки с AWS на GCP. Но это было много работы, я серьезно по много часов в день вкладывался. Что касается младших должностей, мне кажется, в качестве сайд-проекта базовую сертификацию в направлении Сloud DevOps нужно делать тоже за месяц. Если заниматься этим по паре-тройке часов в день, то это возможно. Это дело интересное и очень неплохо оплачивается в очень многих компаниях.
IAAS не всегда решает вопрос рабочих мест. Есть ли альтернативные способы реализации виртуальных рабочих мест кроме RDS (не гибко) и VDS (дорого)?
Всеволод: Я, честно скажу, в основном использовал облака для разработки приложений, которые там будут хоститься. По поводу организации рабочих мест со всеми RDS, VDS и т.д. здесь сложно ответить. Предлагаю связаться в LinkedIn.
Amazon Outpost. Зачем и как применять?
Александр: Это классная возможность, когда вы можете поднять свой собственный ЦОД, и вы можете запустить весь софт AWS на вашей стороне, и вы будете использовать его как полностью интегрированный в инфраструктуру Амазон, но при этом это будет ваше железо, которое стоит у вас и которое охраняется вами, обеспечивается электричеством вами и т. д. Вот что такое Amazon Outpost. Зачем и как применять? Как применять не расскажу, потому что до сих пор не приходилось, это очень специфичный кейс. У меня нет опыта с Outpost никакого, просто никогда не было необходимости. Зачем? В некоторых ситуациях есть супер-строгие требования по аудиту, системам безопасности и т. д. то есть только у вас должны храниться данные и никуда они не должны попадать, с точки зрения аудита.
Какова разница между курсами Слёрма и AWS training?
Александр: Со своей стороны скажу вот что: AWS я больше изучал на практике и отдельно знакомился с некоторыми курсами, которые у них есть. С точки зрения организации обучения, мне очень понравился Google Cloud Platform. Он вперед на милю от AWS с точки зрения организации процесса, материалов для подготовки и т. д. Первая разница между курсами Слёрм и AWS: AWS на английском. Если у вас плохой английский, Слёрм здесь однозначно будет лучшим выбором. У AWS есть тренинги практически на любую тему. Не всегда полные, не всегда хорошие, но они есть. У Слёрм на данный момент есть только один курс по AWS. Это базовый курс, который закрывает все основные юзкейсы и самые наиболее часто используемые сервисы. Но если вам нужен какой-нибудь хитровывернутый кейс, то этого может не оказаться в нашем курсе, опять-таки, курс называется базовый. И последнее — Слёрм обеспечивает определенную поддержку: можно написать, можно сказать, что в практике написано вот так, у меня так не получается, что пошло не так? В AWS Training писать будет некому.
На сколько порядков отличается цена за единицу ресурсов облака для Netflix и стартапа?
Александр: Цена за единицу ресурсов будет одинакова. И это очень классно. Может быть, там есть какие-то секретные скидки для Netflix как глобальной корпорации. Но разные совершенно деньги за потребление.
Где границы между разумным использованием Iaas, PaaS, SaaS?
Александр: Все зависит от того, как много у вас специалистов в этой отрасли, насколько у вас хватает мощностей. Первое правило аутсторса: аутсорсить то, что для вас не принципиально, то, на чем вы не зарабатываете деньги, что не является ключом вашей бизнес-модели. Если вы делаете что-то, что не является для вас принципиальным, это склоняет вас ближе к SaaS. Saas и PaaS очень близки. Вы разрабатываете бессерверное приложение: у вас база данных будет SaaS’ом, а приложение ваше будет запущено на PaaS’е. Я про это рассказываю в восьмом модуле курса. Если у вас много крутейших специалистов, вы Apple, и вы хотите иметь полный контроль над всем железом, то вы ближе к IaaS’у или к on-premices собственному датацентру.
===========
Источник:
habr.com
===========
Похожие новости:
- [Системное администрирование, IT-инфраструктура, Сетевые технологии, Сетевое оборудование, Удалённая работа] Настройка IPsec GRE туннель между FortiOS 6.4.5 и RouterOS 6.48.1
- [Системное администрирование] Обновление Windows вызывает BSoD у пользователей принтеров Kyocera
- [IT-инфраструктура] Обновление и продление поддержки Windows на банкоматах, платежных киосках и кассах
- [Open source, Системное администрирование, IT-инфраструктура, Серверное администрирование] Мощный мониторинг за пять минут с помощью Glances
- [Исследования и прогнозы в IT, Облачные сервисы, Гаджеты, Игры и игровые приставки, Будущее здесь] Полку сервисов облачных игр прибыло: оцениваем My.Games Cloud и SberPlay
- [Системное администрирование, Программирование, IT-инфраструктура, DevOps] Самоподписные сертификаты кровавого энтерпрайза против вашего лампового CI/CD
- [Системное администрирование, IT-инфраструктура, Серверное администрирование, Хранение данных] Функция AppsON в Dell EMC PowerStore: запускаем приложения прямо на массиве
- [Информационная безопасность, Системное администрирование, Софт, IT-компании] Microsoft выпустила обновления для серверов Exchange с неподдерживаемыми версиями CU, уязвимыми для атаки ProxyLogon
- [IT-инфраструктура, Хранение данных, Хранилища данных, Облачные сервисы] Как выбрать облачную систему хранения данных, чтобы получить лучшую производительность и оптимизировать стоимость
- [Python, Microsoft Azure, Тестирование веб-сервисов, Облачные сервисы] HTTP атака на Azure
Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_itinfrastruktura (IT-инфраструктура), #_amazon_web_services, #_oblachnye_servisy (Облачные сервисы), #_aws, #_amazon_web_services, #_mcs, #_mail.ru_cloud_solutions, #_yandex_cloud, #_selectel, #_oblachnye_servisy (облачные сервисы), #_oblachnye_provajdery (облачные провайдеры), #_blog_kompanii_southbridge (
Блог компании Southbridge
), #_sistemnoe_administrirovanie (
Системное администрирование
), #_itinfrastruktura (
IT-инфраструктура
), #_amazon_web_services, #_oblachnye_servisy (
Облачные сервисы
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:33
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
 Публикуем сессию вопросов и ответов о работе с AWS и другими cloud-провайдерами. Сессия прошла в рамках вебинара «Создание эффективной инфраструктуры при помощи облачных решений». На Youtube есть запись вебинара, а в блоге мы уже размещали текстовую расшифровку доклада. Спикер вебинара Александр Волочнев (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 Kernel, есть Ubuntu. Несколько холиварная тема, которую я пока что закрываю. Почему в AWS все так сложно с прайсом? Сложно понять, сколько в итоге будет стоить проект? Александр: Сложно, потому что AWS — это система, которую инженеры создавали для инженеров. А когда инженеры берутся разрабатывать какую-то систему, они думают о том, чтобы все было технически правильно, а не просто. Большой проект иногда бывает проще разработать и внедрить, чем просчитать. Потому что AWS пошло по пути сверхточного вычисления, плюс у каждого сервиса есть отдельные классы, например, у сервиса хранения Simple Storage есть несколько классов хранения файлов. На одном классе хранения файлов у вас файлы будут храниться чуть подороже, но с вас не будут браться деньги, когда их кто-то скачивает, на других классах файлы будут храниться подешевле, но с вас будут браться деньги, когда их кто-то скачивает, причем первые 100 Гб с вас будут брать одну сумму, последующие 100 Гб с вас будут брать другую сумму. При этом, чтобы окончательно всех запутать, есть еще Intelligent Tiering, когда у вас файлы будут прыгать между слоями в зависимости тот того, как будет вам выгоднее, по мнению AWS. И это я только про хранение файлов говорю в одной конкретной корзине. Если мы говорим про AWS Lambda, бессерверные приложения, там тоже красиво, потому что отдельно считается время, отдельно считаются запуски и отдельно считается потребление памяти в Гб/мс. На самом деле они хотели как лучше. Они хотели предоставить вам оплату потребления только того, что вы действительно потребили. Но поскольку они отдельно считают коннекшены, отдельно потребление, отдельно то-се, пятое-десятое… Когда считаете какой-то проект, во-первых, посчитайте, что тарифицируется. Надо учитывать нюансы. Если вы, например, храните маленький файл в их AWS S3 Glacier, ледник – служба длительного хранения файлов на магнитных лентах, самое дешевое хранилище, но не самое быстрое, надо учитывать, что там минимальный размер файла считается 100 с чем-то Кб, то есть надо учитывать, что если вы туда положили файл в 1 Кб, платить вы будете как за 100 Кб. Много нюансов, обсчет сложный. Это характерно для продуктов, разработанных инженерами для инженеров. В защиту AWS скажу, что у них есть очень мощные инструменты для калькуляции. Вы можете запустить калькуляцию, ввести все ваши данные, и вам скажут с точностью до цента, сколько вы потратите. И потратите вы именно столько при условии, что работать будет все именно так, как вы это описали. Всеволод: Я могу добавить? В защиту AWS хочу сказать, что там данные потребления непосредственно трафика, ресурсов и т.д. берутся с физического сервера. И этот физический сервер может отвечать за несколько типов данных, и этих серверов может быть много, они могут быть объединены в датацентр или колокейшн, разделены по зонам, вы это все используете, все это надо собрать и в конце дня вам доставить. Это непростая задача сама по себе. То есть причины для задержек есть, и они достаточно объективны. Никто не хочет нажиться на бедных разработчиках. Как избежать чека в $1000, когда ожидаешь максимум $100-200, и при этом не остаться с заблокированным сервисом в час-пик? Всеволод: Ответ на этот вопрос кроется в твоем предыдущем ответе, Саша. Смысл в том, что, во-первых, надо пользоваться калькулятором, а во-вторых, надо четко понимать, что вы в облаке делаете. Правильный ответ на этот вопрос приходит с опытом использования самого облака. То есть, условно говоря, с опытом вы знаете, что вот для такого функционала вам нужно две машинки С2 и миллион сообщений в SQS, вы ставите такие данные, калькулятор вам выдает число, вы делаете хардкэп на своих сервисах, то есть не больше миллиона сообщений, и отключаете автоскейлинг. Пожалуйста. У вас чек ровно такой, какой вам нужен. Пользуются ли этим в реальной жизни? Не видел еще. Все используют автоскейлинг и очень удивлены. Александр: У автоскейлинга всегда можно задать верхнюю границу. Теперь мой вариант ответа. Во-первых, все, что сказал Всеволод. Во-вторых, проблема общая, все приходят с этими вопросами. Как избежать чека? Нужно понимать, что вы потребляете, где у вас точки расходов, потому что есть, например, условно бесплатные сервисы. И во всех точках расходов можно задать верхний предел масштабирования. Вы используете AutoScaling groups? Ну, пожалуйста, можно задать максимальное количество серверов, после которого вы согласны падать. Создавая AutoScaling group, вы задаете минимальное и максимальное значение. Не ставьте там 100 серверов, поставьте 20, если у вас маленький сервис и вы напрямую не монетизируетесь с пришедших клиентов, и то же самое возможно для всех остальных сервисов. Ставьте ограничения, ставьте лимиты. Это вполне себе работает. Почему так сложно управлять правами доступа в AWS (IAM)? (Прописывание policy вручную, boundary и т.д.) Александр: Я сначала отвечу на вопрос почему, а потом на вопрос как. Представьте себе на одной стороне отрезка самокат, а на другой – самолет, Boieng 777 или что-то подобное. Самокат прост и интуитивно понятен. Вы можете с первого раза встать на него, поехать и через несколько минут с ним справиться, а пару раз набив шишки уже делать какие-то трюки. Порог вхождения низкий, возможности низкие. Вы не можете на самокат посадить себя, своего пьяного друга и два ведра грибов из леса. Мощность низкая, простое управление. Мы начинаем говорить про мощные системы. Identity and Access Management для тех, кто может быть не знает, это система управления правами доступа в AWS, очень мощная. Она позволяет вам генерировать такие правила, что пользователю Васе разрешено будет использование такого-то сервиса с редактированием при, не знаю, восходящей фазе луны в три часа ночи после крика петуха, но не будет доступно все остальное время, и т.д. Любая мощная система не может быть простой. Это закон природы. Из хороших новостей. Да, порог вхождения высокий, но когда привыкаешь, все становится хорошо. И все эти штуки нужные, хорошие и правильные. Boundaries в начале можно не использовать. Для небольших проектов они не критичны. Начинайте с простого. В целом описание правил и политики доступа в IAM – это очень классная вещь. Ее здорово настраивать. Сложные системы не могут быть с низким порогом вхождения. Всеволод: Я слышал, что есть определенные тулзы, позволяющие выкинуть ненужные boundaries, policy, которыми ты никогда не будешь пользоваться, сделать это на начальном этапе, накатить это поверх своего аккаунта. Но насколько я понимаю, AWS такие штуки не рекомендует, поскольку это прямой секьюрити брич, и я их тоже не рекомендую. Проще все это освоить, потыкать и поехать. Александр: Если вы работаете с простым приложением, вам эти навороты не нужны, используйте простой вариант. Если вы инженер, ответственный за это на серьезном проекте, то потратьте один день на то, чтобы изучить, как оно работает. Там не нужно больше одного дня. Восемь часов и читать, читать, смотреть, смотреть. И потом потихоньку внедрять, разбираться на практике. Все. Это не рокет сайнс. Немножко теории и множко практики, все получится. Почему биллинг облаков до сих пор не работает в реальном времени? Всегда есть риск, что выйдет чек в тысячи долларов. Всеволод: Мы уже на этот вопрос отвечали. Даже если собрать данные со всех серверов — на это уже надо время. Нет такой страшной проблемы. Единственное, следите за вашими ресурсами. AWS играет честно. Александр: Биллинг любой системы сложнее велосипеда будет отставать, потому что это чертовски сложно. Есть возможность сделать биллинг быстрым. Но ценой потребления ресурсов с вашего сервера. То есть биллинг у вас будет риал-тайм, а сервер будет работать медленнее. Вы точно этого хотите? «Всегда есть риск, что выйдет чек в тысячи долларов». Есть. Так вы границы задавайте. Все. Ставьте ограничение, кеширование, тротлинг на API Gateway. Всеволод: Справедливости ради стоит отметить, что найти эти AutoScaling groups с первого раза сложно, плюс они по умолчанию настроены очень широко. Александр: Резюмируя: ставьте ограничения, и не будет у вас чеков в тысячи долларов. Как подстраховаться от «политической» блокировки в облаке, и насколько оправдано стремление к гибридному облаку? Всеволод: Можно не делать вендор-локов. Приходя на AWS и зная, что ваш сервис спорный в политическом плане, вы должны знать, что вендор-лок — это плохо. Если вы используете SQS, используйте её через какую-то прокладку вашу, которая может переключиться на ту же Кафку, если вы используете что-то амазоновское, думайте о том, как вы это будете быстро мигрировать, а лучше не используйте ничего вообще, ставьте виртуалки, поднимайте на них базы данных, никаких амазоновских сервисов, все только свое и бэкапы всех данных в другое облако или на какой-нибудь свой собственный провайдер. Александр: Да, избегайте вендор-лока. То есть жесткой привязки к какому-то конкретному поставщику. Насколько оправдано стремление к гибридному облаку? Александр: Очень зависит от вашего проекта. Гибридное облако — это когда часть проекта у вас запущена в AWS, а часть проекта запущена в вашем собственном датацентре. И они взаимодействуют друг с другом. Насколько это оправдано? Для небольших и средних проектов, я бы сказал, это не оправдано чаще всего. Для больших проектов это может быть оправдано, так как это может быть оптимальным способом уменьшения расходов. Все зависит от вашего юзкейса. Если вы хотите создать максимальную доступность и пережить падение облака, такое тоже возможно. Но это очень сложно, и для этого нужны очень хорошие спецы. То есть снова для большинства проектов это будет неактуальным. Проще, конечно, одно чистое облако. Любые интеграции буду всегда сложнее. Всеволод: Хотел еще добавить, что решение о внедрении гибридного проекта должен принимать непосредственно технический директор, так как оно несет CAPEX и накладные расходы, в том числе на человеческие ресурсы. Александр: CAPEX (capital expences, капитальные расходы) — подразумевается, что когда компания покупает новые сервера, она тратит много денег, ставит сервера себе как основные средства. И есть OPEX (operational expences), которые относятся к аренде, и если вы целиком в облаке, у вас все расходы на инфраструктуру являются операционными, и они списываются по-другому. Для некоторых компаний это может быть очень важно с точки зрения бухгалтерии и налогообложения. Как в облаках организована защита критичных для компании данных, интеллектуальной собственности? Или это целиком забота потребителей облачных сервисов? Александр: Как говорят AWS и, полагаю, Azure тоже: “Security is a shared responsibility”. Безопасность — это разделенная ответственность. Имеется ввиду, что часть безопасности организовывает облако, но как бы они ни старались, если вы со своей стороны о безопасности не позаботились, они вам ничем помочь не смогут. То есть это общая ответственность. Хотите безопасность, изучайте, как организовать безопасность. И второй момент надо понимать, что с GCP, с Amazon работают очень серьезные американские правительственные компании, у которых сверх строгие требования по шифрованию и хранению данных. И облака регулярно проходят всевозможные виды аудитов, чтобы подтвердить, что у них есть все необходимое: все виды изоляции, все защиты, шифрования и сертификаты — все вообще, что может только потребоваться. И для совсем Advanced-кейсов можно использовать Outpost, то есть можно разворачивать инфраструктуру AWS на базе вашего собственного железа. Всеволод: Я добавлю, что существуют готовые решения для шифрования и защиты ваших данных, в том числе и баз данных. Существует шифрование дисков, которое даже предоставляется бесплатно, насколько я знаю, Гуглом, насчет Амазона я не уверен. В итоге, сможет ли какой-нибудь блэк хэт с улицы залезть в вашу базу данных, зависит только от вас. Я рекомендую организовывать бастионы, то есть некоторые сервера-прокси, точки входа, изолировать базу данных внутри кластеров, настраивать сервисы Kubernetes так, чтобы они не отвечали ни на что, кроме white-listed IP или white-listed services, ну, и так далее, потому что это большой топик. Что вы думаете насчет отечественных cloud-провайдеров, Yandex, Selectel? Просто ваше мнение и опыт использования, если есть. Александр: Здесь все просто. У меня есть небольшое участие в разработке одного из околооблачных поставщиков в России, опыта использования нет, потому что я почти сразу после этого переехал из России и ни про Yandex, ни про Selectel не могу рассказывать. Всеволод: Последний раз, когда я изучал этот рынок, помимо Яндекса и MCS все остальные провайдеры использовали в некотором смысле openstack-решения. И у них были очень классные решения поверх openstack и очень классный менеджмент. В целом если вы держите бизнес в России, наверное, имеет смысл. У Амазона, например, нет региона Россия. Александр: Да, у GCP, по-моему, тоже. Если вы держите данные ваших пользователей в России, то Yandex и Selectel могут быть для вас хорошим выбором. После вашего курса смогу ли я запустить свой проект (небольшой) в AWS c пониманием дела? Смогу использовать нужные абстракции и т. д.? Александр: Да, безусловно, он для этого и разработан. Я прицеплю сюда еще вопрос ниже: «У меня уже есть AWS-SAA01, стоит ли покупать курс Слёрм. Насколько он будет мне полезен?» Один из ценных моментов курса — возможность задать вопрос и быть услышанным. У Амазона с этим сложно, как правило, такой возможности нет. Я готов взаимодействовать и отвечать на вопросы. Если вы хотите использовать какие-то сложные вещи, про них мы, может быть, в курсе и не говорим. Например, Амазон предоставляет роскошнейшие возможности для machine learning, у них там все автоматизировано, интегрировано, вообще супер. И это в облаке – вообще огонь. Но про это мы не рассказываем в базовом курсе, потому что где базовый курс, а где machine learning? Если вы планируете использовать Fargate, про него мы не рассказываем в базовом курсе, но все стандартные вещи: EC2, S3, AutoScaling, базы данных, Serverly, Lambda, API Gateway, инфраструктура как код, которая помогает вам управлять вашим проектом, и т. д. — это все есть. Почему в России большинство компаний все еще косо смотрит на облака (в пользу in-house инфраструктуры) при всех их преимуществах? Когда ожидать сдвига в мышлении? Всеволод: Здесь причиной является опыт 90-х годов, когда к тебе в любой момент могли прийти за твоими данными. Уже никто в гости не приходит, но привычка осталась. Возможно, учитывая опыт политических блокировок, держать копию где-то при себе имеет смысл. Большинство компаний будет инвестировать в облака, если вы сможете обосновать их стоимость. Александр: Нужно время на сдвиг парадигмы, наверное. Сколько требуется времени для получения опыта или равноценного сертификата, который требуют работодатели для Cloud DevOps Engineer? Александр: Во-первых, я не знаю, каких сертификатов требуют работодатели для Cloud DevOps Engineer. Если говорить про стандартные младшие позиции, если вы не претендуете на Senior Cloud DevOps, то у меня лично подготовка и сертифицирование для GCP заняла ровно месяц. Мне надо было перенести опыт архитектуры и разработки с AWS на GCP. Но это было много работы, я серьезно по много часов в день вкладывался. Что касается младших должностей, мне кажется, в качестве сайд-проекта базовую сертификацию в направлении Сloud DevOps нужно делать тоже за месяц. Если заниматься этим по паре-тройке часов в день, то это возможно. Это дело интересное и очень неплохо оплачивается в очень многих компаниях. IAAS не всегда решает вопрос рабочих мест. Есть ли альтернативные способы реализации виртуальных рабочих мест кроме RDS (не гибко) и VDS (дорого)? Всеволод: Я, честно скажу, в основном использовал облака для разработки приложений, которые там будут хоститься. По поводу организации рабочих мест со всеми RDS, VDS и т.д. здесь сложно ответить. Предлагаю связаться в LinkedIn. Amazon Outpost. Зачем и как применять? Александр: Это классная возможность, когда вы можете поднять свой собственный ЦОД, и вы можете запустить весь софт AWS на вашей стороне, и вы будете использовать его как полностью интегрированный в инфраструктуру Амазон, но при этом это будет ваше железо, которое стоит у вас и которое охраняется вами, обеспечивается электричеством вами и т. д. Вот что такое Amazon Outpost. Зачем и как применять? Как применять не расскажу, потому что до сих пор не приходилось, это очень специфичный кейс. У меня нет опыта с Outpost никакого, просто никогда не было необходимости. Зачем? В некоторых ситуациях есть супер-строгие требования по аудиту, системам безопасности и т. д. то есть только у вас должны храниться данные и никуда они не должны попадать, с точки зрения аудита. Какова разница между курсами Слёрма и AWS training? Александр: Со своей стороны скажу вот что: AWS я больше изучал на практике и отдельно знакомился с некоторыми курсами, которые у них есть. С точки зрения организации обучения, мне очень понравился Google Cloud Platform. Он вперед на милю от AWS с точки зрения организации процесса, материалов для подготовки и т. д. Первая разница между курсами Слёрм и AWS: AWS на английском. Если у вас плохой английский, Слёрм здесь однозначно будет лучшим выбором. У AWS есть тренинги практически на любую тему. Не всегда полные, не всегда хорошие, но они есть. У Слёрм на данный момент есть только один курс по AWS. Это базовый курс, который закрывает все основные юзкейсы и самые наиболее часто используемые сервисы. Но если вам нужен какой-нибудь хитровывернутый кейс, то этого может не оказаться в нашем курсе, опять-таки, курс называется базовый. И последнее — Слёрм обеспечивает определенную поддержку: можно написать, можно сказать, что в практике написано вот так, у меня так не получается, что пошло не так? В AWS Training писать будет некому. На сколько порядков отличается цена за единицу ресурсов облака для Netflix и стартапа? Александр: Цена за единицу ресурсов будет одинакова. И это очень классно. Может быть, там есть какие-то секретные скидки для Netflix как глобальной корпорации. Но разные совершенно деньги за потребление. Где границы между разумным использованием Iaas, PaaS, SaaS? Александр: Все зависит от того, как много у вас специалистов в этой отрасли, насколько у вас хватает мощностей. Первое правило аутсторса: аутсорсить то, что для вас не принципиально, то, на чем вы не зарабатываете деньги, что не является ключом вашей бизнес-модели. Если вы делаете что-то, что не является для вас принципиальным, это склоняет вас ближе к SaaS. Saas и PaaS очень близки. Вы разрабатываете бессерверное приложение: у вас база данных будет SaaS’ом, а приложение ваше будет запущено на PaaS’е. Я про это рассказываю в восьмом модуле курса. Если у вас много крутейших специалистов, вы Apple, и вы хотите иметь полный контроль над всем железом, то вы ближе к IaaS’у или к on-premices собственному датацентру. =========== Источник: habr.com =========== Похожие новости:
Блог компании Southbridge ), #_sistemnoe_administrirovanie ( Системное администрирование ), #_itinfrastruktura ( IT-инфраструктура ), #_amazon_web_services, #_oblachnye_servisy ( Облачные сервисы ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:33
Часовой пояс: UTC + 5