Дмитрий Мартынов

Microsoft Application Architecture Guide, 2nd Edition опубликован в библиотеке MSDN.

Мы планируем перевод на русский язык этого прекрасного руководства – настольной книги каждого серьезного архитектора.

Опубликованы следующие материалы для архитекторов и разработчиков на русском языке:

• Введение в Microsoft® .NET Services для разработчиков
• Руководство по Microsoft® .NET Access Control Service для разработчиков
• Руководство по Microsoft® .NET Service Bus для разработчиков
• Хранилище бинарных объектов Azure
• Очереди Azure
• Таблицы Azure

Рекомендую ознакомиться с изменениями в Ноябрьском CTP

Большое спасибо Вите Шатохину за перевод!

21 мая на кейноте конференции SoftwarePeople с Владом Габриэлем мы демонстрировали пример миграции существующего сайта на Azure --> softwarepeople.cloudapp.net. Для тех, кто не смог посетить эту конференцию я записал скринкаст, который можно посмотреть в плеере ниже (лучше в полноэкранном варианте – double click) или скачать (альтернативная ссылка).

В следующих постах я подробно расскажу как происходила миграция и приведу примеры кода.

Вычисления «в облаке» – это очень привлекательная идея, но, как говорится, есть нюанс. Вряд ли можно ожидать в обозримом будущем, что все компании переведут всю свою IT инфраструктуру и приложения в Интернет. Скорее всего мы будем наблюдать эволюционный процесс, появление различных гибридных моделей смешанного использования локальных и онлайн сервисов. Многие приложения, например, в финансовой и государственной сфере, еще долго не уйдут в Интернет, какими бы защищенными не были датацентры. Никто сейчас не в состоянии предсказать какими темпами будет идти адаптация идеи cloud computing для корпоративных приложений, хотя рост расходов на сервисы в «облаке» по оценкам IDC к 2012 году вырастет в три раза и достигнет 42 млрд. дол. США. Тем не менее очевидно, что несколько задач будут становиться все более актуальными по мере развития Интернет-каналов и повышения доверия к самой идее. Это интеграция локальных и онлайн сервисов; методики и технологические возможности миграции локальных сервисов в «облако» и обратно – на сервера организации; обеспечение информационной безопасности.

Вероятно, довольно длительное время будут сохраняться три модели потребления сервисов и как следствие устройства IT-департаментов:

• Традиционно локальные сервисы, весь софт на собственных серверах, доступный в локальных или VPN-подобных сетях
• Гибридная модель, часть сервисов потребляется из Интернет и интегрируется с локальным софтом на уровне клиента или сервера
• Онлайн модель, в которой сохраняется только клиентский софт, а серверная часть представляет собой онлайновые сервисы

Частные «облака»

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

Публичные «облака»

Далеко не все организации готовы или имеют возможность завтра перейти к модели вычислений в «облаке». Должен существовать выбор между размещением софта локально или онлайн. Например, организаиця может принять решение о переносе своего корпоративного Веб-портала с локальных серверов в датацентр провайдера. При этом желательно не заставлять пользователей заучивать два набора паролей, а IT-департаменту придумывать схемы синхронизации своих политик управления пользователями с политиками онлайнового портала. Должна существовать технологическая возможность смены модели развертывания и эта возможность должна обеспечиваться на уровне поддерживаемых стандартов и платформенной совместимости. Так корпоративный разработчик Веб-сервисов перейдя на Windows Azure по большому счету не заметит перемен, оказавшись в окружении привычного .NET Framework и SQL Server.

Стив Балмер на московском Ремиксе подтвердил, что осенью 2009 года Azure Services Platform должна перейти из беты в продакшн. В чем основные архитектурные различия между традиционным Веб-приложением и Веб-приложением под управлением Azure?
Посмотрите на диаграмму ниже – это каноническая архитектура традиционного Веб-приложения:

А теперь сравните с архитектурой в Azure:

Архитектура Веб-приложения на Azure в принципе не меняется, но есть ключевые нововведения:

• Горизонтально-масштабируемый Веб-сервер.
• Горизонтально-масштабируемое нереляционное хранилище для таблиц, очередей и больших бинарных объектов (aka BLOB). Хранилище доступно по HTTP(S) как RESTful Веб-сервис.
• Сохраняется возможность использовать СУБД SQL Server, что было объявлено на последней конференции Mix.
• Появляется новый архитектурный элемент – фоновый обработчик для асинхронной обработки (aka Worker Role). Это аналог Windows-сервиса.

Тестирование

Получить тестовый доступ к Azure Services Platform можно здесь. Для экспериментов это не обязательно и можно скачать набор инструментов и попробовать Azure на своем компьютере. Лучше всего это сделать по ссылкам со страницы регистрации или в MSDN.

Одно кино заменяет тысячу слов. Я впервые показал этот ролик на конференции независимых компаний-разработчиков ISV Innovation Day в Москве 13 Марта. Мне кажется всем понравилось.

