В отношении политики AWS не может быть никаких претензий, конечно. Все нижеописанное случилось по собственному ротозейству. Мы же вас предупреждали, незнание законов, и т.п.

Необходимое вступление

Эта короткая публикация о том, что нужно очень внимательно относиться к лицензиям и правилам использования облачных служб и инструментов.

Салют, хабровчане. В преддверии старта курса «AWS для разработчиков» подготовили перевод интересного материала.

---

Во многих юзкейсах, которые мы, как bakdata, видим на сайтах наших клиентов, релевантная информация сокрыта в связях между сущностями, например, при анализе отношений между пользователями, зависимостей между элементами или соединений между датчиками. Такие юзкейсы обычно моделируются на графе. Ранее в этом году Amazon выпустила новую графовую базу данных Neptune. В этом посте мы хотим поделиться нашими первыми идеями, хорошими практиками и тем, что может быть улучшено с течением времени.

Статья – гайд о том, как быстро и без боли начать использовать AWS Lambda на простом примере. Подойдет, как разработчику, не работавшему с Lambda вовсе, так и познавшему Cloud, чтобы оценить еще одно видение на разработку Serverless приложений.

Картинка предоcтавлена автором boto3-type-annotations, Allie Fitter

Сейчас мало кто пишет большие проекты на Python без аннотации типов. Это и просто, и позволяет отловить кучу ошибок еще на этапе написания кода, да и работает очень шустро. Но стоит добавить в зависимости boto3, и mypy начинает пестрить сообщениями о том, что аннотаций типов для boto3 не существует в природе.

Не страшно, существует же официальный генератор аннотаций для boto3 botostubs. Только он официально не выпускался, не обновляется и с mypy не работает.

Есть и замечательный boto3-type-annotations, но тоже немного заброшен, и поддержки mypy всё еще нет.

Как же проверять типы для boto3, а бонусом получить автодополнение кода?

Приглашаем на митап AWS_Ru: будем слушать интересные доклады и отмечать три года сообщества, ура! Праздничный митап пройдет 29 января в офисе Райффайзенбанка в Нагатино.

Привет, Хабр! Стараюсь делать переводы лучше и буду рад вашей критике.
(Примечание: цены являются точными по состоянию на август 2018 года)

В сервисе AWS Lambda существует 263 позиции с уникальными ценниками. Например, они могут называться “Accelerated InterRegion Inbound using edge locations outside US, Europe or Japan, From EU (Paris) to EU (London)”, и существуют в каждом из 17 регионов. В сумме, это 4 471 отдельные позиции, которые могут быть выставлены вам в счет при выполнении Lambda.

Материнcкая плата SynQuacer E-Series для 24-ядерного ARM-сервера на процессоре ARM Cortex A53 с 32 ГБ оперативной памяти, декабрь 2018 года

Много лет процессоры ARM с сокращённым набором команд (RISC) доминируют на рынке мобильных устройств. Но им так и не удалось пробиться в дата-центры, где по-прежнему властвуют Intel и AMD с набором инструкций x86. Периодически появляются отдельные экзотические решения, такие как 24-ядерный ARM-сервер на платформе Banana Pi, но серьёзных предложений пока нет. Точнее, не было до этой недели.

На этой неделе AWS запустила в облаке собственные 64-ядерные ARM-процессоры Graviton2 — это система-на-кристалле с ядром ARM Neoverse N1. Компания утверждает, что Graviton2 намного быстрее, чем ARM-процессоры предыдущего поколения в инстансах EC2 A1, а вот и первые независимые тесты.

Прим. перев.: Эта статья, написанная Galo Navarro, что занимает должность Principal Software Engineer в европейской компании Adevinta, — увлекательное и поучительное «расследование» в области эксплуатации инфраструктуры. Её оригинальное название было немного дополнено в переводе по причине, которую объясняет автор в самом начале.



Примечание от автора: Похоже, эта публикация привлекла гораздо больше внимания, чем ожидалось. Я до сих пор получаю гневные комментарии о том, что название статьи вводит в заблуждение и что некоторые читатели опечалены. Я понимаю причины происходящего, поэтому, несмотря на риск сорвать всю интригу, хочу сразу рассказать, о чем эта статья. При переходе команд на Kubernetes я наблюдаю любопытную вещь: каждый раз, когда возникает проблема (например, рост задержек после миграции), первым делом обвиняют Kubernetes, однако потом оказывается, что оркестратор, в общем-то, не виноват. Эта статья повествует об одном из таких случаев. Ее название повторяет восклицание одного из наших разработчиков (потом вы убедитесь, что Kubernetes тут вовсе ни при чем). В ней вы не найдете неожиданных откровений о Kubernetes, но можете рассчитывать на пару хороших уроков о сложных системах.

Пару недель назад моя команда занималась миграцией одного микросервиса на основную платформу, включающую CI/CD, рабочую среду на основе Kubernetes, метрики и другие полезности. Переезд носил пробный характер: мы планировали взять его за основу и перенести еще примерно 150 сервисов в ближайшие месяцы. Все они отвечают за работу некоторых из крупнейших онлайн-площадок Испании (Infojobs, Fotocasa и др.).

