WEBVTT

00:00:00.000 --> 00:00:01.740
>> Hola mi nombre es Thomas Maurer.

00:00:01.740 --> 00:00:04.770
Soy un defensor de la nube en Microsoft
y estoy sentado aquí con

00:00:04.770 --> 00:00:06.645
Chang' del equipo de azure management

00:00:06.645 --> 00:00:08.635
para hablar de Híbrido
Administración del servidor.

00:00:08.635 --> 00:00:11.300
>> Sí. Hola. Soy un
Administrador de programas en Azure.

00:00:11.300 --> 00:00:14.100
>> Hola. Así que hablo mucho con

00:00:14.100 --> 00:00:17.925
clientes que están utilizando el
Nube para recursos informáticos.

00:00:17.925 --> 00:00:20.610
Pero la mayoría de ellos o un
muchos de ellos también tienen

00:00:20.610 --> 00:00:22.950
servidores que se ejecutan en su
centros de datos privados,

00:00:22.950 --> 00:00:24.495
en sus sucursales,

00:00:24.495 --> 00:00:26.910
o incluso tener otras partes en
la organización que

00:00:26.910 --> 00:00:30.195
utilizar otro proveedor de Cloud o
otros proveedores de servicios.

00:00:30.195 --> 00:00:31.830
Uno de los principales retos con

00:00:31.830 --> 00:00:34.490
todos estos servidores que
tienen es básicamente mantener

00:00:34.490 --> 00:00:36.400
control de todos estos
servidores siempre que

00:00:36.400 --> 00:00:38.620
corriendo para asegurarse de que
que están seguros,

00:00:38.620 --> 00:00:42.085
que son parche, que
tienen el cumplimiento.

00:00:42.085 --> 00:00:44.585
Escuché que Azure
equipo y especialmente usted

00:00:44.585 --> 00:00:46.760
están trabajando en algo
que ayuda con eso.

00:00:46.760 --> 00:00:49.940
>> Sí. Absolutamente
Me encanta hablar de

00:00:49.940 --> 00:00:53.240
y yo en realidad estaba haciendo eco
lo que acabas de mencionar.

00:00:53.240 --> 00:00:55.835
De hecho, es un gran desafío.

00:00:55.835 --> 00:00:59.990
Así que había hablado con muchos clientes
así como especialmente necesitan

00:00:59.990 --> 00:01:03.890
para manejar estos muy parecidos
Entornos híbridos,

00:01:03.890 --> 00:01:05.345
así que estamos por todas partes

00:01:05.345 --> 00:01:07.490
con el equipo de la aplicación
tratando de salir,

00:01:07.490 --> 00:01:08.930
obtener todo el recurso que necesitan.

00:01:08.930 --> 00:01:10.010
No importa qué Nube,

00:01:10.010 --> 00:01:12.845
sólo entran y
desplegar cosas allí.

00:01:12.845 --> 00:01:15.560
La TI, por otro lado, es
tratando de entender,

00:01:15.560 --> 00:01:17.540
oh Dios mío, ¿dónde están todas las cosas?

00:01:17.540 --> 00:01:19.070
¿Dónde están todos los datos?

00:01:19.070 --> 00:01:21.650
¿Qué sucede si
algo se vioficó?

00:01:21.650 --> 00:01:24.545
Especialmente ahora que ves la
noticias por todas partes.

00:01:24.545 --> 00:01:29.210
Así que esto es realmente algo
Azure siempre ha estado pensando

00:01:29.210 --> 00:01:31.760
sobre y especialmente los servicios

00:01:31.760 --> 00:01:34.970
hoy en día que ya
gestión del servicio on-prem.

00:01:34.970 --> 00:01:36.470
Pero ahora con este servicio,

00:01:36.470 --> 00:01:39.620
realmente lo estamos tomando
al siguiente paso para

00:01:39.620 --> 00:01:43.160
integrar esos servidores
de forma más nativa en Azure.

00:01:43.160 --> 00:01:44.975
>> Está bien. Eso suena fantástico.

00:01:44.975 --> 00:01:46.640
Así que cuando se habla de integración

00:01:46.640 --> 00:01:49.115
el servicio en Azure,
¿Qué quieres decir con eso?

