Привет!
В понедельник мы писали про то, как мы видим Интернет Вещей – с облаком, которое можно использовать для обработки различного рода данных, а также нашей новой операционной системой Windows 10, которую можно установить на Raspberry Pi 2 или Intel Minnowboard. В среду коллега из технологического центра Microsoft рассказал про то, как они делают умный офис. Вчера @shwars написал колонку про то, как подключить Arduino к Raspberry Pi2. Сегодня я расскажу немного о процессе подключения Intel Galileo & Edison к Microsoft Azure, отправке простых данных и их визуализации с помощью сервисов Azure. На следующей неделе – опыте установки Windows 10 IoT на Minnowboard MAX.

Статья написана техническим директором центра решений и технологий Microsoft (Microsoft Technology Center), Максимом Хлупновым, на основе реального опыта проектирования и реализации проекта умного офиса. Материал является продолжением статьи про Интернет Вещей, опубликованной в понедельник

Второй московский офис Microsoft, расположенный вблизи метро Белорусская, не является офисным помещением в общепринятом понимании. Большую часть 1700 кв.м. площади занимают демонстрационные стенды с новейшими устройствами и решениями, включая небольшой современный центр обработки данных на 160 кВт, три компьютерных класса на 15 рабочих мест каждый, переговорные комнаты и конференц-залы, начиненные современным оборудованием. Но это только «видимая часть» — ее работа обеспечивается системами электроснабжения, охлаждения ЦОД и другими сложными инженерными решениями. Впрочем, именно так и должен выглядеть технологический центр Microsoft (MTC), созданный для демонстрации и тестирования передовых технологий.

Привет!

Сегодня и на ближайшие две недели в нашем хаброблоге тематическая секция — и посвящена она тому, чему последние несколько лет уделяется много внимания как от крупнейших корпораций (Microsoft, Intel, HP и др.), так и компаний меньшего масштаба, но с не менее интересными проектами (например, Aura) — а именно Интернету Вещей. Мы расскажем обо всём, что делаем.

Вступление

Сейчас в разработке ПО весьма популярно использование методологии DevOps. В этой статье я опишу основные подходы DevOps и расскажу о средствах от Microsoft, которые помогают реализовать эти подходы в мире .NET.

Что такое DevOps?

DevOps — набор методик, реализующих простую идею, отраженную в названии. Название DevOps — результат слияния слов Development и Operations, и главное здесь — взаимодействие команды разработчиков (Development) и команды, отвечающей за эксплуатацию ПО (Operations). DevOps утверждает, что близкое взаимодействие между Development и Operations позволит выпускать новые версии программного продукта быстрее и с меньшим количеством ошибок.



Методология DevOps довольно молодая — появилась в 2007 г. и развилась в сообществе IT-профессионалов, что обусловило ее практическую направленность.

Когда и как используют DevOps?

DevOps используют при разработке сложных проектов с развитой инфраструктурой. Использование подходов DevOps полезно, когда:

• Разрабатывают сложные приложения, требующие сложных процессов установки.
• Требуется поддерживать и обеспечивать работу многих компьютеров.
• Требуются частые релизы.
• Отслеживание работы приложений на продакшн и быстрое исправление неполадок играет важную роль.

В таких условиях всё упирается во время. Важно уменьшить время установки приложения на продакшн-окружение и ускорить доставку команде разработчиков отзывов о работе установленного приложения.



Для ускорения взаимодействия команд Development и Operations используют средства автоматизации. Мы можем автоматизировать:

• Управление релизами.
• Мониторинг установленных приложений и доставку команде разработчиков отзывов о работе установленного приложения.

Далее будут описаны средства автоматизации, предлагаемые Microsoft.

В этом году в качестве курсовой работы мне нужно было написать несложную медицинскую информационную систему (МИС) для небольшой частной клиники по лечению эпилепсии.

База данных пациентов в клинике уже была, написана она была еще в далеком 1998 году в Microsoft Access того времени (причем даже с красивым пользовательским интерфейсом), но вот работала она только в одном месте — на компьютере заведующего, да еще и поддерживать ее стало совершенно невозможно. Значит, давно назрела необходимость внедрять что-то новое!

Сказано — сделано. Работать надо было быстро (все-таки сдавать курсовую пора) и при этом хотелось сделать работу максимально интересной для себя. Я давно хотел разобраться с ASP.NET MVC, был немного знаком с C# и общими принципами MVC, поэтому скачал последнюю Visual Studio 2015 RC и принялся за работу.

