WEBVTT

00:00:00.000 --> 00:00:01.740
Привет, меня зовут Томас Маурер.

00:00:01.740 --> 00:00:04.770
Я облачный адвокат в корпорации Майкрософт
и я сижу здесь с

00:00:04.770 --> 00:00:06.645
Чанг» из команды управления Azure

00:00:06.645 --> 00:00:08.635
говорить о гибридных
Управление серверами.

00:00:08.635 --> 00:00:11.300
Да, да. Привет. Я
Менеджер программы в Azure.

00:00:11.300 --> 00:00:14.100
Привет. Так что я много говорю с

00:00:14.100 --> 00:00:17.925
клиентов, использующих
Облако для вычислительных ресурсов.

00:00:17.925 --> 00:00:20.610
Но большинство из них или
многие из них также имеют

00:00:20.610 --> 00:00:22.950
серверы, работающие в их
частные центры обработки данных,

00:00:22.950 --> 00:00:24.495
в своих филиалах,

00:00:24.495 --> 00:00:26.910
или даже есть другие части в
организации, которую они

00:00:26.910 --> 00:00:30.195
использовать другого поставщика облачных услуг или
других поставщиков услуг.

00:00:30.195 --> 00:00:31.830
Одна из основных проблем, связанных с

00:00:31.830 --> 00:00:34.490
все эти серверы они
есть в основном поддержанию

00:00:34.490 --> 00:00:36.400
контроль над всеми этими
серверов, когда они

00:00:36.400 --> 00:00:38.620
работает, чтобы убедиться,
что они в безопасности,

00:00:38.620 --> 00:00:42.085
что они патч, что
они имеют соответствие.

00:00:42.085 --> 00:00:44.585
Я слышал, что Лазурный
команда и особенно вы

00:00:44.585 --> 00:00:46.760
работают над чем-то
что помогает в этом.

00:00:46.760 --> 00:00:49.940
Да, да. Абсолютно
Я люблю говорить о

00:00:49.940 --> 00:00:53.240
это, и я был на самом деле эхо
то, что вы только что упомянули.

00:00:53.240 --> 00:00:55.835
Это действительно огромная проблема.

00:00:55.835 --> 00:00:59.990
Так что я говорил со многими клиентами
а особенно они нуждаются

00:00:59.990 --> 00:01:03.890
управлять этим очень нравится
Гибридные среды,

00:01:03.890 --> 00:01:05.345
так что мы повсюду

00:01:05.345 --> 00:01:07.490
с командой приложений
пытается просто выйти,

00:01:07.490 --> 00:01:08.930
получить все ресурсы, которые им нужны.

00:01:08.930 --> 00:01:10.010
Не имеет значения, какой Облако,

00:01:10.010 --> 00:01:12.845
они просто войти и
развернуть вещи там.

00:01:12.845 --> 00:01:15.560
ИТ, с другой стороны,
пытаясь понять,

00:01:15.560 --> 00:01:17.540
Боже мой, где все вещи?

00:01:17.540 --> 00:01:19.070
Где все данные?

00:01:19.070 --> 00:01:21.650
Что произойдет, если
что-то было нарушено?

00:01:21.650 --> 00:01:24.545
Особенно сейчас вы видите
новости повсюду.

00:01:24.545 --> 00:01:29.210
Так что это действительно что-то
Azure всегда думал

00:01:29.210 --> 00:01:31.760
о и особенно услугах

00:01:31.760 --> 00:01:34.970
сегодня, что уже
управление службой на прем.

00:01:34.970 --> 00:01:36.470
Но теперь с этой услугой,

00:01:36.470 --> 00:01:39.620
мы действительно принимаем его
на следующий шаг к

00:01:39.620 --> 00:01:43.160
интегрировать эти серверы
более родной в Azure.

00:01:43.160 --> 00:01:44.975
Хорошо, хорошо. Звучит фантастически.

00:01:44.975 --> 00:01:46.640
Поэтому, когда вы говорите об интеграции

00:01:46.640 --> 00:01:49.115
служба в Azure,
что вы подразумеваете под этим?

