Гибридные соединения: подключение Azure Web Sites к LOB-приложениям с помощью PortBridge

В противоположность распространенному мнению не все происходит в облаке, по крайней мере пока. Точно так же, как не все автомобили стали гибридными (способными использовать разные виды топлива) и большинство бытовой техники до сих пор не являются энергосберегающими, так и добрая часть ПО в ближайшие годы будет по-прежнему выполняться локально на предприятиях. Трудно отказаться от серьезных вложений, и большинство компаний требуют четкого бизнес-обоснования, прежде чем модернизировать существующие приложения. Есть ли солнечные панели на крыше вашего дома? Несмотря на экономию в долгосрочной перспективе и налоговые льготы, люди весьма неохотно вкладывают деньги в их покупку из-за высокой стоимости. И для организаций ситуация ровным счетом такая же, когда дело доходит до перевода их приложений в облако.

Но, к счастью, гибридные соединения позволяют модернизировать приложения использованием мощи облачных ресурсов и параллельно использовать существующие программные сервисы, которые работают на предприятии в его информационном центре. В этой статье я покажу, как создать веб-сайт, использующий Azure Service Bus для подключения к программным сервисам, выполняемым в информационных центрах, которые не относятся к Azure. Вместо того чтобы напрямую задействовать Service Bus API, я буду применять популярную утилиту PortBridge для соединения Azure Web Sites с локальными сервисами.

Гибридные соединения в Azure

Azure включает ряд сервисов для создания гибридных приложений. Для поддержки гибридных соединений чаще всего используются Azure Virtual Network и Azure Service Bus. Azure Virtual Network позволяет расширять корпоративную сеть до Azure, формируя тем самым частную гибридную сеть между Azure и информационным центром. Расширение между Azure и вашим информационным центром осуществляется на сетевом уровне, а не на прикладном, как в Service Bus. Поскольку эта статья посвящена поддержке соединений приложений через Service Bus, я не стану здесь рассматривать Azure Virtual Network. Подробнее см. на bit.ly/QAODgX.

Сервис Service Bus Relay позволяет соединить два приложения, находящиеся за брандмауэром. Приложения могут быть размещены в Azure или в вашем информационном центре или и там, и там. Service Bus Relay дает возможность зарегистрировать WCF-конечные точки (Windows Communication Foundation) вашего приложения в реестре Service Bus в информационных центрах Azure. После этого можно безопасно обмениваться вызовами методов между клиентом и сервером в пределах инфраструктуры Service Bus, а затем взаимодействовать с соответствующими приложениями, выполняемыми в вашем информационном центре. Это идеально, например, в сценарии, где некоей муниципальной компании нужен доступ к HVAC (системе управления отоплением, вентиляцией и кондиционированием) или к счетчикам электроэнергии для сбора данных и отправки важных событий на эти устройства с центрального сервера, выполняемого в Azure. Рис. 1 иллюстрирует этот пример, где муниципальная компания имеет центральный узел распределения, выполняемый в Azure, а устройства находятся в зданиях.

Рис. 1. Сценарий с Service Bus Relay в муниципальной компании

Управляющий шлюз (control gateway) — это устройство, работающее в каждом здании и отвечающее за управление электрическими устройствами. Каждый управляющий шлюз имеет WCF-конечную точку, зарегистрированную в реестре Service Bus с глобально уникальным идентификатором. Всякий раз, когда головной сервис, выполняемый в одном из Azure Compute Services, хочет связаться с конкретным управляющим шлюзом, он открывает соединение по глобально уникальной конечной точке в Service Bus и начинает посылать сообщения управляющему шлюзу или принимать их от него. Как правило, управляющий шлюз размещен за брандмауэром в здании.

А как быть, если вам нужно подключиться с веб-сайта в Azure Web Sites к сервису, отличному от WCF (например, к базе данных SQL Server) и выполняемому на предприятии?

Знакомимся с PortBridge

