Однажды в Edison Software приехал мужик на гелике. Взглянув на счет, он прищурился и воскликнул: «Почему так дорого?! Я же бедный!». Это стало крылатой фразой и меткой для целого класса проектов. Итак, нам потребовалось реализовать автоматическое обновление для службы Windows, при этом соблюсти нижеследующие условия.
Вчера Github объявил о добавлении AWS Educate в набор бесплатно предлагаемых инструментов и сервисов для студентов. Отныне все студенты, зарегистрированные в программе Github Education, получают в пользование такие инструменты как: БД, cloud-computing, анализ данных и многое другое.
В рамках программы предоставляется доступ к учебной информации, включающей в себя: лабораторные / домашние работы и портал для студентов. Каждый студент получает 35$ (100$ для вузов, зарегистрированных в программе) + бонус в размере 15$ от github, которые можно потратить на оплату счетов AWS. Итого можно получить до 115$ гранта.
Найден быстрый и бесплатный способ решения проблемы сетевой установки GitHub for Desktop for Windows.
Суть в том, во время установки в Windows GitHub for Desktop использует S3 Amazon services, и технологию ClickOnce, однако при установке у меня часто возникали разрывы соединения, зависания, при которых установка продолжалась с ошибкой.
Теплым летним вечером, в процессе разработки очередного приложения для iOS, у меня совпало два фактора — возникла необходимость реализации Apple Push Notification (APN) и желание попробовать что-то совсем новое для меня. Идти проторенной дорогой через один из множества сервисов, предлагающих отправку APN не хотелось.
Для изобретения велосипеда был выбран Amazon Simple Notification Service (Amazon SNS). Amazon SNS — это сервис, который позволяет вам отправлять сообщения-нотификации, посредством разнообразных механизмов (APN, GCM, e-mail, SMS и т.д.).
О том, как это работает и более подробную информацию можно прочитать в документации Amazon. Я расскажу совсем немного, чтобы определиться с дальнейшей терминологией. У SNS есть два типа клиентов — публикаторы (publishers) и подписчики (subscribers). Публикаторы с подписчиками асинхронно обмениваются сообщениями (messages), которые доставляются подписчикам, посредством разнообразных механизмов. Для отправки групповых сообщений подписчики могут быть сгруппированы по темам (topics). Тогда все подписчики, подписанные на тему, получат сообщение в эту тему отправленное.
Если вы серьёзно используете AWS (Amazon Web Services), то наверняка знаете про возможность описать инфраструктуру с помощью JSON шаблонов. В AWS этот сервис называется CloudFormation. По сути это решение позволяет вам описать желаемое состояние любых ресурсов, доступных в AWS (инстансы, слои opsworks, ELB, security groups и т.д.). Набор ресурсов называется стеком. После загрузки CloudFormation шаблона система сама либо создаст необходимые ресурсы в стеке, если их ещё нет, либо попытается обновить существующие до желаемого состояния.
Это хорошо работает если у вас есть небольшое количество ресурсов, но как только инфраструктура разрастается появляются проблемы:
В JSON нет возможности использовать циклы и для похожих ресурсов приходится повторять одни и те же параметры и в случае изменения тоже (не DRY)
Для записи конфигурации для cloud-init нужен двойной escaping
В JSON нет комментариев и он имеет плохую человеко-читаеммость
Для того чтобы избежать подобных проблем инженеры из Heavy Water написали на ruby DSL и CLI для генерации и работы с этими шаблонами под названием SparkleFormation (github).
У компании Amazon, а точнее, у ее облачного подразделения AWS — одна из наиболее быстро развивающихся, развернутых и совершенных инфраструктур. Как мы уже писали, не так давно компания открыла некоторые свои секреты, касающиеся принципов организации работы этой инфраструктуры. Во второй части — информация о том, где размещаются дата-центры, каким образом все это связано в одну систему, и как работает.
Сейчас в распоряжении Amazon Web Services — минимум 30 дата-центров, причем руководство планирует построить дополнительно 10 или 15 новых. Большинство дата-центров размещаются в северной Вирджинии, здесь за работу AWS отвечает примерно 20 дата-центров, общей мощностью примерно в 500 МВт. Но география инфраструктуры дата-центров AWS не ограничена только лишь Вирджинией. Сейчас три крупных кампуса ДЦ строится в Огайо, плюс облачные дата-центры работают еще в Ирландии, Бразилии, Китае, Японии, Австралии и Сингапуре.
Облаков в Таиланде довольно много, и это не фигуральное выражение — здесь действительно часто идут дожди, особенно в сезон муссонов. Наиболее активно природа проявила себя в 2011 году, когда в Таиланде случилось масштабное наводнение, вызванное непрекращающимися в течение долгого времени ливнями. На Таиланде, как известно, много фабрик по производству жестких дисков и накопителей иных типов — и как раз эти фабрики, в большинстве, и были затоплены в 2011 году. Тогда цены на жесткие диски повысились, цепи поставок винчестеров тем, кто в них нуждается, были нарушены.
Облачное подразделе компании Amazon прочувствовало на себе влияние стихии больше, чем многие другие компании. Так, дата-центры Amazon Web Services на некоторое время остались без необходимого оборудования, что привело к некоторыми проблемам в работе AWS. Обо всем этом на недавнем мероприятии «re:Invent» рассказал вице-президент AWS по инфраструктуре Джерри Хантер.
Через неделю после выхода предыдущей статьи, где я рассказывал о сборке бота для Telegram, ко мне за консультацией обратился интернет-магазин наручных часов, который к тому моменту уже построил некоторые процессы для своих нужд. При росте бизнеса они столкнулись с проблемой обработки большого количества входящих заявок, а от быстрой реакции на заявку зависит, купит человек продукт или нет.
Здесь я опишу их кейс оптимизации процессов интернет-магазина с помощью Corezoid.com и дам в открытый доступ ссылку на шаблон процесса, описанного ниже.
Что необходимо сделать:
1) Добавить лид в CRM (в данном случае это Bitrix24) c заполнением всех необходимых дополнительных полей.
2) Уведомить продавцов о пришедшем лиде или ошибке.
3) Уведомить клиента об успешно принятом заказе, а так же рассказать о дополнительной акции (попытаться подогреть клиента, повысить средний чек).
На входе имеем:
1) Имя и телефон клиента, которого заинтересовал наш товар.
2) Определенный по ip город клиента.
3) Таймзону клиента.
4) Идентификатор партнера (реф-ссылка в cookies), от которого пришла заявка.
Решением стало связка API нескольких сервисов через Corezoid.com, а именно: Bitrix24 (СRM-система) + VoxImplant (сервис для реализации обратного вызова) + Telegram (messenger).
Как помнят самые внимательные из вас, мы работаем над инновационной книгой о микросервисах, но в то же время не забываем читать, что пишут в Сети на эту тему. Поэтому не смогли пройти мимо интереснейшей статьи из блога Amazon, автор которой Тим Вагнер делится своими взглядами на микросервисную архитектуру.
Много Java, JavaScript, схем, рассуждений и очень много текста
В прошлой статье был рассмотрен пример настройки автоматической выгрузки данных из Яндекс Метрики. Это облегчает регулярную выгрузку, но способ получается полуавтоматическим: надо запускать скрипт, копировать результаты выгрузки к себе и дальше заниматься их оформлением. Посмотрим как можно сделать процесс полностью автоматическим. Для примера будем использовать выгрузку данных их рекламной системы Adfox.
Adfox имеет много готовых отчетов, однако даже простые усложнения требований к отчетности вызывают проблемы. Есть опция настройки регулярных отчетов, однако в большинстве случаев приходится настраивать комбинации выгрузок самому.
В этой статье показано как сделать скрипт, который выгружает CTR всех баннеров, которые доступны аккаунту (сделать это вручную нереально по времени). А также как отобразить это на графике в виде простой HTML-страницы. Т. е. мы последовательно просмотрим все кампании и флайты, возьмем показы и клики по всем баннерам и нарисуем график CTR. Как и в прошлой статье работать будем на инстансах Amazon Web Services, чтобы было универсально и главное бесплатно. Выгрузка данных на PHP, графики рисуем в Highcharts. В коде реализован самый простой способ выгрузки и обработки данных без каких-либо улучшений. В итоге получим ежедневно обновляемую за вчерашний день страницу вида:
В своей практике работы аналитиком мне часто приходится сталкиваться с ситуациями, когда коллеги ежедневно тратят много времени на нудную выгрузку данных для очередной отчетности. Если для Google Analytics и других продуктов Google написано множество плагинов, сервисов и надстроек для Excel, то для Яндекс Метрики и других аналитических систем удалось найти только пару-тройку библиотек 2013 года.
При работе с рекламными системами типа Adfox ситуация не менее «тяжелая». Многочисленные выгрузки вручную могут со временем вогнать в депрессию кого угодно, совершенно не оставив времени на полезную часть этого действия: анализ и выводы на основе этих данных. Иногда выходом является обращение за помощью к разработчикам, которые могут помочь с настройкой выгрузки необходимых данных. Однако на практике требования к отчетам часто меняются, а постоянно дергать разработчиков не получится.
В этой и следующих статьях я покажу как с помощью Amazon Web Services просто настраивать автоматическую выгрузку данных. На AWS можно в течение 12 месяцев пользоваться бесплатным аккаунтом, в лимиты которого входит описанный в статье алгоритм. Можно выбрать и любой другой сервис аренды вычислительных мощностей, однако совсем бесплатных я не встречал. К тому же на инстансах AWS уже есть питон с нужными библиотеками.
Работа из учетной записи администратора, 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%. И с ростом объёмов генерируемой и хранимой информации трансформируются и требования к системам хранения данных.
