Amazon Web Services *

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

Ваша инфраструктура почти наверняка начинается просто: несколько ресурсов + несколько разработчиков. Со временем она растёт во всевозможные стороны. Вы находите способы сгруппировать ресурсы в Terraform-модули, организовать код по папкам, и что здесь вообще может пойти не так? (известные последние слова)

Проходит время, и вы чувствуете, что ваша инфраструктура — это ваш новый питомец, но почему? Вас беспокоят необъяснимые изменения в инфраструктуре, вы боитесь прикасаться к инфраструктуре и коду — в итоге вы задерживаете новый функционал или снижаете качество…

После трёх лет управления на Github коллекцией community-модулей Terraform для AWS и долгосрочном поддержании Terraform в продакшене, Антон Бабенко готов поделиться своим опытом: как писать TF-модули, чтобы не было больно в будущем.

К концу доклада участники будут лучше знакомы с принципами управления ресурсами в Terraform, лучшими практиками, связанными с модулями в Terraform, и некоторыми принципами непрерывной интеграции, связанными с управлением инфраструктурой.

Так получилось, что до 2020 года я не имел дело с облаками. Когда же, наконец, углубился в эту тему, то немного потерялся от обилия сервисов, предлагаемых в AWS.

Необходимо было создать приложение с такими фичами:

• Авторизацией через facebook или google.
• Возможностью загрузки и отображения медиа-файлов.
• Получением событий с сервера в реальном времени.

В этой статье описаны сервисы, которые понадобились мне для реализации проекта и ощущения от процесса.

Мы живем в удивительное время, когда можно быстро и просто состыковать несколько готовых открытых инструментов, настроить их с «отключенным сознанием» по советам stackoverflow, не вникая в «многобукв», запустить в коммерческую эксплуатацию. А когда нужно будет обновляться/расширяться или кто-то случайно перезагрузит пару машин — осознать, что начался какой-то навязчивый дурной сон наяву, все резко усложнилось до неузнаваемости, пути назад нет, будущее туманно и безопаснее, вместо программирования, разводить пчел и делать сыр.

Не зря же, более опытные коллеги, с посыпанной багами и от этого уже седой головой, созерцая неправдоподобно быстрое развертывание пачек «контейнеров» в «кубиках» на десятках серверов на «модных языках» со встроенной поддержкой асинхронно-неблокирующего ввода-вывода — скромно улыбаются. И молча продолжают перечитывать «man ps», вникают до кровоточения из глаз в исходники «nginx» и пишут-пишут-пишут юнит-тесты. Коллеги знают, что самое интересное будет впереди, когда «всё это» однажды станет ночью колом под Новый год. И им поможет только глубокое понимание природы unix, заученной таблицы состояний TCP/IP и базовых алгоритмов сортировки-поиска. Чтобы под бой курантов возвращать систему к жизни.

Далее последует инструкция по настройке AWS MFA, и последющей установке и настройке AWS CLI.

К сожалению, у меня на эту обязательную процедуру ушла половина рабочего дня. Чтобы другим неуверенным пользователям AWS ;) как и я сам, не тратить драгоценное время на банальное, решил составить инструкцию.

Привет, Хабр!

В этой статье, я расскажу как легко и просто разместить статический сайт с помощью технологий Яндекса, а именно Object Storage.

В конце у вас будет размещенный в сети сайт, который будет доступен по внешней ссылке.

Эта статья будет полезна, если вы

• Начинающий разработчик, который только обучается программированию;
• Разработчик, который сделал портфолио и хочет разместить его в открытом доступе, чтобы показать друзьям и работодателям.

За 25 лет Amazon вырос из онлайн-магазина книг до одного из лидеров сразу в нескольких сферах. Около трети рынка облачных услуг принадлежит ему. Ещё один интересный факт: благодаря использованию микросервисов и continuous deployment сотрудники компании задеплоили что-то в прод 192 миллиона (!) раз за 2019 год. Вот уж у кого есть чему поучиться.

В этом году AWS запустила пилотный проект — AWS Educate Student Ambassador, и мне выпала честь стать одним из амбассадоров. Так что написание этой части мне доставило особое удовольствие.

Всем привет! Меня зовут Кирилл, я CTO Adapty Большая часть нашей архитектуры находится на AWS, и сегодня я расскажу о том, как мы сократили расходы на сервера в 3 раза за счёт использования спотовых инстансов на продакшн окружении, а также о том, как настроить их автомасштабирование. Сначала будет обзор того, как это работает, а потом подробная инструкция для запуска.