PortBridge — это утилита, созданная на основе Service Bus API. Она обеспечивает взаимодействие между любыми конечными точками сервиса, использующими TCP и работающими на предприятии и в Azure. Базовая концепция PortBridge и прототип были разработаны Клеменсом Вастерсом (Clemens Vasters) (bit.ly/SI93GM). Я немного модифицировал его для этой статьи и скомпилировал с недавней версией Service Bus SDK. Создавая приложения для Service Bus Relay, вам придется создавать WCF-интерфейс для всех релевантных конечных точек, которые должны быть доступны в облаке. Это может стать весьма утомительным занятием, когда у вас большое количество конечных точек или универсальных конечных точек, например, для баз данных и поисковых систем. Добавление еще одной WCF-абстракции поверх этих сервисов не имеет смысла. Вместо этого вы можете задействовать PortBridge для предоставления конечных точек TCP, не использующих WCF, для поддержки соединений через Service Bus Relay. Клиентские приложения вроде Azure Web Sites смогут тогда использовать преимущества соединения с любым TCP-источником данных, находящимся в вашем информационном центре за брандмауэром. С концептуальной точки зрения, PortBridge создает обобщенный WCF-интерфейс, показанный на рис. 2.

Рис. 2. Обобщенный WCF-интерфейс PortBridge

namespace Microsoft.Samples.ServiceBus.Connections
{
  using System;
  using System.ServiceModel;
  [ServiceContract(Namespace="n:",
    Name="idx", CallbackContract=typeof(IDataExchange),
    SessionMode=SessionMode.Required)]
  public interface IDataExchange
  {
    [OperationContract(Action="c",
      IsOneWay = true, IsInitiating=true)]
    void Connect(string i);
    [OperationContract(Action = "w", IsOneWay = true)]
    void Write(TransferBuffer d);
    [OperationContract(Action = "d",
      IsOneWay = true, IsTerminating = true)]
    void Disconnect();
  }
  public interface IDataExchangeChannel :
    IDataExchange, IClientChannel { }
}

С помощью всего трех обобщенных методов PortBridge действует как прокси между клиентской и серверной конечными точками и пересылает все TCP-вызовы выделенному серверу через Service Bus Relay. Самое крупное преимущество применения PortBridge в том, что вам не придется создавать WCF-интерфейс для каждой конечной точки на предприятии, для которой вы хотите разрешить гибридные соединения.

PortBridge состоит из двух компонентов:

1. агента, который выполняется ближе к клиентскому приложению или в виртуальной машине (VM) в Azure Infrastructure as a Service (IaaS);
2. Windows-службы (или консольного приложения), которая выполняется на предприятии и действует как прокси для конечных точек сервиса, выполняемого в той же среде.

Некоторые распространенные случаи применения PortBridge перечислены ниже:

• подключение к любому локальному источнику данных на основе TCP;
• подключение к сторонним веб-сервисам, которые нельзя перенести в Azure;
• соединения с удаленными рабочими столами.

В этой статье вы узнаете, как развернуть и сконфигурировать PortBridge для поддержки взаимодействия между Azure Web Sites и базой данных SQL Server, выполняемой на вашем локальном компьютере.

Гибридное решение

Azure Web Sites обычно образует клиентский веб-уровень или уровень веб-сервисов вашего приложения. Но во многих ситуациях вы не можете перенести некоторые из источников данных для веб-сайта в Azure. В таких случаях PortBridge — идеальное решение для подключения Azure Web Sites к базам данных, выполняемым на предприятии. Azure Web Sites взаимодействует с PortBridge Agent, а тот — с сервисом PortBridge через Service Bus. Затем сервис PortBridge пересылает вызов нужной базе данных. Рис. 3 иллюстрирует архитектуру гибридного веб-сайта, который я создам в этой статье, а также показывает типичный обмен сообщениями в среде PortBridge (или Service Bus Relay).

Рис. 3. Пример архитектуры PortBridge

1. Консольное приложение PortBridge на предприятии (или Windows-служба) регистрирует TCP-конечную точку базы данных (1433 для SQL Server) в реестре имен Service Bus с уникальным URI. Service Bus Relay открывает исходящее двухстороннее соединение с этим консольным приложением.
2. Когда HTTP- или HTTPS-запрос поступает в Azure Web Sites, веб-сайт открывает соединение с базой данных, как обычно, но по IP-адресу PortBridge Agent VM.
3. PortBridge Agent VM действует как прокси базы данных в облаке и имеет два коммуникационных интерфейса: для приема TCP-запросов и для подключения к конечной точке Service Bus Relay консоли PortBridge.
4. PortBridge Agent направляет запрос к базе данных сервису Service Bus Relay. Изящность этого решения в том, что для Azure Web Sites все идет привычным образом. API для базы данных не меняется — лишь IP-адрес используется другой.
5. Service Bus Relay направляет вызов приложению PortBridge, выполняемому в вашем localhost (или информационном центре).
6. Наконец, вызов достигает базы данных, и данные извлекаются по тому же соединению.