00:01:49.115 --> 00:01:51.260
Да, да. Я люблю показывать
Вы картина его.

00:01:51.260 --> 00:01:52.070
Идеально. Спасибо.

00:01:52.070 --> 00:01:56.630
Вот как услуги
управления этими средами.

00:01:56.630 --> 00:01:59.070
Таким образом, эти услуги на самом деле,

00:01:59.070 --> 00:02:01.560
все удалось на прем службы сегодня.

00:02:01.560 --> 00:02:03.470
Кстати, я звоню.
сервер на прем

00:02:03.470 --> 00:02:05.480
но это действительно не
вопрос, где они находятся.

00:02:05.480 --> 00:02:07.400
Они могут быть на прем в центрах обработки данных,

00:02:07.400 --> 00:02:10.580
частных центров обработки данных или в
других хостов Облака.

00:02:10.580 --> 00:02:11.975
Но, как вы можете видеть,

00:02:11.975 --> 00:02:15.170
все эти серверы, управляющие
Виртуальные машины Azure через

00:02:15.170 --> 00:02:18.515
то, что называется Azure
Менеджер ресурсов, кратко ежект ПО ARM,

00:02:18.515 --> 00:02:21.305
и где на прем-серверах,

00:02:21.305 --> 00:02:24.485
они действительно должны понять,
из способ получить свой код

00:02:24.485 --> 00:02:28.220
развернуты на тех, на prem
серверы по отдельности.

00:02:28.220 --> 00:02:29.840
Итак, как вы можете видеть,

00:02:29.840 --> 00:02:32.180
есть некоторое неравенство между

00:02:32.180 --> 00:02:35.540
трубки панели и это

00:02:35.540 --> 00:02:39.320
это действительно то, что я имею в виду по родной
интегрированы в ARM.

00:02:39.320 --> 00:02:43.315
Теперь они получают прогнозируемые как
ресурс ARM в Azure.

00:02:43.315 --> 00:02:45.295
Выгода будет огромной.

00:02:45.295 --> 00:02:48.220
Как вы можете видеть много
инвестиции пошли в ARM;

00:02:48.220 --> 00:02:50.710
как идентичность, как
RBAC, как политики.

00:02:50.710 --> 00:02:53.170
Самое главное много
клиенты действительно заботятся о

00:02:53.170 --> 00:02:57.460
соответствие, а также просто регулярные
управления, как пометить их,

00:02:57.460 --> 00:02:59.800
показать, что мои серверы
все в производстве,

00:02:59.800 --> 00:03:03.820
такого рода простые вещи
способны через ARM.

00:03:03.820 --> 00:03:07.930
Так что теперь у меня есть один раз проект
эти серверы в ARM,

00:03:07.930 --> 00:03:09.520
Я получаю все эти преимущества.

00:03:09.520 --> 00:03:12.160
Кроме того, все
услуги теперь могут быть

00:03:12.160 --> 00:03:16.725
на Лазурном берегу, а также
на прем в том же порядке.

00:03:16.725 --> 00:03:18.000
Как вы можете видеть здесь,

00:03:18.000 --> 00:03:22.805
Я назвал это очень важным
компонент под названием Гостевой агент.

00:03:22.805 --> 00:03:25.250
Цель этого
агентом является управление

00:03:25.250 --> 00:03:28.430
жизненный цикл этих
расширений, и мы следуем

00:03:28.430 --> 00:03:30.635
та же модель, так что теперь

00:03:30.635 --> 00:03:34.630
все эти расширения могут быть применены
на прем-сервис, а также.

00:03:34.630 --> 00:03:38.700
Так что это здорово. Таким образом, наши серверы
отображаться как ресурсы Azure.

00:03:38.700 --> 00:03:41.480
Они появляются на портале, а также
в менеджере ресурсов Azure,

00:03:41.480 --> 00:03:44.330
и я могу в основном лечить
их, как машины,

00:03:44.330 --> 00:03:47.195
как я делал с Azure
Виртуальные машины, не так ли?