Что такое спотовые инстансы?

Спотовые инстансы — это сервера других пользователей AWS, которые в данный момент простаивают, и они продают их с большой скидкой (Amazon пишет до 90%, по нашему опыту ~3x, варьируется в зависимости от региона, AZ и типа инстанса). Основное их отличие от обычных в том, что они могут выключиться в любой момент. Поэтому мы долгое время считали, что их нормально использовать для дев окружений, либо для задач по расчёту чего-то, с сохранением промежуточных результатов на S3 или в базу, но не для прода. Существуют сторонние решения, которые позволяют использовать споты на проде, но там для нашего кейса много костылей, поэтому мы не внедряли их. Подход, описанный в статье, работает полностью в рамках стандартного функционала AWS, без дополнительных скриптов, кронов и тд.

В одной из прошлых статей мы разобрали несколько ключевых моментов настройки мультиарендного (далее multitenant) кластера Amazon EKS. Что касается безопасности, то это очень обширная тема. Важно понимать, что безопасность касается не только кластера приложений, но и хранилища данных.

AWS в качестве платформы для SaaS решений обладает большой вариативностью для хранилищ данных. Но, как и везде, грамотная настройка безопасности, проработка multitenant-архитектуры под неё, настройка различных уровней изоляций требуют определенных знаний и понимания специфики работы.

У всех есть инфраструктура, и у всех она разная: кому-то милей родной дата-центр, кто-то живет в облаке или multi-cloud. В нашем случае инфраструктура — это 1500+ хостов на полусотне оружений, распределенные по десятку VPC, а те — по нескольким AWS-аккаунтам. Кажется, не так уж и много, но есть своя специфика: разные операционные системы, нетиповая конфигурация, Legacy и прочие тонкости, усложняющие процесс поддержания всей этой системы.

В этой статье я расскажу, как мы облегчили работу с инфраструктурой и автоматизировали ее поддержку и выполнение операционных задач с помощью Ansible, Molecule, Docker, Gitlab CI и Packer.

Push-уведомления играют важную роль в любом приложении. Это может значительно увеличить взаимодействие с пользователями.

Настройка push-уведомлений с нуля может быть немного сложной. К счастью, Amplify предоставляет услуги push-уведомлений и SDK для React Native приложений. В этом уроке мы узнаем, как интегрировать в наше приложение этот сервис.

В начале года мы с коллегой начали интересоваться различными технологиями связанными с искусственным интеллектом и машинным обучением. Для начала решили попробовать освоить продукт компании Amazon – камеру AWS DeepLens. Мы заказали устройство на официальном сайте и хотим поделиться опытом использования. В настройке и подключении камеры есть множество нюансов и на данный момент по этому вопросу мало структурированной документации, что приводит к большим трудозатратам при установке и настройке. Надеемся, этот tutorial поможет избежать траты времени и вы сможете быстро начать пользоваться устройством.

Мы постоянно используем Cloud-native технологии, и запускаем системы в контейнерах на платформе Kubernetes. Эта технология отлично подходит для оркестрации контейнерных нагрузок благодаря гибкости и установке виртуальных машин прямо на железо (bare metal). Когда-то Kubernetes подходил только для простых рабочих нагрузок без сохранения состояния, теперь там стало возможным хранить базы данных, обучать машины и развертывать сложные приложения.

Одна из самых запрашиваемых тем, среди подписчиков моего канала Димка Реактнативный — это аутентификация и авторизация в приложении React Native. Поэтому я решил посветить этому вопросу отдельный лонгрид и перед тем как мы начнем кодить, необходимо разобраться с определением Аутентификация/Авторизация.

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



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

Прощай Redux, MobX, Apollo! Грань между бэкендом и фронтендом сломана! Инновационый шаг эволюции стейт менеджеров.

Одна из самых сложных задачах при разработке веб и мобильных приложений — это синхронизация данных между устройствами и выполнение автономных операции. В идеале, когда устройство находится в автономном режиме, ваши клиенты должны иметь возможность продолжать использовать ваше приложение не только для доступа к данным, но также для их создания и изменения. Когда устройство возвращается в оперативный режим, приложение должно повторно подключиться к бэкэнду, синхронизировать данные и разрешить конфликты, если таковые имеются. Для правильной обработки всех крайних случаев требуется много недифференцированного кода, даже при использовании кэша AWS AppSync SDK на устройстве с автономными мутациями и дельта-синхронизацией.

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

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

