Serverless architecture: Amazon vs Azure


I’ve been reading about serverless architecture, starting in this article http://martinfowler.com/articles/serverless.html, 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: https://aws.amazon.com/lambda/

More info in Azure Functions here: https://azure.microsoft.com/en-us/documentation/articles/functions-overview/

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:

Languages:

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.

Organization:

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.

Deployment:

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) (https://www.npmjs.com/package/aws-lambda-toolkit).

Execution:

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.

 

Victor

Thanks to www.cienciadesofa.com for the italic voice idea.

Anuncios

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

Registro

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. midominio.com) . No usar nunca un nombre tipo <nombreapp>.cloudapp.net.

GateKeeper

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.

<httpRuntime

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.

(…)

Google
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

AzureCmdlets

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.

deploy.ps1

#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

Google
Visita mi perfil en Google Plus