00:03:47.195 --> 00:03:49.759
Да, да. От
управленческая перспектива,

00:03:49.759 --> 00:03:51.500
это наша главная цель.

00:03:51.500 --> 00:03:54.170
Мы хотели, чтобы все это
решения для управления

00:03:54.170 --> 00:03:57.470
серверы так же
для Azure, а также

00:03:57.470 --> 00:04:03.805
для на прем, а также они
получить ту же выгоду ARM.

00:04:03.805 --> 00:04:05.360
Хорошо, это потрясающе.

00:04:05.360 --> 00:04:07.850
Так что я хочу теперь использовать это.

00:04:07.850 --> 00:04:11.215
Так что вы можете показать мне, как мы
на борту этой службы в Azure?

00:04:11.215 --> 00:04:13.460
Абсолютно, пусть
мне показать вам демо.

00:04:13.460 --> 00:04:15.560
Это страница, которую мы построили, чтобы показать

00:04:15.560 --> 00:04:19.960
все на прем серверов, которые
был на борту в Azure.

00:04:19.960 --> 00:04:23.890
По существу на борту,
клиент должен запустить

00:04:23.890 --> 00:04:27.790
скрипт на сервере и
помочь построить этот сценарий,

00:04:27.790 --> 00:04:32.840
мы на самом деле построить поток в
Azure для создания этого скрипта.

00:04:33.260 --> 00:04:36.235
Так что это вариант, что они могут

00:04:36.235 --> 00:04:39.100
щелкнуть, чтобы создать сценарий
но в то же время,

00:04:39.100 --> 00:04:42.520
он также признает, является проблемой
для клиентов на борту

00:04:42.520 --> 00:04:44.080
шкалы, если они должны подключиться к

00:04:44.080 --> 00:04:46.705
каждый сервер по отдельности
для запуска этих скриптов.

00:04:46.705 --> 00:04:49.240
Таким образом, мы также пытаемся
чтобы понять, что

00:04:49.240 --> 00:04:53.140
некоторые общие на прем-сервер
управление приложением, чтобы мы могли

00:04:53.140 --> 00:04:57.505
интегрироваться, чтобы помочь клиентам
на борту этих машин в масштабе.

00:04:57.505 --> 00:05:00.295
Например, здесь, если
сервер уже

00:05:00.295 --> 00:05:03.100
управляемый службой обновления Azure,

00:05:03.100 --> 00:05:05.120
мы строим на самом деле сценарий

00:05:05.120 --> 00:05:07.640
или runbooks на самом деле
развертывание на борту

00:05:07.640 --> 00:05:10.505
эти машины на Azure

00:05:10.505 --> 00:05:13.055
без фактически клиентов
касаясь всех этих машин.

00:05:13.055 --> 00:05:15.770
Но в будущем, мы также
работа с, например,

00:05:15.770 --> 00:05:19.129
Менеджер конфигурации системного центра
и они также интегрируют

00:05:19.129 --> 00:05:20.870
опыт посадки на борт и

00:05:20.870 --> 00:05:22.580
в дополнение к Windows Admin Center.

00:05:22.580 --> 00:05:25.850
Так что мы просто держать на
расширение о том, как клиенты могут

00:05:25.850 --> 00:05:29.240
на борту в Azure в
наименее усилий путь.

00:05:29.240 --> 00:05:32.630
Но в этом случае, позвольте мне показать
как создать сценарий.

00:05:32.630 --> 00:05:35.510
Так как вы можете видеть эти
являются ресурсами Azure.

00:05:35.510 --> 00:05:37.220
Таким образом, они следуют той же иерархии

00:05:37.220 --> 00:05:39.140
как в подписках
и ресурсной группы.

00:05:39.140 --> 00:05:40.385
Так что теперь вы можете выбрать

00:05:40.385 --> 00:05:44.870
какой подписки и ресурса
группа, они хотели пойти и здесь

00:05:44.870 --> 00:05:46.790
регион указывает, что

00:05:46.790 --> 00:05:48.950
который Azure регион работает