Before my presentation at our quarterly ISV Community Days had a rather long discussion staying in a circle of ISV techies.

To the left was PM from one of the ERP vendor who're doing Remoting and to the right stayed Web-services guy with process automation app.

It was again a controversy: what use for distributed apps - WS or Remoting.

ERP guy points were:

• Need stateful object model - it allows me to keep objects in memory between calls and therefore perform long running taks a breeze
• XML serializer is too slow
• Having types on the client doesn't confuse - there is a way to update those types when server changes
• No needs for special host process - IIS goes very well for HTTP/SOAP, does all authentication stuff, is secure, etc...
• Remoting will be for ever... By the way what will change in .NET 2.0?

OK, points seem to be reasonable... and... the following was my answers:

• Stateful model? That's probably the biggest dim point on Web-services. Not just because you obviously can have a state for WS in ASP.NET but because it's really a mistakenly mixing activation pattern and state. Yes, it's true that Web-services end-point is activated in singe-call mode by default. For "OLTP" operations it also pushes a good notation of freeing resources and commiting transaction on each call. Another point is state. Before all: question of keeping state is only valid when state resides in memory. Why have state in memory? Because you'd like to offload database.So it's like a cache - a sort of optimization and not a design pattern at all. If consider it this way - you'll discover that when you use Web-services and single-call pattern then there are a number of options to keep a state data around - be it a real cache (Cache API),  external process, static variables or the same bunch of objects that you previously created in Remoting.
• When I hear that something is slow the first question I ask is: did you really measure that? Did you? In which conditions? For which operations? Was it a fair bottleneck or you just think it slower? I'll give an example. You have an interface and some object which implements it. In order to perform some logical operation you need to call 3 methods and set 5 properties on the interface. When you use Remoting it takes N ms. Now you want to compare the same implementation on Web-services and it takes N + M ms. What a pity! And you decide that Web-services terrifically slow. What's wrong here? The interface! You never, ever should design Web-services interface like this. Web-services idea is: 1 logical operations == 1 method == 1 message.
• About types on the client. For me it is about productivity. Good developer is a lazy one. You like update client and server when you change implementation? Let it be... The less dependency the better (if you develop anything more complex than notepad). Think about XML, why it's so successful...
• IIS is good host. Completely agree - it's best. SOAP is also good thing. And single-call pattern is good too. So why did you use Remoting whatsoever in this case?
• Remoting will be, true. It's cool technology and please use it everywhere - but inside boundaries under your control (cross-appdomain, cross process inside your app, etc). In .NET 2.0 we get authentication over TCP and crypto stuff. Look at http://msdn2.microsoft.com/library/59hafwyt.aspx and http://msdn2.microsoft.com/library/k62k71x0.aspx

This posting is provided "AS IS" with no warranties, and confers no rights

The main driving factors here are:

• Customers (support of different product versions)
• Competitors
• Technology trends
• Legacy code (extensive approach of adding functionality)
• Little or none on-site customization during deployment
• Support of different databases

It particularly means that ISVs:

• reduce dependencies on the higher level technologies thus relying upon base platform services, but ...
• must adopt newer technologies to be competitive on the market and ...
• often have to integrate and extend thereby ...
• face with dilemma: to change or not to change?

Some approaches generally taken are:

• Componentization and seeking for code and binary reuse
• Layered architecture to isolate:
• Data access layer
• External changes (protect itself from technology changes)
• Internal changes (free itself to change internals)
• Integration to well-known and respectful brands (e.g. VSIP)
• "Outsourcing" non-inherent functionality (e.g. using Reporting Services or Authorization Manager)

This posting is provided "AS IS" with no warranties, and confers no rights

Many partners that I'm working with now face with client-server to 3-layers migration challenge.
It gets harder in big organizations like banks where developers and other tech staff have grown on mainframes and just recently switched to "newest" client-server.
ISVs on the other hand must support their customers thus maintaining huge legacy code base.
They normally use MS C++ and VB, often Delphi for the client.
So it's a 2-side challenge: switching to 3-layers architecture and finding ways to migrate from the legacy code (while keep everything going).

High level mental flow can be the following:

to be continued...

This posting is provided "AS IS" with no warranties, and confers no rights

Just delivered session on our ".NET Architecture Day for ISV" seminar about Application Server.
There are 3 themes chosen to define W2K3 as a application server:

• Component hosting
• Activation
• Transactions support
• Security
• State
• Communication
• Data access
• Provider model
• Service agents
• Different clients
• Rich (smart) clients
• Web (thin) clients

What I like most - is an accessing transaction services without registering in COM+ catalog - aka "Services without components".
Another often forgotten feature - MSMQ, especially in context of some database server offloading (by serializing access at business logic layer).

It seems like the better way of doing things is to delegate those things to somebody already experienced with them :). That's what exactly why app server is needed!

This posting is provided "AS IS" with no warranties, and confers no rights