Беседа с Перри Кларком


Ниже вы найдете перевод статьи Talking Exchange Server with Microsoft’s Perry Clarke, написанной и опубликованной Тони Редмонтом в его блоге. Но прежде, мне думается, нужно сделать некоторые разъяснения: кто такие Перри Кларк и Тони Редмонт, почему статья так важна и что за особенный перевод.

И так по порядку.

Перри Кларк – главный идеолог разработки Exchange Server. Человек практически всю жизнь посвятивший системам электронной почты. Он знает про Exchange все – от идеи до реализации, и даже больше – он знает его будущее на много лет вперед. Ныне его пост именуется как вице-президент по разработке Exchange Server.

Тони Редмонт – уникальный человек и уникальный специалист, который знает о системах электронной почты и об Exchange и очень много, и очень рано (раньше многих). Автор нескольких книг и множества иных публикаций по Exchange Server.

В чем уникальность статьи: в ней передано то, что вы не найдете нигде более, это даже не идеи, а «дух идей», которым поделился Перри, проникаясь которым вы сможете лучше понять, что такое Exchange сервер в прошлом, сейчас и в обозримом будущем.

В чем нестандартность ситуации: Тони просто вел дискуссию с Перри, которую записал на диктофон, затем попытался переложить на бумагу то образное изложение, которое свойственно Перри – как вы понимаете, задача нетривиальная.

В чем особенность перевода: если у Тони была проблема передать дух идей словами, то мне досталась задача в квадрате – я не мог делать «художественный» перевод, который бы тут же убил «дух идей», и не мог следовать «машинному» дословному переводу, т.к. читать такое по-русски было бы издевательством. Поэтому ниже представлен некоторый компромисс: я постарался, где возможно, «говорить» по-русски, а где это невозможно, и таких мест больше, сохранить максимальную близость к оригиналу.

В чем особенность вашего погружения в «дух идей»: если вы хорошо владеете английским, то читайте оригинал – перевод с искажениями вам не нужен; если исходный текст покажется вам слишком сложным, то прочитайте сначала перевод, а потом оригинал – именно для этого я постарался сохранить близость к оригиналу; если же вообще не хотите мучиться с оригиналом, то читайте перевод – все идеи в нем сохранены; если перевод покажется вам слишком «машинным», то подождите: вполне возможно я сделаю несколько статей в этом блоге на тему проблем затронутых в беседе Перри и Тони.

И так – в путь!

——-

Беседа с любым Главным специалистом может быть проблемой для журналиста (замечу, что я не журналист). Задача журналиста – извлечь самую соль во время интервью, в то время как собеседник должен противостоять всем попыткам заставить открыть ее и сосредоточиться вместо этого на передачу сообщения «du jour». (Дословно «повестка дня» — прим. переводчика). Когда я взял на себя руководство безопасностью HP в 2003 году, я получил совет от команды PR, что я должен «всегда говорить абзацами», потому что «ты имеешь меньше шансов быть неправильно истолкованным» и «все, что вы говорите, будет сообщаться дословно, потому что все связано вместе».

Теперь десять лет спустя я говорю с Перри Кларком, корпоративным вице-президентом по разработке Exchange, и я тот, который пытается сорвать покровы. Это интересный поворот событий, особенно когда сталкиваешься с кем-то, кого ты знал в течение многих лет. Перри определенно не отвечает на вопросы четкими абзацами. Вместо этого вы получаете лавины идей и мнений, глубокие суждения и размышления, все это интересно слушать, но иной раз трудно расшифровать.

Перри сделал 17-тилетнюю карьеру в Майкрософт, работая над Exchange, и ныне отвечает за каждый кусок кода написанного для Exchange и корпоративного и облачного (Office 365). После недавней статьи Перри в блоге EHLO «Exchange Server: The Road Ahead» я провел краткий опрос в сообществе и получил много отзывов и идей (посмотрите также сайт идей для Exchange), какие вопросы задать – определенно слишком много, чтобы ответить на них за час, особенно в жарком споре двух людей, которые глубоко озабочены определенной технологией, которой посвятили большую часть своей карьеры. В конечном итоге нам удалось охватить следующие области:

· Текущее состояние Exchange

· Движение к Облаку и будущее корпоративного ПО

· Мобильность

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

Текущее состояние Exchange