00:05:48.950 --> 00:05:51.980
эти серверы, управляющие
эти ресурсы на прем.

00:05:51.980 --> 00:05:56.930
Таким образом, вы можете видеть из соответствия
или точки зрения регуляторных точек,

00:05:56.930 --> 00:05:59.635
мы знаем, где метаданные
хранится в Azure.

00:05:59.635 --> 00:06:03.620
Физическое местоположение является новым, в частности,
для серверов на прем.

00:06:03.620 --> 00:06:06.245
Это позволяет клиенту
для пометки серверов

00:06:06.245 --> 00:06:10.655
или конкретно указать
в каком центре обработки данных они находятся.

00:06:10.655 --> 00:06:13.940
Это действительно о
легкость управления.

00:06:13.940 --> 00:06:15.440
Хорошо, это довольно круто.

00:06:15.440 --> 00:06:18.650
Таким образом, клиенты не могли просто добавить
имя над центрами обработки данных.

00:06:18.650 --> 00:06:20.330
Таким образом, они могли бы даже, как, например,

00:06:20.330 --> 00:06:22.460
также добавить комнату местоположения или

00:06:22.460 --> 00:06:25.520
даже прямое имя или прямое
номер для сервера?

00:06:25.520 --> 00:06:26.570
Да, абсолютно.

00:06:26.570 --> 00:06:28.670
Так что это действительно для клиента

00:06:28.670 --> 00:06:31.100
легко определить
где этот ресурс.

00:06:31.100 --> 00:06:32.750
Если что-то случится с этим сервером,

00:06:32.750 --> 00:06:34.810
они могут пойти, если им нужно
физический доступ,

00:06:34.810 --> 00:06:37.160
они точно знают,
где они должны быть.

00:06:37.160 --> 00:06:41.825
Здесь мы также позволяем клиенту
выбрать операционные системы.

00:06:41.825 --> 00:06:45.200
Я не совсем конкретно
изложить его, но, как всегда,

00:06:45.200 --> 00:06:48.395
в Azure мы пытаемся принять
Windows, а также Linux.

00:06:48.395 --> 00:06:50.570
То же самое здесь, что мы строим

00:06:50.570 --> 00:06:52.820
два пакета для агента

00:06:52.820 --> 00:06:56.460
на борту либо Windows
Сервер или Linux-сервер.

00:06:57.380 --> 00:07:01.200
Понять много клиентов
для на прем особенно,

00:07:01.200 --> 00:07:03.520
они не хотят
подвергают свои серверы

00:07:03.520 --> 00:07:06.805
Интернет непосредственно, и они
положить его за прокси-сервер.

00:07:06.805 --> 00:07:12.050
Так вот в этом случае наш агент
необходимо подключиться к Azure.

00:07:14.280 --> 00:07:18.400
Если эти серверы не
подключиться к Azure напрямую,

00:07:18.400 --> 00:07:21.610
они могут настроить
прокси-сервер здесь и тогда

00:07:21.610 --> 00:07:26.000
агент сможет общаться
через прокси-сервер.

00:07:26.880 --> 00:07:33.700
Это всего лишь ресурс Azure
возможность, чтобы они могли лавировать

00:07:33.700 --> 00:07:36.220
серверы для обозначения
может быть, кто владеет

00:07:36.220 --> 00:07:39.805
их или же они
являются частью команды.

00:07:39.805 --> 00:07:41.570
Да, да. Это также
означает, что это просто

00:07:41.570 --> 00:07:43.670
как с другими Azure
ресурсов, право.

00:07:43.670 --> 00:07:46.100
Так, например, в моем
среда I тег ресурсов

00:07:46.100 --> 00:07:48.665
на основе производства,
среда развития,

00:07:48.665 --> 00:07:50.375
демо-среды и так далее;

00:07:50.375 --> 00:07:52.265
так что они могут использовать тот же пометки

00:07:52.265 --> 00:07:53.870
для их в основном на прем-серверов?

00:07:53.870 --> 00:07:56.560
Да, точно. Ты понял.

00:07:56.750 --> 00:07:59.340
В конце концов здесь,

