Работаем над видео =) нет предела совершенству подямали мы и решили немного «домонтировать» видео. Друзья, все будет! Очень много получили вопросов про первое видео, и это нас радует и воодушевляет! Не судите строго, пожалуйста =)
И не говорите :) в ТЗ нашем изначально было, но не все из ТЗ иногда доживает до продакшена =) была бы, конечно, приятность, но для идеи проекта не критично, поэтому чтобы не опоздать к намеченному сроку :)
Ринат, а что имеете в виду? С точки зрения разработки в Android L не так много поменялось, если говорить об основах (ведь если для начинающих, то как раз про основы), если говорить про визуальную составляющую, то да, изменения есть. Поясните, пожалуйста, чтобы лучше нам представлять. Спасибо.
Спасибо за развернутый отзыв, учитывая интерес к теме, соберу в n-ый период отзывы и направлю в соответствующих канал внтури.
Что касается ручной (именно ручной, тк понимаю, что она имелась с виду) премодерации, то здесь тоже есть свои плюсы и минусы (например, какой начинается процесс для обычного приложения при ручной модерации, если требуется исправить срочно выявленный баг). Но именно анализ и отзывы помогают идентифицировать востребованность фичи и узкие места. Консолидированные фидбэки учитываются и анализируются (в сочетании со внутреннимм метриками стора), поэтому они действительно важны, даже если изменения и не появятся сиюминутно. Думаю, что все разработчики точно представляют процедуру change management'а.
Все случаи индивидуальные, тк. любое приложение — это свой маленький мир, часто не только изолированный в пределах стора (имею в виду, что приложение может быть расширением онлайн или оффлайн бизнеса; а может быть просто казуальной игрой без монетизации или с моентизацией средствами рекламы). С другой стороны, отзыв Ваш понятен. Я постараюсь подготовить статью на эту тему, хотя сразу скажу, что об основных моментах будет рассказано, с одной стороны, которые большую часть аудитории могут затронуть, с другой стороны — наиболее легко проверяемых и отслеживаемых. Спасибо за отзыв.
Использование в проекте сервиса (в данном случае подразумеваю любую облачную платформу как конечный сервис для той системы, которую создаете) отличается от привычного ранее использования в системе коробочного ПО и серверов. Конечно, увеличение ресурсов в ответ на нагрузку и ранее всегда планировалось для систем, но обычно планировалось немного в другом ключе — не мгновенный ввод дополнительных серверов, а скорее заранее создание фермы, по которой равномерное распределяется нагрузка (с невысокой утилизацией каждого отдельного узла, а как только утилизация приближается к 70%-75%, то обычно вводятся n-новых узлов «на последующий рост»). В облаке же схема другая, и она иногда порождает свои интересные вещи. Но здесь есть и плюсы, тк с подобной проблемой в традиционной серверной модели можно бороться (и искать ее) очень долго и иногда единолично (хотя и существует референсные дизайны архитектур, тк. конфигурации практически разные у всех, особенно в связке железо + ПО). А в облаке провайдер этого облака видит целостную картину ото всех клиентов, которые используют сервисы. И выявить (и отследить, тк железо в ЦОДе если не одинаковое, тк существуют разные поколения, то точно соответствует ожиданиям и спецификации) аномалию становится зачастую проще =) и устранить их тоже, соответственно.
Да, все верно. Для Azure IP может быть Microsoft Account (LiveID), либо Azure AD (это как раз Organizational Account, о котором говорится в данном руководстве).
Что касается интеграция, то можно попробовать опосредованно. Т.е. сценарий такой: настраивается синхронизация между Вашей локальной AD и Azure AD. Пароли могут в Azure AD не хранится, а при настройке синхронизации можно выбрать только одностороннюю (из Вашей AD в Azure AD).
Если интеграция Вашего IP с локальной AD предполагает, что при запросах приложения прост «берутся» дополнительные данные из системы вашего IP, то описанный выше сценарий, как я понимаю, не подойдет.
Цены на базовые сервисы (хранилище, стандартные виртуальные машины, исходящий трафик) у основных провайдеров публичного облака паритетные. Например, цены Amazon здесь, Azure — здесь (обратите внимание, что с 1 мая цены на LRS хранилище будут снижены на 65%; пока в табличке старые цены, т.к. 30 апреля), цены Google Cloud Storage — здесь.
Но опять же, хранилище бывает разным: например, локально отказоустойчивым (3 реплики в пределах одного ЦОД; гео-отказоустойчивым — плюс к трем репликам в одном ЦОД еще 3 асинхронные реплики в соседнем и т.п.). Кроме того, иногда облачные провайдеры предоставляют скидки за «пакетное» приобретение услуг. У Amazon есть предложение для виртуальных машин — Reserved Instances на срок от 1 года, кажется. У Azure, на мой взгляд, есть более привлекательная схема — 6-month или 12-month планы (подробнее здесь), по которым получается скидка от 20% на любые ресурсы (виртуальные машины, хранилище и т.п.); при этом этим планы не означают, что должна быть выполнена предоплата (предоплата просто дает еще дополнительную скидку 2,5%).
Т.е. итоговая стоимость и «выгодность» будет зависеть от многих показателей: соотношение производительность\цена; дополнительные (не базовые сервисы), которые будете использовать; выбранный план\схема оплаты; сэкономленное время на программирование\администрировании\разворачивании отказоустойчивой конфигурации и т.п.
Могли бы Вы пояснить задачу? Что подразумевается под ролью Azure как service provider'а?
Azure Active Directory поддерживает (реализует) SAML 2.0 Web Browser SSO схему. Можно реализовать схему, когда приложение (service provider) будет предоставлять доступ через Azure AD. Есть уже встроенная интеграция со многими SaaS-сервисами, например, можно выполнить интеграцию с DropBox.
Правда, кажется, что пока Azure AD не поддерживает SSO, инициированное service provider'ом (дискуссия на StackOverflow). Сама не проверяла.
Спасибо за приложение и статью, особенно сравнение с тем, как было сделано приложение прошлых игр, является полезным! Еще бы из технических деталей хотела заметить, что облачная платформа Windows Azure использовалась для предоставления информации для всех мобильных устройств! А также облачная медиа платформа Windows Azure Media Services использовалась для online вещания 204 видео-каналов видео (NBC вещание на 22 страны).
Подробнее в официальных пресс-релизах здесь (RU) и здесь (EN). В первой статье еще цифры по нагрузке на сам сайт игр. Но здесь от себя могу сказать, что я пользовалась только мобильным приложением и на сайт не заходила. В мобильном приложение было все, что мне требовалось!
Подскажите, пожалуйста, а каков алгоритм определения, что Master скорее мертв, чем жив, т.е. не отвечает. В каком режим происходит переключение (с точки зрения приложения, использующего такую схему)? Спасибо.
Спасибо за цикл статей. Хотела бы уточнить «Windows Azure Media Services берет деньги за кодирование видео и за его трансляцию в режиме Live, а Amazon Elastic Transcoder – только за кодирование.» Windows Azure Media Services «берет деньги» за исходящий трафик при трансляции (Amazon ровно тоже «берет» за исходящий трафик), по умолчанию, есть режим shared, который именно как трансляция бесплатный, но при этом канал может делиться между несколькими потоками (клиентами), платным является зарезервированная полоса (200 Mbps) — Reserved Unit (которых может быть несколько). Кроме того, на данный момент Media Services предоставляют публично только VOD, появление Live очень-очень ждем =)
По поводу этого пункта смотрите Windows Azure Customer PCI Guide, стр. 6 — 1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.. Большая часть подпунктов требования покрывается платформой.
На всякий случай для тех, кто не сталкивался с PCI DSS. Аттестация PCI DSS любой облачной платформы автоматически не означает, что развернутая на ней система получает тот же уровень сертификации. Это означает, что на облачной платформе можно строить системы, которые смогут (при выполнении системой требований) пройти такую сертификацию. В облаке вы не можете на все влиять, поэтому и требуется аттестация самой облачной платформы, чтобы гарантировать выполнения определенных пунктов требований (на которые может влиять только облачный провайдер). Windows Azure и подтвердила, что требования выполняются.
Ясно, спасибо. Есть Web Sites, которые предоставляют три модели Free\Shared\Standard. По сути, Standard аналогичен веб-роли с точки зрения цены, а Free\Standard дешевле и могут подходить для определенных задача. Так, на будущее :)
«Прогноз платежа за использование ресурсов Azure составил 5000 рублей в месяц». Если можете то, пожалуйста, поясните, как такие расчеты получились. Например, у Windows Azure Web Sites, на которых можно разместить Node.js приложение, есть решим Free, т.е. 0$\месяц. Если режима этого не достаточно, то есть Shared (~$10\месяц). Для небольших проектов и сайтов оба режима подходят и часто применяются.
Лично меня радует то, что теперь можно HTML5 загрузчик написать и напрямую в BLOB файлы заливать! И не надо никакой масштабировать промежуточный слой, т.к. BLOB служба сама за это отвечает и это ее работа.
Немного не в тему CORS, но тоже в BLOB жутко порадовало — появилась поддержка Content-Disposition!
Что касается ручной (именно ручной, тк понимаю, что она имелась с виду) премодерации, то здесь тоже есть свои плюсы и минусы (например, какой начинается процесс для обычного приложения при ручной модерации, если требуется исправить срочно выявленный баг). Но именно анализ и отзывы помогают идентифицировать востребованность фичи и узкие места. Консолидированные фидбэки учитываются и анализируются (в сочетании со внутреннимм метриками стора), поэтому они действительно важны, даже если изменения и не появятся сиюминутно. Думаю, что все разработчики точно представляют процедуру change management'а.
Использование в проекте сервиса (в данном случае подразумеваю любую облачную платформу как конечный сервис для той системы, которую создаете) отличается от привычного ранее использования в системе коробочного ПО и серверов. Конечно, увеличение ресурсов в ответ на нагрузку и ранее всегда планировалось для систем, но обычно планировалось немного в другом ключе — не мгновенный ввод дополнительных серверов, а скорее заранее создание фермы, по которой равномерное распределяется нагрузка (с невысокой утилизацией каждого отдельного узла, а как только утилизация приближается к 70%-75%, то обычно вводятся n-новых узлов «на последующий рост»). В облаке же схема другая, и она иногда порождает свои интересные вещи. Но здесь есть и плюсы, тк с подобной проблемой в традиционной серверной модели можно бороться (и искать ее) очень долго и иногда единолично (хотя и существует референсные дизайны архитектур, тк. конфигурации практически разные у всех, особенно в связке железо + ПО). А в облаке провайдер этого облака видит целостную картину ото всех клиентов, которые используют сервисы. И выявить (и отследить, тк железо в ЦОДе если не одинаковое, тк существуют разные поколения, то точно соответствует ожиданиям и спецификации) аномалию становится зачастую проще =) и устранить их тоже, соответственно.
Что касается интеграция, то можно попробовать опосредованно. Т.е. сценарий такой: настраивается синхронизация между Вашей локальной AD и Azure AD. Пароли могут в Azure AD не хранится, а при настройке синхронизации можно выбрать только одностороннюю (из Вашей AD в Azure AD).
Если интеграция Вашего IP с локальной AD предполагает, что при запросах приложения прост «берутся» дополнительные данные из системы вашего IP, то описанный выше сценарий, как я понимаю, не подойдет.
Но опять же, хранилище бывает разным: например, локально отказоустойчивым (3 реплики в пределах одного ЦОД; гео-отказоустойчивым — плюс к трем репликам в одном ЦОД еще 3 асинхронные реплики в соседнем и т.п.). Кроме того, иногда облачные провайдеры предоставляют скидки за «пакетное» приобретение услуг. У Amazon есть предложение для виртуальных машин — Reserved Instances на срок от 1 года, кажется. У Azure, на мой взгляд, есть более привлекательная схема — 6-month или 12-month планы (подробнее здесь), по которым получается скидка от 20% на любые ресурсы (виртуальные машины, хранилище и т.п.); при этом этим планы не означают, что должна быть выполнена предоплата (предоплата просто дает еще дополнительную скидку 2,5%).
Т.е. итоговая стоимость и «выгодность» будет зависеть от многих показателей: соотношение производительность\цена; дополнительные (не базовые сервисы), которые будете использовать; выбранный план\схема оплаты; сэкономленное время на программирование\администрировании\разворачивании отказоустойчивой конфигурации и т.п.
Azure Active Directory поддерживает (реализует) SAML 2.0 Web Browser SSO схему. Можно реализовать схему, когда приложение (service provider) будет предоставлять доступ через Azure AD. Есть уже встроенная интеграция со многими SaaS-сервисами, например, можно выполнить интеграцию с DropBox.
Правда, кажется, что пока Azure AD не поддерживает SSO, инициированное service provider'ом (дискуссия на StackOverflow). Сама не проверяла.
Подробнее в официальных пресс-релизах здесь (RU) и здесь (EN). В первой статье еще цифры по нагрузке на сам сайт игр. Но здесь от себя могу сказать, что я пользовалась только мобильным приложением и на сайт не заходила. В мобильном приложение было все, что мне требовалось!
На всякий случай для тех, кто не сталкивался с PCI DSS. Аттестация PCI DSS любой облачной платформы автоматически не означает, что развернутая на ней система получает тот же уровень сертификации. Это означает, что на облачной платформе можно строить системы, которые смогут (при выполнении системой требований) пройти такую сертификацию. В облаке вы не можете на все влиять, поэтому и требуется аттестация самой облачной платформы, чтобы гарантировать выполнения определенных пунктов требований (на которые может влиять только облачный провайдер). Windows Azure и подтвердила, что требования выполняются.
Немного не в тему CORS, но тоже в BLOB жутко порадовало — появилась поддержка Content-Disposition!