Мы начали с текущего состояния Exchange, и я спросил Перри, насколько он доволен тем, где сейчас находится Майкрософт, принимая во внимание неофициальные данные о том, что клиенты не переходят на Exchange 2013 также быстро как на предыдущие версии, несмотря на некоторые крупные инженерные изменения, возможно из-за опасения по поводу низкого качества, вопросов совместимости, некоторых отсутствующих функций и отчетов о плохой производительности сервера. Я спросил, была ли ситуация аналогичной Exchange 2000, когда клиенты откладывали внедрение из-за того, что была предложена новая архитектура и отсутствовали принципиально новые функции, что говорит о том, что Exchange 5.5 считался ими «достаточно хорошим».

Хотя и следовало ожидать, что лидер разработки любого продукта будет защищать свою работу, но Перри удивил меня, сказав, что он доволен той позицией, которую достигла группа разработки Exchange, указав, что они находятся в гораздо лучшем положении на данный момент в цикле разработки (спустя год после выпуска основной версии), чем они были в аналогичное время для Exchange 2010. Общая кодовая база, которая охватывает корпоративный и облачный сегменты, готова и работает; Exchange Online приобрел миллионы новых почтовых ящиков; и это все подтверждается опытом, который получает Майкрософт при эксплуатации этого сервиса. Перри отметил, что бракованный продукт скорее всего не справился бы с теми нагрузками, которые испытывает Exchange Online. Код Exchange 2013 обрабатывает в четыре раза больше облачных почтовых ящиков, чем год назад, и все внутренние метрики Майкрософт показывают более высокую производительность и надежность при меньшем числе алертов по сравнению с Exchange 2010.

Я выразил сомнение в этом и указал, что многие из тех, кто пытался внедрить Exchange 2013 в корпоративной среде отмечают, что он требует гораздо больше ресурсов (главным образом памяти), чем Exchange 2010, и выглядит более хрупким. Потеря функциональности, например, поддержки S/MIME, ощущается также остро, как и необходимость изменить административную модель. Однако правдой также является то, что сейчас накоплено много знаний и опыта внедрения Exchange 2007 и 2010, и потребуется время, чтобы накопить аналогичный опыт для Exchange 2013.

Он также сказал, что корпоративные клиенты получают огромный выигрыш от того факта, что теперь «одна и та же» кодовая база используется в обеих платформах, и от того, что новый код работает в Office 365 несколько недель, прежде чем выпускается для корпоративных клиентов в виде кумулятивного обновления. «В основной части Exchange сервера не существует части, которая бы не поставлялась корпоративным клиентам. Мы не имеем специального Exchange, который работает в облаке». Он сказал, что то, что «код, который корпоративные клиенты запускают, проверяется на миллионах почтовых ящиках до того, как он внедряется ими, должно вызывать комфорт у корпоративных клиентов».

Я отметил, что Office 365 представляет собой очень структурированную среду, которая тщательно тестирует многие части путем выполнения кода в экстремальном масштабе, но пропускает многие детали, которые присутствуют в среде корпоративных клиентов. Например, Office 365 не позволяет развертывание продуктов третьих фирм на стороне сервера и настаивает на использовании последних версий клиента, тогда как практически любое корпоративное внедрение использует один или несколько продуктов третьих фирм и смесь версий клиентов. Перри согласился, но отметил, что «это проблема (тестирования в специфической среде заказчика) существовала всегда» и сказал, что Майкрософт «не сделала ни шагу назад в том, что она исторически сделала для решения этого вопроса».

Мы обсудили взаимодействие с Exchange 2007, это часть функциональности, которая не проверялась, не тестировалась в Exchange Online, и которая, кажется, вызывает проблемы в проектах заказчиков. Перри признал, что «версия n-1 (Exchange 2007) всегда была проблемой при проверке совместимости». Он отметил, что Майкрософт все еще имеет некоторое количество серверов Exchange 2007 в эксплуатации и в тестовых лабораториях, но что у заказчиков среда «более сложная», что делает тестирование совместимости более трудным. Учитывая характер некоторых инфраструктур, развернутых у клиентов (включая программное обеспечение сторонних производителей), невозможно для Майкрософт проверить каждый аспект совместимости, но они «не отступили ни на шаг» от своей ответственности. Он также сказал, что модели расширяемости (начиная с версии Exchange 2000), которые в настоящее время существуют, гораздо лучше и должны бы показывать себя более надежными.