00:07:59.340 --> 00:08:01.670
мы создаем этот скрипт.

00:08:01.670 --> 00:08:03.650
Так что теперь вы можете взять копию

00:08:03.650 --> 00:08:06.110
сценарий и запустить его
на целевом сервере.

00:08:06.110 --> 00:08:09.485
Позвольте мне показать вам точно
содержимое скрипта.

00:08:09.485 --> 00:08:11.585
Итак, первый - это действительно три шага.

00:08:11.585 --> 00:08:13.580
Как только вы загрузите пакет,

00:08:13.580 --> 00:08:17.270
но если вы на самом деле уже
загружены и помещены на файл доля,

00:08:17.270 --> 00:08:20.105
Вы можете просто изменить, что для копирования
его от этой доли власти.

00:08:20.105 --> 00:08:23.195
Вторая команда заключается в том, чтобы
установить этот пакет.

00:08:23.195 --> 00:08:25.100
Последний из них является важным

00:08:25.100 --> 00:08:28.515
здесь, которые мы на самом деле
во время посадки на борт.

00:08:28.515 --> 00:08:30.480
Этот инструмент будет на самом деле

00:08:30.480 --> 00:08:33.170
создать ресурс ARM
, а затем ссылку обратно на

00:08:33.170 --> 00:08:37.995
агент, так что в конце
процесса посадки на борт,

00:08:37.995 --> 00:08:40.985
Вы на самом деле увидеть эти ресурсы

00:08:40.985 --> 00:08:44.300
представляя, что физические
сервера на портале Azure.

00:08:44.300 --> 00:08:45.485
О, это потрясающе.

00:08:45.485 --> 00:08:49.115
Таким образом, мы делаем это супер легко в основном
для клиентов на борту

00:08:49.115 --> 00:08:51.050
серверов, в основном создания

00:08:51.050 --> 00:08:53.315
им сценарий они
нужно и, очевидно,

00:08:53.315 --> 00:08:54.500
Я думаю, что они также могут работать

00:08:54.500 --> 00:08:56.630
скрипты против
кратные серверам, если они

00:08:56.630 --> 00:08:58.610
на борту, как не только
один или два сервера

00:08:58.610 --> 00:09:00.035
но, может быть, сотни серверов?

00:09:00.035 --> 00:09:01.355
О, да. Абсолютно.

00:09:01.355 --> 00:09:04.340
Хорошо, это здорово. Сооо
Теперь у меня есть сервер в

00:09:04.340 --> 00:09:05.870
портал, и я вижу, что и

00:09:05.870 --> 00:09:07.520
управлять им с помощью
Менеджер ресурсов Azure,

00:09:07.520 --> 00:09:10.250
какие услуги могут
Я на самом деле использовать сейчас?

00:09:10.250 --> 00:09:12.110
Да, позвольте мне показать вам это.

00:09:12.110 --> 00:09:15.740
Так что если вы нажмете на один из
ресурса, как вы можете видеть здесь,

00:09:15.740 --> 00:09:19.610
мы действительно хотим следовать
Модель виртуальной машины Azure.

00:09:19.610 --> 00:09:25.145
Таким образом, вы можете увидеть список
возможности и по мере продвижения вперед,

00:09:25.145 --> 00:09:28.655
мы собираемся расширить на этих
управления и возможностей.

00:09:28.655 --> 00:09:33.320
Сегодня мы позволяем
двух конкретных услуг.

00:09:33.320 --> 00:09:35.480
Один мы можем интегрировать его с

00:09:35.480 --> 00:09:38.420
Аналитика журнала так, чтобы
Вы можете получить на самом деле получить

00:09:38.420 --> 00:09:41.060
журналы, добавленные в идентификатор ресурса

00:09:41.060 --> 00:09:43.940
и вы можете заделать запрос тех,
журналы в одном центральном месте.

00:09:43.940 --> 00:09:47.630
Так что позволь мне показать тебе. Если я нажму
на "Логи" Я смогу

00:09:47.630 --> 00:09:52.470
чтобы получить все журналы
имеющих отношение к данному серверу.

