Serverless architecture: Amazon vs Azure

I’ve been reading about serverless architecture, starting in this article, written by Martin Fowler.

Yes, sure, and now you are going to summarize the article.

Not at all, italic voice, I am trying to add more value to that article and, at the same time, take some notes I can review in the future.

As Martin Fowler was talking a lot about AWS Lambda, I was trying to see if there is something similar in Azure because, as Amazon says, Lambda functions are to be written in Java, Node.js or Python and neither of those is my main backend language. I have nothing against none of those languages or against Amazon, but, if I can choose, I prefer to write code in C# and deploy it to Azure (and I believe I am not the only case), just because of my knowledge and experience. I’ve been reading from lots of different websites and I have written this article not with my own experience, but with my compendium of information obtained.

So, let me understand, all this article is because you don’t know how to write code in Python?

No, italic voice, I don’t mind learning new languages, I think it is a good thing, the point here is, there are more actors in the market and, as a TA, I need to know the most relevant to offer alternatives to my clients.

I assume that not many companies are ready for such a huge change of philosophy and, more than the companies, the IT teams behind them. If exposing data from their well protected backend to the outside, even throughout very well secured API Gateways is seen like a weakness in some IT departments, if we remove the backend server from the equation, the heat is starting to hit the room. The idea of losing control of their servers would drive crazy more than one security engineer. The idea of the neediness of their services to configure scalable virtual machines, would make more than one job obsolete. It is our responsibility to give good and enough information to our clients when we propose a solution for a problem, and provide good reasons for the change and, in order to do that, research is our allied, with research we can answer the why’s and the how’s. I tried to do that in this article, at least, for me as a notebook.

Uh huh! Gotcha! What you want is a justification to remove people from projects!

Not at all, italic voice, what I need to understand, is the differences between platforms, because perhaps in the near future I will need to advice some client with them.

Let’s be clear, serverless does not mean no server is used, it means, according to ThoughtWorks: “Serverless architecture replaces long-running virtual machines with ephemeral compute power that comes into existence on request and disappears immediately after use.” So, yes, there is a server. The main difference is you don’t have to care about scale, provision or operation.

Such an architecture is really efficient in terms of compute power, but, on the other hand, makes harder to deploy, manage and share code amongst services.

So, lately I read a lot about AWS Lambda but, surprisingly, I haven’t found too much information regarding the equivalent in Microsoft Azure. There is an equivalent and, as there is, it is needed to be compared before to advise any client willing to start thinking on this cutting edge architecture.

More info in AWS Lambda here:

More info in Azure Functions here:

So, which one is better? As usually, it depends. Do you need to write the code in C#? You can’t use Lambda. Do you need to deploy your serverless architecture on premises? You can’t use Lambda. I’ve read somewhere (I don’t really know where at the moment of writing this) that Lambda supports up to 100 concurrent executions and Functions only 10. In that case, Lambda is the winner. Let’s get into some details and differences between them:


Lambda supports Java, Node.js and Python… for now.

Functions supports C#, F#, Node.js and PHP. They also claim for Java, bash and batch files, but I believe those are still in beta.


Functions are organized in something called App Service which is a group of functions that share memory. This is radically different in Lambda, where you allocate memory per function. This concept is important, because in Azure, you pay per time and memory used.


Functions can be deployed using just an FTP client, but, also, you can link your CI environment to the deployment folder easily, including TFS, Git and even OneDrive and others.

One important thing in the CI aspect is the versioning. Functions does not support versioning while Lambda does.