Exchange 2013 привнес новую проблему в том, что нужно постоянно увеличивать масштаб (Exchange Online) и сохранять развитие кодовой базы. Он сказал, что «превращение выпуска кумулятивных обновлений в совершенство было интересным вызовом». Подобные проблемы с качеством обновлений происходили и в предыдущих версиях и должны были быть преодолены. Прошлым летом был проведен скрупулёзный анализ, чтобы выяснить, где возникали проблемы в обновлениях. Хотя более лучшее тестирование с точки зрения масштабов было сделано путем внедрения кода в Exchange Online, по-прежнему пролезали проблемы. Например, недавняя проблема в Exchange 2013 CU3, когда клиенты Windows XP не могут использовать IE8 для подключения к OWA.

По мысли Перри существует простой контракт между командой Exchange и корпоративными клиентами: «просто применяйте обновления, и ваша жизнь станет лучше», так что даже одиночная проблема — это слишком много. Такого вида проблем, который мы увидели в Exchange 2013 CU3, «не должно происходить» и что даже не смотря на то, что Майкрософт чувствует уверенность в том, что они держат под контролем эту проблему и внедрили новые проверки и тесты, чтобы улучшить код, который поставляется корпоративным клиентам, им еще надо много работать, чтобы обеспечить в будущем высокое качество обновлений. Перри признает, что корпоративные клиенты не поверят в качество Exchange 2013, пока они не увидят ряд успешных обновлений, которые демонстрируют этот факт. Он сказал, что внутренние данные Майкрософт показывают, что доставка обновлений в лучшем состоянии, чем когда-либо в прошлом, но он также отметил, что трудно реализовать тот вид функциональности, который требуется заказчикам на старых клиентах, особенно когда эти клиенты не поддерживают некоторые базовые основы, необходимые для включения новых функций в таких компонентах как OWA.

Перри ни разу не пытался сказать, что все хорошо с новым кодом. Наоборот он сказал, что каждый новый продукт создает некоторое количество «кочек на дороге» для корпоративных клиентов. Но так как большинство клиентов не производит внедрения до тех пор, пока не выйдет SP1, это дает Microsoft шанс обнаружить, какие элементы отсутствуют или не работают и исправить их в SP1. Перри отметил, что в Exchange 2010 было «больше безумства с тем, что отсутствовало в OWA (в RTM версии, OWA был переписан в Exchange 2010 SP1), чем в текущей ситуации». Он сказал, что была огромная реакция внутри и за пределами Майкрософт, когда появился Exchange 2010, из-за некоторых проблем совместимости и некоторых других проблем, но что SP1 заставил всех забыть исходные проблемы. По его мнению Exchange 2013 сейчас лучше, чем был Exchange 2010 в аналогичный период времени, и когда SP1 выйдет мы увидим ту же степень прогресса.

Я спросил, почему же история с выпусками Exchange повторяется, когда RTM версия забраковывается, а SP1 решает проблемы? Является ли это результатом внутренней политики Майкрософт, которая требует, чтобы Exchange вышел в определенную дату, как это было с выпуском Exchange 2013 RTM, который появился вместе с другими продуктами Office Wave 15? Перри решительно не согласился с этой гипотезой. Так почему же мы видим так много проблем с Exchange 2013 RTM?

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

Перри заключил, что единственным способом получения масштабной обратной связи поэтому является размещение продукта на торговой площадке (marketplace), что и произошло с Exchange 2013 RTM. Клиенты, которые хотели определенный набор функций, имели возможность внедрить и успешно использовать программное обеспечение, в то время как те, которым нужны были исправления некоторых вещей, должны были ждать очередной версии вроде CU1. Многие будут ждать SP1 и некоторые даже дольше. Перри пришел к выводу, что это «природа корпоративной игры». Он также сказал, что «на поверхности планеты не существует клиента, который способен внедрять основные версии Exchange меньше, чем за три года (после выхода предыдущей основной версии). Системы находятся в пятилетнем цикле: это факт жизни.»

