Amazon Web Services *

В начале марта 2019 года команда «Интерсофт Евразия» завершила работу над тестовой партией гаджетов ДО-РА – персональных, кроссплатформенных ДОзиметров-РАдиометров для контроля радиационной обстановки в месте измерения, совместимых со смартфонами и планшетами под iOS и Android.

Что же получает пользователь, приобретая такое устройство: проверенную под радиационной нагрузкой в лаборатории завода надёжную электронику, стильный цветной корпус в духе Малевича;) на любой вкус, подарочную упаковку, цветную вкладыш-инструкцию на русском и английском языках, специальный кабель для подзарядки гаджета через USB разъём, бесплатное обновляемое приложение DO-RA.Pro из App Store и Google Play.

Следующий шаг на пути реализации нашего проекта – найти оптимальные каналы продаж изделий Made in Russia в сложной обстановке стагнирующей покупательской способности.

Привет, Хабр! Сегодня мы построим систему, которая будет при помощи Spark Streaming обрабатывать потоки сообщений Apache Kafka и записывать результат обработки в облачную базу данных AWS RDS.

Представим, что некая кредитная организация ставит перед нами задачу обработки входящих транзакций «на лету» по всем своим филиалам. Это может быть сделано с целью оперативного расчета открытой валютой позиции для казначейства, лимитов или финансового результата по сделкам и т.д.

Как реализовать этот кейс без применения магии и волшебных заклинаний — читаем под катом! Поехали!


(Источник картинки)

Теперь стало больше голосов и языков. Раньше был голос только через AWS Polly.

А еще статьи синхронизируются в ваш личный подкаст, но это уже было.

Хотел бы рассказать про новый CLI tool который я написал для решения одной старой проблемы.

Проблема

Terraform уже давно стал стандартом в Devops/Cloud/IT сообществе. Вещь очень удобная и полезная чтоб заниматся infrastructure as code. Есть много прелестей в Terraform а так же много вилок, острых ножей и граблей.
С Terraform очень удобно делать новые вещи и потом ими управлять, менять или удалять. А что делать тем у кого есть огромная инфраструктура в облаке и не создано через Terraform? Переписывать и пересоздавать все облако как то дорого и небезопасно.
Я сталкивался с такой проблемой на 2 работах, самый простой пример когда хочешь что все было в гите виде терраформ файлов, а у тебя 250+ бакетов и писать их для терраформа руками как то много.
Есть issue еще с 2014 года в terrafom которую закрыли в 2016 с надеждой что будет import.

Вообщем все как на картинке только справа налево

Я работаю в аутсорсе, где главный принцип можно описать фразой «продавай много, делай быстро». Чем быстрее сделаем, тем больше заработаем. И, желательно, чтобы всё работало не на костылях и соплях, а с приемлемым уровнем качества. Я расскажу о своём опыте, когда за короткий срок нужно было разработать промо-сервис.

Дано: root-аккаунт на AWS, отсутствие ограничений по выбору стека технологий, один бэкендер, и один месяц на разработку.

Задача: реализовать промо-сервис, где пользователи загружают от одного до четырёх видео длительностью от одной до четырёх секунд, которые потом встраиваются в оригинальный видеоряд. То есть, подменяем фрагменты оригинального видео (заставка сериала) на пользовательские. Киллер-фича — возможность отправить своё имя, которое в виде красивого текста наложится на соответствующий фрагмент видео. Кроме того, пользователь может загружать видео длиной от 4 до 30 секунд, и на стороне сервиса оно обрежется до 4 секунд.

Обычно для мониторинга и анализа работы Nginx используют коммерческие продукты или готовые open-source альтернативы, такие как Prometheus + Grafana. Это хороший вариант для мониторинга или real-time аналитики, но не слишком удобный для исторического анализа. На любом популярном ресурсе объем данных из логов nginx быстро растет, и для анализа большого объема данных логично использовать что-то более специализированное.

В этой статье я расскажу, как можно использовать Athena для анализа логов, взяв для примера Nginx, и покажу, как из этих данных собрать аналитический дэшборд, используя open-source фреймворк cube.js. Вот полная архитектура решения:

TL:DR;
Ссылка на готовый дэшборд.

Зачем же может потребоваться эмулировать инфраструктуру Amazon web services?

Прежде всего это экономия — экономия времени на разработку и отладку, и что не менее важно — экономия денег из бюджета проекта. Понятно что эмулятор не будет на 100% идентичен исходной среде которую пытаемся эмулировать. Но для целей ускорения разработки и автоматизации процесса существующего сходства должно хватать. Наиболее злободневное что случилось в 2018 году с AWS — это блокировки провайдерами IP адресов подсетей AWS в РФ. И эти блокировки затронули нашу инфраструктуру, размещенную в облаке Amazon. Если планируете использовать технологии AWS и размещать проект в этом облаке, то для разработки и тестирования эмуляция с лихвой окупается.