29-30 октября в Санкт-Петербурге прошла конференция DevOops. В этой статье я поделюсь впечатлениями и инсайтами, а также краткими заметками о прослушанных докладах. Небольшой disclaimer: поскольку я разработчик, то некоторые мысли и комментарии могут быть с уклоном в Dev, нежели в Ops, но я постараюсь быть как можно объективнее.

DevOops входит в число мероприятий, которые проводит JUG Ru Group. И нужно признать, организация и уровень докладов были на уровне. Конференция длилась два дня, в три потока. Помимо этого, были дискуссионные зоны для общения со спикерами, мастер-классы, а также lightning talks — более лёгкие и короткие доклады, в том числе для тех, кто ранее не выступал и хочет попробовать себя в качестве спикера.

Тематическая канва DevOops 2019 — cloud native. Бо́льшая часть докладов была прямо или косвенно посвящена облакам. Тема давно уже не новая, однако есть множество неочевидных сложностей, которые возникают в процессе использования облачных технологий. И многие пришли специально, чтобы найти ответы. Это было особенно заметно на QA-сессиях после докладов. Спикерам задавали практические вопросы, которые действительно волнуют людей. Почти на каждый вопрос следовали реплики других участников «У нас такая же проблема!» и начиналась оживлённая дискуссия.

Юрий Дзюбан, разработчик программного обеспечения, более семи лет назад переехал работать в Польшу, а после этого релоцировался в Германию по предложению от Scalors. Сейчас он уже около полугода занимает должность Java Middle программиста в компании Amazon, в Мюнхене.



— Откуда ты? Где учился и с чего начал карьеру?

— Я родом из Запорожья. Закончил магистратуру в КПИ, факультет ФИОТ. Любовь к компьютерным играм в пятом классе повлияла на мой выбор профессии. Мне казалось, что вся разработка сводится к написанию компьютерных игр. Уже будучи немного старше, пришло осознание насколько широка эта область, и как далеко переходит за границы написания игр. Частично также повлияла сестра, которая первой начала протаптывать этот путь.

Перевод статьи Nick Price

В настоящее время я работаю над большим проектом логирования, который изначально был реализован с использованием AWS Elasticsearch. Поработав с крупномасштабными магистральными кластерами Elasticsearch в течение нескольких лет, я совершенно повержен качеством реализации AWS и не могу понять, почему они не исправили или хотя бы улучшили ее.

Масштаб сети Amazon Web Services — это 69 зон по всему миру в 22 регионах: США, Европа, Азия, Африка и Австралия. В каждой зоне находится до 8 ЦОД — Центров Обработки Данных. В каждом ЦОД тысячи или сотни тысяч серверов. Сеть построена так, что все маловероятные сценарии перебоев в работе принимаются в расчет. Например, все регионы изолированы друг от друга, а зоны доступности разнесены на расстояния в несколько километров. Даже если перерубить кабель, то система перейдет на резервные каналы, а потери информации составят единицы пакетов данных. О том, на каких еще принципах построена сеть и как она устроена, расскажет Василий Пантюхин.



Василий Пантюхин начинал Unix-админом в .ru-компаниях, 6 лет занимался большими железками Sun Microsystem, 11 лет проповедовал дата-центричность мира в EMC. Естественным путем эволюционировал в приватные облака, потом подался в публичные. Сейчас, как архитектор Amazon Web Services, техническими советами помогает жить и развиваться в облаке AWS.

В предыдущей части трилогии об устройстве AWS Василий углубился в устройство физических серверов и масштабирование базы данных. Nitro-карты, кастомный гипервизор на базе KVM, база данных Amazon Aurora — обо всем этом в материале «Как AWS «варит» свои эластичные сервисы. Масштабирование серверов и базы данных». Прочитайте, чтобы погрузиться в контекст, или посмотрите видеозапись выступления.

В этой части речь пойдет о масштабировании сети — одной из сложнейших систем в AWS. Эволюция от плоской сети к Virtual Private Cloud и ее устройство, внутренние сервисы Blackfoot и HyperPlane, проблема шумного соседа, а в конце — масштабы сети, backbone и физические кабели. Обо всем этом под катом.

Дисклеймер: всё, что ниже — личное мнение Василия, и оно может не совпадать с позицией Amazon Web Services.

В конце августа Imperva оповестила клиентов сервиса Cloud WAF (бывш. Incapsula) об утечке конфиденциальной информации и инициировала сброс паролей учетных записей. Оказалось, что посторонние получили доступ к хешам паролей, ключам API и SSL-сертификатам.

10 октября исполнительный директор компании Крис Хайлен (Chris Hylen) и технический директор Кунаи Ананд (Kunal Anand) изложили post mortem с деталями инцидента. Как такое могло произойти у компании, которая специализируется на защите данных и приложений?

Если резюмировать, проблема возникла из-за некорректной миграции БД с собственного хостинга на Amazon Web Services.