Некоторые могут не согласиться с этим, но я думаю, что это утверждение выражает некоторое вполне естественное разочарование разработчиков ПО от того, что их работа не используется так быстро, как этого бы хотелось. Конечно, то, что Exchange имеет огромную базу инсталляций, является как преимуществом, так и проблемой, т.к. потребуется много времени, чтобы модернизировать основную часть инсталляций. Это не новое явление: то же самое верно для операционных систем и было верно в 80-е годы, когда команда, в которой я работал в Dell, пыталась убедить клиентов, внедрять новые версии системы ALL-IN-1, которая была в то время ведущей системой корпоративной почты. Но Перри действительно ценит объем инсталляций Exchange, потому что это гигантский актив Майкрософт.

В силу выше сказанного новая модель обслуживания Майкрософт для Exchange основывается на двух принципах: во-первых, они никогда не будут замораживаться на два или три года, это означает, что продукт будет находиться в состоянии постоянного совершенствования путем обновлений, которые будут предоставляться клиентам в виде инкрементных обновлений. Второй принцип заключается в том, что должен быть принят некоторый метод, который даст возможность клиентам идти в ногу с разработчиками, внедряя инкрементные обновления. Эти принципы привели к ежеквартальному ритму выпуска кумулятивных обновлений, который ныне существует для Exchange Server 2013.

Объясняя логику, срытую в кумулятивных обновлениях, каждое из которых представляет собой полнофункциональную версию Exchange и может быть установлено на чистую систему, Перри отметил, что с другой стороны традиционные основные версии состоят из трех частей: 1 – изменения в пользовательском интерфейсе, улучшении существующей функциональности и улучшение качества (bug fixes); 2 – архитектурные изменения, которые дают возможность воспользоваться преимуществами новых технологий и нового оборудования – смещение Exchange в сторону оперативной памяти от дисков является хорошим примером того, как Майкрософт использовала тот факт, что память значительно дешевле для повышения производительности; 3 – развитие того, как должен работать пользователь (user experience) в свете новых технологий и изменений в окружающем мире – пример этого мобильные устройства.

Перри сказал, что задача Майкрософт в том, «как упаковать дополнительные улучшения в обновления и уложить разрушительные вещи в корзины, которые заказчики могут использовать». Основные версии изменяют всю экосистему вокруг Exchange, Майкрософт должен объяснять своим партнерам, что из себя представляют основные версии и почему они важны, включая «глубокие раздумья», которые привели к этим изменениям. Клиенты берут эту информацию и знания о новом ПО и помещают их в контекст их собственных бизнес требований и существующей инфраструктуры, чтобы оценить, как они могут построить стратегию внедрения, которая обосновывает необходимые расходы на проект миграции, включая расходы на новые компьютеры. Он сказал, что «никто не запрашивает у нас разрушительные вещи чаще, чем мы сейчас предоставляем. Во всяком случае, они хотели бы темп помедленнее».

Так мы пришли к циклу выпуска версий состоящего из инкрементных обновлений завершающихся выпуском новой основной версии каждые три года или около того. Переход к новому ритму вызвал проявление некоторых проблем, которые клиенты видят как проблемы качества, которые просачиваются в обновления. Перри считает, что эта модель устаканивается по мере того, как Майкрософт и клиенты привыкают к ней, и он уверен, что «инкрементный поток (обновлений) будет более надежным движением вперед».

Exchange и облако

Возвращаясь к теме облака и к тому, почему так важно сегодня размещать платформы в облаке, мы обсудили, как Майкрософт разработала план превращения Exchange в облачное приложение. Перри рассказал, как после выпуска Exchange 2003, Майкрософт пришлось сесть и наметить план перевода Exchange в состояние, где она могла бы заниматься некоторыми техническими разработками, которые они могли предсказать на тот момент, и могла бы исправить некоторые глубинные технические и архитектурные недостатки, которые были в Exchange 2000 – большинство из этих недостатков были решены в Exchange 2003, но некоторые потребовали трех версий, чтобы трансформировать Exchange из продукта, в котором компоненты были «тесно связаны и слабо структурированы», в ситуацию, которая существует сегодня, где акцент делается на «слабой связанности и глубокой структурированности». (Лучший пример того, где это изменение произошло, это то, что Exchange 2013 твердо настаивает на том, чтобы серверы взаимодействовали, используя небольшое количество четко определенных протоколов, таких как SMTP, Exchange Web Servioces и MSRProxy).

