First contact with AppNow, an awesome tool for generating and deploying code on the cloud

Disclaimer: Although I know personally members of the AppNow team, I don’t have any relationship with the company and with the products it develops.

TL; DR The creators of the Radarc tool have just launched a free preview of AppNow, an online cloud based service that allows us to generate a MEAN backend for our apps. In this article we will see how to create our solution, the generated result, and finally some notes about what can we find under the hood.

contents

Some context

If you don’t know what is Icinetic, it is a company based in Seville, Spain dedicated to the development of products and mobile applications. Its flagship product, Radarc, is a solution that generate native mobile and web applications from a class based model (model-driven design).

This operation is carried out through various modules called formulas and is integrated into Visual Studio through an extension. I could see it in action a few months ago and I was very impressed with the quality of the generated code.

In the last /Build event, they announced Radarc Online, which is independent from Visual Studio, and today have gone one step further with AppNow, a tool to create and deploy custom backends in the cloud.

Technical features and limitations

The beta version is limited to a MEAN stack:

  • Cloud server: Heroku
  • Database: MongoDB
  • Backend: Node.js + Express.js
  • Frontend: Angular.js

First contact

When we reach the web the first thing we can do is login by using our favourite social network account:

appnow_home

The next step is configuring our data model, for this example I opted to load the default sample set:

datamodel

Once configured the data model, we continue with our Heroku credentials. At this point, it is very important that our Heroku account is validated (read more…) and that we have added our SSH key to Heroku to continue.

heroku

If all goes well you will see a screen like the one shown, that it will be updating while the solution is generating.

generated

Thus we have generated code from our class model, and we have deployed it in the cloud with a single step. The result of this deployment is this site:

result

From here we can list created models, as well as add, edit and delete them.

Under the hood

contents

In the list of files we can see different views, drivers and services that are part of an angular application inside the public directory, and on the other hand we can see the backend on the app directory.

If we take a look at the code we can see some details:

  • Access to MongoDB occurs by mongoose, which is an ORM that gives us validation and strict data types for working with MongoDB.
  • The API (Generated using Express.js) is compatible with swagger, which if you don’t know it, is a tool that allows us to generate documentation as well as static and dynamic clients automatically from the API comments and endpoints.
  • Angular app is a SPA, with a controller for each entity we have specified at the beginning, and different actions for adding, editing and deleting each entity.
  • Supports, in addition, authentication and session services for Angular.

Conclusiones

An interesting point here is that it offers the full package, not only the generation of code but it also deployment. Being based on git means that we can, from that moment, gain control of the code and continue to develop. It is a simple and elegant way of creating a service backend, which once generated, does not have any additional dependency to Radarc services.

Although it is only a demo, it is an interesting test of the power behind this tool. It generates clean, well commented code so we can continue developing it (nothing to do with the generated code that we have seen in some tools). My recommendation is to try it with patience, and tell the guys from Icinetic if you find something wrong. Without a doubt, a project to follow closely!

Links

Probando AppNow, lo nuevo de los chicos de Icinetic

Disclaimer: Aunque conozco personalmente a miembros del equipo de AppNow (unos auténticos cracks) no tengo ninguna relación con la empresa ni con los productos que ella desarrolla.

TL; DR Los creadores de Radarc acaban de lanzar la preview gratuita de AppNow, una herramienta en la nube para generar un backend para nuestras aplicaciones. En este artículo veremos cómo generar nuestro backend, el resultado, y qué nos podemos encontrar en el código generado.

contents

Un poco de contexto

Si no sabes qué es Icinetic, es una empresa con sede en Sevilla que se dedica al desarrollo de productos y aplicaciones móviles. Su producto estrella, Radarc, es una una solución para generar modelos de aplicaciones nativas a partir de un modelo de clases (model-driven design).

Su funcionamiento se realiza a través de diversos módulos llamados fórmulas y se integran en Visual Studio a través de una extensión. Pude verlo en acción hace unos meses y me quedé muy impresionado con la calidad del código generado.

En el pasado /Build, saltaron a la nube presentando Radarc Online, lo que supone una independencia de Visual Studio, y hoy han ido un paso más allá con AppNow, una herramienta para crear y desplegar backends personalizados en la nube.

Características técnicas y limitaciones

La versión beta nos permite probar un stack MEAN, es decir:

  • Servidor: Heroku
  • Base de datos: MongoDB
  • Backend: Node.js + Express.js
  • Frontend: Angular.js

