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.


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

Fácil, rápido. O el valor del correo electrónico.

No es lo mismo “fácil” que “rápido”. Este es el problema de comunicación oral  que suele existir entre un programador y un cliente. Me explico. A veces, un trabajo del que un cliente solicita valoración no es de envergadura suficiente como para generar un proyecto y el cliente se lo expone de palabra al programador. Por lo general, el programador se hace una idea mental de cómo haría qué. Si esta estructura mental no es complicada de generar, posiblemente el programador conteste al cliente que es “fácil”. Aquí viene el primer problema. Al recibir el mensaje “fácil”, el cliente puede entender que lo que solicita será “rápido” de hacer y, por consiguiente, “barato”.

Seguramente, si el cliente hubiera usado el correo electrónico para comunicar sus necesidades al programador, hubiera explicado más y mejor los requerimientos.

Seguramente, al enfrentarse el programador con un correo electrónico, lo habría leído en detalle y calibrado todas las posibilidades (opción que no tiene al responder de palabra inmediatamente) y, al contestarlo, no habría usado palabras ambiguas en su respuesta.

Conclusión: Cliente, cuando quiera saber algo, pregúntelo por correo electrónico. Programador, cuando quiera contestar algo, no lo haga inmediatamente, piénselo un rato y envíe la respuesta por correo electrónico. Se evitarán discusiones y malentendidos.


¡Don’t make the programmer think!

Tras cierto tiempo programando en Delphi (+10 años), en Softeng nos hemos tenido que certificar en SharePoint 2010. Del mundo que vengo, la programación de escritorio con Delphi, mucha gente decide compartir sus conocimientos en blogs, páginas técnicas, etc. Esto nos ha servido a muchos programadores durante muchos años para conocer mejor el API, la VCL de Delphi, técnicas para mejorar procesos, etc.

Acostumbrado a esto, he aterrizado en el mundo Sharepoint. Cuál está siendo mi sorpresa viendo este mismo tipo de blogs, páginas técnicas, etc. El hiperespacio está forrado de gente que escribe artículos no basados en su propia experiencia y conocimiento, sino basados en el propio MSDN y sus ejemplos. Hasta que me he dado cuenta de esto, he perdido mucho tiempo implementando una y otra vez los mismos ejemplos (muchas veces para SP2007). Encontrando una y otra vez los mismos fallos. Descubriendo una y otra vez que, los ejemplos de Microsoft, son básicos. No he encontrado (no muchas) páginas escritas por profesionales que se han encontrado con los mismos requerimientos que yo haciendo “algo”.

Intentaré que esta página sea eso. Lo que otras pretenden y no son. Intentaré que los post que aquí haya, estén con los pies en el suelo. Los ejemplos que ponga no serán básicos (pues el mundo real nunca lo es).

Este es mi compromiso y aquí comienza mi blog.


Visita mi perfil en Google Plus