В публикации расскажу, как нам удалось выполнить такой трюк с сервисами S3, SQS, RDS PostgreSQL и Redshift при миграции существующего много лет хранилища данных на AWS.

Привет, Хабр! На тему архитектуры хранилищ данных написано немало, но так лаконично и емко как в статье, на которую я случайно натолкнулся, еще не встречал.

Предлагаю и вам познакомиться с данной статьей в моем переводе. Комментарии и дополнения только приветствуются!


(Источник картинки)

Приветствую всех любителей покритиковать чужой код. :) Сегодня в нашей лаборатории новый материал для исследования — исходный код проекта AWS SDK для .NET. В своё время мы писали статью о проверке AWS SDK для C++. Тогда не нашлось ничего особо интересного. Посмотрим, чем нас порадует .NET версия AWS SDK. Хорошая возможность в очередной раз продемонстрировать возможности анализатора PVS-Studio, а также сделать мир немного совершеннее.

В 1999 году доходы музыкальной индустрии США достигли максимальной отметки $14,6 млрд (все цифры от RIAA). Но важно понимать, что именно продавалось:

• $12,8 млрд получено от продажи CD
  
• $1,1 млрд от продажи кассет
  
• $378 млн составили продажи музыкальных видео на физических носителях
  
• $222,4 млн — синглы на CD

В общем, музыкальная индустрия в основном продавала пластиковые диски в красивых коробках. Записанная музыка — просто способ отличить одни кусочки пластика от других. Сама музыка не продавалась.

Это может показаться глупым отличием, но так становится понятно, что произошло дальше:

Представляю вашему вниманию перевод части статьи: The non-primitive approach of amazon — how AWS IoT meets IoT challenges

AWS IoT Core, пожалуй, является наиболее значимым сервисом среди базовых сервисов Amazon, посвященных IoT. Он позволяет просто и безопасно подключать физические устройства к облаку, надежно их масштабировать и обеспечивает полное взаимодействие между устройствами IoT с их периферийным программным обеспечением и облачными сервисами AWS IoT, упомянутыми выше.

Чтобы начать работу с AWS IoT, давайте организуем пробное подключение тестового устройства, содержащего микроконтроллер, а также следующие датчики HDC1080 — (температура, влажность), BME280 — (давление), MH-Z19 — (CO2), CCS811 — (eCO2, tVOC) в AWS IoT Core для пробной передачи данных.

От переводчика: мне кажется, заголовок слегка неточный и на самом деле средний палец показали ребятам из MongoDB, которая теперь не очень то и Open Source.

Сегодня, Amazon AWS запустил продукт DocumentDB — новую базу данных, совместимую с API MongoDB. Компания описывает DocumentDB так — "быстрая, масштабируемая и отказоустойчивая документная база данных, разработанная так, чтобы быть совместимой с вашими существующими приложениями и инструментами на MongoDB". Фактически, это полная замена MongoDB, развёрнутая в AWS, которая не использует код MongoDB.

В AWS утверждают, что, хотя MongoDB отлично справляется со своими задачами, их клиентам всё же трудно создавать быстрые и высокодоступные приложения на платформе с открытым исходным кодом, которые смогут масштабироваться до нескольких терабайт и сотен тысяч операций чтения и записи в секунду. Поэтому компания создала свою собственную базу данных документов, но сделала ее совместимой с API MongoDB 3.6, распространяющимся под лицензией Apache 2.0.

Привет, Хабр! Сегодня продолжим разговор о возможностях, которые предоставляет нам Amazon Web Services и о том, как эти возможности использовать в решении прикладных задач.

На простом примере рассмотрим создание буквально за несколько минут собственного бессерверного автомасштабируемого REST API с разбором кейса — получения списка для ресурса.

Интересно? Тогда заходим под кат!


(Источник)

Долгое время в iFunny использовался Redshift в качестве базы данных для событий, которые происходят в сервисах бэкенда и мобильных приложениях. Его выбрали потому, что на момент внедрения, по большому счёту, не было альтернатив, сравнимых по стоимости и удобству.

Однако всё изменилось после публичного релиза ClickHouse. Мы долго его изучали, сравнивали стоимость, прикидывали примерную архитектуру и вот, наконец, этим летом решились посмотреть, насколько он нам полезен. Из этой статьи вы узнаете о том, какую проблему нам помогал решить Redshift, и как мы перенесли это решение на ClickHouse.