Заметьте, что во взаимодействии поверх PortBridge участвует несколько компонентов, и вам действительно нужна дополнительная VM, которая не понадобилась бы при прямом использовании Service Bus. Как уже упоминалось, здесь преимущество в универсализации предоставления доступа к любым конечным точкам TCP: вы можете повторно использовать ту же PortBridge Agent VM для соединения с несколькими источниками данных, выполняемыми в разных местах. Теперь, когда я показал системную архитектуру решения, займемся его конструированием.

Создание веб-сервиса RESTful

Чтобы не усложнять статью, я спроектирую RESTful-сервис ASP.NET Web API под названием «Countries», который извлекает список всех стран из таблицы в базе данных SQL Server. В процессе разработки я всегда рекомендую до развертывания в облаке компилировать и тестировать локально. На рис. 4 показан код для веб-сервиса Countries.

Рис. 4. Веб-сервис Countries

public class CountriesController : ApiController
{
  private string DatabaseConnectionString { get; set; }
  public CountriesController()
  {
    try
    {
      DatabaseConnectionString =
        ConfigurationManager.
        ConnectionStrings["DatabaseConnectionString"].
        ConnectionString;
      }catch(Exception ex)
      {
        Trace.TraceError(ex.Message);
      }
  }
  // GET: api/Countries
  public IEnumerable<Country> Get()
  {
    return CountryService.GetCountries(DatabaseConnectionString);
  }
  // GET: api/Countries/AD
  public Country Get(string id)
  {
    return CountryService.GetCountry(DatabaseConnectionString, id);
  }
}

У этого веб-сервиса всего два метода: Get и Get(string id). Метод Get получает все страны из таблицы в базе данных, а метод Get(id) — объект Country по коду страны. Рис. 5 иллюстрирует таблицу Countries в локальной базе данных SQL Server.

Рис. 5. Таблица Countries базы данных

На рис. 6 показан класс CountryService, который получает данные от базы данных и возвращает объекты Country.

Рис. 6. Класс CountryService

