Цель этой статьи не рассказать детально о каком-то сервиса еще раз, а сделать классификацию сервисов Azure для разработчиков, краткое описание, указать границы применения этих серверов.
Как я вижу Azure для разработчиков (DEV/OPS team):
Developer Services
Visual Studio Online
VSO- это TFS вынесенный из onpremise в cloud. (TFS это наша система по управлению проектом, исходным кодом, ведения задач, тестирование, автоматической сборкой и развертыванием. Т.е. система покрывает весь процесс разработки). Его функционал обновляется быстрее чем TFS (раз в месяц примерно), и кроме этого отличий очень мало.
Application Insights
AI- это система мониторинга приложений(мобильных-веб.) В ваш код вы встраиваете вызовы на подобии ILogger.Write и на выходе получаете на Azure портале кучу красивых графиков. Это может быть посещаемость страниц сайта, или время, проведенное на экране мобильного приложения.
Сам AI достаточно умел, к примеру- если пользователь пользуется вашим мобильным приложениям без интернета, AI будет писать в буфер и при появлении интернета, отправит все массово на сервер. Вам при этом ничего дополнительно написать не нужно.
Web
- Azure Web Apps (бывшие Web Sites).
- Web Role в Cloud Service.
- Virtual machines, в которых можно развернуть и веб сайты.
Virtual Machines — Работы с виртуальными машинами- самая привычная для разработчиков, т.к. они мало чем отличаются от того, что разработчик использует onpremise и знаний Azure по сути не требует.
Web Apps — самый правильный с точки зрения дизайна масштабируемости и простоты вариант. Единственный минус- слабая интеграция с virtual network. Т.е. этот вариант рассчитан на внешний доступ, а не на доступ из корпнета. Писать можно на .net/java/node.js/php.
Web Role — это самый старый вариант хостинга, который появился еще в самой первой публичной версии Azure в далеком 2008 году. В те времена, мы рекомендовали переписывать свои приложения под Web Role. Сейчас такой рекомендации нет. Единственным преимуществом перед веб сайтами является- интеграция с virtual network.
Кроме основных, есть еще и несколько дополнительных сервисов связанных с web.
API Management
(смысл которого мало кто поймет в корпоративном секторе).Его идея в том, чтобы забрать на себя рутинные функции при написании API и оставить разработчику- только то, что приносит business value.
Сервис на себя берет функции единой точки входа, и перенаправлять запросы к десяткам разных сервисов. В нем можно вести документацию к методам. Можно считать число вызовов, создать тарифные планы, проводить конвертацию форматов, авторизацию и т.п. А разработчику остается писать код сервиса, который и несет основную ценность для пользователя.
Compute
Давайте пойдем методом исключения, нишевых сервисов.
Media Encoding-из названия понятно, что это сервис умеет конвертировать видео, но заодно помогает делать стриминг видео, помогает его шифровать, защищать от не разрешенного распространения. Этот сервис не только про видео, но он прекрасно работает с аудио. Это очень специализированное решение.
Упорядочим оставшиеся сервисы в порядке возрастания сложности.
Virtual Machine – Cloud Server Worker Role – Batch – HDInsight
- Virtual Machine — тут все понятно. Размеры от 1 ядра до 32, различный объем памяти до 448GB, различные интерконннекты (Infiniband – быстрый коннект, который используется в кластера-суперкомпьютерах), и недавно анонсировали графические ускоритель на базе NVidea Cuda.
- Cloud Service Worker Role — Этот вариант проще чем виртуальная машина, легче масштабируется. По мощности (если не учитывать специфичные сценарии типа работа с сетью или наличие графического ускорителя) – не уступает виртуальным машинам. Мы не занимается управлением ОС, просто оборачиваем наш код в Worker Role.
- Batch Это такой более простой чем HDInsight сервис, но при этом потенциально более мощный чем VM и Worker Role. В сервисе Batch уже встроена система журналирования задач, мониторинга ресурсов, очередей задач и т.п.
- HDInsight– реализация на нашей платформе Hadoop (который реализует MapReduce). Родная платформа для Hadoop-это Linux. Этот сервис стоит использовать, когда мы перемалываем действительно Big Data… Это не про гигабайты в день, с ними прекрасно справятся пара виртуальных машин…. Это про регулярную обработку терабайтов и более. Большая часть того, что у нас принято называть Big Data, таким не является. Как ранее было с нанотехнологиями, и многими, другими словами.
Mobile
- Notification HubСервис, который позволяет отправлять нотификации на 3 мобильные платформы. Т.к. сервисы google, ms, apple не совместимы, то notification hub – очень полезное решение, упрощающее работу с нотификациями на всех платформах.
- Mobile Engagement Сервис который умеет собирать статистику использования пользователем различных страниц мобильного приложения, может отправлять таргетированные нотификации (пример-пользователи открывавшие определенную страницу, за последние 5 дней… Отличная штука для рекламы и продаж, получения фидбэека.).
- Mobile Apps Многострадальный сервис, который то в один раздел подтыкали, то в другой, ранее назывался Mobile Services. Разработчики плохо понимают, что это. Под этим сервисом скрывается группа сервисов- массовая рассылка нотификаций (notification hub), online/offline синхронизация данных между, хостинг мобильного бэкенда.
Data & Storage
- Storage — все вроде должны быть понятно. Зачем это разработчикам- для админов (it pro) это просто хранилище vhd дисков, и тут главное подобрать нужные IOPs. Для разработчиков- это еще и система очередей, в хранение больших бинарных объектов(blob) можно вообще что угодно хранить, а не только диски. Таблицы- это вообще NoSQL хранилище.
- Redis Cache — это рекомендованный для всех новых приложений в Azure кэш. Базируется на opensource движке redis, но очень сильно ограничивает его функционал. По факту- это стандарт для кэша, на ряду с MemCache, но уже быстрее его.
- Document DB — написанная в Microsoft документ-ориентированная NoSQL база данных. Прямой конкурент MongoDB, RavenDB и т.п. Но их написали не мы.
- SQL Azure — версия SQL для Cloud. В большинстве случаев совместима с onPremise решением и даже собирается из одной ветки исходного кода.
- Search — предоставление мощного поискового движка из коробки, по вашим данным. Т.е. данные не публикуются для общего доступа тому-же google/bing. Конкурентов из не cloud мира много (Apache Lucene), но этот сервис написали мы.
Надеюсь, статья помогла упорядочить сервисы и Azure перестала быть огромным не понятным черным ящиком, где все есть, но не понятно что конкретно.
Комментарии (15)
chumakov-ilya
09.11.2015 12:07+2SQL Azure — версия Azure для Cloud.
имелось ввиду «версия SQL Server для Cloud?»
dobriykot
09.11.2015 12:13Наконец стало немного понятно что для чего.
Но почему такие цены высокие? Например, для API Management придется выложить 35 000 рублей в месяц. Для бесплатного приложения с 1000 запросов в день это как-то слишком много. Developer tier пишут что нельзя использовать в продакшене.
SychevIgor
09.11.2015 12:38Я честно говоря, не могу ответить на вопрос- как происходит ценообразование каких-либо продуктов, т.к. я «полевой инженер».
На страничке с feedback для api management топовое предложение feedback.azure.com/forums/248703-api-management/suggestions/5919427-a-developer-free-tier — как раз сделать что-нибудь дешевле, что бы покрывать ваш случай.
Предлагаю как минимум проголосовать по ссылке.
Как максимум- задаться вопросом: как повысить использования API и получать с этого деньги,! Т.к. за указанные вами тариф, предлагает до 32000 запросов в день и 1миллион в месяц.
dobriykot
09.11.2015 12:48В комментариях к обучению увидел упоминание AWS API Gateway, цены гораздо лучше. 3.5 доллара за миллион запросов, фиксированных тиеров нет.
Если приложение — это клиент к какому-то сервису, которого нет на WP и который в принципе мало кому нужен, то трудновато будет брать деньги с пользователей. Разве что рекламой, но это тухлый способ. Остается выбор, либо писать все популярное, либо страдать от отсутствия денег.SychevIgor
09.11.2015 12:59Я не сравнивал функционал AWS API Gateway и Azure API Management, но разница в цене меня заинтриговала и сподвигла глянуть т.к. уж слишком большая разница, значит должна быть разница в функционале.
«клиент к какому-то сервису, которого нет на WP и который в принципе мало кому нужен»- если сервис мало кому-нужен, то согласен платный тир Вам не подойдет.
SychevIgor
09.11.2015 18:29+1Посмотрел возможности у AWS API Gateway. С разбегу, по заявленной функциональности сервисы очень близки.
Спорить смысла нет, для вашего приложения, с его текущимей нагрузкой, Azure будет сильно дороже.
Я посмотрел как считаются цену у AWS aws.amazon.com/api-gateway/pricing и сравнил с тем, как это в Azure azure.microsoft.com/en-us/pricing/details/api-management
Если я правильно понял, то в AWS идет тарификация плоская, по миллионам запросов без привязки к каким-либо Tier 3.5$ каждый миллион и все.
В Azure есть Tier(по произвоидтельности, наличию sla и т.п.)
Так вот, если мы возьмем Standard Tier в Azure (и поделим 22.5$ в день, на 7 миллионов запоросов. Я взял для Северной Европы.) то получим 3.2$ за миллион.
Т.е. цена за миллион, в Azure даже ниже. В вашем случаи, когда у вас всего 1000 запросов в день, то Azure оказывается дороже.
По поводу использования Development Tier для production нужд(49$ за месяц). В документации указано should, а не must. Т.е. это рекомендация. Рекомендация основана на том, что в dev tier нет sla, но в случаи бесплатного приложений, которое «мало кому нужно»- я думаю это не приципиально.
"–What is the purpose of the Developer tier?
The Developer tier is for API Management trial, development, and functional test. Customers should not use this tier for production: It lacks an SLA and is limited to 10 users. It also does not have deployment-specific capabilities like multi-region and VPN."dobriykot
09.11.2015 18:34Спасибо за развернутый ответ!
«10 users» — это значит, что десять человек, которые скачают и установят приложение? Если да, то использовать его не получится. :)SychevIgor
09.11.2015 18:54Рекомендую почитать лично, чтобы убедиться лично.
Но в документации «Azure Active Directory Integration Up to 10 User Accounts». Так что не ограничение, если вы AAD не используете.
tangro
09.11.2015 12:37Для использования многих других сервисов, нужно иметь хотя бы минимальные навыки разработчика.
А ещё нужно согласиться с головой завязаться на инфраструктуру Майкрософта, чего можно избежать, используя Azure как просто виртуалки.
leschenko
09.11.2015 20:52А что не так? Готовая инфраструктура и называется той платформой от PaaS. Т.е. или вы пишете приложение под эту платформу и с вас снимаются траты на поддержание этой платформы или строите свою платформу и поддерживаете ее сами.
Кажется в этом и заключается весь смысл PaaS, нет?tangro
09.11.2015 23:04-1Всё так, просто формулировка в статье такая, типа «а кто не разобрался, тот дурак». Я лишь хотел подчеркнуть, что могут быть и другие причины неиспользования «многих других сервисов».
HDDimon
Хорошая статья, спасибо Игорь!