Primer contacto

Cuando entramos a la web lo primero que podemos hacer es iniciar sesión con nuestra cuenta de nuestra red social favorita:

appnow_home

El siguiente paso es configurar nuestro modelo de datos, que para este ejemplo he optado por cargar el conjunto que ofrecen por defecto:

datamodel

Una vez configurado el modelo de datos, continuamos con nuestras credenciales de heroku. En este punto es muy importante que nuestra credencial esté validada (ver más..) y que agreguemos nuestra clave SSH a Heroku para poder continuar.

heroku

Si todo ha ido bien podremos ver una pantalla como la que se muestra, que se irá actualizando mientras se va generando la solución.

generated

Con ello hemos generado código a partir de nuestro modelo de clases, y lo hemos desplegado en la nube con un solo paso. El resultado de dicho despliegue es este sitio:

result

Desde él podemos listar los modelos creados, así como agregar, editar y borrar los mismos.

Bajo el capó

contents

En la lista de ficheros podemos ver, dentro del directorio public las diferentes vistas, controladores y servicios que forman parte de una aplicación angular, y por otro el backend dentro del directorio app.

Si echamos un vistazo al código podremos ver algunos detalles:

  • El acceso a MongoDB se realiza mediante mongoose, que es un ORM que nos aporta validación y tipos estrictos de datos para trabajar con MongoDB,
  • La API (generada usando Express.js) es compatible con swagger, que si no lo conoces, es una herramienta que nos permite generar documentación así como clientes estáticos y dinámicos de manera automática a partir de los comentarios de la API
  • La aplicación Angular es una SPA, con un controlador por cada entidad que hemos especificado al principio, y diferentes acciones de edición, agregación, listado o borrado para cada uno de ellos.
  • Soporta, adicionalmente, autenticación y sesiones a través de servicios de Angular.

Conclusiones

Un punto interesante en este aspecto es que ofrece el paquete completo, no solamente la generación de código sino que también el despliegue, y, al estar basado en git, podemos, a partir de ese momento, obtener el control del código y continuar el desarrollo. Es una manera simple y elegante de crear un servicio de backend, que, una vez generado, no tiene ninguna dependencia adicional a servicios de Radarc.

Aunque no es más que una demo, es una prueba interesante de la potencia tras esta herramienta. El código que genera es limpio, bien comentado, a partir del cual se podría continuar el desarrollo (nada que ver con el código auto-generado que hemos visto en algunas herramientas). Mi recomendación es probarlo con paciencia, y avisar a los chicos de Icinetic si encontramos algún fallo. Sin duda, un proyecto a seguir de cerca!

Enlaces

Cacheando con Varnish un proyecto ASP.net MVC5

Una caché, por definición, es un almacenamiento a corto plazo de información y con una altísima velocidad de acceso, permitiéndonos mejorar el rendimiento de nuestros sistemas. En el caso de la web podemos diferenciar dos tipos:

  • Caché de cliente, que se hace en el navegador y que nos permite no tener que traer de internet imágenes o ficheros de estilo una vez hemos obtenido una copia.
  • Caché de servidor, que guarda una copia de manera temporal para evitar sobrecarga de nuestro servidor de aplicaciones.

Esto último tiene una justificación, y es que el acceso a las aplicaciones (PHP, ASP.net, Ruby) es un proceso relativamente lento que suele estar acompañado de un acceso a una base de datos, una aplicación de la lógica de negocio y la composición final de la página.

Existen diferentes sistemas y tipos de caché, como Memcached o Redis. En este artículo hablaremos de Varnish, un proyecto open-source que se instala sobre sistemas UNIX (aunque tiene soporte para Windows mediante Cygwin).

La principal peculiaridad que tiene este sistema, además de sus casi-infinitas opciones de configuración, es que permite dividir nuestra página en trozos y cachearlos de manera independiente, en función del intervalo de actualización de los mismos, un proceso conocido como Edge Side Includes (ESI) y que veremos a lo largo del artículo.

Instalación y configuración

La instalación de Varnish es un proceso tan simple como brew install varnish si usamos homebrew en mac. Una vez instalado, para ejecutarlo usamos el siguiente comando:

sudo /usr/local/opt/varnish/sbin/varnishd -n /usr/local/var/varnish -f /usr/local/etc/varnish/default.vcl -s malloc,1G -T 127.0.0.1:2000 -a 0.0.0.0:8082