public class CountryService
{
  public static IEnumerable<Country> GetCountries(string connectionString)
  {
    IList<Country> countries = new List<Country>();
    using (IDataReader reader =
      SqlHelper.ExecuteReader(connectionString,
      System.Data.CommandType.Text, "SELECT CountryId, CountryName,
      CountryCode FROM Country"))
    {
      while(reader.Read())
      {
        Country c = new Country()
        {
          CountryId = Convert.ToInt32(reader["CountryId"]),
          CountryCode = Convert.ToString(reader["CountryCode"]),
          CountryName = Convert.ToString(reader["CountryName"]),
        };
        countries.Add(c);
      }
    }
    return countries;
  }
  public static Country GetCountry(string connectionString,
    string countryCode)
  {
    Country c = new Country();
    using (IDataReader reader =
      SqlHelper.ExecuteReader(connectionString,
      System.Data.CommandType.Text,
      "SELECT CountryId, CountryName, CountryCode FROM Country WHERE
      CountryCode=@countryCode",
      new SqlParameter("@countryCode", countryCode)))
    {
      if (reader.Read())
      {
        c.CountryId = Convert.ToInt32(reader["CountryId"]);
        c.CountryCode = Convert.ToString(reader["CountryCode"]);
        c.CountryName = Convert.ToString(reader["CountryName"]);
      }
    }
    return c;
  }
}
  [DataContract]
    public class Country
    {
      [DataMember]
      public int CountryId { get; set; }
      [DataMember]
      public string CountryName { get; set; }
      [DataMember]
      public string CountryCode { get; set; }
}

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

Настройка PortBridge

Прежде чем перемещать веб-сервис в облако, нужно сконфигурировать и протестировать PortBridge. Поскольку в архитектуре несколько уровней, важно получить конфигурацию всех компонентов. Обычно я создаю таблицу, где перечисляются входные и выходные конечные точки для каждого компонента (табл. 1).

Табл. 1. Конечные точки и местонахождение

В данном случае эта таблица может показаться тривиальной, но для приложений с сотнями конечных точек такая таблица поможет правильно сконфигурировать сервисы. Как уже говорилось, PortBridge Agent находится в VM и имеет две конечные точки: входную от приложения и выходную к конечной точке Service Bus Relay. Аналогично сервис PortBridge, выполняемый на вашей локальной машине, имеет две конечные точки: входную от Service Bus Relay и выходную к базе данных SQL Server. Записав конфигурационные параметры, можно приступать к процессу развертывания.

Создание пространства имен Service Bus

Поскольку коммуникационной основой этого решения является Service Bus Relay, я должен сначала создать пространство имен Service Bus с портала Azure (manage.windowsazure.com), как показано на рис. 7.

Рис. 7. Создание пространства имен Service Bus

Пространство имен countries на рис. 7 является глобально уникальным и будет использоваться для создания глобально уникальной конечной точки для сервиса. Создав пространство имен, щелкните кнопку Connection Information в нижней части страницы, чтобы увидеть информацию о доступе к этому пространству имен. Для доступа к этому пространству имен вам понадобятся Default Issuer и Default Key, показанные на рис. 8, так что отметьте себе и эти параметры.

Рис. 8. Удостоверения для пространства имен Service Bus

PortBridge Agent и приложение PortBridge требуют эти удостоверения для подключения к данному пространству имен.

Конфигурирование приложения PortBridge

Приложение PortBridge имеет собственный конфигурационный раздел:

<portBridge serviceBusNamespace="countries"
  serviceBusIssuerName="owner"
  serviceBusIssuerSecret="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX">
  <hostMappings>
   <!--Открывает порты HTTP, SQL Server, RDP и ElasticSearch-->
     <add targetHost="TREDKAR-W530" allowedPorts="1433" />
  </hostMappings>
</portBridge>

Для подключения к созданному мной пространству имен Service Bus Relay требуется передать пространство имен, имя издателя (issuer name) и секрет. В разделе hostMappings указывается хост целевого сервиса. В моем примере это локальная машина и порт 1433. Вы можете добавить порты через запятую, чтобы сделать доступными несколько конечных точек на том же хосте. Кроме того, можно указать несколько целевых хостов, если только они достижимы с машины, на которой работает приложение PortBridge. По окончании конфигурирования запустите приложение PortBridge на своей локальной машине. Если все идет, как ожидалось, вы должны увидеть экран наподобие показанного на рис. 9.

Рис. 9. Выполняемое приложение PortBridge

Приложение PortBridge создает исходящее соединение с сервисом Service Bus Relay в пространстве имен countries, а также уникальное имя в формате PortBridge/[целевой хост], где [целевой хост] — параметр targetHost в конфигурационном файле приложения PortBridge (рис. 10).

Рис. 10. Соединение с Service Bus Relay

Часть имени, относящаяся к PortBridge, «зашита» в код, а целевой хост меняется в зависимости от количества созданных вами хостов. Важно отметить следующее. Чтобы сохранить имя в пространстве имен уникальным, у каждого целевого хоста должна быть только одна запись в разделе hostMappings конфигурационного файла. Кроме того, если вы неправильно настроили параметр targetHost, созданная конечная точка не подойдет для сервиса, который вы хотите предоставлять, и коммуникации будут невозможны.

Информацию об исходящих портах, требуемых привязками Service Bus Relay, см. bit.ly/1l8lncx.

Конфигурирование PortBridge Agent

Как и приложение PortBridge, PortBridge Agent тоже имеет свой конфигурационный раздел:

<portBridgeAgent serviceBusNamespace="countries"
  serviceBusIssuerName="owner"
  serviceBusIssuerSecret=" XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ">
<portMappings>
<port localTcpPort="1433" targetHost="TREDKAR-W530"
      remoteTcpPort="1433">
<firewallRules>
  <rule source="127.0.0.1"/>
  <rule sourceRangeBegin="208.0.0.0"
        sourceRangeEnd="208.255.255.255"/>
...
</firewallRules>
</port>
</portMappings>

PortBridge Agent имеет раздел portMappings, где вы сопоставляете каждый порт входной конечной точки (localTcpPort) с портом конечной точки Service Bus Relay (remoteTcpPort). Значение целевого хоста должно совпадать с ранее созданным таковым значением в конфигурации приложения PortBridge. Это значение используется для подключения к соответствующей конечной точке пространства имен Service Bus. Если эти два значения не совпадают, приложение не будет работать.

В разделе firewallRules можно явным образом перечислить IP-адреса машин, от которых PortBridge Agent будет принимать запросы. Поскольку мой PortBridge Agent будет принимать запросы от веб-сайта в Azure Web Sites, мне нужно добавить диапазон IP-адресов информационных центров Azure в правила брандмауэра. Вы можете получить диапазон IP-адресов информационного центра Azure по ссылке bit.ly/1l8yDxV.

Чтобы развернуть PortBridge Agent в Azure, перейдите на портал Azure, создайте новую Windows VM, скопируйте файлы PortBridge Agent и запустите PortBridgeAgent.exe. После создания VM убедитесь, что вы открыли конечную точку 1433 для внешнего доступа, чтобы веб-сайт в Azure Web Sites мог обращаться по этому порту в PortBridge Agent VM.

Другой вариант развертывания PortBridge Agent — применение Apps for Azure; это простой способ развертывания приложений Windows Store. Apps for Azure — бесплатное приложение с заранее упакованными VM, уже готовыми к развертыванию, и среди них есть PortBridge VM, показанная на рис. 11. Вы можете установить Apps for Azure с сайта appsforazure.com.

Рис. 11. Apps for Azure для развертывания PortBridge Agent

Заранее упакованная PortBridge Agent VM по умолчанию открывает для коммуникаций конечные точки (порты) 1433 и 80. Если вам нужна другая конфигурация PortBridge Agent, вы должны модифицировать файл PortBridgeAgent.exe.config в папке C:\ddapplications. После настройки этого файла вам придется перезапустить Windows-службу DynamicDeployInitService.

Тестирование и развертывание веб-сервиса Countries

Как только компоненты PortBridge установлены и запущены, вам нужно модифицировать строку подключения к базе данных веб-сервиса так, чтобы она указывала на PortBridge Agent VM:

<add name="DatabaseConnectionString"
  connectionString=
  "Server=tejaswisvm1.cloudapp.net;
  Database=cf10292013;
  Trusted_Connection=True;"/>

Заметьте, что, помимо имени хоста, остальные параметры остаются теми же. Внеся такое изменение в конфигурацию, вы укажете на PortBridge Agent VM, а не напрямую на базу данных. Далее опубликуйте сервис Countries Web API в Azure Web Sites и протестируйте его, перейдя по следующим URI:

1. http://[хост веб-сайта в Azure]/api/Countries — для получения списка всех стран;
2. http://[хост веб-сайта в Azure]/api/Countries/[код страны] — для получения объекта конкретной страны по ее коду.

Если связь между двумя конечными точками работает, оба URI вернут JSON-объекты при вызовах методов. Теперь вы можете вызывать веб-сервис Countries с любого устройства, и вызов будет отправлен от веб-сайта из Azure Web Sites в PortBridge Agent, а затем он достигнет базы данных SQL Server через приложение PortBridge. Данные будут получены из базы данных, выполняемой на вашем локальном компьютере (или в вашем информационном центре).

Соображения по производительности

Поскольку PortBridge — это своего рода уровень абстракции, он неизбежно вызывает задержки в сравнении с архитектурами, где взаимодействие с базами данных идет напрямую или по гибридному соединению виртуальной сети. PortBridge рекомендуется только в сценариях, где виртуальная сеть и прямое взаимодействие невозможны. На момент написания этой статьи Azure Web Sites не поддерживает виртуальные сети, а значит, Service Bus — это единственный вариант поддержки гибридных соединений. В ходе тестов с веб-сервисом Countries я наблюдал задержки, варьирующиеся от 50 до 300 мс. В некоторых сценариях я советую использовать кеширование данных в облаке и лишь периодически обращаться к сервисам, выполняемым в удаленных информационных центрах.

Соображения по безопасности

PortBridge опирается на средства защиты Service Bus Relay. По умолчанию PortBridge защищает соединение при подключении к пространству имен Service Bus, но не использует средства шифрования на уровне транспорта и сообщений. PortBridge Agent предоставляет свой механизм фильтрации IP-адресов, но его не следует считать столь же надежным, как и встроенные механизмы защиты Azure Service Bus. Советую детально смоделировать потоки перед развертыванием решения в производственной среде.

Горизонтальное масштабирование PortBridge

Из архитектуры на рис. 3 кажется, что PortBridge Agent является единой точкой сбоя. Но вы можете горизонтально масштабировать PortBridge Agent, добавив конечную точку с балансировкой нагрузки в VM и создав несколько экземпляров PortBridge Agent VM. Тогда вызовы, исходящие из Azure Web Sites, будут равномерно распределяться между несколькими PortBridge Agent. Но финальная конечная точка (база данных) должна быть рассчитана на обработку такого масштабирования. Вы ведь не хотите горизонтально масштабировать веб- и промежуточный уровни и получить сбой на уровне базы данных. Ваша архитектура должна быть эластичной на всех уровнях.

PortBridge в реальном мире

За последние несколько лет на основе запросов от нескольких крупных заказчиков наша группа создала централизованный узел для обмена сообщениями (messaging hub) в облаке с целью интеграции сторонних приложений с сервисами Azure. Задача заключалась в том, что создать простую модель автоматического конфигурирования (plug-and-play model) для сбора данных от разнообразных источников, а затем предоставлять агрегированные данные конечным пользователям на различных устройствах. Группа решила использовать PortBridge в качестве опоры в создании этой модели, так как это обеспечивает необходимую абстракцию для подключения сервисов, построенных не на основе WCF, к приложениям, выполняемым в Azure. Мы модифицировали код PortBridge для улучшения диагностики, производительности и кеширования. Некоторые успешно реализованные нами сценарии перечислены ниже.

1. Создание унифицированного сервиса обмена сообщениями, который интегрирует 19 разных источников данных в компаниях из списка «Fortune 50», и предоставление разнородных контекстно-зависимых данных работникам на местах в организации заказчика. Быстрый доступ к необходимой информации работникам в поездках был основной целью этого решения.
2. Извлечение данных из тысяч экземпляров приложения, используемого для управления парком грузовых машин для коммерческих перевозок, и хранение этих данных в центральном репозитарии в облаке. Собранные данные использовались для профилактического обслуживания и изучения поведения покупателей. Без Service Bus (и PortBridge) такое приложение обошлось бы в десять раз дороже и потребовало бы куда больше усилий на его разработку.
3. Предоставление материалов по делам (case information) и управление журналами учета рабочего времени (timesheet management) для тысяч юристов на их мобильных устройствах в любой точке мира. Когда такого приложения не было, юристам приходилось ездить в офис после каждого судебного заседания для фиксации потраченного ими времени. С помощью этого мобильного приложения они могут протоколировать свои действия прямо из здания суда.

Заключение

Azure Web Sites и Service Bus дополняют друг друга при создании гибридных веб-приложений. PortBridge — это просто уровень абстракции поверх Service Bus Relay для удобного предоставления конечных точек (не основанных на WCF) в облаке. Я рассмотрел несколько сценариев, которые требовали создания веб-сайтов для агрегации разнородного контента, где данные извлекались из множества веб-сервисов, выполняемых в разных географических точках. Используя PortBridge, эти приложения можно было проектировать, реализовать и тестировать без значительных изменений в коде исходного приложения. После проверки начальной конфигурации PortBridge поддержка соединений работает согласованно при условии доступности Service Bus и веб-сервисов. Хотя PortBridge позволяет быстро создавать гибридные приложения, учитывайте, что он вносит дополнительные задержки в вызовы сервисов. Если ваше приложение критично ко времени ответа, PortBridge может оказаться неподходящим выбором, и вы должны подумать о применении Azure Virtual Network или о переносе сервисов с предприятия в облако. Пройдя вместе со мной решение, обрисованное в этой статье, вы должны были получить необходимые навыки для переноса любых локальных конечных точек в Azure и их вызова с веб-сайта, размещенного в Azure Web Sites.