I am no expert in Lambda, but I’ve read about some third party tools to deploy the functions, for instance, here you have something to test and deploy (Node.js) (


Microsoft Azure Functions are open source. Yes, you’ve read right. They are open source, like almost everything new Microsoft is doing, so, yes, you can run it locally. On the other hand, Lambda is not, but I’ve read about some custom tools created to run the functions locally before to deploy.

Wait, no way, Microsoft open source, since when?

Yes, italic voice, since the new CEO took control of Microsoft, a lot of things have changed, like that, for instance, if you search for Microsoft Open Source code in GitHub, you will be amazed…

Functions does not have an execution limit, but Lambda does. Why is this important? Because of billing. With Lambda you can be sure that even though you have a sleepy process that is taking forever to execute (not a normal behavior), that process will be killed in 5 minutes. In Azure, you can be sure your bill will be huge if you are not monitoring the functions closely.

Ok, so after all that literature in favour of Microsoft, you are saying that Lambda is better?

No, italic voice, I am not saying that, in fact, I am not in favour of Microsoft nor Amazon what I say is that, after some research, it seems to me that AWS Lambda is being adopted prior to Functions because:

  • They are Amazon
  • They were there first
  • They are not Microsoft
  • And yes, they are Amazon

And many people are not considering Microsoft seriously and they should. But, that said, that is my opinion and I hope this article can be as a starting poing of a discussion that help me and others to understand better Serverless Architecture, what vendor advice to clients and why.


I hope you enjoyed the reading.



Thanks to for the italic voice idea.


Seguridad en aplicaciones desplegadas en Windows Azure

Política de seguridad en aplicaciones en Microsoft.Windows.Azure

Recientemente un compañero de IT me ha preguntado por los sistemas de seguridad que implementamos en las plataformas que hemos desarrollado sobre Azure. Bien, había algunos que yo ya tenía claro, pero para acabar de clarificarlo todo, he decidido investigar un poco, recopilar información de diferentes fuentes y plasmarlo en este artículo. Espero que este resumen le sirva a alguien más.

Para establecer que una solución es segura, se deben tener en cuenta diferentes niveles de seguridad. En los que son responsabilidad del proveedor no me voy a extender mucho, pues ya hay mucha literatura al respecto en internet:

Seguridad física

Responsabilidad de Microsoft Windows Azure.

Centros de datos Microsoft Global Foundation Services (GFS) con ISO 27001.

Implementación de Safe Harbor Framework para garantizar la transmisión y custodia de los datos entre U.S.A. y la U.E. (con apartado especial para U.S.A. y Suiza).

Seguridad de la red

Responsabilidad de Microsoft Windows Azure.

Sistema diseñado sobre la base del Hypervisor de Hyper-V.

Arquitectura triple de aislamiento para cada VM de otras VM’s y de elementos que procedan de Internet. Una VLAN con las VM. Otra VLAN con los nodos de FC (Fabric Controller) que se encargan de crear nuevos roles y supervisar los existentes. La tercera se encarga de los dispositivos de red y otros elementos de infraestructura.

Esta arquitectura asegura que si el código que se está ejecutando en una VM compromete la seguridad, este compromiso no se va a transmitir a los nodos de FC ni a los dispositivos de red.

Además de esta protección interna, se añaden tres elementos de filtrado:

                Filtrado de Paquetes

El hypervisor implementa un filtro de paquetes para evitar Spoffing y tráfico no autorizado hacia las VM’s.

                Canales SSL

Todas las comunicaciones en Azure se producen mediante un canal seguro.

Entre el desarrollador y el entorno para despliegue de aplicaciones.

Entre la aplicación y SQL Azure para ejecución de consultas.

Entre la aplicación y el BlobStorage para guardar y recuperar archivos.

Entre la aplicación y el TableStorage para guardar y recuperar registros.

Entre el cliente y la aplicación (siempre y cuando no especifiquemos un EndPoint no seguro por ejemplo por el puerto 80).

                Firewalls de IP

Superficie de ataque minimizada en SQL Azure al seleccionar específicamente las IP desde las que se permite acceder a los datos.

Al definir EndPoints en los Roles de Azure, automáticamente se generan las reglas que se configuran en los Firewalls de dichos roles.

Seguridad del host

Responsabilidad de Microsoft Windows Azure.

Entorno completamente virtualizado. Dicha virtualización es, en parte, responsable de la capacidad de escalado horizontal rápido tanto hacia arriba como hacia abajo. No existe el almacenamiento persistente en nodos de este tipo.

El hipervisor de Windows.Azure hereda directamente del Hypervisor de Hyper-V usando únicamente los elementos imprescindibles de Windows Server para ser capaz de hospedar VM’s, como el Fabric Controller. Es una manera también de reducir la superficie posible de ataque.

Otra barrera crítica es el aislamiento de la VM raíz de las VM’s invitadas y las VM’s invitadas unas de otras. Esta barrera la maneja el hipervisor y el SO raíz.

Azure revisa automáticamente el VHD(disco virtual) que contiene el sistema operativo y lo mantiene actualizado.

El diseño de las máquinas virtuales es otro mecanismo mediante el cual poder controlar la integridad de la aplicación. Cada VM está conectada a tres VHD:

D: Versiones de SO invitado. Mantenidas actualizadas por el sistema.

E: Imagen construida por el FC basado en el paquete de la aplicación subido por el cliente.

C: Configuración, archivos de paginación y otros tipos de almacenamiento.

Seguridad de las aplicaciones

Responsabilidad del desarrollador.

Para asegurar nuestras aplicaciones, podemos utilizar diversas técnicas, algunas o todas a la vez. Un ejemplo serían las siguientes:

Ejecución de aplicaciones en Modo PARTIAL TRUST

En modo FullTrust, la aplicación tendrá acceso a:

Ejecución en modo no-administrador

Ejecución de Código Nativo

Variables de Entorno

P/ Invoke


Sistema de archivos

Sin embargo, si ejecutamos la aplicación en modo Partial Trust:

Ejecución en modo no-administrador

Acceso parcial al sistema de archivo (TEMP)

Espacio de nombres

Usar un nombre personalizado para guardar este nombre en las cookies (p.ej. . No usar nunca un nombre tipo <nombreapp>


El GateKeeper se implementa en un WebRole que recibe las peticiones desde internet. Este WebRole se comunica con el KeyMaster que es un WorkerRole que sólo permite comunicaciones internas dentro de Azure, por lo que está aislado del exterior. El KeyMaster recibe peticiones del WebRole, en quien confía, y traslada las peticiones del WebRole al sistema de almacenamiento a través de SSL.

XSS (Cross Side Scripting)

Aparentemente, si usamos el framework MVC3, la protección contra XSS parece bastante robusta.

Llegados a este punto, será perfectamente comprensible que separemos absolutamente el código <script> de nuestro renderizado Html en ficheros diferentes.

Session Hijacking

Aun así, si un atacante pudiera orquestar un ataque XSS, lo siguiente que haría sería intentar tomar control de la cuenta de usuario.

HttpOnly Flag

Si en la creación de la cookie de autenticación, añadimos este flag, ningún código en Javascript será capaz de usar la cookie y, por tanto, inyectarnos código.

Además, si añadimos al formulario el helper Html.AntiForgeryToken(), haremos que la cookie contenga el mismo valor aleatorio que el campo renderizado. Una vez hecho esto, podemos decorar nuestros actions de [HttpPost] además con [ValidateAntiForgeryToken].

Ataques DDOS

En Web.Config, estos valores evitarán algún tipo de estos ataques. Se puede consultar en esta documentación para lo que sirve cada uno.


enableHeaderChecking = “True”

executionTimeout = “60”

maxQueryStringLength = “2048”

maxRequestLength = “4096”

maxUrlLength = “260”


Seguridad de los datos

Responsabilidad de Microsoft Windows Azure y del desarrollador.

Autenticación SQL

Se provee el usuario en cada conexión y se obliga a autentificar cada 60 minutos.

Bloqueo de IP Nativo en el Firewall de SQL Azure

SQL Azure nos proporciona de manera nativa un Firewall en el que, si queremos acceder desde fuera de Azure tendremos que añadir nuestras IP. Bien, esto no es excesivamente seguro y, para reducir la superficie posible de ataque, podemos eliminar incluso el acceso desde dentro de Azure y habilitar únicamente la ip que corresponda con nuestros WebRoles.

Inyección SQL

Partimos de la base de que estamos usando un ORM. En mi caso EF. Si queremos evitar que nos inyecten código SQL es sencillo. En el caso de EntityFramework, sólo existe la posibilidad de que juntemos el resultado de un editor con el contenido de un Command Text de Entity. Si evitamos esto, será difícil que nos cojan desprevenidos.

Evitar devolver IQueryable

Bueno, además de no devolver IQUERYABLE, intentar devolver un IENUMERABLE (con .ToList()) de EXCLUSIVAMENTE lo que se va a renderizar.  Linq permite el método Take y el operador Limit para limitar el tamaño del resultado. Esto, además de hacer que la página se renderice más deprisa, evita que se pueda iterar sobre el objeto devuelto.


Bueno, aquí me paro por hoy, ampliaré más información en  breve.


Visita mi perfil en Google Plus

Despliegue automatizado en Azure

En este artículo voy a describir los pasos necesarios para conseguir realizar un despliegue automatizado en Azure.

Requisitos previos

PowerShell v.2.0


Preparación del entorno para el despliegue automatizado en Azure

Lo primero que hay que hacer es instalar los requisitos previos. Para ello, descargamos de los siguientes links los instalables:

PowerShell v.2.0 (no es necesario en Windows 7 ni en Windows 2008R2, pues ya va incluido con el sistema)

Azure PowerShell Cmdlets

Instalar los paquetes

  • Ejecutar WindowsAzurePowerShell.3f.3f.3fnew.exe
  • Ejecutar WAPPSCmdletsBin.Setup.exe

Para comenzar a usar Windows Azure PowerShell Cmdlets, hay que seguir los siguientes pasos:

Ejecutar el archivo StartHere.cmd que está en el directorio de instalación.

El script lanzará automáticamente la herramienta Dependency Checker. Esta herramienta verifica que el sistema operativo está configurado adecuadamente para todas las dependencias necesarias al usar los Cmdlets de Azure.

El primer paso que sigue la herramienta es chequear las dependencias necesarias. Si no están instaladas en la máquina, la herramienta sugerirá instalarlas en un link usando el Web Platform installer.

Cuando las dependencias terminen de intalarse, comienza el programa de instalación de los Cmdlets de Azure para PowerShell. Escoger la opción de instalación como Snap-in.

Cuando termine la instalación, para probar que se ha instalado bien, seguir los siguientes pasos

Ejecutar PowerShell v 2.0

Añadir los Cmdlets ejecutando:

Add-PSSnapin WAPPSCmdlets

Listar los comandos incluidos en el SnapIn:

Get-Command –Module WAPPSCmdlets

Preparación de la carpeta con los archivos de despliegue

Copiar en una carpeta los archivos cscfg, csdef y cspkg junto con el archivo adjunto deploy.ps1

Ejecución del script

Ejecutar el script con todos los parámetros bien rellenos. El script tiene los siguientes parámetros y POR ESTE ORDEN:

  1. Carpeta de compilación. En este parámetro indicamos cuál es la carpeta que contiene los archivos implicados en el despliegue. P.Ej.: c:\Projects\AzureDeploy.
  2. Nombre del paquete. Nombre del archive cspkg que contiene la aplicación a desplegar. Este es el paquete que se genera con la herramienta cspack del SDK de Azure. P.Ej.: CloudServiceSmall.cspkg.
  3. Archivo de configuración. Nombre del archivo de configuración. El que modificamos desde VS. P.Ej.: ServiceConfigurationSmall.cscfg.
  4. Nombre del servicio. Típicamente será el prefijo de DNS que hemos escogido para nuestra subscripción. P.Ej.: misite.
  5. Nombre del servicio de almacenamiento que queremos usar para subir el paquete para desplegar. Incluir aquí el nombre del servicio. P.Ej.: misitestorage.
  6. Firma del certificado del servicio. Aquí tenemos que incorporar la ruta donde lo tenemos instalado. P.Ej.: cert:\CurrentUser\My\DD6656D6D6666DD66D66D666D66D66D6D6D6D66D.
  7. Id de la subscripción a Azure que vamos a usar. P.Ej.: “66666666-d6d6-6666-d6d6-d666666d6dd6”

Con todo esto, la línea de comando que deberemos ejecutar es la siguiente:

PS C:\Projectes\AzureDeploy> ./deploy.ps1 c:\Projects\AzureDeploy CloudServiceSmall.cspkg ServiceConfigurationSmall.cscfg misite misitestorage cert:\CurrentUser\My\ DD6656D6D6666DD66D66D666D66D66D6D6D6D66D "66666666-d6d6-6666-d6d6-d666666d6dd6"

Y con esto, veremos que automáticamente se nos despliega el paquete en nuestra subscripción. Este sistema nos serviría para, por ejemplo, ejecutar esta última línea de comando desde un entorno de Integración Continua como Jenkins (Hudson).

En próximos artículos, escribiré sobre cómo generar el paquete que subimos con este sistema, de modo que podamos automatizar completamente la compilación, generación y despliegue en entornos gratuitos como SVN+Jenkins en lugar de usar TFS.


#Variables que se recogen desde los parámetros de la línea de comandos

$buildPath = $args[0]
$packagename = $args[1]
$serviceconfig = $args[2]
$servicename = $args[3]
$storage = $args[4]
$cert = Get-Item $args[5]
$sub = $args[6]

#Crear variables nuevas con los valores de los argumentos
$package = join-path $buildPath $packageName
$config = join-path $buildPath $serviceconfig
$a = Get-Date
$buildLabel = $servicename + "-" + $a.ToShortDateString() + "-" + $a.ToShortTimeString()

#Comprobar si no tenemos instalados los Cmdlets
if ((Get-PSSnapin | ?{$_.Name -eq "WAPPSCmdlets"}) -eq $null)
 Add-PSSnapin WAPPSCmdlets

#Obtener el servicio hosteado
$hostedService = Get-HostedService $servicename -Certificate $cert -SubscriptionId $sub | Get-Deployment -Slot Staging

#Si existe el servicio, eliminar
if ($hostedService.Status -ne $null)
 $hostedService |
 Set-DeploymentStatus 'Suspended' |
 Get-OperationStatus -WaitToComplete
 $hostedService |
 Remove-Deployment |
 Get-OperationStatus -WaitToComplete

#Desplegar en Staging
Get-HostedService $servicename -Certificate $cert -SubscriptionId $sub |
 New-Deployment -Slot Staging -package $package -configuration $config -label $buildLabel -serviceName $servicename -StorageServiceName $storage|
 Get-OperationStatus -WaitToComplete

#Activar el servicio en Staging
Get-HostedService $servicename -Certificate $cert -SubscriptionId $sub |
 Get-Deployment -Slot Staging |
 Set-DeploymentStatus 'Running' |
 Get-OperationStatus -WaitToComplete

Visita mi perfil en Google Plus

Cloud computing (II)

Viene de Cloud Computing(I)

Hablando de Cloud, tenemos principalmente 3 modelos:

IaaS (Infrastructure as a Service):

Con este modelo, lo que ponemos en la nube es la infraestructura, esto es, la maquinaria. Conseguimos un ahorro importante, ya que no tenemos que comprar dichas máquinas ni sufrir su obsolescencia y pérdida de garantía.

No nos libramos de su mantenimiento pues lo único que tenemos son máquinas remotas. La instalación de programas, su actualización, etc., sigue corriendo de nuestra cuenta.

Este modelo de base lo usaría un departamento de TI.

Proveedores de IaaS más importantes:

Amazon EC2

PaaS (Platform as a Service):

Este modelo intermedio proporciona la infraestructura y el sistema operativo. Nos ahorramos el mantenimiento de la infraestructura y también el mantenimiento del sistema operativo y sus actualizaciones.

Una empresa de software que quisiera vender software como servicio optaría por este modelo.

Proveedores de PaaS más importantes:

Google App Engine

Microsoft Windows Azure

SaaS (Software as a Service):

Este modelo de alto nivel nos abstrae de todo lo relacionado con infraestructura, sistemas y software. Hacemos uso del software según lo necesitemos y pagamos por ello un alquiler.

La implementación de este modelo será objeto del siguiente capítulo de esta serie.

Proveedores de SaaS más importantes:

Google Apps

Microsoft Office 365

Visita mi perfil en Google Plus

Cloud computing (I)

Cloud computing (I)

Este artículo no es un artículo al uso, más bien es un ensayo que supongo corregiré en alguna ocasión. También es una serie de reflexiones personales acerca de lo que entiendo que es el famoso y de moda Cloud Computing.

Bien, comenzamos.

Está de moda usar el término Cloud Computing indiscriminadamente. Ahora todos los proveedores de servicios se quieren apuntar al carro y ofrecen servicios “Cloud” que, bajo mi punto de vista (y seguramente el de muchos otros) son otra cosa. De hecho, otra cosa que ya existía casi desde siempre. Es como si los profesores de primaria, de repente, decidieran ir a clase a impartir “Learning”. Más de lo mismo, pero con otro nombre.

Computación en la nube no es que los servicios que contratamos están en un centro de datos muy grande y muy seguro, porque eso es lo que es cualquier servicio de hosting que se precie.

Computación en la nube no es que contratemos online un servicio de aplicación en un proveedor y nos emita automáticamente facturas por los servicios consumidos. Al menos no sólo eso.

Computación en la nube no es que contratemos un espacio en un proveedor en el que ubiquemos nuestra máquina (o granja) y nuestros servicios tengan un ancho de banda muy “ancho” pero nosotros seamos los que controlemos la máquina (o granja).

Bajo mi punto de vista, la computación en la nube, tiene implícitas unas cuantas características inevitables, que voy a detallar en los siguientes puntos.

Escalabilidad lineal de costes

El primer punto importante para considerar el servicio “cloud”, es la escalabilidad de costes lineal.

¿Qué es? Pues muy sencillo. Si consideramos una gráfica de dos dimensiones en la que tenemos en la X los recursos utilizados y en la Y el coste del servicio, la línea debe ser absolutamente recta y, coincide exactamente, con los recursos contratados:

Gráfico de escalabilidad lineal

En un servicio de hosting tradicional, no podemos contratar los recursos en el momento en que los necesitamos, por lo que para dimensionar adecuadamente los requerimientos de nuestro servicio, tenemos que hacerlo con cierta dosis de generación de hipótesis basada en conocimientos previos de uso. Esta hipótesis nos suele llevar a errores en ciertas ventanas de tiempo, es decir, hay momentos del tiempo en que tenemos más recursos contratados de los que usamos (sobredimensionamiento) y hay momentos del tiempo en que tenemos menos recursos contratados de los que necesitamos (cuellos de botella):

Esto es debido principalmente al modo de licenciamiento de los proveedores de hosting. Es difícil encontrar uno que nos permita contratar 3 máquinas por 2 horas, las siguientes 5 horas contratar únicamente 1 máquina, después 10 horas con 8 máquinas, y así sucesivamente. Lo más normal que nos podemos encontrar es que el tiempo mínimo por recurso que podamos contratar sea de 1 mes (lo más habitual será de 3 meses en adelante).

Si en lugar de un hosting tenemos contratado un housing, no hay comparación posible. O tenemos el servicio sobredimensionado, o tenemos un gran cuello de botella. Nuestro dimensionamiento no puede ser evolutivo, es decir, a veces más o a veces menos. Tenemos las máquinas (o front-ends) que tenemos: ni más, ni menos. Y estaremos de acuerdo en que no tenemos una carga lineal de trabajo en una aplicación. Es decir, seguro que, sea una página web, un ERP, un CRM, o cualquier otra aplicación, no tendremos que soportar el mismo número de peticiones por hora durante las veinticuatro horas del día.

Imaginemos que somos Facebook. Ambicioso, ya lo sé. Pero imaginémoslo por un momento. Seguramente, la carga de peticiones que debe tener en Europa durante las horas GTM -4 y GTM +2 de 10:00AM a 22:00PM debe ser sensiblemente superior a entre las 22:00PM y las 10:00AM. Y, en el mismo rango de horas, la carga de peticiones seguramente se balanceará hacia las américas subiendo el índice de GTM o hacia Asia bajando el índice de GTM. Si tenemos, pongamos por caso, un par de centros de datos en Europa, otro par en América y otro par en Asia, en cada centro de datos contratamos, por redondear, 12 horas diarias con 100 máquinas y 12 horas diarias con 10 máquinas.

La diferencia de coste es evidente si la comparamos con tener 24 horas al día 100 máquinas en cada centro de datos. Si conseguimos balancear el número de máquinas contratadas hacia los centros de datos de América y Asia según la hora del día, seguramente, con casi la mitad de coste, tendremos cubiertos todos los picos posibles de servicio solicitado que si tuviéramos sobredimensionado el servicio a 100 máquinas por centro de datos.

Hagamos el ejercicio en una tabla simplificando a un coste de 25 céntimos por front-end/hora:

Coste porFront-End/hora 0,25 €
Centro de datos cloud
Europa América Asia
Horas 12 12 12 12 12 12
Front-Endscontratados 100 10 100 10 100 10
Coste mensual (30 días) 9.000 € 900 € 9.000 € 900 € 9.000 € 900 €
Total 9.900€ Total 9.900 Total 9.900€


29.700 €
Centro de datos standard
Europa América Asia
Horas 24 0 24 0 24 0
Front-Endscontratados 100 0 100 0 100 0
Coste mensual (30 días) 18.000 € 0 € 18.000 € 0 € 18.000 € 0 €
Total 18.000€ Total 18.000€ Total 18.000€
Total: 54.000 €

Y eso que nuestro dimensionamiento simulado sólo ha contemplado dos situaciones, 100 y 10 front-ends. El ahorro sería más importante si consideráramos un dimensionamiento progresivo tanto en subida como en bajada.


Visita mi perfil en Google Plus