pasando como parámetros las siguientes opciones:

  • Ruta del fichero de configuración
  • Puerto de registro de log
  • Máximo consumo de RAM
  • Puerto de escucha (en nuestro caso el 8082)

El fichero de configuración default.vcl, para nuestro ejemplo, contiene las siguientes directivas:

backend default {
    .host = "127.0.0.1";
    .port = "8087";
}

sub vcl_recv {
	if (req.http.cookie) {
		unset req.http.cookie;
	}
}

sub vcl_fetch {
	
	if (req.url == "/layout/*") {
       set beresp.ttl = 2m;      /* Sets a one minute TTL on        */
    } else {
       set beresp.do_esi = true; /* Do ESI processing               */
       set beresp.ttl = 30s;     /* Sets the TTL on the HTML above  */
    }
    unset beresp.http.set-cookie;
}

sub vcl_deliver {

    if (obj.hits > 0) {
            set resp.http.X-Cache = "HIT";
    } else {
            set resp.http.X-Cache = "MISS";
    }
}

Los comandos que hemos implementado son:

  • backend: Permite especificar qué servidores estarán funcionando al otro lado, se puede especificar una IP o un nombre DNS.

  • vcl_recv: En el caso de ASP.net, se genera una cookie de sesión al acceder al sitio, lo cual no siempre es lo deseable. En este ejemplo se borran todas las que provienen del servidor, de manera que se pueda cachear la página.

  • vcl_fetch: Se ejecuta cuando obtenemos un elemento desde el servidor, y en este caso especificamos que si estamos solicitando algún elemento de “layout” como el menú o la cabecera, ha de cachearlo durante 2 minutos, en caso contrario configuramos para que haga el procesamiento ESI (es decir, que intente unir los pedazos) y cachee el conjunto durante 30 segundos.

  • vcl_deliver: Nos permite editar la cabecera HTTP para saber si ha podido resolver el elemento en la caché o si ha tenido que acceder al servidor de aplicaciones.

Cacheando voy, cacheando vengo:

En este ejemplo hemos usado una plantilla de bootstrap que tiene el siguiente aspecto dentro de una aplicación prácticamente vacía en MVC5:

goal

Lo primero que podemos apreciar son tres zonas claramente diferenciadas, una cabecera, una barra lateral, y, finalmente, un área de contenido principal.

Estructura

Para mostrar la página, empleamos un controlador muy sencillo que genera una espera de 3 segundos para simular carga del servidor y almacena la fecha de generación en el ViewData:

public class HomeController : Controller
{
	public ActionResult Index ()
	{
		ViewData ["now"] = String.Format ("{0:HH:mm:ss}", DateTime.Now);
		System.Threading.Thread.Sleep (3000);
		return View ("Index");
	}
}

De manera adicional y para poder aplicar ESI, necesitaremos dividir nuestra vista en tres vistas diferentes que correspondan a acciones diferentes del controlador, que serán:

  • / <- que genera el contenido de la página
  • /layout/header <- que genera la cabecera
  • /layout/sidebar <- que genera la barra lateral

Las dos acciones del controlador Layout son idénticas, como muestra el código:

public class LayoutController : Controller
{
    public ActionResult Sidebar()
    {
		ViewData ["now"] = String.Format ("{0:HH:mm:ss}", DateTime.Now);
		System.Threading.Thread.Sleep (3000);
        return View ("Sidebar");
    }

	public ActionResult Header()
	{
		ViewData ["now"] = String.Format ("{0:HH:mm:ss}", DateTime.Now);
		System.Threading.Thread.Sleep (3000);
		return View ("Header");
	}
}

Nótese que por cada acción hemos agregado otros 3 segundos de retraso, teniendo un total de 9 segundos en el caso peor.

Para poder activar el ESI en las vistas, usamos etiquetas HTML que tienen el siguiente formato:

<esi:include src="/layout/sidebar" onerror="continue"/>

Además, a modo de prueba, podemos agregar algo de código javascript que se ejecute una vez cargada la página para apreciar la diferencia entre hora de generación y hora de renderización. Si todo ha ido bien, cuando carguemos por primera vez nuestra caché, se encontrará vacía, y sufriremos la espera de los 9 segundos.