В своем сообщении Крис Хайлен перечисляет ряд ошибок, сделанных во время миграции. Все вместе, они позволили неизвестным украсть админский ключ API к одному из аккаунтов в продакшне на Amazon Web Services. Расследование показало, что неавторизованный доступ произошёл ещё в октябре 2018 года.

Админский ключ дал злоумышленнику доступ к снимку БД с различными сведениями о клиентах, которые зарегистрировались до 15 сентября 2017 года. Информация включала адреса электронной почты, хэшированные и солёные пароли, а для некоторого количества клиентов — ключи API и предоставленные клиентами SSL-сертификаты.

Начать разбираться с IoT (Internet of Things) платформами меня останавливало отсутствие IoT устройства, которое было бы совместимо по протоколам и способам доступа. Но когда я понял, что в качестве устройства можно использовать обыкновенный смартфон, то реализация работающей цепочки заняла один день.

Возьмем смартфон, который будет эмулировать IoT устройство c датчиками температуры, влажности и давления и отсылать показания на Amazon IoT платформу. На платформе заведем правило, которое при поступлении данных от нашего устройства будет вызывать сервис нотификаций, который в свою очередь будет отсылать e-mail с полученными данными.

Такая система, конечно, несет мало практической ценности, но позволяет разобраться, как все устроено:



Почему именно IoT платформа от Amazon? И зачем вообще нужно понимать, как работают IoT платформы?

Облака подобны магической шкатулке — задаешь, что тебе нужно, и ресурсы просто появляются из ниоткуда. Виртуальные машины, базы данных, сеть — все это принадлежит только тебе. Существуют и другие тенанты облака, но в своей Вселенной ты единоличный правитель. Ты уверен, что всегда получишь требуемые ресурсы, ни с кем не считаешься и самостоятельно определяешь, какой будет сеть. Как устроена эта магия, которая заставляет облако эластично выделять ресурсы и полностью изолировать тенанты друг от друга?



Облако AWS это мегасуперсложная система, которая эволюционно развивается с 2006 года. Часть этого развития застал Василий Пантюхин — архитектор Amazon Web Services. Как архитектор он видит изнутри не только конечный результат, но и сложности, которые преодолевает AWS. Чем больше понимания работы системы, тем больше доверия. Поэтому Василий поделится секретами облачных сервисов AWS. Под катом устройство физических серверов AWS, эластичная масштабируемость БД, кастомная база данных Amazon и методы повышения производительности виртуальных машин с одновременным уменьшением их цены. Знание архитектурных подходов Amazon поможет эффективнее использовать сервисы AWS и, возможно, даст новые идеи по построению собственных решений.

Добрый день, хочу поделиться с вами своим опытом по настройке и использованию сервиса AWS EKS (Elastic Kubernetes Service) для Windows контейнеров, а точнее о невозможности его использования, и найденном баге в системном контейнере AWS, тем кому интересен этот сервис для Windows контейнеров, просьба под кат.

Начинайте с простого, но не в ущерб дальнейшему росту.



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

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

Написанной мной инструмент командной строки Sloc Cloc and Code (scc), который теперь доработан и поддерживается многими отличными людьми, подсчитывает строки кода, комментарии и оценивает сложность файлов внутри каталога. Здесь нужна хорошая выборка. Инструмент подсчитывает в коде операторы ветвления. Но что такое сложность? Например, заявление «У этого файла сложность 10» не очень полезно без контекста. Чтобы решить эту проблему, я запустил scc на всех исходниках в интернете. Это также позволит найти какие-то крайние случаи, которые я не рассматривал в самом инструменте. Мощное испытание методом грубой силы.

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

Короче говоря, я загрузил и обработал много исходников.

Голые цифры:

• 9 985 051 репозиториев всего
  
• 9 100 083 репозитория хотя бы с одним файлом
  
• 884 968 пустых репозиториев (без файлов)
  
• 3 500 000 000 файлов во всех репозиториях
  
• Обработано 40 736 530 379 778 байт (40 ТБ)
  
• Идентифицировано 1 086 723 618 560 строк
  
• Распознано 816 822 273 469 строк с кодом
  
• 124 382 152 510 пустых строк
  
• 145 519 192 581 строк комментариев
  
• Общая сложность по правилам scc: 71 884 867 919
  
• 2 новые ошибки, найденные в scc

У нас было 4 Amazon-аккаунта, 9 VPC и 30 мощнейших девелоперских окружений, стейджей, регрессий — всего более 1000 EC2 instance всех цветов и оттенков. Раз уж начал коллекционировать облачные решения для бизнеса, то надо идти в своем увлечении до конца и продумать, как все это автоматизировать.

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

Статья длинная, поэтому запаситесь попкорном чаем и вперед!

И еще один нюанс — статья писалась на основе версии 0.11, в свежей 0.12 многое изменилось но основные практики и советы по прежнему актуальны. Вопрос миграции с 0.11 на 0.12 заслуживает отдельной статьи!

Публикуем любые сервисы, расположенные в домашнем гипервизоре через сервис EC2 Amazon Web Services через бесплатный инстанс под Amazon Linux AMI 2018 с помощью libreswan, xl2tpd и с небольшой толикой извращения…