В 2005 году облако получило немало серьезной поддержки и обещало оказать серьезное влияние на будущее, при этом было очевидное осознание того, что не существует «способа, которым бы вы могли взять команду разработчиков, код и базу знаний (которая была наработана в корпоративной среде) и перенести все это в облако».

В некоторых отношениях задача использования кода параллельно та же, с которой Майкрософт столкнулась, когда разрабатывала Windows NT, чтобы прорваться на корпоративный рынок и отойти от создания только настольных клиентов. Казалось бы, что «должен был бы потребоваться чистый лист бумаги и новая организация, чтобы двигаться вперед» к превращению приложений вроде Exchange в облачные приложения. Перри сказал, что при таком подходе были очевидны две проблемы – внутри себя Майкрософт вынужден был бы отказаться от большей части кода, людей и знаний, и они вынуждены были бы отказаться от корпоративных инсталляций (которые составляли на тот момент более 100 миллионов почтовых ящиков).

Я спросил, а не кажется ли ему, что сегодня корпоративные заказчики чувствуют себя брошенными, учитывая явное стремление Майкрософт перенести все в облако. Перри признал, что такое восприятие может существовать, но указал, что в 2005 году было три варианта:

· Игнорировать облако и сконцентрироваться на корпоративном ПО

· Построить новую команду и новый продукт на основе облачной технологии

· Выяснить как согласовать обе платформы

Первый вариант полностью игнорировал бы платформу, которая сегодня так важна, и уступил бы господство на рынке облачных почтовых систем Google. Второй вариант уменьшал бы объем установленных систем и привел бы к все большему и большему их устареванию. Это приемлемый вариант для новичка на рынке почтовых систем и это путь, который выбрала Google, когда они разрабатывали Gmail. Этот вариант должен был бы также вызвать «панику» внутри Майкрософт, т.к. части компании старались бы сохранить клиентов, влияние, что подорвало бы возможность новой продуктовой команды выпускать новый продукт. Третий вариант, который выбрала Майкрософт, и который, как показало время, оказался самым ценным, хотя преобразования в архитектуре и коде и вызвали некоторые проблемы, которые клиенты видят как недостатки и проблемы качества. Перри считает, что Майкрософт держит под контролем эти проблемы, т.к. код все более устаканивается, и Майкрософт все лучше управляет единой кодовой базой, которая служит и корпоративной, и облачной платформам. Некоторые доказательства этому видны в CU3 Exchange 2013, который имеет меньше обнаруженных проблем, чем RTM, CU1 или CU2.

Перри сказал, что сегодня существует не так много клиентов, которые не обдумывали бы двигаться в облако или нет. Он сказал, что «очень большой процент клиентов не движется в облако», но что «два года назад, когда клиенты думали о том, что делать (относительно будущего большого обновления), процент клиентов, которые рассматривали облачную стратегию, был гораздо меньше». Он считает, что компаниям требуется время, чтобы осмыслить новые разработки и выяснить, когда им выгодно их освоение. Тот факт, что Office 365 представил функциональный и надежный сервис с июня 2011 года, помогает многим клиентам сделать выводы.

Если компания не знает, что делать с облаком, то она может пойти и создать тестовый домен в Office 365, чтобы прицениться и выяснить, что хорошо и что плохо в облачных системах. Это легко и это доступно. Запустить облачный пилот сегодня намного легче по сравнению с организационными и техническими усилиями, которые требуются для запуска нового ПО в корпоративной среде. Это помогает ИТ становиться более гибкой и принимать более обоснованные решения.

Учитывая, что многим клиентам трудно внедрять новое ПО так быстро, как оно выпускается Майкрософт, мы обсуждали, как много из установленных систем смигрируют в Office 365, где Майкрософт заботиться о развертывании и управлении этим ПО. Получим ли мы ситуацию, предсказанную некоторыми комментаторами, когда смигрируют целиком все установленные системы, или значительная часть останется в корпоративной среде?

По мнению Перри, что даже не смотря на то, что существует много «признанных идейных лидеров» (в том числе внутри Майкрософт), которые предсказывают, что 100% клиентов будут в облаке, это ошибка, и что многие клиенты имеют операционные и бизнес основания, чтобы остаться в корпоративной среде. Клиенты слышат от людей (в том числе от аналитиков рынка), которые признаны на рынке, что все идет в облако, но это не дает бизнесу понимания. В терминах Перри это «орешки».