Если вы лениво следите за последними новостями, просматривая заголовки в своей ленте, то в течение последних двух лет вы сталкивались с пассажами примерно такого уровня: «Amazon борется с доминацией Intel и запускает производство своих серверных CPU», «Intel теряет значительную долю рынка», «Amazon отказывается от процессоров Intel», «В разработке находятся серверные ARM-процессоры от Amazon», «Intel переносит потребительский релиз 10 нм CPU» и наконец «Intel представит 7 нм процессор в 2020 году».

Конечно, заголовки эти весьма примерные и если вы не занимаетесь обслуживанием серверов или не арендуете мощности у AWS, то все это вас слабо касается. Ну барахтаются там гиганты между собой, как девицы на вечеринке лупят друг друга мешками, набитыми деньгами, при этом Qualcomm и AMD ведут каждый свою разработку, у NVIDIA какое-то движение с их CUDA, а Apple как обычно тихо в углу жует клей занимается своими делами. А еще создается впечатление, что скоро Intel свергнут, если уже не свергли (до сих пор сидят на 14 нм !), про электовафельницы от AMD перестанут шутить да и вообще, Amazon станет крупным производителем ARM-процессоров. Но все далеко не так, так что давайте разбираться.

Каждый раз, когда приходится читать про очередного новорожденного убийцу айфона или фейсбука, невольно начинаешь улыбаться. За эти годы столько их уже было, а воз и ныне там. Поэтому, наткнувшись на очередную публикацию, где ключевой мыслью была идея о том, что наступающая эпоха бессерверных вычислений приложений (Serverless) «съест» DevOps, скепсису не было предела.

На AWS re:Invent 2018, что проходит в эти дни в Лас-Вегасе, состоялся анонс Firecracker — новой технологии виртуализации с открытым кодом, основанной на Linux KVM. Авторы обещают, что с ней «в доли секунды можно запускать легковесные микровиртуальные машины (microVMs) в невиртуализированной среде, получив преимущества и традиционных ВМ — в виде безопасности и изоляции рабочих нагрузок, и контейнеров — в виде эффективного использования ресурсов».

Java является одним из самых популярных языков, используемых клиентами AWS, и мы стремимся поддерживать Java, сохраняя эту поддержку бесплатной. Многие наши клиенты стали беспокоиться о том, что они будут вынуждены платить за LTS-версию Java при выполнении своей рабочей нагрузки. В качестве первого шага мы недавно подтвердили долгосрочную поддержку Java в Amazon Linux. Однако, наши клиенты и более широкое Java-сообщество запускает Java на различных платформах, как на AWS, так и вне её. Вот почему мы рады анонсировать предварительную [preview] версию Amazon Corretto — бесплатного, мультиплатформенного и готового к использованию на продакшене дистрибутива OpenJDK от Amazon.

«Amazon имеет долгую и глубокую историю с Java. Я очень рад видеть, что работа нашей внутренней критически важной Java-команды становится доступной для остального мира»
— Джеймс Гослинг [James Gosling, создатель языка Java, работает в AWS с мая 2017 года]

Казалось бы, задача реализации фронтенда для AWS на nginx звучит как типовой кейс для StackOverflow — ведь проблем с проксированием файлов из S3 быть не может? На деле выяснилось, что готовое решение не так-то просто найти, и данная статья должна исправить эту ситуацию.

Зачем это вообще может понадобиться?

1. Контроль доступа к файлам средствами nginx — актуально для концепции IaC (инфраструктура как код). Все изменения, связанные с доступом, будут вноситься только в конфигах, которые лежат в проекте.
2. Если отдавать файлы через свой nginx, появляется возможность их кэшировать и сэкономить тем самым на запросах к S3.
3. Подобный прокси поможет абстрагироваться от типа хранилища файлов для разных инсталляций приложения (ведь помимо S3 существуют и другие решения).

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

Но люди, разбирающиеся в ИБ всегда знали: облачные сервисы намного более уязвимы, чем отдельная рабочая станция. Ведь в случае форс-мажорной ситуации ПК можно физически ограничить доступ в сеть, а там уже начинается гонка по смене явок и паролей на всех атакуемых направлениях. Облачная же инфраструктура огромна, зачастую децентрализована, а на одном и том же физическом носителе могут храниться данные нескольких клиентов, либо наоборот, данные одного клиента разнесены по пяти континентам, а объединяет их лишь учетная запись.

Короче говоря, когда интернет был сравнительно свеж и юн (а было это в 2003 году), тогдашние специалисты по информационной безопасности внимательно посмотрели на систему защиты от переполнения буфера 1997 года, и разродились технологией, которую сейчас мы называем Honeytoken или Canarytoken. И пятнадцать лет они исправно работали (и до сих пор работают), вот только последнее исследование говорит, что вместо последнего рубежа обороны в ряде сервисов AWS, Honeytoken превратился в зияющую дыру в ИБ из-за особенностей реализации на стороне Amazon.