En la imagen, G muestra la hora de generación en el servidor y R la hora de renderización en el cliente:

miss

Si volvemos a acceder, comprobaremos que el contenido de la página ya se ha cacheado, que las fechas de generación y de ejecución distan más de tres segundos, y que el inspector nos muestra el tiempo total de acceso a la página (700 milisegundos aprox):

hit

Conclusiones

Ha sido una prueba de concepto muy interesante, el hecho de descubrir que podemos tener nuestra web dividida en secciones con cachés diferentes nos da mucha movilidad al hacer portales con información dinámica. Varnish es una herramienta suficientemente compleja para ser tomada en serio y requiere que estudiemos a fondo sus características antes aplicarla a un sistema en producción.

Lecturas adicionales y enlaces

Probando módulos de NancyFx

En el artículo anterior de la serie de NancyFx hablábamos de diferentes tipos de respuesta así como el uso de plantillas en la plataforma. En este artículo veremos cómo crear pruebas unitarias para asegurarnos que nuestros módulos funcionan correctamente.

Creando nuestro primer test

Desde la documentación de Nancy se recomienda usar un proyecto diferente (es decir, un ensamblado diferente) para nuestros tests, ya que los módulos se descubren de manera automática por el “bootstrapper”. Una vez creado nuestro proyecto, necesitamos agregar las siguientes referencias, via nuget o de manera manual:

  • NUnit (o XUnit, o el framework que deseemos)
  • Nancy
  • Nancy.Testing

Una vez tenemos las referencias, podemos crear nuestro primer test (que tiene el original nombre de RoutesTest.cs). Dicho test estará dividido en tres partes:

  • Arrange: Toda la preparación necesaria para poder llevar a cabo el test
  • Act: La ejecución de nuestro test
  • Assert: La fase de comprobación de los resultados
[Test ()]
public void TestPut ()
{
        //Arrange
	var bootstrapper = new DefaultNancyBootstrapper();
	var browser = new Browser(bootstrapper);

        //Act
	var result = browser.Put("/routes", with => {
		with.HttpRequest();
	});

        //Assert
	Assert.AreEqual (HttpStatusCode.OK, result.StatusCode);
	Assert.AreEqual ("Response with Put\n", result.Body.AsString());
}

Qué hace el test?

  • Arrange: Para este test el primer paso es crear nuestro Bootstrapper que descubrirá los módulos existentes, seguido de un Browser con el que simularemos las llamadas a nuestros módulos.

  • Act: Una vez tenemos el browser, el siguiente paso es generar la peticion, en este caso Put, a una ruta especificada.

  • Assert: Con el resultado de la ejecución, comprobamos el estado de la respuesta (en este caso 200 OK) y que el texto corresponda con lo que necesitamos, que es “Response with Put\n”.

Una vez tenemos las referencias, recordemos qué contenía el módulo que queríamos probar:

public class Routes : NancyModule
{
	public Routes ()
	{
		Get["/routes"] = _ => "Response with GET\n";
		Post["/routes"] = _ => "Response with POST\n";
		Put["/routes"] = _ => "Response with Put\n";
                ...
	}
}

Podemos identificar claramente una línea donde el verbo PUT devuelve “Response with Put\n”, con lo cual nuestro test es correcto

Probando una ruta errónea

Al igual que podemos probar rutas correctas, los test son igual de válidos para comprobar que el acceso a una ruta no autorizada o no implementada se controla correctamente, como sucede a continuación:

[Test ()]
public void TestNotFound ()
{
	//Arrange
	var bootstrapper = new DefaultNancyBootstrapper();
	var browser = new Browser(bootstrapper);

	//Act
	var result = browser.Delete("/routes", with => {
		with.HttpRequest();
	});

	//Assert
	Assert.AreEqual (HttpStatusCode.MethodNotAllowed, result.StatusCode);
}

En este caso, la ruta no está implementada, con lo cual el resultado será un error de tipo “Method Not Allowed”.

Conclusiones

Con pocas líneas de código podemos comenzar a probar nuestros módulos de NancyFx, podemos probar la respuesta de los mismos, así como códigos de error. El sistema de test permite, adicionalmente, pasar parámetros (simulando el uso de un formulario) o navegar a través del DOM del HTML devuelto, si usamos un ViewEngine.

Hangout el próximo miércoles con panel de lujo: Hablemos de blogs!