00:01:49.115 --> 00:01:51.260
>> Sí. Me encanta mostrar
que una foto de ella.

00:01:51.260 --> 00:01:52.070
>> Perfecto. Gracias.

00:01:52.070 --> 00:01:56.630
>> Así es como son los servicios
gestión de estos entornos.

00:01:56.630 --> 00:01:59.070
Así que estos servicios en realidad,

00:01:59.070 --> 00:02:01.560
todo administrado servicio bajo reserva hoy.

00:02:01.560 --> 00:02:03.470
Por cierto, te llamo
el servidor local

00:02:03.470 --> 00:02:05.480
pero realmente no
materia donde están.

00:02:05.480 --> 00:02:07.400
Pueden estar en los centros de datos,

00:02:07.400 --> 00:02:10.580
centros de datos privados, o en
otros anfitriones de la Nube.

00:02:10.580 --> 00:02:11.975
Pero como pueden ver,

00:02:11.975 --> 00:02:15.170
todos estos servidores que gestionan el
Azure Virtual Machines a través de

00:02:15.170 --> 00:02:18.515
el algo llamado Azure
Resource Manager, abreviatura de ARM,

00:02:18.515 --> 00:02:21.305
y en qué parte de los servidores en las instalaciones,

00:02:21.305 --> 00:02:24.485
que realmente necesitan para figurar
una manera de obtener su código

00:02:24.485 --> 00:02:28.220
desplegadoen en aquellos en las
servidores individualmente.

00:02:28.220 --> 00:02:29.840
Como pueden ver,

00:02:29.840 --> 00:02:32.180
hay cierta disparidad entre

00:02:32.180 --> 00:02:35.540
el panel del tubo y este

00:02:35.540 --> 00:02:39.320
es realmente lo que quiero decir con nativo
integrado en su ARM.

00:02:39.320 --> 00:02:43.315
Ahora se proyectan como
el recurso ARM en Azure.

00:02:43.315 --> 00:02:45.295
El beneficio será enorme.

00:02:45.295 --> 00:02:48.220
Como se puede ver un montón de
inversión entró en ARM;

00:02:48.220 --> 00:02:50.710
como la identidad, como
RBAC, como políticas.

00:02:50.710 --> 00:02:53.170
Lo más importante es que una gran cantidad de
los clientes realmente se preocupan por

00:02:53.170 --> 00:02:57.460
cumplimiento y también sólo regular
gestión como etiquetarlos,

00:02:57.460 --> 00:02:59.800
mostrar cuáles son mis servidores
están todos en producción,

00:02:59.800 --> 00:03:03.820
ese tipo de cosas simples
todos son capaces a través de ARM.

00:03:03.820 --> 00:03:07.930
Así que ahora tengo una vez proyecto
estos servidores en ARM,

00:03:07.930 --> 00:03:09.520
Recibo todos estos beneficios.

00:03:09.520 --> 00:03:12.160
Además, todos los
servicios ahora pueden ser

00:03:12.160 --> 00:03:16.725
implementado en Azure, así como
de la misma manera.

00:03:16.725 --> 00:03:18.000
Como pueden ver aquí,

00:03:18.000 --> 00:03:22.805
Yo etiquesé este muy importante
componente llamado Agente invitado.

00:03:22.805 --> 00:03:25.250
El propósito de este
agente es gestionar

00:03:25.250 --> 00:03:28.430
el ciclo de vida de estos
extensiones y estamos siguiendo

00:03:28.430 --> 00:03:30.635
el mismo modelo para que ahora

00:03:30.635 --> 00:03:34.630
todas estas extensiones se pueden aplicar
al servicio on-prem también.

00:03:34.630 --> 00:03:38.700
>> Así que eso es genial. Así que nuestros servidores
aparecen como recursos de Azure.

00:03:38.700 --> 00:03:41.480
Se presentan en el portal y también
en Azure Resource Manager,

00:03:41.480 --> 00:03:44.330
y básicamente puedo tratar
como máquinas,

00:03:44.330 --> 00:03:47.195
como solía hacer con Azure
Máquinas virtuales, ¿verdad?