00:09:54.320 --> 00:09:59.910
Без этого, если клиент пытается
для доступа к журналу для сервера,

00:09:59.910 --> 00:10:01.790
они по существу должны идти
на сервер и фигуру

00:10:01.790 --> 00:10:03.980
из которого идентификатор рабочего пространства подключается к,

00:10:03.980 --> 00:10:05.230
а затем прийти на портал,

00:10:05.230 --> 00:10:07.040
найти, что рабочее пространство, а затем

00:10:07.040 --> 00:10:09.110
вы можете фильтровать на основе
на имя компьютера.

00:10:09.110 --> 00:10:10.865
Теперь, когда эта интеграция,

00:10:10.865 --> 00:10:13.130
Вы можете просто нажать здесь

00:10:13.130 --> 00:10:15.440
, а затем получить все журналы
принадлежат одному и тому же серверу.

00:10:15.440 --> 00:10:16.700
О, это фантастика.

00:10:16.700 --> 00:10:18.470
Это также помогает мне, как,

00:10:18.470 --> 00:10:19.760
Я вижу много клиентов, имеющих

00:10:19.760 --> 00:10:21.560
различные части организации

00:10:21.560 --> 00:10:24.590
и некоторые из них просто
действительно приложение сосредоточено,

00:10:24.590 --> 00:10:28.040
так что теперь я могу просто дать доступ
этой конкретной команде, чтобы

00:10:28.040 --> 00:10:30.410
определенный набор
серверы, и они могут

00:10:30.410 --> 00:10:33.360
просто получить доступ к замкам для подач?

00:10:33.360 --> 00:10:36.020
Да, это на самом деле большой
пользу вам, что упомянутые там

00:10:36.020 --> 00:10:39.200
в марте мониторинговая группа имеет

00:10:39.200 --> 00:10:41.420
выпустила эту новую возможность
называется ресурс

00:10:41.420 --> 00:10:45.620
ориентированная роль RBAC
доступ к журналам,

00:10:45.620 --> 00:10:49.685
и они сделали его доступным для
Azure VMs, теперь с гибридом.

00:10:49.685 --> 00:10:52.705
Теперь вы также можете получить его
для обслуживания на прем.

00:10:52.705 --> 00:10:55.715
О, это потрясающе. Сооо
вы также упомянули политики.

00:10:55.715 --> 00:10:59.285
Да, да. Таким образом, политика Azure

00:10:59.285 --> 00:11:01.700
место, где клиенты могут определить

00:11:01.700 --> 00:11:04.780
их соответствие, а также может
просматривать их статус соответствия.

00:11:04.780 --> 00:11:06.860
Там в этой конкретной категории

00:11:06.860 --> 00:11:09.815
политики под названием Гость
Политики конфигурации.

00:11:09.815 --> 00:11:12.770
Вы можете думать о гость
Политика конфигурации почти как

00:11:12.770 --> 00:11:17.595
политики группы, но для
серверы, не книжаемые домены.

00:11:17.595 --> 00:11:22.800
Так что есть длинный список
Политики конфигурации гостей.

00:11:22.800 --> 00:11:26.495
Сегодня мы сделали 18 встроенных полисов.

00:11:26.495 --> 00:11:30.335
Таким образом, вы можете развернуть
их прямо из коробки.

00:11:30.335 --> 00:11:35.149
Но также есть, если у вас есть
требование, чтобы не встроенный,

00:11:35.149 --> 00:11:37.295
Вы можете создать на самом деле
эти пользовательские политики

00:11:37.295 --> 00:11:40.055
и развернуть их в
уникальной среде.

00:11:40.055 --> 00:11:42.440
С гостем
Политики конфигурации,

00:11:42.440 --> 00:11:46.025
он на самом деле работает через
ARM для VM Azure.

00:11:46.025 --> 00:11:48.695
Теперь с гибридом, они также могут быть

00:11:48.695 --> 00:11:52.275
мониторинг и управление
серверов на прем.

00:11:52.275 --> 00:11:54.090
Итак, как вы можете видеть, я развернул