И хотя ему было не раз сказано за его 17-тилетнюю карьеру в Майкрософт, что электронная почта умерла, Перри указал на «уровень инвестиций, которые делают клиенты в почтовые системы каждую секунду дня» для обеспечения доступа к почте с любого устройства из любой точки. Это создает «интересные задачи в обеспечении безопасности, конфиденциальности и утечки информации». Майкрософт пришлось продумать эти проблемы для того, чтобы разработать Office 365 для больших масштабов, и этот опыт, по мнению Перри, «чрезвычайно ценен для наших клиентов».

Учитывая фактические данные по Office 365 и доступные факты по рынку, мы оба согласились, что где-то процентов 40 от установленных систем останется в корпоративной среде как минимум несколько лет (с моей точки зрения, возможно, намного дольше), и это дает Майкрософт довольно значительный повод гарантировать, что это ПО останется высоко функциональным. Перри признал, что это действительность и указал на большие инвестиции, которые Майкрософт предпринимает, чтобы гарантировать поддержку корпоративной и облачной платформ с большой совместимостью между ними.

Мобильные вычисления

Одно из крупнейших изменений в последние годы, которое отметил Перри, заключается в изменении центра внимания клиентов от простого обсуждения стоимости почтового ящика к тому, как они могут сделать их пользователей более продуктивными. В прошлом заказчики не сказали бы Майкрософт о новом ПО, если бы оно не могло уменьшить стоимость; теперь они хотят знать, какие возможности существуют, чтобы сделать их работников более продуктивными во всех смыслах этого слова. Это изменение в ИТ привело к изменению того, как Майкрософт думает о продуктах подобных Exchange. Часть этого изменения была спровоцирована взрывом возможностей мобильных устройств и сетей, которые позволяют людям оставаться постоянно подключенными к сервисам вроде электронной почты.

Я спросил о Exchange ActiveSync (EAS) и его будущем, т.к. кажется не так много изменилось за последние несколько лет. Перри сделал смелое утверждение, что «Я не думаю, что Apple были бы настолько успешными с iPhone против RIM (производитель Blackberry устройств – прим. переводчика) на корпоративном рынке, если бы мы не создали экосистему EAS. Теоретически возможно, чтобы Apple создало хорошего клиента (для Exchange), используя другие протоколы, но маловероятно, чтобы они инвестировали бы необходимые средства в их собственный клиент. Просто не существует способа, чтобы они (Apple) смогли бы разработать MAPI клиент (для подключения к Exchange)».

Это конечно справедливо сказать, что Exchange ActiveSync (EAS) является стандартом подключения мобильных устройств к Exchange. Ранние версии iPhone были ограничены подключениями по POP и IMAP, но как только Apple лицензировало EAS, iPhone-ы безусловно получили распространение внутри корпораций. Нет никаких сомнений, что появление iPhone вслед за Android и Windows Phone устройствами, использующими EAS для подключения к Exchange, ознаменовало начало упадка RIM, так как меньшее число компаний могут оправдать покупку дорогих лицензий BlackBerry Enterprise Server (BES), в то время как Майкрософт предоставляет EAS бесплатно со времен Exchange 2003 SP1.

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

Далее Перри сказал, что появление все более функциональных мобильных устройств сделало трудным для платформ, которые используют подход на основе синхронизации (т.е. ActiveSync), сохранять соответствие развитию функциональности на сервере. Люди хотят использовать новейшие возможности их мобильных устройств, но производители устройств не могут обновлять их клиенты достаточно быстро, и в любом случае протокол EAS не поддерживает множество функций, которые доступны для других Exchange клиентов. Возможность пойти в репозиторий подобный iOS app store и загрузить код, который предоставляет полную функциональность Exchange, является «уникальным механизмом для смены правил игры», который будет стимулировать производительность труда пользователей. Перемещение логики с клиентов на сервер дает Майкрософт возможность предоставлять «полный набор пользовательских возможностей» на весь набор мобильных устройств всех форм-факторов, без необходимости создания много раз однотипной функциональности многими производителями. Еще одним преимуществом является то, что Майкрософт может воспользоваться достоинствами, которые существуют на каждой платформе, подобно браузеру Safari на iOS. Все это вместе стало абсолютной реальностью в Outlook Web App for Devices, выпущенном ранее в июле 2013 года для iOS.