Под катом — весь процесс знакомства с технологией и разработки такой системы со всеми встретившимися подводными камнями. Данная статья пригодится всем, кто знаком с программированием и когда-то делал блог по туториалу для любого MVC фреймфорка и хочет узнать, как же сделать что то более интересное.

Требования

В данной статье мы рассмотрим задачи переноса сложных объектов между процессами и машинами. В наших системах было много мест, где требовалось перемещать большое кол-во бизнес объектов различной структуры, например:

• самозацикленные графы объектов (деревья с back-references)
• массивы структур (value types)
• классы/структуры с readonly полями
• инстансы существующих .Net коллекций (Dictionary, List), которые внутренне используют custom-сериализацию
• большое кол-во инстансов типов, специализированных для конкретной задачи

Речь пойдёт о трёх аспектах, которые очень важны в распределённых кластерных системах:

• скорость сериализации/десериализации
• объём объектов в сериализированном виде
• возможность использовать существующие объекты без надобности “украшения” этих объектов и их полей вспомогательными атрибутами для сериализации

Камень преткновения — GC

Все managed языки такие как Java или C# имеют один существенный недостаток — безусловное автоматическое управление паматью. Казалось бы, именно это и является преимуществом managed языков. Помните, как мы барахтались с dandling-указателями, не понимая, куда утекают драгоценные 10KB в час, заставляя рестартать наш любимый сервер раз в сутки? Конечно, Java и C# (и иже с ними) на первый взгляд разруливают ситуацию в 99% случаев.

Так-то оно так, только вот есть одна проблемка: как быть с большим кол-вом объектов, ведь в том же .Net никакой магии нет. CLR должен сканировать огромный set объектов и их взаимных ссылок. Это проблема частично решается путём введения поколений. Исходя из того, что большинство объектов живёт недолго, мы высвобождаем их быстрее и поэтому не надо каждый раз ходить по всем объектам хипа.

Но проблема всё равно есть в тех случаях, когда объекты должны жить долго. Например, кэш. В нём должны находиться миллионы объектов. Особенно, учитывая возрастание объемов оперативки на типичном современном серваке. Получается, что в кэше потенциально можно хранить сотни миллионов бизнес-объектов (например, Person с дюжиной полей) на машине с 64GB памяти.

Однако на практике это сделать не удаётся. Как только мы добавляем первые 10 миллионов объектов и они “устаревают” из первого поколения во второе, то очередной полный GC-scan “завешивает” процесс на 8-12 секунд, причём эта пауза неизбежна, т.е. мы уже находимся в режиме background server GC и это только время “stop-the-world”. Это приводит к тому, что серверная апликуха просто “умирает” на 10 секунд. Более того, предсказать момент “клинической смерти” практически невозможно.
Что же делать? Не хранить много объектов долго?

Зачем

Но мне НУЖНО хранить очень много объектов долго в конкретной задаче. Вот например, я храню network из 200 миллионов улиц и их взаимосвязей. После загрузки из flat файла моё приложение должно просчитать коэффициенты вероятностей. Это занимает время. Поэтому я это делаю сразу по мере загрузки данных с диска в память. После этого мне нужно иметь object-graph, который уже прекалькулирован и готов “к труду и обороне”. Короче, мне нужно хранить резидентно около 48GB данных в течении нескольких недель при этом отвечаю на сотни запросов в секунду.

Вот другая задача. Кэширование социальных данных, которых скапливаются сотни миллионов за 2-3 недели, а обслуживать необходимо десятки тысяч read-запросов в секунду.

Всем привет!

В нашем облачном меню — новинка: облако AzureLine на базе технологии Microsoft Hyper-V и с порталом управления Windows Azure Pack.
Спешим поделиться подробностями.

Относительно недавно в Microsoft Azure появилась возможность управлять DNS зонами. Пока сервис находится в статусе Preview, управлять им можно только с помощью PowerShell.

Для того, чтобы необходимые командлеты стали доступны, надо установить Microsoft Azure PowerShell. С тем, что PowerShell — крут, я спорить не буду. Это так, но, иногда хочется обойтись без него.

Поэтому, я представляю, на суд людской, свой велосипед — утилиту для управления Azure DNS.

Раз уж тут у нас «неделя» nginx, например тут или тут, то попробую и я внести свою, так сказать, лепту. Речь пойдет про nginx 4 windows, а именно про более-менее официальную сборку для этой пропритарной, некоторыми не очень любимой платформы.

Почему Windows. Все просто, в корпоративном секторе Windows на сервере, да и на рабочих станциях — нередко обязательная программа. И от этих требований к платформе, например в ультимативной форме озвученных клиентом, никуда не денешься.
И раз уж имеем Windows, но не хочется мучиться с IIS, apache и иже с ними, если хочется использовать любимые инструменты, а nginx однозначно к ним относится, то приходится иногда мириться даже с некоторыми ограничениями на этой платформе. Вернее приходилось…

Хотя нужно заметить, что даже с этими ограничениями, nginx даст фору практически любому веб-серверу под windows по многим факторам, в том числе по стабильности, потреблению памяти, а главное производительности.

Спешу сразу поделится хорошей новостью — больше ограничений, критичных к высокой производительности, при использовании nginx под windows практически не существует, и последнее из критичных, с высокой долей вероятности, тоже скоро отпадет. Но по порядку…

Здесь описаны известные проблемы nginx 4 windows, а именно:

• Рабочий процесс может обслуживать не более 1024 одновременных соединений.
• Кэш и другие модули, требующие поддержки разделяемой памяти, не работают под Windows Vista и более поздними версиями в связи с тем, что на этих версиях Windows включена рандомизация адресного пространства.
• Хоть и возможен запуск нескольких рабочих процессов, только один из них реально работает.

Я немного изменил порядок, т.к. именно в такой последовательности я разбирался с этими ограничениями, так сказать отсортировано «исторически».

Буквально только что закончился хакатон компании Microsoft по Azure ML. В процессе решения одной из задач потребовалась обработка русскоязычных текстовых данных, причём желательно внутри системы. В итоге, потратив ощутимое время на поиск решения, хочу им поделиться. Надеюсь, что это поможет кому-то сэкономить время и не биться головой в стенку зря.

Все организации в Российской Федерации так или иначе обрабатывают персональные данные, а следовательно попадают под действие ФЗ №152. На текущий момент бОльшая часть из них вообще ничего не делала на тему защиты персональных данных.

Доброе утро, дорогие читатели.

Мы начнем неделю с такого информативного, пусть и несколько тезисного перевода, который поможет нам уточнить, насколько аудитория заинтересована в издании книг по ASP.NET. Практика показала, что книги Питера "Разработка приложений с испоользованием ASP.NET и AJAX" и "Программирование с использованием Microsoft ASP.NET 4" не пользовались бешеным спросом. Однако вполне возможно, что по результатам данного поста мы все-таки решимся замахнуться на ASP.NET 5 и MVC 6.

В этом обзоре мы поговорим про бесплатные курсы виртуальной академии Microsoft MVA, которые будут полезны как профессиональным разработчикам программного обеспечения и ИТ-про, так и новичкам. Некоторые курсы предлагают бесплатную подготовку к официальным сертификационным экзаменам. Обратите внимание, что видео-плеер на сайте для ряда курсов, которые созданы на английском языке, содержит возможность включить русские субтитры.

Абсолютным хитом этого месяца является курс Дмитрия Сошникова «Как научить ребенка программировать».

Этот обзорный курс рассматривает множество технологий, которые могут помочь вам увлечь ребенка компьютерами и программированием. Не претендуя на методическую полноту и на исчерпывающий рассказ про технологии, этот курс даст вам правильные ссылки и идеи, благодаря которым вы сможете много часов провести вместе с ребенком у компьютера, изучая и творя вместе с ним.

На конференции Ignite, прошедшей в Чикаго в первой декаде мая, компания Microsoft обрисовала общее видение новой функциональности и планов разработки SharePoint Server 2016. На нескольких сессиях официальные представители компании официально заявили, что все их усилия направлены на завершение разработок и начало поставок в следующем году.

В соответствии с информацией, представленной на конференции, Microsoft анонсирует бета-версию SharePoint Server 2016 в 4 квартале этого года. Продукт будет полностью доступен заказчикам во втором квартале в 2016 года.