El próximo día 2 de julio, a las 21:00 (Hora Peninsular Española, ver hora local) tendremos un hangout donde hablaremos sobre la manera de escribir artículos tecnológicos.

Te apuntas? Inscríbete en: https://plus.google.com/events/cfglotuffumq9cd3665o8c15870

Todo surge a raíz de los siguientes tweets:

Tras hablarlo un poco, y convencer a algunos compañeros de batalla, Juan lo anunciaba públicamente:

Panel de asistentes

Para esta edición nos acompañan diferentes profesionales de campos variados, como son:

Jose Manuel Alarcón (@jm_alarcon)

31dbba0

Director de Krasis, editorial de libros de caracter técnico y plataforma de formación online a través de CampusMVP. MVP de Microsoft en materia de ASP.net, y autor de varios libros y cursos, tanto en castellano como en inglés sobre desarrollo web así como sobre e-mail marketing.

Escribe frecuentemente en sus dos blogs, cada uno de diferente temática:
http://www.jasoft.org/blog/ de caracter técnico
http://jmalarcon.es/ más relacionado con desarrollo empresarial

Bruno Capuano (@elbruno)

0b39c61

Innovation Product Manager en Avanade, y miembro activo de la comunidad de desarrolladores, podemos verlo habitualmente hablando en eventos de temas variados. Últimamente le hemos visto con tecnologías como Arduino/Netduino, .NET Gadgeter, Pebble, o Lego Mindstorms.

Apasionado de la tecnología en general, mantiene un blog desde hace ya algunos años, en el que podemos ver novedades (salvo raras excepciones) de manera diaria tanto en inglés como en castellano. http://elbruno.com

David Salgado (@davidsb)

0edfe9e

Product Marketing Manager en Microsoft Corporation en el equipo de Visual Studio Online. Anteriormente como parte del equipo de DPE en Microsoft Ibérica, se enfrentó con la tarea de dar el mismo mensaje a diferentes entornos, así como variar la forma y el contenido de estos mensajes.

Le hemos visto en charlas, talleres, workshops, en eventos con la comunidad de desarrolladores, y también en newsletters y artículos de MSDN.

Vanessa Pizarro (@vanesapizarro)

23554a4

Social Media Manager en Hydra Social Media, es una profesional de comunicación a nivel corporativo. La podemos encontrar definiendo estrategias para redes sociales, campañas de publicidad y tras clientes como IE Business School.

Durante 2011 estuvo trabajando en los canales corporativos de Microsoft Ibérica así como en el mantenimiento y la redacción de los contenidos del blog corporativo. Nos traerá la visión de los blogs como herramienta de comunicación desde el punto de vista de las marcas y las empresas.

Juan Carlos Quijano Abad (@jc_quijano)

1ed9a54

Juan, como todo buen superhéroe, tiene doble vida. Por el día es responsable del departamento de desarrollo de TeamPro, donde realiza labores de apoyo técnico así como gestión. Por la noche es editor en Xataka Windows y GenbetaDev, dos de los blogs más visitados a nivel nacional en cuanto a tecnologías Microsoft y Desarrollo web. Asistente y ponente habitual en eventos organizados por la comunidad, nos trae su visión como editor profesional de blogs tecnológicos, a su vez nos ayudará moderando y conduciendo el debate.

Roberto Luis Bisbé (@rlbisbe)

1b83681

Finalmente, el que escribe, Desarrollador de software en VS Anywhere, mantengo este blog desde 2009, escribiendo temática variada pero habitualmente relacionada con desarrollo software y concretamente con tecnologías Microsoft. Estaré comentando mi experiencia desde el punto de vista de un blog personal.

Es una suerte para mí poder formar parte de un panel tan selecto, y estoy seguro que el evento será muy enriquecedor para todos. Además, si no puedes asistir, quedará grabado en youtube.

Te he convencido? Inscríbete aquí!: https://plus.google.com/events/cfglotuffumq9cd3665o8c15870

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/, 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:

Preparando el examen 70-484

El pasado 30 de mayo aprobé el examen 70-484 de desarrollo de aplicaciones para Windows 8 con C#, lo que me acerca un paso más al MCPD en desarrollo de apps para la plataforma, y es a su vez una excusa y un reto para aprender más de la misma.

Al comentarlo por Twitter, algunos desarrolladores me preguntaron qué recursos había usado, y aquí va un pequeño resumen.

Sigue leyendo