В статье описан процесс миграции приложения. Миграция компонента уровня базы данных — это тема отдельной статьи. Конечно если Staging и Production окружение работают с одной базой данных, то априори Staging версия не должна содержать никаких breaking changes в базе данных. Ну или поддерживать хотя бы backward compatibility.
В вашем примере, я бы для staging использовал отдельную БД, и при необходимости синхронизировал данные из production, допустим с помощью того же SQL Server Agent или SQL Azure Data Sync. Да это накладно, однако на мой взгляд production нельзя ломать ни в коем случае.
К тому же, если уж пошел разговор для разделения окружений, то centur ниже совершенно правильно заметил, что если вы хотите разграничить окружения, то лучше будет сделать отдельный облачный сервис, либо вообще отдельную подписку. Такие решения как раз встречаются чаще в продакшене.
Статья лишь описывает средства, которые Microsoft предоставляет из коробки. Конечно в любой технологии есть свои подводные камни и скрытые фичи. Но возможность реализовать одну задачу разными способами — это преимущество.
Кстати, в следующей статье, я как раз опишу механизм, как сделать Zero Downtime для нескольких облачных сервисов, без использования Staging и Production слотов.
Подразумеваю, что «прогрев» приложение в staging окружении уже прошло. То есть оно работает и отвечается на запросы про URL: http://{guid}.cloudapp.net/. В случае свопа балансировщик (внутренний) просто перенаправляет запросы на новый адрес.
Однако, вы абсолютно верно заметили! Есть вариант организации балансировщика «in front». Об этом будет вторая часть — Traffic Manager.
Спасибо большое, Наталья! Комментарий специалиста Microsoft — очень важен. Могу лишь добавить, что вся информация по прайсингу может быть найдена здесь.
Нет, выполнить запрос «в целом» (через root) к сожалению нельзя. Вы должны сами объединить результаты одного запроса с другим. Вот кстати интересная ссылка на MSDN, где Microsoft описывает, о чем еще стоит подумать при работе с федерациями (раздел «Design Considerations»).
Каждый шард соответствует разному физическому серверу (если исходить из архитектуры SQL Azure). Действительно он выполнится на каждом шарде дважды, но быстрее. Я не говорю, что это плохо. Наоборот именно в этом и заключается преимущество горизонтального масштабирования. В примере, где будет разбиваться таблица Entity это плохо лишь потому, что данные одного пользователя могут оказать на разных шардах, а значит допустим получить список операций, которые он делал (Name, Description) придется с другого шарда, что для производительности не есть гуд.
Насколько мне известно, это необходимо все же делать руками. То есть средства позволяющего просто перетащить ползунок и сказать, что вместо 2-х шардов теперь хочу получить 8 нет. Возможно стоит организовать цикл вызова ALTER FEDERATION SPLIT.
Список действительно не адаптирован для СНГ. Не берусь утверждать, что абсолютно все приложения, но допустим тот же Mint Personal Finance в СНГ регионе недоступен. Ссылка.
Результаты исходного сравнения от cloudspectator.com можно посмотреть здесь.
Методика выбора виртуальных машин для сравнения непонятна. Выбираем виртуальные машины, приблизительно одного шейпа. На мой взгляд это игра в одни ворота. Как можно сравнивать 1 ядерный Amazon EC2 с 4-х ядерным HP Cloud. Если уж брать по честному, то лучше было бы сравнивать инстансы с одной стоимостью. К примеру до $0,35 за час вычислений. Вот тогда можно было бы сделать выводы, что за те же деньги вы получаете большое compute-ресурсов.
Думаю заказчика в первую очередь будут интересовать сколько денег он будет платить за конфигурацию, а не мегагерцы с мегабайтами. Все в жизни деньги. Это бизнес!
Несколько дней назад поставил на свой старенький SGS2 Nightly сборку (других просто нет) 10.1 от 19.07.2013. По сравнению со стоявшей до этого и дико глючившей MIUI 3.5.4 (тоже Nightly) + SiyahKernel S2-v5.0.1 просто небо и земля. Ощутимо батарею на стоковом ядре держит на 1 час дольше. Максимум при остатке в 6% батарея продержалась 1 день, 1 час, 14 минут и сколько-то там секунд (жаль скриншот не сделал). Думаю достойный показатель. При установке делал полный вайп data/cache/factory reset + battery stats. Вполне возможно что именно поэтому батарея объективно держит дольше.
Вообще CyanogenMod очень понравился своим минимализмом. Правда я бы предпочел, чтобы не было предустановленного Apollo, а при установке gapps добавлялся лишь один значок — Play Market (я сам хочу решать, что ставить, а что — нет). Но опять же все решается чисткой /system/app от ненужных apk файлов.
В общем на данный момент прошивка устраивает полностью. Весь софтверный стек работает идеально. Никаких тормозов/вылетов я не обнаружил. Неожидал такого от Nightly сборки.
На самом деле есть сторонние клиенты: InSync, Grive, Google Docs FS и другие. Сам использую консольный Grive, но конечно официальное приложение всегда лучше.
Да, скорее это касается дефотных прошивок. По опыту перезда на своем Galaxy S II. Каждый раз переезжая со стока на MIUI, потом, допустим, на CyanogenMod, а потом еще на что-то привыкаешь очень долго. Ну это конечно субъективные впечатления, можно поставить свою звонилку везде, но предпочитаю пользоваться встроенными.
Как долго у вас эти аппараты? Соглашусь с первым комментарием, что обзоров каждого из аппаратов уже довольно много. Может стоит сравнить их с точки зрения эксплуатации недели-две. То есть впечатления от недели-двух использования: удобно ли совершать звонки; писать/читать смс на солнце/ночью; приходили ли апдейты в период использования; наблюдались ли вылеты приложений/подтормаживания.
Начал разбираться с MongoDB на Windows Azure. Заметил что для Украины (может быть и для России тоже) доступен только Free план, ограниченный 500 Мб. Он называется Sandbox. Однако на сайте MongoLab есть упоминание обо всех планах, доступных в Windows Azure. Может я чего-то не доглядел? Как мне тогда допустим подписаться на план Single-Node. Это возможно?
На самом деле отчет в SQL Reporting представляет из себя по сути обычный SQL запрос, результаты которого оформлены с использованием HTML-разметки. Вот и все. Поэтому размер базы и не фигурирует в вычислениях. То есть один отчет — один запрос. В калькуляторе Windows Azure и при настройке SQL Reporting вы нигде не найдете упоминание о размере базы, которая указана в качестве Data Source для сервиса отчетов. Кстати, если интересует, могу поделиться Excel файлом с табличкой для подсчетов. Может быть вы что-то подскажите, что можно добавить.
1. Ну почему же неправильно? Давайте считать вместе. Стоимость одного часа вычислений виртуальной машины с SQL Server Standard (лицензия SQL Server уже включена в стоимость), размера Medium (2 ядра, 3,5 ГБ ОЗУ) составляет $0,73 (http://www.windowsazure.com/en-us/pricing/details/virtual-machines/). Умножаем на 24. Потом на 31 (а Microsoft отталкивается от 744 часов в месяц, то есть 24 часа умножить на 31 день). Получается: 0,73 * 24 * 31 = 543,12.
И почему тогда нет подсчета стоимости SQL сервера для Reporting Services?
Не совсем понял вопрос. Функционал SQL Reporting Services (SSRS) уже включен в стоимость SQL Server. Если же вы используете SQL Reporting как сервис (то есть не поднимаете виртуальную машину с SQL Server, а просто создаете endpoint для работы с функционалом SQL Reporting), то расчет уже идет по стоимости $0,16 за 30 отчетов в час.
2. Я думаю смысл и так понятен. Опять же. Я не хочу сказать, что SQL Reporting чем-то хуже и т.д. Оба решения имеют право на существование. К примеру, в стоимость SQL Server можно было бы включить зарплату maintenance engineer, который будет support-ить эту виртуальную машину. Тогда как в случае с SQL Reporting сервисами, все поддерживается Microsoft. Я думаю скорее будет уместно сказать, что если приложение генерирует большое количество отчетов за час, тогда скорее всего выгоднее будет поднять отдельную виртуальную машину, нежели использовать SQL Reporting.
В вашем примере, я бы для staging использовал отдельную БД, и при необходимости синхронизировал данные из production, допустим с помощью того же SQL Server Agent или SQL Azure Data Sync. Да это накладно, однако на мой взгляд production нельзя ломать ни в коем случае.
К тому же, если уж пошел разговор для разделения окружений, то centur ниже совершенно правильно заметил, что если вы хотите разграничить окружения, то лучше будет сделать отдельный облачный сервис, либо вообще отдельную подписку. Такие решения как раз встречаются чаще в продакшене.
Статья лишь описывает средства, которые Microsoft предоставляет из коробки. Конечно в любой технологии есть свои подводные камни и скрытые фичи. Но возможность реализовать одну задачу разными способами — это преимущество.
Кстати, в следующей статье, я как раз опишу механизм, как сделать Zero Downtime для нескольких облачных сервисов, без использования Staging и Production слотов.
Однако, вы абсолютно верно заметили! Есть вариант организации балансировщика «in front». Об этом будет вторая часть — Traffic Manager.
Не нужно никаких дополнительных утилит. Надеюсь поможет. =)
Насколько мне известно, это необходимо все же делать руками. То есть средства позволяющего просто перетащить ползунок и сказать, что вместо 2-х шардов теперь хочу получить 8 нет. Возможно стоит организовать цикл вызова ALTER FEDERATION SPLIT.
Методика выбора виртуальных машин для сравнения непонятна. Выбираем виртуальные машины, приблизительно одного шейпа. На мой взгляд это игра в одни ворота. Как можно сравнивать 1 ядерный Amazon EC2 с 4-х ядерным HP Cloud. Если уж брать по честному, то лучше было бы сравнивать инстансы с одной стоимостью. К примеру до $0,35 за час вычислений. Вот тогда можно было бы сделать выводы, что за те же деньги вы получаете большое compute-ресурсов.
Думаю заказчика в первую очередь будут интересовать сколько денег он будет платить за конфигурацию, а не мегагерцы с мегабайтами. Все в жизни деньги. Это бизнес!
Вообще CyanogenMod очень понравился своим минимализмом. Правда я бы предпочел, чтобы не было предустановленного Apollo, а при установке gapps добавлялся лишь один значок — Play Market (я сам хочу решать, что ставить, а что — нет). Но опять же все решается чисткой /system/app от ненужных apk файлов.
В общем на данный момент прошивка устраивает полностью. Весь софтверный стек работает идеально. Никаких тормозов/вылетов я не обнаружил. Неожидал такого от Nightly сборки.
Давайте вместе посчитаем. $0,25 за 1 ГБ. Первые 5 Гб — бесплатно. Получается: $0.25 * 1000 — ($0.25 * 5) = $248.75.
Опять же. Сервисы в данный момент находятся в состоянии «preview». Вполне возможно, что цена может опуститься.
Хотя опять же, согласно все тому же прайсингу:
1. Ну почему же неправильно? Давайте считать вместе. Стоимость одного часа вычислений виртуальной машины с SQL Server Standard (лицензия SQL Server уже включена в стоимость), размера Medium (2 ядра, 3,5 ГБ ОЗУ) составляет $0,73 (http://www.windowsazure.com/en-us/pricing/details/virtual-machines/). Умножаем на 24. Потом на 31 (а Microsoft отталкивается от 744 часов в месяц, то есть 24 часа умножить на 31 день). Получается: 0,73 * 24 * 31 = 543,12.
Не совсем понял вопрос. Функционал SQL Reporting Services (SSRS) уже включен в стоимость SQL Server. Если же вы используете SQL Reporting как сервис (то есть не поднимаете виртуальную машину с SQL Server, а просто создаете endpoint для работы с функционалом SQL Reporting), то расчет уже идет по стоимости $0,16 за 30 отчетов в час.
2. Я думаю смысл и так понятен. Опять же. Я не хочу сказать, что SQL Reporting чем-то хуже и т.д. Оба решения имеют право на существование. К примеру, в стоимость SQL Server можно было бы включить зарплату maintenance engineer, который будет support-ить эту виртуальную машину. Тогда как в случае с SQL Reporting сервисами, все поддерживается Microsoft. Я думаю скорее будет уместно сказать, что если приложение генерирует большое количество отчетов за час, тогда скорее всего выгоднее будет поднять отдельную виртуальную машину, нежели использовать SQL Reporting.
3. Этот пункт упомянул в предыдущем разделе.
Надеюсь я ответил на вопросы? =)