00:11:54.090 --> 00:11:56.315
некоторые из гость
Политика конфигурации и

00:11:56.315 --> 00:12:00.755
в одном представлении я вижу все
эти несовместимые статусы.

00:12:00.755 --> 00:12:04.865
Если я сверлить вниз я замечаю
политика паролей,

00:12:04.865 --> 00:12:07.610
У меня есть куча
услуг, не соответствующих требованиям.

00:12:07.610 --> 00:12:09.620
Итак, позвольте мне прийти сюда, просверлить,

00:12:09.620 --> 00:12:13.765
то я могу видеть все серверы
что не в соответствии.

00:12:13.765 --> 00:12:17.120
Вы можете увидеть, какой ресурс
группы они принадлежат,

00:12:17.120 --> 00:12:19.475
так что вы можете получить представление
что они делают.

00:12:19.475 --> 00:12:22.145
Но также важно то, что,

00:12:22.145 --> 00:12:26.045
это виртуальные машины Azure
и это серверы на прем.

00:12:26.045 --> 00:12:27.440
Таким образом, с одной точки зрения, вы получите

00:12:27.440 --> 00:12:30.470
полное изображение всех серверов
которые не соответствуют требованиям.

00:12:30.470 --> 00:12:32.030
Вау, это фантастика.

00:12:32.030 --> 00:12:34.179
Так что я вижу все мои серверы,

00:12:34.179 --> 00:12:35.730
не имеет значения, где они работают;

00:12:35.730 --> 00:12:37.770
если они работают в Azure,
если они работают на прем,

00:12:37.770 --> 00:12:40.225
в моих центрах обработки данных, в
мои филиалы,

00:12:40.225 --> 00:12:43.160
Я вижу их до одного вида

00:12:43.160 --> 00:12:45.680
и я могу управлять ими из Azure?

00:12:45.680 --> 00:12:48.830
Да, это наши цели
иметь Azure, чтобы быть

00:12:48.830 --> 00:12:50.930
одно центральное место, и мы хотим

00:12:50.930 --> 00:12:53.545
обеспечить последовательный опыт.

00:12:53.545 --> 00:12:55.230
Так что это фантастика.

00:12:55.230 --> 00:12:56.685
Так что, если я сегодня клиент,

00:12:56.685 --> 00:12:57.930
как я могу получить мои руки на этом?

00:12:57.930 --> 00:13:01.505
Да, так что мы действительно
получение публичного предварительного просмотра сейчас.

00:13:01.505 --> 00:13:03.680
Так что если вы будете следовать
ссылка на экране,

00:13:03.680 --> 00:13:05.990
Вы сможете увидеть
нашей документации и

00:13:05.990 --> 00:13:08.935
процесс о том, как
зарегистрируйтесь в службе.

00:13:08.935 --> 00:13:10.275
Хорошо, хорошо. Фантастика

00:13:10.275 --> 00:13:12.120
и как насчет стоимости для этого?

00:13:12.120 --> 00:13:13.805
О, да. Это отличный момент.

00:13:13.805 --> 00:13:16.730
Получить много вопросов по
сколько я буду платить за

00:13:16.730 --> 00:13:20.135
это и хорошие новости или
хорошая новость в том, что это бесплатно.

00:13:20.135 --> 00:13:22.520
Это означает, что вы
на самом деле не платят

00:13:22.520 --> 00:13:25.070
чтобы на борту ваших машин на Azure,

00:13:25.070 --> 00:13:27.410
и вы только будете платить
для решений

00:13:27.410 --> 00:13:29.510
что вы собираетесь
развернуть на этих серверах.

00:13:29.510 --> 00:13:31.070
Ну, это фантастические новости.

00:13:31.070 --> 00:13:32.630
Так что большое спасибо Чанг.

00:13:32.630 --> 00:13:34.370
Спасибо за то, что здесь и показывая

00:13:34.370 --> 00:13:36.245
нам это гибридный
управленческие возможности.

00:13:36.245 --> 00:13:38.130
Да, спасибо