00:03:47.195 --> 00:03:49.759
>> Sí. Desde un
perspectiva de gestión,

00:03:49.759 --> 00:03:51.500
ese es nuestro objetivo central.

00:03:51.500 --> 00:03:54.170
Queríamos todo esto
soluciones para gestionar

00:03:54.170 --> 00:03:57.470
los servidores de la misma manera
para Azure, así como para

00:03:57.470 --> 00:04:03.805
para el estado de seguridad y también para
obtener el mismo beneficio ARM.

00:04:03.805 --> 00:04:05.360
>> Está bien, eso es increíble.

00:04:05.360 --> 00:04:07.850
Así que ahora quiero usar eso.

00:04:07.850 --> 00:04:11.215
Así que puedes mostrarme cómo
incorporar este servicio a Azure?

00:04:11.215 --> 00:04:13.460
>> Absolutamente, deje mosquenos
te muestro una demostración.

00:04:13.460 --> 00:04:15.560
Esta es una página que hemos creado para mostrar

00:04:15.560 --> 00:04:19.960
todos los servidores en las prem que
se ha incorporado a Azure.

00:04:19.960 --> 00:04:23.890
Esencialmente a bordo,
el cliente necesita correr

00:04:23.890 --> 00:04:27.790
un script en el servidor y para
ayudar a construir ese guión,

00:04:27.790 --> 00:04:32.840
en realidad construimos un flujo en
Azure para generar ese script.

00:04:33.260 --> 00:04:36.235
Así que esta es la opción que pueden

00:04:36.235 --> 00:04:39.100
haga clic para generar el script
pero al mismo tiempo,

00:04:39.100 --> 00:04:42.520
también reconocer es un desafío
para que los clientes a bordo

00:04:42.520 --> 00:04:44.080
una escala si tienen que conectarse a

00:04:44.080 --> 00:04:46.705
cada servidor individualmente
para ejecutar estos scripts.

00:04:46.705 --> 00:04:49.240
Así que también estamos tratando de
para entender lo que son

00:04:49.240 --> 00:04:53.140
algunos servidores locales comunes
aplicación de gestión para que podamos

00:04:53.140 --> 00:04:57.505
integrarse para ayudar a los clientes a
a bordo de esas máquinas a escala.

00:04:57.505 --> 00:05:00.295
Por ejemplo, aquí, si
el servidor ya está

00:05:00.295 --> 00:05:03.100
administrado por el servicio de actualizaciones de Azure,

00:05:03.100 --> 00:05:05.120
construimos en realidad el guión

00:05:05.120 --> 00:05:07.640
o los runbooks para realmente
desplegar a bordo

00:05:07.640 --> 00:05:10.505
esas máquinas en Azure

00:05:10.505 --> 00:05:13.055
sin realmente clientes
tocando todas esas máquinas.

00:05:13.055 --> 00:05:15.770
Pero en el futuro, también estamos
trabajando con, por ejemplo,

00:05:15.770 --> 00:05:19.129
System Center Configuration Manager
y también están integrando

00:05:19.129 --> 00:05:20.870
la experiencia de incorporación y

00:05:20.870 --> 00:05:22.580
además del Centro de administración de Windows.

00:05:22.580 --> 00:05:25.850
Así que sólo hemos seguido
ampliando cómo los clientes pueden

00:05:25.850 --> 00:05:29.240
a bordo de Azure en
una manera de menos esfuerzo.

00:05:29.240 --> 00:05:32.630
Pero en este caso, permítanme mostrar
cómo generar el script.

00:05:32.630 --> 00:05:35.510
Así que como pueden ver estos
son recursos de Azure.

00:05:35.510 --> 00:05:37.220
Así que siguen la misma jerarquía

00:05:37.220 --> 00:05:39.140
como en las suscripciones
y grupo de recursos.

00:05:39.140 --> 00:05:40.385
Así que ahora puedes elegir

00:05:40.385 --> 00:05:44.870
que la suscripción y el recurso
grupo que querían ir y aquí

00:05:44.870 --> 00:05:46.790
la región indica que

00:05:46.790 --> 00:05:48.950
que la región de Azure está ejecutando

00:05:48.950 --> 00:05:51.980
estos servidores de gestión
estos recursos en el estado de las condiciones.