Некоторое время назад в Москве прошла конференция Failover, посвящённая такой важной проблематике, как обеспечение отказоустойчивости онлайн-сервисов. За день перед слушателями выступили 19 докладчиков, рассказав немало интересных вещей для разработчиков, тестировщиков и эксплуатантов. Мы решили, что такие полезные материалы не должны «пылиться» в архиве и должны стать достоянием ещё более широкой общественности. И начнём мы с выступления Сергея Рыжикова, озаглавленного «Нужно ли переезжать на хостинг в Россию, или Отказоустойчивость по 242-ФЗ».

Шел 2013 год. За доллар давали 30 рублей, а я устроился в компанию 2ГИС разрабатывать под Windows Phone. Мне удалось поучаствовать в запуске почти готового к тому времени приложения 2ГИС, которое в скором времени стало доступно нашим пользователям в Marketplace.

Была у этого приложения одна досадная особенность: оно работало на нашем WebAPI, и, соответственно, требовало подключения к Интернету. Поэтому почти сразу возникла необходимость научить 2ГИС под WP работать офлайн. А заодно решить другие насущные проблемы.

Сегодня мы расскажем о том, как создать гибридное облако на базе облака Microsoft Azure и облака российского сервис-провайдера на базе Microsoft Azure Pack, объединив их в единое сетевое пространство через Site-to-Site VPN. Плюс создадим на базе этого гибрида единый домен Active Directory.

Данный сценарий является практическим применением концепции Microsoft Cloud OS — единой облачной платформы для частного облака, публичного облака Microsoft Azure и партнёрского облака от локального сервис-провайдера.


В качестве облака сервис-провайдера будет использоваться услуга AzuRus от компании «Облакотека». Данное решение было реализовано в рамках программы Microsoft Cloud OS Network Russia при участии инженеров Microsoft, и использует платформу Microsoft Azure Pack в качестве системы управления облаком. За счёт этого оно без проблем интегрируется с облаком Microsoft Azure.

Подробности реализации ниже.

Мое знакомство с облаком Azure началось еще во время практики в DataArt. На третьем месяце обучения к моему ментору Диме пришел коллега Антон и сказал, что ему нужен кто-то для маленького демонстрационного проекта. Так мы и познакомились.

Антон – человек увлеченный и очень активный, умеет вдохновлять идеями. Практика давно закончилась, через какое-то время Антон расстался с DataArt, но продолжает активно интересоваться и продвигать Microsoft Azure, часто консультирует наших коллег по Azure-технологии и предлагает поучаствовать в разных тематических событиях. В частности, он проводит разные семинары, тренинги, встречи, посвященные этому облаку, и не так давно в Киеве было создано первое в нашей стране Ukrainian Azure Community.

Это группа единомышленников, которые активно интересуются технологией, делятся полученными знаниями и общаются на тему Azure. Раз в месяц-два проходят встречи, каждая посвящена отдельной теме. Часто эти встречи проходят как раз в киевском офисе DataArt.

Темой встречи, где, в частности, выступала я, выбрали обмен сообщениями при помощи разных Azure-сервисов. Мы услышали об Azure Storage Queues, Azure Service Bus Queues, Azure Service Bus Topics & Subscriptions.

Поделюсь технической частью. Существует три типа моделей обмена сообщениями.


Рис. 1

В случае с моделью А сообщение отправляется напрямую от отправителя к получателю. Это самая простая модель, но у нее есть недостатки:
— сложно масштабировать (да-да, это ж облака!);
— легко потерять сообщения (например, получатель уходит в офлайн);
— сложно реализовать retry policy.
Из-за этих недостатков в Azure в основном используются модели Б (сообщение попадает в своеобразный брокер, получатель «забирает» его оттуда) и В (сообщение попадает в брокер, а брокер отправляет его получателю).

Создание Windows Runtime (WinRT) в качестве API, с одной стороны, можно только приветствовать, так как предыдущий — WinAPI — особой простотой и человеколюбием не отличался. С другой стороны, в полный рост при этом всплывает проблема обратной совместимости. Что делать, если нужно заиспользовать какую-то приятную мелочь, появившуюся в Win8, но при этом не терять совместимости с Win7, все еще бодро шагающей в строю?

Официальный MSDN к этому относится весьма однозначно: если нужен WinRT, то забываем про версии Windows, старше восьмерки; если нужно поддерживать всякое старье, то собираем приложение отдельно без упоминания об WinRT. Такие вот простые и незатейливые парни работают в Microsoft. Тем не менее, решение проблемы, причем достаточно простое, удалось отыскать.