Просмотр исходного текста страницы Блог:Максима Цепкова/2013-06-10: По следам MS DevCon-2013

{{Conf-Ref}}
В конце мая я был на [http://www.msdevcon.ru/ MS DevCon-2013], где весьма продуктивно послушал о трендах развития отрасли по версии Microsoft. К сожалению, сразу по возвращении возникло много работы, так что реплика по этому поводу появилась только сейчас.

Я уже писал осенью под впечатлением от Patterns&Practices: [[Блог:Максима Цепкова/2012-10-06: Пока мы наступаем, Microsoft меняет рельеф местности|«Пока мы наступаем, Microsoft меняет рельеф местности»]]. Это впечатление сохраняется, и, более того, изменения рельефа постепенно проясняются.

=== О трендах в целом ===

Готовясь к Windows 8, Microsoft проанализировал тренды отрасли, переосмыслил их по-своему и теперь выдает на основании этого свои новые решения. Правда, ситуация осложняется следующим. Одни концепции MS расценивает как свое конкурентное преимущество, и для них есть хорошее концептуальное описание, guideline, sample и так далее. Примером может служить концепция метро-интерфейса Windows 8. При этом такие решения формально отрицают предыдущее развитие, подобно тому как интерфейс Office 2010 отрицал предыдущую концепцию интерфейса. И это действительно средство конкурентной борьбы.

А вот другие концепции рассматриваются лишь как средства обеспечения хорошей технологии разработки, например, continuous delivery или DevOps. И их Microsoft не выделяет столь явно как концепции. Он лишь говорит, что, используя его средства разработки, можно достичь таких результатов, и показывает, как сам их достигает — Microsoft во внутренней разработке использует свои средства. Но вот чтобы достичь этого, надо следовать внутренней логике средств разработки. Она изложена в конкретных руководствах и примерах, но не подчеркивается как концепция: чтобы не сузить рынок разработчиков, которые выбирают эти средства. Тем более что жестких ограничений действительно нет. А сами концепции в целом находятся в русле развития отрасли, у них есть параллели в Java-мире. Только вот параллелей — много, есть вариации, а что именно поддерживается — до конца неясно. Впрочем, такая ситуация была всегда.

А еще нельзя сказать, что у MS есть целостная концепция разработки во всех проявлениях. Они тоже ее осмысливают и развивают — по мере развития отрасли. Появляются новые течения и варианты, иногда происходит отказ от ранее выбранных решений, и тогда развитие соответствующих инструментов приостанавливается. Таким образом, разработчикам, как правило, приходится выбирать из следующих двух зол.
* Можно пользоваться новыми перспективными и развивающимися решениями в разработке, которые, однако, ненадежны и склонны изменять направление движения, например, писать метро-интерфейсы. На этих направлениях часто требуются разработка собственных решений для стандартных задач, потому что библиотечные решения разработать не успели.
* Можно использовать надежные и устоявшиеся способы разработки с богатыми библиотеками, которые, однако, не имеют перспективы развития, как, например, классические desktop-интерфейсы.
Промежуточный вариант — когда мы имеем развивающееся, но уже достаточно зрелое направление, устойчиво работающее и с библиотечной поддержкой: присутствует крайне недолго, оно склонно переходить к устойчивому, но бесперспективному в развитии решению или, наоборот, получать какой-то неожиданный вектор развития.

А для тех, кто занимается enterprise-разработкой, нынешняя ситуация осложняется тем, что она для MS — скучна и неинтересна. Они заняты завоеванием нового рынка мобильных приложений, и основные усилия направлены именно в эту сторону. Так что каким образом новые тренды обернутся в enterprise-приложениях, не в виде отдельных элементов, целенаправленно доступных с мобильных устройств, как клиент-банки, а в операционных desktop-приложениях — пока неизвестно. Однако часть будущих трендов в этом сегменте можно попробовать увидеть в докладах о разработке на платформе SharePoint.

После этой длинной, но, думаю, полезной преамбулы — перехожу к тем трендам, которые я почувствовал на DevCon. Именно почувствовал, а не услышал, дальнейший текст — авторский, а не цитаты из докладов.

=== Меняется концепция клиент-серверного приложения ===

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

Что же будет вместо больших приложений? А будут небольшие клиентские приложения и серверные сервисы, которые активно обмениваются данными как на серверной, так и на клиентской стороне, связаны общими точками входа для поиска и запроса объектов, общей средой аутентификации и общими настройками, а также средствами обновления. Средства интеграции клиентских приложений поставляет платформа, в данном случае — Windows 8, но вообще решения в этом направлении наблюдаются и на других платформах. Для интеграции серверных приложений есть много различных решений, они активно развиваются и в облаке, поэтому там тренд не такой явный, хотя о новых средствах интеграции в Azure в докладах было много.

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

Таким образом, некоторый основной серверный сервис, комплементарный приложению, обычно сохраняется, но приложение обращается и к другим, хостинг которых в общем случае неизвестен. Более того, вполне может существовать и смешанная конструкция, когда одни сервисы имеют обычный хостинг, в то время как другие выполняются в облаке. Что интересно — эта конструкция может включать в себя как глобальные сервисы, так и корпоративные. На уровне Windows 8 Microsoft реализует для этого средства, включая аутенфикацию и взаимодействие с сервисами внутрикорпоративной безопасности.

Если представить, как могла бы выглядеть, например, автоматизированная система банка в соответствии с новыми трендами, то мы получаем относительно маленькие изолированные сервисы, такие как ведение контрагентов, ведение лицевых счетов, ведение платежных документов, исполнение платежей через банки-корреспонденты и так далее. Которые могут хоститься на различных серверах и фермах, в том числе с разделением хранения счетов или документов по разным нодам для балансировки нагрузки. Если мы создаем новое платежное поручение, то информацию по счету мы получаем непосредственно из сервиса лицевых счетов, включая текущие остатки, которые необходимы в интерфейсе, а потом вновь созданный документ отправляется в сервис клиентских платежей (например). При этом документ сопровождает некоторая необходимая для обработки информация по счету, такая как 20-значный номер, наименование счета и идентификатор клиента, но полной таблицы счетов в сервисе платежных документов может и не быть. Источником же информации о справочнике БИК или курсах валют может быть внешний публичный сервис, если банк ему доверяет. Подтвержденные внешние платежи выбираются отдельным приложением, с которым работают сотрудниками банка, занимающиеся корр. отношениями, и оно их маршрутизирует в соответствующий сервис для отправки в РКЦ или банки-корреспонденты. А внутренние платежи исполняются автоматически. Все проводки собираются в сервис Главной книги и служат основанием для контроля учетной политики и выпуска отчетности. Если же кому-либо надо посмотреть все документы по счету, то он через интерфейс, аналогичный интерфейсу поиска (google, yandex), просто вводит запрос и получает результат по всем системам. А согласованная работа всего этого комплекса мониторится отдельными средствами, аналогичными тем, что используются администраторами для мониторинга серверного хозяйства, однако работающими на уровне бизнес-операций.

Аналогичную картину мелкого деления можно нарисовать и для корпораций. Интересно, что в такой конструкции может исчезнуть MDM, хотя по отдельным видам данных хозяева должны быть. Существенно уменьшается консистентность данных или использование общей базы данных, хотя несколько сервисов могут использовать одну базу данных, а операционные документы — отражаться в единых хранилищах по типам данных после нескольких ступеней обработки. Понятно, что конструкция становится сильно сложнее, чем ранее имевшаяся конструкция единого приложения, поделенного на серверную и клиентскую часть. Зато она вписывается в сложный ИТ-ландшафт предприятия, уже сейчас состоящий из достаточно большого количества крупных элементов. Мы получаем возможность интегрироваться с глобальными сервисами. Но главное — в целом отрасль развивается именно в этом направлении в глобальных приложениях. А значит, появляющиеся средства поддержки будут ориентированы именно на такие схемы работы.

=== Windows 8, DevOps, Облака и Интеграция ===

Наиболее явное внешнее проявление Windows 8 — метро-интерфейс, и на конференции было несколько докладов о конструировании таких интерфейсов, в том числе о переносе интерфейсов существующих приложений. Отличительная фишка состоит в том, что платформа обеспечивает весь спектр устройств от мобильных телефонов до больших экранов. Устройства обладают, к тому же, существенно различными средствами ввода: touchscreen есть не везде, клавиатура тоже есть не везде, разрешения и детали — различны. А еще в них появляются различные сенсоры, которые ранее были только на мобильных телефонах — они есть в планшетах и выходят на ноуты, и переворот экрана на лету — желаемая опция. И надо обеспечить комфортную эргономичную работу если не на всем спектре, то на достаточно широком классе целевых устройств, а на остальных — хотя бы приемлемую работу. Что будет со сложными enterprise-приложениями в этом интерфейсе — никто не знает, пока рассказывают о сайтах и простых приложениях.

А по устройствам ввода — есть явный уклон в сторону touchscreen, притом что пользователи сейчас к нему привыкли не все и далеко не все операции на нем удобно делать. Судя по всему, тут нас ждет такая же волна, как была с появлением мыши, — многие приложения начали отвратительно поддерживать эргономичную работу с клавиатурой, другие, наоборот, долго не могли воспринять мышь, и переход занял много лет.

Основной рефрен докладов о новом интерфейсе: используйте guideline, следуйте им. Рефрен — не нов, но много ли разработчиков читают guideline?

Но Windows 8 — это не только интерфейс и широкий спектр устройств. Это еще и среда исполнения приложений, позволяющая им активно взаимодействовать между собой, а одному приложению — исполняться на разных устройствах с сохранением контекста работы. При этом на уровне протоколов оно выглядит достаточно просто и формально «надо поддержать 2-3 программных интерфейса». А вот на уровне реализации — сложнее. Потому что для правильной работы надо поддержать согласованную работу этих интерфейсов как минимум в рамках некоторых интерактивных сценариев, полагаемых типичными. А по ним — куда меньше согласия и больше интерпретаций. Сами же сценарии полагают взаимодействие нескольких приложений от разных вендоров. И эти сценарии надо тестировать, в том числе когда твое приложение играет ведомую роль, а ведущим выступает какое-то внешнее приложение. Это довольно новая задача в разработке, раньше интеграция воспринималась как задача сопутствующая, а не основная.

Интеграция клиентских приложений влечет за собой интеграцию сервисов серверной части. И MS развивает средства интеграции приложений Windows Azure, в частности Service Bus, в том числе для взаимодействия с приложениями на других технологических стеках, средства интеграции можно использовать не только в облаке — они появляются в серверной версии. Просто позже. Зато там транзакции бесплатны, а в облаке каждая транзакция взаимодействия приложений стоит денег, пусть небольших — 1 цент за 10К транзакций. О новых средствах интеграции, а также об отладке взаимодействия был ряд докладов.

Естественным образом, такая гетерогенная среда исполнения, состоящая из мозаики приложений, повышает требования к сопровождаемости систем, к передаче проблем пользователей и решению проблемных ситуаций. Это все — актуальный ныне тренд DevOps, призванный развернуть разработчиков лицом к проблемам эксплуатации — поддержки, сопровождения и администрирования приложений. Здесь Microsoft не предлагают принципиально новых решений, однако в рамках своих средств разработки, администрирования и поддержки обеспечивают достаточно легкий и прямой путь от пользователя до разработчика через линии поддержки и обратно. Этим путем пользуются и они сам, строя поддержку своих продуктов. Им могут воспользоваться и другие разработчики — для этого их приложения должны удовлетворять определенным требованиям, например, производить логи в нужных форматах. А службы эксплуатации и сама компания-разработчик — использовать продукты MS.

А еще кейсы и сценарии DevOps от MS можно использовать как источник идей для поддержки службы эксплуатации систем на альтернативных платформах. На самом деле, уровень интеграции и сопряжения, который для этого надо обеспечить, не слишком велик и сложен. Просто надо взять эти сценарии и продумать, как именно будет обеспечиваться их выполнение для вашего случая, и создать необходимую поддержку, такую как перенос обращений пользователя во внутреннюю систему ведения багов с сохранением трассировки.

=== TFS, Git, Continious delivery ===

Microsoft использует TFS как средство ведения своих проектов и продолжают его развивать, включая средства тестирования и непрерывной интеграции. Из существенных прорывов для разработчика — поддержка Git. MS не стали писать собственную версию распределенного контроля кода, а использовали готовую, причем открытую.

Развиваются средства отладки, построение графа зависимостей, в том числе для динамических языков, а в перспективе — для асинхронного кода. Правда, некоторые из них MS встраивают только в дорогую ultimate-версию Visual Studio, делая таким образом ее необходимой и для разработчиков, а не только для архитекторов. Кстати, по чисто архитектурным средствам VS особого прогресса, прорыва пока не видно, хотя какое-то развитие есть.

А в части continious delivery был впечатляющий доклад Евгения Чигиринского — как у них устроена система сборки, тестирования и выпуска на продакшн тех сервисов, которые обеспечивают работу binq и сайтов MSN. Она реально непрерывная, до 24 релизов в сутки. При этом квантом изменения является один сервис, изменения подхватываются автоматически из системы контроля версий, где настроено pre-commit тестирование в автономном окружении. А потом после интеграционного тестирования, занимающего не более одного часа в автоматическом режиме, выдается решение: новый билд идет на продакшн или откатывается из-за зафиксированных ошибок. И для выходного тестирования выбирается следующий сервис. Чтобы обеспечить такие времена выпуска, ряд сервисов пришлось декомпозировать. А система надстроена над имеющимися средствами TFS, и, по словам докладчика, основная проблема состояла в том, что TFS ориентирован на подъем на виртуальных машинах, а у них тестовая среда на реальном железе, с этим были связаны доработки, плюс — сериализация билдов. Но все доработки используют штатное API в предусмотренных открытых точках кастомизации.

=== И о докладах в целом ===

И в заключение — несколько слов о докладах конференции в целом. Не только по моему личному мнению, но и по общению с другими участниками.

Microsoft осознает объем предлагаемых изменений. А еще — они нацелены на расширение ареала разработчиков и захват новых сегментов рынка. Поэтому многие доклады ориентированы на новичков — не в разработке вообще, а в разработке на MS или на новых платформах. Они представляют материал на уровне продвинутых примеров. И такие доклады находят своих слушателей, хотя тем, кто уже этим сегментом разработки овладел, представляются поверхностными.

Докладов, рассчитанных на опытных разработчиков в определенном сегменте, — сильно меньше. И квалифицированный разработчик, желающий получить новую информацию в сегменте своей деятельности, получает ее лишь в нескольких (1-2-3) докладах. Но это — оборотная сторона разработки на переднем крае. В общем-то, если ты к нему достаточно близко, то другим просто нечего тебе сказать. Организаторы конференции пытались найти побольше таких докладов — и от сотрудников Microsoft, и от компаний-партнеров, но все равно много их не получилось.

А еще — хотелось бы побольше докладов на хорошем концептуальном уровне. Представляющим модель разработки от Microsoft во всей полноте. Да, она всегда меняется, и ее сложно поймать в моменте. Но авторский взгляд был бы очень востребован. Хотя это, конечно, сложно, в том числе потому, что концептуальный доклад требует большой подготовки, а устареть может даже за неделю — мир ИТ меняется очень быстро.

Из конкретных докладов особенно хочется отметить уже упомянутое выступление Евгения Чигиринского — «Внутренний опыт компании Microsoft по автоматической сборке и непрерывной интеграции веб-сервисов и приложений с помощью TFS 2012». А традиционного для меня обзора конкретных докладов сегодня не будет, потому что из позиции архитектора, который с технологическими деталями знаком больше косвенно, я не могу адекватно оценить их значение для разработчика.

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

{{wl-publish: 2013-06-10 16:02:46 +0400 | MaksTsepkov }}