Работа из учетной записи администратора, root оставьте для расчетов и проверки состояния счета, последнее рекомендую делать почаще, так как оплата производится за количество использованных ресурсов. Услуги Amazon, задействованые в данном хауту — в рамках бесплатного аккаунта, если вы самостоятельно не нажмете еще на какую-нибудь кнопочку в панели управления Amazon.
Нашему заказчику, одному из крупнейших мировых издательств, потребовалось увеличить производительность приложения для публикации видео новостей в связи с возросшим объемом трафика. Пользователи приложения — редакторы media-ресурсов. В день через него проходит порядка 200 новостных роликов, средний размер каждого из них ~ 500 мб, итого около 100 Гб свежих новостей в сутки.
Сегодня мы поделимся опытом, как CloudFront и S3 помогли нам построить высоконагруженную и устойчивую систему обработки контента.
Надеемся, наш опыт заинтересует разработчиков/проектировщиков систем по хранению и обработке медиаконтента (видео, аудио, изображения) и технических специалистов, активно использующим сервисы AWS.
В день запуска ботов в Telegram я за 3 часа собрал бота, который присылает температуру воздуха в ответ на геолокацию пользователя. С того же дня я бредил вызовом такси через бота в Telegram, так как API службы такси у меня был под рукой.
Моя цель – не просто рассказать, как я собрал бота для вызова такси, а поделиться этим процессом с другими, чтобы то время, которое я потратил на реализацию алгоритма не тратили остальные. Вследствие этой работы любая служба такси, при наличии API, может за 5 минут настроить шаблон этого бота под себя. Или владелец бота с большим количеством пользователей сможет быстро подключать к себе службу такси.
Очень полезный пост на 3 предложения, который, тем не менее, поможет сэкономить время и нервы.
Несколько дней назад, со мной случилась пренеприятнейшая штука: при попытке войти в AWS Console с домашнего компьютера, я увидел вместо списка сервисов — экран регистрации. Смешных картинок с моим фейсом не будет, вы и так понимаете ситуацию — проект в лайве. После нескольких попыток перелогиниться в режиме инкогнито и в других браузерах, ситуация оставалась прежней. Ничего кроме как завершить регистрацию мне не оставалось. После этого я получил — ТА-ДАМ — совершенно девственный аккаунт.
В первой части статьи мы описали одну из задач, с которой мы столкнулись при работе над публичным сервисом для хранения и анализа результатов биологических исследований. Были рассмотрены требования, предоставленные заказчиком, и несколько возможных вариантов имплементации на основе существующих продуктов.
Сегодня речь пойдет о решении, которое было воплощено.
Сегодня хочется рассказать об одной из типичных задач в области Cloud Computing и Big Data и подходе к ее решению, найденному нами в TeamDev.
Мы столкнулись с проблематикой BigData при разработке публичного сервиса для одной из компаний, занимающихся хранением и анализом результатов биологических исследований. Целью заказчика на очередном этапе стала визуализиция в реальном времени определенных срезов таких данных.
Почитав в свое время «Cloudmouse удалил все виртуальные сервера» и некоторые комментарии в стиле «сам виноват, надо было доверять проверенным облакам», решил поведать свою историю ужаса с весьма уважаемым облаком от Амазона (AWS). В подкасте радио-т я вкратце об этом рассказывал, но тут, как мне кажется, важны детали и впечатления от всего произошедшего кошмара.
Ни для кого сегодня уже не является секретом (или даже новостью) успех технологий контейнеризации в общем и платформы Docker, как успешного практического решения, в частности. Каждый, кто хотя бы раз попробовал упаковать своё приложение в контейнер, испытал это ощущения чисто детского счастья от понимания того, что вот она — упакованная и готовая к работе компонента, которая развернется где-угодно, в каких-угодно количествах и заработает там так же хорошо, как работала на компьютере разработчика. Деплоймент стал удовольствием, а не наказанием. «Гибкость» и «масштабируемость» перестали быть маркетинговой чушью из рекламных буклетов и стали реально достижимыми вещами. Писать микросервисы стало не просто «модно», но попросту логично и практично. Контейнеры навсегда изменили мир. (Была, тут правда, вчера мысль о том, что контейнеры — это зло, но в комментариях вроде бы разобрались, что не в контейнерах конкретно беда, а в общем подходе к безопасности)
Не прошло и 100 лет, как это заметила компания Amazon, выпустив в конце 2014-го в бету свой новый сервис — Amazon EC2 Container Service. Общий смысл сервиса — дать возможность разворачивать Docker-контейнеры удобным способом. «Удобным» — означает без необходимости углубляться во внутренности Docker, да и вообще делать что-либо руками в консоли хост-машины. Вы просто создаёте новый кластер, добавляете в него виртуалки, на которых будут работать контейнеры, а потом указываете сколько и каких контейнеров нужно запустить. Всё остальное (выбор на какой машине запустить контейнер, права доступа, проброс портов) Амазон берёт на себя. Кроме того, вы можете использовать из Docker-контейнера всю инфраструктуру Амазона — сохранять файлы на S3, пользоваться очередями SQS, прикрутить на входе амазоновский балансировщик нагрузки, а на выходе — амазоновские логи и сервисы аналитики. Контейнеры могут «видеть» друг друга, делиться (или не делиться) ресурсами, стартовать и быть остановленными из консоли AWS (вручную либо по заданным правилам).
Давайте попробуем что-нибудь запустить в Amazon EC2 Container Service. Например, поднимем Wordpress + Mysql.
Девять лет назад «Международный день телекоммуникаций» был переименован в «Международный день телекоммуникаций и информационного общества». Для золотого миллиарда будущее уже наступило: интернет стал одной из важнейших частей нашей жизни. Ежесекундно по всему миру создаются и потребляются колоссальные объёмы информации, а рынок всевозможных онлайн-сервисов является одним из самых быстрорастущих.
Одной из главных тенденций последнего времени стало развитие облачных технологий. Они используются повсеместно, от файлообменников и видеохостингов до мобильных приложений, сервисов заказа услуг и внутренних корпоративных систем. Подавляющее большинство подобных проектов оперируют неструктурированной информацией, причём ёмкость файловых хранилищ ежегодно увеличивается примерно на 53%. И с ростом объёмов генерируемой и хранимой информации трансформируются и требования к системам хранения данных.
Крупные игроки рынка облачных сервисов стараются занять доминирующее положение. При этом такие компании тратят миллиарды долларов в год на расширение мощностей своих дата-центров, с тем, чтобы поддерживать работоспособность собственных сервисов на высоком уровне. При этом бюджет таких проектов увеличивается год от года.
Лучше всего такая тенденция прослеживается на примере Amazon с их Amazon Web Services. Здесь все хорошо и с точки зрения затрат, и с точки зрения получаемого дохода. Так, в 2015 году выручка за первый квартал составила около $1,57 млрд. Это на 50% больше, чем за аналогичный период времени в прошлом году. Чистая прибыль — $265 млн. Доход компании за год, показанный в первом квартале 2015, составил $5,16 млрд.
Amazon S3 удобно использовать для хранения файлов любых форматов. Кроме удобного API получаем практически безразмерное хранилище. Отличная доступность и невысокая стоимость делают S3 мегапривлекательной для молодых и небольших проектов.
Однако со временем файлов становится все больше. А платить придется не только за новые данные, но за всю историю. Кроме этого, Amazon дерет деньги за GET и POST запросы, а также за трафик.
Несмотря на низкую стоимость на старте, с ростом это решение будет обходиться все дороже.
Компания Amazon заявила о том, что в дата-центре, обслуживающем Amazon Web Services, будут установлены аккумуляторные батареи Tesla. При этом речь идет о Западном регионе США. В ДЦ Amazon установит аккумуляторную систему Tesla в 4.8 мВт*ч.
Ранее компания Amazon объявила о намерении перейти на 100% обеспечение энергией из возобновляемых источников, включая солнечную энергию, ветровую и прочие виды «зеленой» энергии. Использование батарей Tesla — часть общего плана по этому проекту.
Уважаемые Хабражители, после экспериментов с самарским коворкингом и другими проектами, мы наконец решили начать писать что-нибудь для Хабра по основному виду нашей деятельности, то есть хостингу, серверам и связанным с этим технологиям. Для начала хотелось бы написать о популярных ныне среди разработчиков облачных ресурсах и сравнить основных игроков на этом рынке.
Вступление
Слово “облачный” хорошо известно всем владельцам сайтов. Облачные технологи предоставляются как сервис — есть доступ к ресурсам (оперативной памяти, процессору, устройствам хранения информации и т. д.), без указания, где конкретно в какой момент ресурсы эти ресурсы находятся.
«Облачность» предполагает возможность предоставления ресурсов с высокой гарантией их наличия. Иными словами, если аппаратные ресурсы на части физических компьютеров облака выйдут из строя или будут отключены, облако как целое может продолжать функционировать (в ряде случаев без существенной потери эффективности), или даже восстановить работоспособное состояние автоматически («самоизлечение», self-healing).
В случае, если есть необходимость выбора облачного провайдера, ниже предлагается список, с которого можно начать знакомство. Все они годятся в т.ч. для хостинга сайтов.
Часто зависая на Хабре и не только много раз ловил себя на мысли, что информация и статьи гораздо эффективнее воспринимаются с телефона или планшета, когда читаешь в удобной позе, или даже не дома — в транспорте, командировках, и т.п. Описание игр с напильником для оригинальной конвертации Хабрахабра в PDF-вариант для комфортного оффлайн чтения на электронной книге — скорее любопытный вариант эксперимента, где задействовано сразу несколько интересных сервисов и известных всем технологий: PHP, CURL, ajax, js, css.
Хочу поделиться скриптом для $subj. Возможно, кому-то он окажется полезен.
Постановка задачи: есть некоторое количество EC2-серверов в AWS, разбросанных по разным регионам. Требуется автоматизировать их резервное копирование так, чтобы восстановление было легким и быстрым.
В прошлой статье я рассказал о новой версии образовательного проекта Хекслет. В голосовании вы решили, что следующая статья будет о технической реализации платформы.
Напомню, Хекслет — это платформа для создания практических уроков по программированию в настоящей среде разработки. Под настоящей средой разработки мы подразумеваем полноценную машину, подключенную к сети. Эта важная деталь отличает Хекслет от других образовательных проектов (например, Codecademy или CodeSchool) — у нас нет симуляторов, все по-настоящему. Это позволяет обучать и обучаться не только программированию, но и работе с базами данных, серверами, сетью, фреймворками и так далее. В целом, если это запускается на Unix-машине — этому можно обучать на Хекслете. При этом, понимая это или нет, пользователи используют Test-Driven Development (TDD), потому что их решения проверяются юнит-тестами.
В этом посте я расскажу про архитектуру платформы Хекслет и инструменты, которые мы используем. О том, как на этой платформе создавать практически уроки — в следующей статье.
Перед нами стояла задача, обеспечить бесперебойную работу Staply, минимизировав затраты, сохраняя гибкость и простоту архитектуры.
В этой статье мы расскажем какую серверную конфигурацию используем в период перехода из закрытой беты в открытое использование. Период, когда вопрос стоимости стоит наиболее остро, так как есть нагрузка, но еще нет прибыли.
Время релиза моего проекта выходного дня приближалось. Мобильные приложения были загружены в магазины приложений и мы ждали ответа от Apple, поскольку проверка в Google Play проходит довольно быстро и безболезненно. Весь код серверного приложения был уже написан, делать было нечего, а свободного времени было около недели. Я подумал, что неплохо было бы заранее обзавестись load balancer-ом, чтобы в будущем не тратить много времени на его настройку, да и к тому же настройка после релиза наверняка привела бы к тому, что сервер какое-то время перестал бы обслуживать пользователей. Для хостинга серверов мы использовали Amazon EC2, поэтому и load balancer выбрали амазоновский — Amazon Elastic Load Balancer (ELB).
Как-то незаметно прошел анонс новой версии MongoDB. Изменение номера версии с 2 на 3 указывает на значительные изменения внутри базы данных. Разработчики заявляют о значительном увеличении производительности и улучшении маштабируемости. Немного подробнее под катом.
Почему выгодно продавать на Амазоне?
Интернет размыл границы между странами и континентами, позволяя вести бизнес из любой точки мира или покупать в интернете с любого материка. Вы можете, например, прямо сейчас купить в одном из 2000, расположеных по всему миру, интернет-магазинов сервиса, и получить кэшбэк за свою покупку, находясь при этом в России. Бессмысленно ограничиваться локальными рынками учитывая эти условия. Представляем вашему вниманию серию статей, посвященную e-commerce, из которой можно почерпнуть много нового о зарубежных рынках и механиках, которые там используются. Сегодня мы расскажем о том, как начать продавать на Amazon.