Вы можете использовать Amplify DataStore для автономного использования в режиме «только локальный» без учетной записи AWS или предоставить весь бэкэнд с помощью AWS AppSync и Amazon DynamoDB.

DataStore включает в себя Delta Sync с использованием вашего бэкенда GraphQL и несколько стратегий разрешения конфликтов.

Minio это простое, быстрое и совместимое с AWS S3 хранилище объектов. Minio создан для размещения неструктурированных данных, таких как фотографии, видеозаписи, файлы журналов, резервные копии. В minio также поддерживается распределенный режим (distributed mode), который предоставляет возможность подключения к одному серверу хранения объектов множества дисков, в том числе расположенных на разных машинах.

Цель этого поста настроить minio так чтобы каждый юзер мог работать только со своим bucket.

Привет, Хабр!

А вы любите летать на самолетах? Я обожаю, но на самоизоляции полюбил еще и анализировать данные об авиабилетах одного известного ресурса — Aviasales.

Сегодня мы разберем работу Amazon Kinesis, построим стримминговую систему с реал-тайм аналитикой, поставим NoSQL базу данных Amazon DynamoDB в качестве основного хранилища данных и настроим оповещение через SMS по интересным билетам.

Все подробности под катом! Поехали!

Этот гайд — результат личного опыта разработки и тестирования Serverless-приложений, а также маневрирования между «костылями» и «велосипедами» при попытках их протестировать. Когда я только начинал заниматься разработкой Serverless-приложений, во всем приходилось разбираться руками, не было четких гайдов или удобных инструментов локальной разработки и тестирования.

Сейчас ситуация меняется: инструменты стали появляться, но найти мануалы по их использованию непросто. В этом материале я покажу на простом примере, как работать с новым функционалом. Вы сможете легко его освоить и обойти те проблемы и баги, с которыми «посчастливилось» столкнуться мне.

Вы узнаете, как вести разработку с помощью браузерной консоли AWS, SAM-CLI и IntelljIDEA. Еще я расскажу про тестирование: интеграционные, E2E и юнит-тесты. А напоследок обсудим, во сколько обойдется такое решение (спойлер: на нем можно неплохо сэкономить).

Статья будет полезна тем, кто начинает вести разработку Serverless-приложений и еще не знаком с ее инструментарием и подходами.

Как и во многих других американских компаниях, организация рабочих процессов в Amazon построена на базовых принципах, основная цель которых – помочь сотрудникам принять правильное решение, основываясь на ценностях компании. Мы поговорили с продукт-менеджером в Amazon, который рассказал о том, каким принципам следуют в компании, как они помогают при выполнении задач, и через какие процессы проходит команда при разработке нового продукта. Ниже мы оставили ссылку на видео с полным интервью.

Миссия, видение и принципы Amazon

В моем понимании, миссия Amazon – быть самой клиентоориентированной компанией в мире. Все продукты, над которыми работает корпорация, разрабатываются с целью сначала сделать продукт для клиента, а потом уже увеличить его продажи.

Есть 14 принципов, которыми живет компания, и они используются во всех рабочих процессах. Эти принципы достаточно базовые, в них нет ничего особенного. Ими руководствуются при запуске нового продукта, во время собеседований, или когда даешь обратную связь коллеге. Их не заставляют заучивать, но когда ты работаешь в компании, хочешь-не хочешь начинаешь следовать этим принципам.

В 1970 г. американские инженеры запустили аппарат Аполлон-13 к Луне. На борту три батареи топливных элементов, беспокоиться не о чем, всё надежно и многократно продублировано. Но никто не мог предположить, что взрыв кислородного баллона выведет из строя две батареи из трёх. Трагедия! Астронавты вернулись домой, о событии сняли художественный фильм с Томом Хэнксом, а фраза астронавта Джека Свигерта: «Хьюстон, у нас проблема!», вошла в историю.



История Аполлона-13 это еще одно доказательство известного факта, что нельзя подготовиться ко всем возможным неприятностям. Это естественное свойство окружающего мира: железо периодически ломается, код сбоит, а люди ошибаются. Полностью исключить это невозможно.

Для больших распределенных систем такое поведение нормально, это следствие эффекта масштаба и статистики. Именно поэтому Design for Failure (дизайн на отказ) — базовый принцип проектирования облачных сервисов AWS. Системы изначально строятся так, чтобы максимально быстро восстановить штатную работу и минимизировать ущерб от известных и ещё неизвестных сбоев. На HighLoad++ Василий Пантюхин на примерах реальных проблем с боевыми сервисами показал паттерны проектирования распределенных систем, которые используют разработчики AWS.