Amazon Web Services *

Перерыв в работе заставил меня задуматься над смыслом выражения "Сапожник без сапог". Будучи Java Backend Developer с 3-ех летним стажем я не имею на руках ни одного pet проекта. Конечно, на GitHub у меня есть какие-то мелкие проектики, но они не доведены до конца и кроме того как просто висеть на доске "почета" они больше ничего и не могут. С этой мыслёй я пошел в интернет гуглить "как мне задеплоить свое приложение?".

Скажу сразу, это статья содержит шаги по развертыванию Java приложения с помощью GitHub Actions на серверах AWS EC2 и это моя интрерпретация тех инструкций, которые я находил в интернете. Собственно это статья содержит для новичков, кто просто не делал никогда деплой своего приложения, но очень хочет в сжатые сроки похвастаться своим результатом.

Привет, Хабр. Вашему вниманию предлагается сокращённый перевод эпичного поста под авторством Энди Уорфилда, вице-президента и заслуженного инженера в компании Amazon, занятого разработкой S3. Пост основан на его пленарном выступлении с конференции USENIX FAST ‘23 и затрагивает три различных аспекта, касающихся выстраивания и эксплуатации такого огромного хранилища данных как S3. Если пост окажется интересным - рассмотрим вариант перевести и вторую часть

Это история о том, как мы сократили расходы на AWS на 80% всего за две недели.

Для разработчиков AWS — это Клондайк возможностей

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

Прежде, чем я начну своё повествование о процессе, хочу отметить, что выступаю не в качестве специалиста в области сервисов Amazon, а в качестве разработчика, которому пришлось в моменте столкнуться с технологией, и к сожалению, некогда было детально разбираться c довольно громоздкой панелью управления. Гайд подойдёт для тех, кто ещё не сталкивался с AWS, но хотел бы попробовать его для своих личных проектов, либо обучиться самим технологиям. Мы рассмотрим с вами создание простого пользователя IAM, необходимую конфигурацию для работы, и простой пример работы с библиотекой Boto3.

CI/CD-пайплайны автоматизируют процессы создания, тестирования и развертывания программного обеспечения, позволяя командам быстро и надежно выпускать обновления. В этой статье рассмотрим, как создать пайплайн с помощью AWS, как использовать CodeBuild для запуска при размещении кода в ветке. Также разберем, как запускать тесты, затем собирать и размещать образ Docker в ECR, и сохранять артефакты кода в S3, после чего можно использовать функцию Lambda для запуска CodeDeploy, которая развернет код на группе EC2-инстансов.

• Почему вывод наших нейрохудожников так отдаёт англичанкой.
• Как исторически связаны MidJourney, Stable Diffusion и ChatGPT?
• Как подружить AWS с русскими доменами, и чтобы всё за тебя сделала машина.

Сегодня под нашим скальпелем оказался проект AWS SDK для .NET. Мы посмотрим на подозрительные места из исходного кода, разберёмся, что в них происходит, и попробуем воспроизвести некоторые проблемы. Заваривайте кофе и устраивайтесь поудобнее.

Привет, Хабр! Меня зовут Сергей Дербуш, я архитектор в компании «СмартАп Технолоджи».

Это третья часть из цикла статей о SSP (Supply‑Side Platform). В предыдущих статьях мы рассказывали о том, как поднимали систему и как боролись с проблемой несоответствия. В этой статье коснемся архитектуры и того, как от ее выбора зависит стоимость трафика. Всех, кому данная тема интересна, жду под катом!

Привет, Хабр! В предыдущей статье мы рассказывали, как поднимали для клиента SSP (Supply‑Side Platform). В процессе напоролись на проблему несоответствия. 

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

Меня зовут Сергей Дербуш, я архитектор в компании «СмартАп Технолоджи». В этой статье расскажу о проблеме в общем, а также о подходах, которые мы использовали для ее решения.

Привет, Хабр! Я разработал помощника по поиску жилья HomeBro, который помог десяткам тысяч людей найти новый дом. Расскажу, с чем я облажался, а с чем – нет.

В 2019ом году я работал продактом в Яндекс.Погоде и подумывал, что было бы здорово запилить что-то свое. Начал смотреть, какие есть большие рынки и в чем их боль. Перебирая варианты, вспомнил, каким изнуряющим был для меня поиск съемного жилья. 

Идея управления серверной инфраструктурой через код (Infrastructure as Code, IoC) не нова. Управление настройками через скрипты или файлы конфигурации позволяет стандартизировать настройку системы, масштабировать решение, снизить ошибки и исключить “человеческий фактор”. Shell-скрипты или их прототипы существовали с момента создания компьютеров, а с появлением виртуальных машин стало возможно заскриптовать настройку сервера с нуля. Однако сегодня я хочу сконцентрироваться на кодировании именно облачной инфраструктуры. Это интересно, потому что облака вывели фреймворки по управлению инфраструктурой на принципиально новый уровень.

Связано это, в первую очередь, с подходом по предоставлению облаком конечному пользователю единого API с помощью которого можно управлять любым ресурсом или сервисом в нем. Таким образом у пользователя появились возможность создания подобных фреймворков. Последующий же рост и популяризация самих облаков создали спрос и на системы управления ими, что стимулировало большой сегмент IT индустрии инвестировать в это направление. 

Сегодня лидеры индустрии предоставляют 200+ сервисов которые работают на разных уровнях абстракции (IaaS, PaaS, SaaS), но все так же позволяют управлять всем через единый API. В данной статье я рассмотрю историю развития фреймворков для управления облачной инфраструктурой, выделив ключевые этапы и события, которые, по моему мнению, повлияли на их эволюцию.

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

AWS CloudFormation - это сервис, который помогает вам моделировать и настраивать ресурсы Amazon Web Services, чтобы вы могли тратить меньше времени на управление ими и больше времени уделять приложениям, которые работают в AWS. Вы создаете шаблон, описывающий все необходимые вам ресурсы AWS (например, экземпляры (инстансы) Amazon EC2 или Amazon RDS DB), а AWS CloudFormation позаботится о предоставлении и настройке данных ресурсов за вас.

Эта заметка является переводом поста в блоге Дэвида Ханссона под заголовком «Even Amazon can't make sense of serverless or microservices». Здесь минимум редактуры для сохранения оригинальной авторской подачи.

Команда Prime Video из Amazon опубликовала довольно примечательное тематическое исследование, посвящённое их решению отказаться от своей микросервисной serverless-архитектуры и заменить её монолитом. Этот шаг сэкономил им ошеломляющие 90% (!!) эксплуатационных расходов, а также упростил систему. Какая победа!

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

В Prime Video мы предлагаем нашим клиентам тысячи прямых трансляций. Чтобы гарантировать, что клиенты беспрепятственно получают контент, Prime Video создала инструмент для мониторинга каждого потока, просматриваемого клиентами. Этот инструмент позволяет нам автоматически выявлять проблемы с качеством воспринимаемого контента (например, повреждение блока или проблемы с синхронизацией аудио / видео) и запускать процесс их устранения.

У нашей команды анализа качества видео (VQA) в Prime Video уже был инструмент для проверки качества аудио / видео, но мы никогда не планировали и не проектировали его для масштабной работы (нашей целью было отслеживать тысячи одновременных потоков и увеличивать это число со временем). Подключая к сервису больше потоков, мы заметили, что масштабная эксплуатация инфраструктуры обходится очень дорого. Мы также заметили узкие места в масштабировании, которые мешали нам отслеживать тысячи потоков. Итак, мы сделали шаг назад и пересмотрели архитектуру существующего сервиса, сосредоточив внимание на стоимости и узких местах масштабирования...

Я стал большим сторонником DynamoDB за последние несколько лет. Эта база данных имеет много сильных сторон, которых нет у конкурентов, таких как гибкая ценовая модель, соединение без состояния (stateless), которое прекрасно работает для беcсерверных (serverless) вычислений, и постоянное время ответа, даже когда ваша база данных масштабируется до огромных размеров.

Однако разработка структуры данных с помощью DynamoDB вызывает трудности у тех, кто привык к реляционным базам данных, которые доминировали в течение последних нескольких десятилетий. Существует несколько особенностей в создании структуры данных с помощью DynamoDB, но самая значимая - это рекомендация от AWS использовать одну таблицу для всех ваших записей.

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

Привет, я, Петер Ибрагимов, и в Whoosh я занимаюсь бекенд разработкой на Python. В этой статье расскажу, как мы делаем наши микросервисы на лямбдах. 

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

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

Организации должны быть уверены в том, что их системы способны справляться с проблемами производительности и простоев. В некоторых случаях вызов внешнего API может быть связан с дополнительными расходами, такими как плата за лицензию. Если с поставщиком внешнего API заключен контракт о соблюдении максимального RPS (количества запросов в секунду), система должна соответствующим образом адаптироваться.

В этой посте мы покажем вам, как будет выглядеть архитектура для вызова внешнего API с помощью AWS Step Functions, с упором на надежность.

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