Возникает естественный вопрос, что Майкрософт собирается отказаться от EAS и сосредоточится на приложениях, которые публикуются Майкрософт и обновляются на регулярной основе. Выразительный ответ Перри заключается в том, что в то время как производство собственных мобильных клиентов будет представлять собой «растущую часть этой истории», Майкрософт продолжит вкладывать значительные средства в EAS, который сейчас используют для подключения намного больше клиентов, чем когда-либо ранее, и Перри объявил, что «ежегодно продается порядка миллиарда мобильных устройств с EAS на борту».

Перри также указал, что Майкрософт тратит много времени, чтобы поощрять лицензиатов EAS правильно реализовывать EAS в их коде, и что группа Exchange изучила некоторые «ошибки», которые были сделаны в EAS и улучшила возможность сервера противостоять эффектам со стороны плохо реализованных клиентов. Он отметил, что сам размер экосистемы EAS означает, что влияние любой ошибки является «в самом деле огромным», потому что ощущается сотнями миллионов пользователей, и что Майкрософт очень серьезно берет на себя ответственность за предоставление безопасного и надежного протокола.

В то же время они будут выделять необходимые ресурсы для удовлетворения потребностей высоко функциональных мобильных клиентов, которые могут использовать новейшие технологии в браузерах, работающих на мобильных устройствах. «Линии размываются, когда дело доходит до главных вычислительных устройств»,- сказал Перри, имея в виду, что Майкрософт должен поставлять хорошие наработки на смартфоны и планшеты высшего класса. Дискуссия о том, как наилучшим образом предоставлять наилучшие мобильные наработки продолжается на постоянной основе как с Apple, Sumsung и другими производителями, так и с собственной командой Майкрософт разрабатывающей Windows Phone. Перри отметил, что «теперь это больше не просто почтовый клиент, существует также возможность использовать Exchange Web Services для взаимодействия с сервером интересными способами. Количество инноваций и инвестиций, которые происходят здесь, на самом деле огромно. Это чрезвычайно интересная область».

Моя интерпретация происходящего – EAS остается как наименьшая общая мерка функциональных возможностей подключения к Exchange (тем не менее с возможностью включения на высоко функциональных клиентах) в тандеме с набором клиентов на основе браузера, которые предоставляют больше возможностей сервера. Майкрософт может предоставлять новые версии этих клиентов через облако гораздо быстрее, чем они могут получить новые функции через расширения EAS предоставляемые производителями мобильных устройств. Учитывая разнообразие (не всегда хорошее) клиентских приложений с поддержкой EAS реализованных на платформах Windows Phone, Android и iOS, я думаю это разумный подход, но мы должны подождать и посмотреть, как OWA for Devices будет распространяться в последующие несколько лет.

В заключение

Мы обсудили необходимость улучшения безопасности электронной почты и шифрования между конечными точками в свете откровений PRISM и требования защиты содержимого сообщений, когда они передаются между компаниями. Перри сказал, что «неразумность отправки SMTP в открытом виде будет устранена», и что Майкрософт будет работать с партнерами, чтобы решить эту проблему стандартным образом. Хотя не существует твердой даты, когда это произойдет, но это должно произойти достаточно скоро. Несомненно, что все мы должны будем обновить ПО (надеюсь через инкрементные обновления), чтобы получить этот уровень защиты.

Мы закончили разговор обсуждением предстоящей конференции Microsoft Exchange Conference (MEC), которая пройдет в Остине, штат Техас, в начале апреля 2014 года. Перри с нетерпением ожидает MEC, потому что он полагает, что команда Exchange расставит ключевые вехи, которые опровергнут часто повторяемое предсказание так называемых экспертов, что электронная почта в скором времени сойдет на нет. Он хочет показать, что сервер подобный Exchange может выступать как точка опоры для многих форм естественной и эффективной совместной работы. Будет интересно посмотреть на повестку дня MEC, которая должна подтвердить данные в этих словах обещания. Мы увидим это в свое время!

Реклама

Один ответ

  1. […] Перевод, Ilya Sazonov Беседа с Перри Кларком […]

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: