Archivo de la etiqueta: azure

Creando una VM de Azure desde línea de comandos (Primera parte)

Hoy tenía la necesidad de configurar una máquina virtual de Azure. Podía haber optado por la manera simple, que es conectarme al portal y configurarla, pero ya que tenía el SDK de Azure instalado, he decidido probar a ver cuanto puedo hacer desde línea de comandos.

Creando un grupo de afinidad y una storage account

El primer paso es crear un grupo de afinidad que es, básicamente, una sub-región donde podemos tener varios servicios. En mi caso lo configuraremos en la región del oeste de Europa:

New-AzureAffinityGroup -Name Sample -Location "West Europe"

El siguiente paso es crear una storage account, una cuenta en la que almacenaremos la máquina virtual, en el grupo de afinidad que hemos creado antes

New-AzureStorageAccount -StorageAccountName "NAME" -Label "sqlServer" -AffinityGroup "Sample"

Una vez la hemos creado, la podemos almacenar en una variable para su posterior uso:

$storage = (Get-AzureStorageAccount | where {$_.StorageAccountName -Contains "NAME"})

Finalmente fijamos esta cuenta de almacenamiento como la cuenta por defecto de nuestra suscripción.

Para ello necesitamos el nombre de nuestra suscripción, que lo podemos obtener con este comando:

Get-AzureSubscription

Con el nombre de la suscripción podemos fijar la cuenta de storage actual, usando la variable obtenida anteriormente:

Set-AzureSubscription -SubscriptionName $subscription.SubscriptionName -CurrentStorageAccountName $storage.StorageAccountName

Buscando la máquina que necesitamos desplegar

El primer paso es conseguir la máquina virtual que queremos agregar, para lo cual podemos filtrar y seleccionar solamente las máquinas que cumplen ciertos requisitos:

Get-AzureVMImage | where {$_.Label -match "SQL Server 2014"} | Select Label

Una vez que hemos seleccionado una imagen base, la podemos asignar a una variable para su posterior uso:

$vm = (Get-AzureVMImage | where {$_.Label -match "SQL Server 2014"})[6]

Finalmente podemos crear nuestra máquina virtual, con los comandos New-AzureVMConfig, Add-AzureProvisioningConfig y New-AzureVM:

New-AzureVMConfig -Name "VM-NAME" -InstanceSize Small -ImageName $vm.ImageName | Add-AzureProvisioningConfig -Windows -AdminUsername "USER" -Password "PASSWORD" | New-AzureVM -ServiceName 'SERVICENAME' -AffinityGroup "Sample"

Si todo ha ido bien, podremos ver que, tras ejecutar el siguiente comando:

Get-AzureVM 

Se muestra nuestra máquina virtual en estado de “Provisioning”.

Conclusiones

Ha sido cuanto menos curioso (y más difícil de lo que imaginaba en un principio) no solo por la sintaxis de los comandos, sino porque a veces no somos conscientes de todos los procesos que se ejecutan cuando creamos una máquina virtual.

El hecho de que esto sea un script, es que lo podemos meter en un bucle for y crear 20-50-100 máquinas de la misma manera, según nuestras necesidades.

En el siguiente artículo veremos qué podemos hacer una vez que el provisionamiento está completo. Nos podremos conectar por Powershell como si de SSH se tratara? Podremos descargar el perfil de RDP desde la línea de comandos? La respuesta a esta y más preguntas en el próximo artículo de la serie.

Balanceo de carga y escalabilidad con ASP.net, primer contacto

Una de los problemas a los que no he tenido la oportunidad de enfrentarme, de manera profesional, es manejar carga de servidores web, así que esta semana me he dispuesto a montar un sistema para balancear dos sitios ASP.net alojados en Azure. En este artículo veremos cómo ponerlo en marcha. Ha sido una aventura muy interesante, así que te invito a que sigas leyendo.

La arquitectura

Últimamente tenemos muchas capas de servicios que nos abstraen de la lógica necesaria para todo esto: los Azure Websites pueden escalar automáticamente, Azure proporciona su propio balanceador de carga a través del componente Traffic Manager, y Amazon tiene su Elastic Load Balancer.

Para este escenario, sin embargo, quería montarlo de manera un poco más artesanal, y esta es la arquitectura:

  • Dos Azure Websites diferentes, uno alojado en North Europe y otro en West US.
  • Una máquina virtual, con Linux (aquí meteremos el balanceador de carga) alojada en East Asia.

¿Por qué Linux? Linux tiene una gran importancia en la actualidad en el área de servidores. Llevaba tiempo sin trabajar con él y además parecía divertido combinar las diferentes plataformas.

Identificando las instancias

Un detalle que puede pasar desapercibido si vamos a nuget.org, es que en el pie de página identifican el servidor en el que estamos (You are on XXXX), con lo cual, si refrescamos la página, veremos otro servidor.

nuget

Para esta prueba sería muy útil saber qué servidor está sirviendo los contenidos, así que lo primero que haremos será crear un proyecto por defecto de ASP.net, y sustituir la acción Index de HomeController por:

public ActionResult Index()
{
    ViewBag.Title = "Home Page";
    ViewBag.ServerName = System.Environment.MachineName;
    return View();
}

Por otro lado sustituimos el código de Index.cshtml (la vista) por:

<div class="jumbotron">
    <h1>Load balancing testing</h1>
    <p class="lead">You are on @ViewBag.ServerName</p>
</div>

El resultado (en local) es este:

Lb_local

Una vez que tenemos nuestro sitio funcionando, el siguiente paso es subirlo a dos servidores diferentes, que son en este caso:

Cada máquina tiene un identificador diferente, de esta manera, cuando hagamos el balanceo de carga, podremos saber en qué máquina estamos.

Agregando el balanceador

Para el balanceador he optado por un Ubuntu Server 12 hospedado en una máquina virtual también en Azure. Una de las cosas que no debemos olvidar es abrir el puerto 80 para poder recibir tráfico normal de Internet (para este ejemplo dejamos de lado temas relacionados con HTTPS, certificados SSL y similares). Con Linux tenemos muchas opciones. Estuve probando las siguientes:

Fair

Es una opción muy sencilla para empezar, pero tiene un problema, ya que necesita un componente en cada máquina que queremos balancear, lo cual nos limita el radio de acción. Puede que en otra ocasión…

Balance

A diferencia de Fair, no necesita un componente en cada máquina, lo que era un plus. Sin embargo, el hecho de estar basado en comandos y no en configuración no me acababan de convencer. Finalmente, no pude hacerlo funcionar por problemas de puertos, permisos y otros.

HAProxy

HAproxy es, según he podido leer, el balanceador más completo y configurable. Funciona mediante un fichero de configuración y necesita direcciones IP fijas, ya que, según los ejemplos, está pensado para que los servidores a balancear estén en la misma red. Después de varios intentos, no conseguí que el balanceador funcionara, así que desistí.

Apache

Por último, descubrí que Apache tiene un módulo específico para proxy y balanceo, que se parecía bastante a lo que necesitaba. Aunque parezca matar moscas a cañonazos, al final resultó ser bastante fácil de configurar.

Instalando y configurando Apache

El primer paso es instalar Apache en nuestro sistema:

sudo apt-get install apache2

El siguiente paso es habilitar los componentes necesarios para el balanceador:

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod proxy_balancer

Una vez tenemos activados todos los componentes, debemos escribir la configuración al final (justo antes de la directiva </IfModule>) de /etc/apache2/mods-available/proxy.conf:

<VirtualHost *:80>
ProxyRequests off
<Proxy balancer://mycluster>
    # WebHead1
    BalancerMember http://scaledemo7844.azurewebsites.net:80

    # WebHead2
    BalancerMember http://scaledemoamerica.azurewebsites.net:80

                Order Deny,Allow
                Deny from none
                Allow from all

    ProxySet lbmethod=byrequests

</Proxy>
        ProxyPass / balancer://mycluster/
</VirtualHost>

Finalmente reiniciamos el servicio:

sudo apache2 restart

Si todo ha ido bien (y espero que sí), podemos acudir a http://ubuntubalancer.cloudapp.net/ (actualmente offline), donde accederemos indistintamente a cualquiera de las dos instancias y podremos ver su identificador.

Conclusiones

En este artículo hemos visto cómo podemos escalar nuestra página y usar un balanceador intermedio para gestionar las peticiones. Es un primer paso y todavía quedaría mucho por hacer. En el próximo artículo de esta serie, veremos cómo compartir la sesión entre las diferentes páginas que componen nuestro pequeño cluster.

Enlaces Interesantes:

Y esto son las Interactive Rooms

En las últimas semanas he estado trabajando junto con el resto del equipo de VS Anywhere en una funcionalidad completamente nueva para nuestro Web Workspace, que hemos denominado Interactive Rooms.

Con ella, y aprovechando la recientemente presentada API de Visual Studio Online, podemos iniciar sesiones de colaboración directamente desde el navegador conectados con un repositorio Git o TFSVC, algo que, hasta ahora, resultaba imposible.

En este artículo veremos qué tecnologías y servicios hemos empleado para poder hacer posible este producto.

Obteniendo la información de Visual Studio Online

La API REST de Visual Studio Online, presentada en el pasado TechEd, permite acceder a la información de los ficheros almacenados en un repositorio, para poder comenzar una sesión en un punto específico de la historia del proyecto. Entre la información a la que podemos acceder están:

  • Team projects del portal de Visual Studio
  • Commits de un team project específico
  • Estado del repositorio en un commit específico, es decir, acceso a los ficheros.
  • Acceso a la Team Room del Team Project, para poder emitir mensajes.

Con esto, mostramos esta pantalla para que el usuario seleccione los datos antes de comenzar la sesión:

session

La autenticación está basada en OAuth2, lo que permite, una vez autorizado, poder realizar llamadas a la API sin tener que solicitar el usuario y la contraseña una y otra vez. El funcionamiento de OAuth va asociado a dos tokens, de autorización y de refresco, para asegurar la integridad de la cuenta en caso de que alguno de ellos se vea comprometido.

connectToVSO

Estos tokens, en nuestro caso, se asocian a la cuenta de usuario de VS Anywhere.

Almacenamiento y caché

Cuando creamos una sesión guardamos un snapshot de esta primera versión, que no contiene cambios. Esta snapshot se almacena dentro de Windows Azure Storage, concretamente dentro de un blob, que tiene esta estructura:

  • 123456789
    • 123456789000
    • 235123789021
    • 563473568561

Si accedemos desde el Azure Storage Explorer podemos ver qué se está almacenando:

blobs

Esta estructura de árbol nos permite obtener el histórico de una sesión y poder agregar nuevos items usando los ticks como clave. De esta manera podemos mostrar la fecha de creación sin necesidad de acceder al contenido del blob.

El resto de información almacenada (serializada como JSON) está relacionada con el tipo de autenticación, el team project, el commit o la lista de ficheros que se ha usado para poder re-crear la sesión en el futuro.

Para mantener una caché de sesiones activas usamos Redis, que nos permite un almacenamiento clave-valor con un acceso increíblemente rápido.

Descargando los datos

De la misma manera que podemos crear un snapshot, también podemos descargar el estado actual del proyecto, para integrarlo en nuestro workspace de git o TFS local, descargando un fichero que contiene solamente los documentos abiertos y los editados, siendo el resultado el que se muestra:

download

El fichero .zip se genera sobre la marcha, usando la información actual de la sesión y las opciones de compresión de .net 4.5 (ver más en MSDN).

Conclusiones

Mediante el uso de Azure Storage, Redis, y las API de Visual Studio Online hemos podido crear una funcionalidad adicional que complementa, por una parte el Web Workspace, y por otra el propio Visual Studio Online, dando nuevas opciones de colaboración.

La API, aún en estado beta, está bastante avanzada y productos como UserVoice o Zapier la están integrando dentro de sus propias soluciones.

¿Cómo empiezo?

Para poder empezar a usar las Interactive Rooms, solamente necesitas VS Anywhere 3.0.0.157 y una cuenta en Visual Studio Online. Puedes comenzar desde el propio Visual Studio siempre que:

  • Estés conectado a Visual Studio Online
  • El proyecto sea C# y esté en control de versiones
  • El team project esté conectado a visualstudio.com

Si se cumplen esos dos requisitos, las opciones se mostrarán al hacer click derecho sobre un proyecto:

options

Información y registro

Puedes encontrar más información (y registrarte) en la web de Interactive Rooms

Azure Mobile Services bajo el capó: Insertando elementos

Azure Mobile Services nos proporciona servicios de backend en la nube para Windows Phone, Windows 8, iOS, Android y plataformas basadas en web. Permite además agregar seguridad, autenticación y notificaciones de manera sencilla y rápida. Pero, cómo funciona realmente?

Para averiguarlo, podemos recurrir a la documentación que tenemos en MSDN, aunque también podemos ver directamente el código fuente.

La API que se nos ofrece es open source, con lo cual podemos no solamente ver el código fuente sino además poder realizar contribuciones al mismo.

En este artículo quiero hacer un breve recorrido por la API, para una operación muy concreta, insertar elementos. En otros artículos de esta serie veremos cómo hacer consultas, o qué pasa del lado de servidor.

Para este artículo usaremos los siguientes elementos:

Los ejemplos los veremos con el SDK de Windows Phone 8, pero podemos ver que existe un código similar para el resto de plataformas compatibles.

De un vistazo

La API de Azure Mobile Services está compuesto por objetos que nos ayudan a:

  • Convertir nuestros objetos a formato JSON para su envío y hacer la operación contraria a la recepción (Serialización)
  • Realizar solicitudes al servicio que hemos creado en Azure mediante comandos HTTP usando una arquitectura REST
  • Gestionar autentificación y seguridad para las mismas.

El código fuente del SDK para Windows Phone 8 contiene varios elementos

  • Tests que aseguran su integridad (a nivel de core como a nivel de cada cliente en particular).
  • Código manejado (es decir, código en .NET tradicional).
  • Código nativo, dentro de los espacios de nombres de WinMD (Recordemos que Windows Phone 8 tiene soporte para las API nativas de WinRT).

Para poder trabajar con Mobile Services necesitamos en primer lugar una referencia a la tabla:

private MobileServiceCollection<TodoItem, TodoItem> items;
private IMobileServiceTable<TodoItem> todoTable = 
    App.MobileService.GetTable<TodoItem>();

Este método está situado en la clase MobileServiceClient que contiene otros que veremos a lo largo del artículo:

Este método está situado en la siguiente ruta:

src/
  Microsoft.Azure.Zumo.WindowsPhone8.Managed/
    Core/
      MobileServiceClient.Managed.cs

El código es el siguiente:

public IMobileServiceTable GetTable()
{
    SerializableType type = SerializableType.Get(typeof(T));
    return new MobileServiceTable(type.TableName, this);
}

En primer lugar obtiene un tipo serializable específico, que es el que se usará para poder transformar el objeto en una tabla en el servidor. Luego generará una tabla de tipo MobileServiceTable con el nombre creado a partir de este tipo. Hasta aquí solamente hemos hecho trabajo en local, es decir, no ha habido conexión con el servicio.

Veamos qué pasa al insertar un elemento en la tabla:

await todoTable.InsertAsync(todoItem);

El código para esta función se encuentra en la siguiente ruta:

src/
  Microsoft.Azure.Zumo.WindowsPhone8.Managed/
    Core/
      MobileServiceTable.Generic.cs

En este código lo que vemos es lo siguiente:,

  • No podemos insertar elementos nulos,
  • Se obtiene un JObject (un objeto serializado en formato JSON) a partir de MobileServiceTableSerializer
  • Se envía una petición ya con el objeto serializado
  • Se recibe el resultado de la petición (en formato JSON)
  • Finalmente, se convierte el objeto recibido en el enviado, por si los datos hubiesen cambiado.
public async Task InsertAsync(T instance)
        {
            if (instance == null)
            {
                throw new ArgumentNullException("instance");
            }

            // Serialize the instance
            JObject value = MobileServiceTableSerializer.Serialize(instance).AsObject();

            // Send the request
            JToken response = await this.InsertAsync(value);

            // Deserialize the response back into the instance in case any
            // server scripts changed values of the instance.
            MobileServiceTableSerializer.Deserialize(response, instance);
        }

El envío de la petición se hace en dos fases, una fase manejada, y otra fase nativa, la fase manejada se hace en un fichero situado en:

src/
  Microsoft.Azure.Zumo.WindowsPhone8.Managed/
    Core/
      MobileServiceClient.Managed.cs

En el que se realiza la siguiente operación:

public Task<JToken> InsertAsync(JObject instance)
{
    return this.SendInsertAsync(instance);
}

Que nos lleva a este otro fichero (situado en la fase manejada):

internal async Task SendInsertAsync(JObject instance)
{
    if (instance == null)
    {
        throw new ArgumentNullException("instance");
    }

    // Make sure the instance doesn't have its ID set for an insertion
    if (instance.Get(IdPropertyName) != null)
    {
        throw new ArgumentException(
            string.Format(
                CultureInfo.InvariantCulture,
                Resources.CannotInsertWithExistingIdMessage,
                IdPropertyName),
            "instance");
    }

    string url = GetUriFragment(this.TableName);
    JToken response = await this.MobileServiceClient.RequestAsync("POST", url, instance);
    JToken patched = Patch(instance, response);
    return patched;
}

Aquí las operaciones realizadas son:

  • Comprobar que el elemento que estamos insertando no tenga ya un Id, al fin y al cabo es nuevo.
  • Obtener la url de la tabla a la que vamos a insertar el elemento.
  • Enviar una petición HTTP POST al servicio web, con la url que hemos especificado y los datos, y recuperar el resultado.
  • Actualizar el objeto enviado con la respuesta.
  • Devolver el objeto enviado.

Finalmente llegamos a RequestAsync, donde se realiza la petición, situada en este fichero:

src/
  Microsoft.Azure.Zumo.WindowsPhone8.Managed/
    Core/
      MobileServiceClient.cs

Este método genera una petición del tipo deseado, especifica que solamente queremos parámetros en formato JSON, especifica la autenticación a partir de las claves que hemos especificado en la configuración inicial, y finalmente envía la petición:


internal async Task<JToken> RequestAsync(string method, string uriFragment, JToken content)
        {
            Debug.Assert(!string.IsNullOrEmpty(method), "method cannot be null or empty!");
            Debug.Assert(!string.IsNullOrEmpty(uriFragment), "uriFragment cannot be null or empty!");

            // Create the web request
            IServiceFilterRequest request = new ServiceFilterRequest();
            request.Uri = new Uri(this.ApplicationUri, uriFragment);
            request.Method = method.ToUpper();
            request.Accept = RequestJsonContentType;

            // Set Mobile Services authentication, application, and telemetry
            // headers
            request.Headers[RequestInstallationIdHeader] = applicationInstallationId;
            if (!string.IsNullOrEmpty(this.ApplicationKey))
            {
                request.Headers[RequestApplicationKeyHeader] = this.ApplicationKey;
            }
            if (!string.IsNullOrEmpty(this.currentUserAuthenticationToken))
            {
                request.Headers[RequestAuthenticationHeader] = this.currentUserAuthenticationToken;
            }

            // Add any request as JSON
            if (content != null)
            {
                request.ContentType = RequestJsonContentType;
                request.Content = content.ToString();
            }

            // Send the request and get the response back as JSON
            IServiceFilterResponse response = await ServiceFilter.ApplyAsync(request, this.filter);
            JToken body = GetResponseJsonAsync(response);

            // Throw errors for any failing responses
            if (response.ResponseStatus != ServiceFilterResponseStatus.Success || response.StatusCode >= 400)
            {
                ThrowInvalidResponse(request, response, body);
            }

            return body;
        }

Es todo un conjunto de acciones que se llevan a cabo solamente para insertar un elemento. En el próximo artículo veremos cómo se ejecutan las consultas usando la API, y cómo funcionan métodos como este:

List<TodoItem> items = await todoTable
   .Where(todoItem => todoItem.Complete == false)
   .ToListAsync();

Happy Hacking!

Cómo configurar una máquina virtual de SQL Server 2012 en Azure

Con la última actualización de Azure, a la manera clásica de trabajar con SQL en la nube se le agrega una segunda opción, más potente, ya que nos permite contar con una máquina virtual completa con Windows Server a la cual podemos acceder remotamente, ajustar los servicios a nuestras necesidades, o instalar el software necesario para nuestra infraestructura.

Esta opción requiere algo de configuración, y este artículo pretende ser un pequeño resumen de temas a tener en cuenta a la hora de realizar la puesta a punto de este servicio:

  • Se puede crear la máquina virtual o bien desde línea de comandos o desde el portal de Azure. Para ello es necesario habilitar la característica, que en estos momentos se encuentra en fase Preview. Se ha de especificar que se trata de SQL Server 2012 Evaluation Edition, aunque se cuenta también con la edición 2008 R2.
  • El proceso de aprovisionamiento (copiar, instalar e iniciar la máquina por primera vez) tarda un rato, ya que tiene que crear los discos, copiar la información, y realizar una primera configuración.
  • Al realizar el aprovisionamiento, se configura automáticamente un endpoint para la conexión por RDP, pero es necesario habilitar otro para el puerto 1433 si queremos tener acceso remoto a la base de datos, esto se hace desde la vista de endpoints dentro del panel de la máquina virtual.
  • La máquina tiene el firewall activado por defecto, así que es necesario crear una regla para que permita el paso al puerto 1433 definido antes, la regla debe estar bajo Inbound Rules ya que se desea permitir conexiones entrantes.
  • Desde SQL Server Configuration Manager, habilitar las opciones Named PipesTCP/IP para poder acceder remotamente.
  • A no ser que se configure la máquina virtual para que forme parte de un dominio, será necesario activar la autenticación mixta (Windows y SQL Server) y crear un nuevo usuario para acceder remotamente, estableciendo los permisos adecuados. Ambas operaciones se realizan desde SQL Server Management Studio.
  • Si todo ha ido bien, se podrá realizar la conexión a la recién creada instancia desde un Management Studio local (disponible en el Centro de descargas de Microsoft)