00:05:51.980 --> 00:05:56.930
Así que se puede ver desde el cumplimiento
o punto de vista regulatorio,

00:05:56.930 --> 00:05:59.635
sabemos dónde los metadatos
se almacena en Azure.

00:05:59.635 --> 00:06:03.620
La ubicación física es nueva específicamente
para los servidores en las aplicaciones en el estado de la configuración.

00:06:03.620 --> 00:06:06.245
Esto permite al cliente
para etiquetar los servidores

00:06:06.245 --> 00:06:10.655
o indique específicamente
en qué centro de datos se encuentran.

00:06:10.655 --> 00:06:13.940
Esto es realmente acerca de
facilidad de gestión.

00:06:13.940 --> 00:06:15.440
>> Está bien, eso es genial.

00:06:15.440 --> 00:06:18.650
Así que los clientes no podían simplemente añadir
un nombre sobre los centros de datos.

00:06:18.650 --> 00:06:20.330
Así que incluso podrían gustar, por ejemplo,

00:06:20.330 --> 00:06:22.460
también añadir una habitación de la ubicación o

00:06:22.460 --> 00:06:25.520
incluso nombre directo o directo
número para el servidor?

00:06:25.520 --> 00:06:26.570
>> Sí, absolutamente.

00:06:26.570 --> 00:06:28.670
Así que esto es realmente para el cliente

00:06:28.670 --> 00:06:31.100
para identificar fácilmente
donde está ese recurso.

00:06:31.100 --> 00:06:32.750
Si algo le pasa a ese servidor,

00:06:32.750 --> 00:06:34.810
pueden ir si necesitan
para acceder físicamente,

00:06:34.810 --> 00:06:37.160
saben exactamente
donde tienen que estar.

00:06:37.160 --> 00:06:41.825
Aquí también permitimos que el cliente
elegir los sistemas operativos.

00:06:41.825 --> 00:06:45.200
Realmente no específicamente
deletrearlo, pero como siempre,

00:06:45.200 --> 00:06:48.395
en Azure estamos tratando de abrazar
Windows, así como Linux.

00:06:48.395 --> 00:06:50.570
Lo mismo aquí que construimos

00:06:50.570 --> 00:06:52.820
dos paquetes para que el agente

00:06:52.820 --> 00:06:56.460
a bordo ya sea Windows
Servidor o servidor Linux.

00:06:57.380 --> 00:07:01.200
Comprender a muchos clientes
para el pre-prem especialmente,

00:07:01.200 --> 00:07:03.520
no quieren
exponer sus servidores a

00:07:03.520 --> 00:07:06.805
Internet directamente y
ponerlo detrás de un servidor proxy.

00:07:06.805 --> 00:07:12.050
Así que aquí en este caso nuestro agente
necesita conectarse a Azure.do need to connect to the Azure.

00:07:14.280 --> 00:07:18.400
Si estos servidores no son
conectarse a Azure directamente,

00:07:18.400 --> 00:07:21.610
pueden configurar el
servidor proxy aquí y luego

00:07:21.610 --> 00:07:26.000
el agente será capaz de comunicarse
a través del servidor proxy.

00:07:26.880 --> 00:07:33.700
Esto es solo un recurso de Azure
capacidad para que puedan tack

00:07:33.700 --> 00:07:36.220
los servidores para indicar
tal vez quién es el propietario

00:07:36.220 --> 00:07:39.805
ellos o si
son parte de un equipo.

00:07:39.805 --> 00:07:41.570
>> Sí. Esto también
significa que es sólo

00:07:41.570 --> 00:07:43.670
como con otros Azure
recursos, cierto.

00:07:43.670 --> 00:07:46.100
Así que, por ejemplo, en mi
entorno i etiquetar recursos

00:07:46.100 --> 00:07:48.665
basado en la producción,
entorno de desarrollo,

00:07:48.665 --> 00:07:50.375
entornos de demostración, y así sucesivamente;

00:07:50.375 --> 00:07:52.265
para que puedan usar el mismo etiquetado

00:07:52.265 --> 00:07:53.870
para sus servidores básicamente en el momento de la prem?