La explicación completa, más ampliada, se puede encontrar en el Blog del equipo de Windows Azure

La evolución de la nube, de tu servidor al cielo

Desde hace ya unos años se oye mucho a los grandes proveedores de plataforma hablar sobre la nube, que si la nube pública, la privada, platform as a service. Yo sinceramente tenía un poco de lío con tanto término, así que le pedí a Javier Albert (@jalberts), amigo IT, que me lo explicara. Me quedé tan impresionado con la facilidad de la descripción que sentí la necesidad de escribirlo.

En este artículo se verá la evolución de los servicios IT desde un servidor simple hasta una completa infraestructura virtualizada usando el ejemplo de la nube privada.

Un servidor

En una empresa todo empieza por un servidor, ese gestionaba habitualmente el portal corporativo, los ficheros compartidos, las cuentas de correo, etc.. La ventaja es que era un buen sitio para empezar, e incurría en poco gasto. La desventaja era que todo el servicio estaba en un solo ordenador, con lo cual la capacidad se podía quedar corta para momentos de picos, además del problema de seguridad de tener todo en el mismo equipo, que unos servicios accedieran a recursos de otros no era nada deseable.

Varios servidores

El siguiente paso lógico era comprar varias máquinas, lo que permitía ahora tener cada servicio en un ordenador diferente, logrando especialización de los ordenadores, uno dedicado al portal, otro al correo, y así sucesivamente. El resultado final era tener un CPD (Centro de procesamiento de datos, también conocido como sala de servidores) lleno de máquinas donde algunas estaban a tope de capacidad y otras, se quedaban bastante infrautilizadas.

Virtualización, ese concepto

Entonces llegaron las soluciones de virtualización de mano de Microsoft y VMWare, que, mediante un soporte de hardware, permitían que un sistema operativo pudiera ejecutar de manera virtual, varias copias de otros sistemas de otros fabricantes, lo que permitía tener en un solo servidor físico, varios servidores virtuales, con el consecuente ahorro de costes en cuanto a infraestructura. El problema era que seguía siendo una sola máquina, y agregar una segunda suponía empezar a duplicar máquinas, los sistemas carecían de redundancia, además de que el proceso de migración a una nueva máquina era muy costoso en cuanto a tiempo.

Y entonces llegó la nube

Estos pasos nos llevan a la situación actual, que es la nube. En este caso se evoluciona de software virtualizado sobre hardware fijo, a software virtualizado sobre hardware variable. Esto implica que una infraestructura de nube privada gestiona todos los recursos de todos los ordenadores de la red como si se tratara de un único host, lo que permite tener acceso a una mayor cantidad de recursos, y lo más importante, poder asignar recursos de manera temporal a servicios que más lo requieran (por ejemplo, subir de RAM y disco duro el servicio de contabilidad al cierre del trimestre fiscal). Esto permite además mantener redundancia entre la información disponible en los equipos físicos, lo que permite en caso de fallo de alguno de los sistemas que la nube siga funcionando correctamente.

Finalmente esta estructura permitiría agregar nuevos equipos a la red de una manera sencilla, ya que tras una breve configuración, el administrador de la nube reconocería el nuevo servidor y actualizaría sus capacidades. Este concepto explicado anteriormente recibe el nombre de nube privada.

Esta misma idea es la que se lleva a la nube pública, donde estos servicios de máquinas virtuales se ponen a disposición de los clientes de manera abierta en internet, con lo cual, nuestra aplicación se ejecuta en un entorno protegido (como es el caso de Azure) y se accede a un almacenamiento de datos también aislado.

Conclusiones

Todas las soluciones mencionadas anteriormente se siguen empleando por empresas a lo largo del globo, ya que existen diferentes necesidades de capacidad, o de asignación de recursos. Espero que quede más claro por qué la nube representa un avance, al menos tanto como me quedó a mí.

Agradecimientos a Javier Albert por la información y la revisión del artículo.