00:07:53.870 --> 00:07:56.560
>> Sí, exactamente. Entendido.

00:07:56.750 --> 00:07:59.340
Al final aquí,

00:07:59.340 --> 00:08:01.670
generamos este script.

00:08:01.670 --> 00:08:03.650
Así que ahora usted puede tomar una copia de

00:08:03.650 --> 00:08:06.110
el script y ejecutarlo
en el servidor de destino.

00:08:06.110 --> 00:08:09.485
Permítanme mostrarles exactamente
el contenido del script.

00:08:09.485 --> 00:08:11.585
Así que el primero es realmente tres pasos.

00:08:11.585 --> 00:08:13.580
Una vez que descargue el paquete,

00:08:13.580 --> 00:08:17.270
pero si en realidad ya
descargado y puesto en un recurso compartido de archivos,

00:08:17.270 --> 00:08:20.105
sólo se puede cambiar eso para copiar
que fuera de esa parte de poder.

00:08:20.105 --> 00:08:23.195
El segundo comando es
instalar ese paquete.

00:08:23.195 --> 00:08:25.100
El último es el importante

00:08:25.100 --> 00:08:28.515
aquí que en realidad estamos
durante la incorporación.

00:08:28.515 --> 00:08:30.480
Esta herramienta en realidad

00:08:30.480 --> 00:08:33.170
crear el recurso ARM
y luego enlazar de nuevo a

00:08:33.170 --> 00:08:37.995
el agente para que al final
del proceso de incorporación,

00:08:37.995 --> 00:08:40.985
usted realmente verá estos recursos

00:08:40.985 --> 00:08:44.300
presentando que la física
servidor en Azure Portal.

00:08:44.300 --> 00:08:45.485
>> Oh, eso es increíble.

00:08:45.485 --> 00:08:49.115
Así que lo hacemos súper fácil básicamente
para que los clientes a bordo de la

00:08:49.115 --> 00:08:51.050
servidores mediante la creación básica de

00:08:51.050 --> 00:08:53.315
ellos el guión que
necesidad y obviamente,

00:08:53.315 --> 00:08:54.500
Creo que también pueden correr

00:08:54.500 --> 00:08:56.630
los guiones en contra
múltiplos de servidores si

00:08:56.630 --> 00:08:58.610
a bordo como no sólo
uno o dos servidores

00:08:58.610 --> 00:09:00.035
pero tal vez cientos de servidores?

00:09:00.035 --> 00:09:01.355
>> Oh sí. Absolutamente.

00:09:01.355 --> 00:09:04.340
>> Está bien, eso es genial. así que
ahora tengo mi servidor en

00:09:04.340 --> 00:09:05.870
el portal y puedo ver que y

00:09:05.870 --> 00:09:07.520
gestionarlo utilizando el
Azure Resource Manager,

00:09:07.520 --> 00:09:10.250
qué servicios pueden
¿De verdad uso ahora?

00:09:10.250 --> 00:09:12.110
>> Sí, déjame mostrarte eso.

00:09:12.110 --> 00:09:15.740
Así que si hace clic en uno de los
recurso, como se puede ver aquí,

00:09:15.740 --> 00:09:19.610
realmente queremos seguir el
Modelo de máquina virtual de Azure.

00:09:19.610 --> 00:09:25.145
Para que pueda ver la lista de
capacidades y a medida que avanzamos,

00:09:25.145 --> 00:09:28.655
vamos a ampliar en estos
gestión y capacidades.

00:09:28.655 --> 00:09:33.320
Hoy estamos habilitando
dos servicios específicos.

00:09:33.320 --> 00:09:35.480
Uno con el que podemos integrarlo

00:09:35.480 --> 00:09:38.420
Log Analytics para que
en realidad se puede obtener

00:09:38.420 --> 00:09:41.060
los registros agregados al identificador de recurso

00:09:41.060 --> 00:09:43.940
y usted puede consultar esos
registros en un lugar central.

00:09:43.940 --> 00:09:47.630
Así que déjame mostrarte. Si hago clic
en "Logs" voy a ser capaz de

00:09:47.630 --> 00:09:52.470
para obtener todos los registros
relevantes para este servidor.

00:09:54.320 --> 00:09:59.910
Sin esto, si el cliente intenta
para acceder a un registro de un servidor,

00:09:59.910 --> 00:10:01.790
esencialmente necesitan ir
al servidor y la figura

00:10:01.790 --> 00:10:03.980
hacia dónde se conecta el ID del espacio de trabajo,

00:10:03.980 --> 00:10:05.230
y luego venir al portal,

00:10:05.230 --> 00:10:07.040
encontrar ese espacio de trabajo, y luego

00:10:07.040 --> 00:10:09.110
se puede filtrar basado en
en el nombre del equipo.

00:10:09.110 --> 00:10:10.865
Ahora, con esta integración,

00:10:10.865 --> 00:10:13.130
simplemente puede hacer clic aquí

00:10:13.130 --> 00:10:15.440
y luego obtener todos los registros
pertenecen al mismo servidor.

00:10:15.440 --> 00:10:16.700
>> Oh, eso es fantástico.

00:10:16.700 --> 00:10:18.470
Así que esto también me ayuda a como,

00:10:18.470 --> 00:10:19.760
Veo a muchos clientes teniendo

00:10:19.760 --> 00:10:21.560
partes de una organización diferente

00:10:21.560 --> 00:10:24.590
y algunos de ellos son sólo
realmente aplicación enfocada,

00:10:24.590 --> 00:10:28.040
así que ahora puedo dar acceso
a este equipo específico para

00:10:28.040 --> 00:10:30.410
un conjunto específico de
servidores y pueden

00:10:30.410 --> 00:10:33.360
sólo acceder a las cerraduras para los saques?

00:10:33.360 --> 00:10:36.020
>> Sí, eso es en realidad un gran
beneficio que mencionó allí

00:10:36.020 --> 00:10:39.200
es en marzo el equipo de monitoreo ha

00:10:39.200 --> 00:10:41.420
lanzó esta nueva capacidad
llamado el recurso

00:10:41.420 --> 00:10:45.620
papel centrado de RBAC
acceso a los registros,

00:10:45.620 --> 00:10:49.685
y lo hicieron disponible para
Máquinas virtuales de Azure, ahora con el híbrido.

00:10:49.685 --> 00:10:52.705
Ahora también puedes conseguirlo
para el servicio on-prem.

00:10:52.705 --> 00:10:55.715
>> Oh, eso es increíble. así que
también mencionó las políticas.

00:10:55.715 --> 00:10:59.285
>> Sí. Por lo tanto, la directiva de Azure es

00:10:59.285 --> 00:11:01.700
el lugar donde los clientes pueden definir

00:11:01.700 --> 00:11:04.780
su cumplimiento y también puede
ver su estado de cumplimiento.

00:11:04.780 --> 00:11:06.860
Hay una categoría particular de

00:11:06.860 --> 00:11:09.815
políticas llamadas Invitado
Directivas de configuración.

00:11:09.815 --> 00:11:12.770
Puedes pensar en El Invitado
Políticas de configuración casi como

00:11:12.770 --> 00:11:17.595
políticas de grupo, pero para
servidores no unidos a un dominio.

00:11:17.595 --> 00:11:22.800
Así que hay una larga lista de la
Directivas de configuración de invitado.

00:11:22.800 --> 00:11:26.495
Hoy hicimos 18 políticas incorporadas.

00:11:26.495 --> 00:11:30.335
Así que realmente puede implementar
ellos directamente de la caja.

00:11:30.335 --> 00:11:35.149
Pero también hay, si usted tiene un
requisito de que no incorporado,

00:11:35.149 --> 00:11:37.295
en realidad se puede crear
esas políticas personalizadas

00:11:37.295 --> 00:11:40.055
y desplegarlos en
ambiente único.

00:11:40.055 --> 00:11:42.440
Con el Invitado
Políticas de configuración,

00:11:42.440 --> 00:11:46.025
en realidad funciona a través de
ARM para las máquinas virtuales de Azure.

00:11:46.025 --> 00:11:48.695
Ahora, con el híbrido, también pueden

00:11:48.695 --> 00:11:52.275
vigilancia y gobierno
los servidores on-prem.

00:11:52.275 --> 00:11:54.090
Como pueden ver, desplegé

00:11:54.090 --> 00:11:56.315
algunos de los Huéspedes
Políticas de configuración y

00:11:56.315 --> 00:12:00.755
en una sola vista puedo ver todos los
estos estados no conformes.

00:12:00.755 --> 00:12:04.865
Si apero lo hago notar
la política de contraseñas,

00:12:04.865 --> 00:12:07.610
Tengo un montón de
servicios no conformes.

00:12:07.610 --> 00:12:09.620
Así que permítanme venir aquí, profundizar,

00:12:09.620 --> 00:12:13.765
entonces puedo ver todos los servidores
que no cumple con las normas.

00:12:13.765 --> 00:12:17.120
Puede ver qué recurso
grupo al que pertenecen,

00:12:17.120 --> 00:12:19.475
para que puedas tener una idea
lo que están haciendo.

00:12:19.475 --> 00:12:22.145
Pero también aquí es importante que,

00:12:22.145 --> 00:12:26.045
estas son Azure Virtual Machines
y estos son servidores en el tiempo.

00:12:26.045 --> 00:12:27.440
Así que en una vista, se obtiene

00:12:27.440 --> 00:12:30.470
una imagen completa de todos los servidores
que no cumplen.

00:12:30.470 --> 00:12:32.030
>> Wow, eso es fantástico.

00:12:32.030 --> 00:12:34.179
Así que veo todos mis servidores,

00:12:34.179 --> 00:12:35.730
no importa a dónde corren;

00:12:35.730 --> 00:12:37.770
si se están ejecutando en Azure,
si se están ejecutando en el tiempo,

00:12:37.770 --> 00:12:40.225
en mis centros de datos, en
mis sucursales,

00:12:40.225 --> 00:12:43.160
Puedo verlos una sola vista

00:12:43.160 --> 00:12:45.680
y puedo administrarlos desde Azure?

00:12:45.680 --> 00:12:48.830
>> Sí, ese es nuestro propósito
de tener Azure para ser

00:12:48.830 --> 00:12:50.930
el único lugar central y queremos

00:12:50.930 --> 00:12:53.545
proporcionar la experiencia consistente.

00:12:53.545 --> 00:12:55.230
>> Así que eso es fantástico.

00:12:55.230 --> 00:12:56.685
Así que si soy un cliente hoy,

00:12:56.685 --> 00:12:57.930
¿Cómo puedo poner mis manos en esto?

00:12:57.930 --> 00:13:01.505
>> Sí, así que estamos realmente
obtener la vista previa pública ahora.

00:13:01.505 --> 00:13:03.680
Así que si usted sigue el
enlace en la pantalla,

00:13:03.680 --> 00:13:05.990
usted será capaz de ver
nuestra documentación y

00:13:05.990 --> 00:13:08.935
el proceso sobre cómo
inscribirse en el servicio.

00:13:08.935 --> 00:13:10.275
>> Está bien. Eso es fantástico,

00:13:10.275 --> 00:13:12.120
y ¿y qué hay del costo de esto?

00:13:12.120 --> 00:13:13.805
>> Oh sí. Ese es un gran punto.

00:13:13.805 --> 00:13:16.730
Obtenga muchas preguntas sobre
cuánto pagaría por

00:13:16.730 --> 00:13:20.135
y las buenas noticias o
una gran noticia es que es gratis.

00:13:20.135 --> 00:13:22.520
Eso significa que
en realidad no pagan

00:13:22.520 --> 00:13:25.070
para incorporar sus máquinas a Azure,

00:13:25.070 --> 00:13:27.410
y sólo pagarás
para las soluciones

00:13:27.410 --> 00:13:29.510
que vas a
implementar en esos servidores.

00:13:29.510 --> 00:13:31.070
>> Bueno, son noticias fantásticas.

00:13:31.070 --> 00:13:32.630
Así que muchas gracias Chang'.

00:13:32.630 --> 00:13:34.370
Gracias por estar aquí y mostrar

00:13:34.370 --> 00:13:36.245
nosotros este híbrido
capacidades de gestión.

00:13:36.245 --> 00:13:38.130
>> Sí, gracias

