Artigo
02/16/2017

Fevereiro de 2017

Volume 32 - Número 2

Azure - Arquitetura sem servidor com o Azure Functions

Por Joseph Fultz | Fevereiro 2017

De ferramentas a máquinas a computadores, procuramos sempre automatizar o trabalho repetitivo e padronizar o contexto em que trabalhamos para podermos focar em contribuições especializadas de grande valor para concluir tarefas e resolver problemas. Em paralelo, é claro que como a indústria de TI evoluiu, nós nos empenhamos para atingir uma alta densidade em todos os níveis de um sistema, desde a CPU até o farm do servidor, na esperança de atingir a maior eficiência de nossos sistemas. Uma arquitetura sem servidor é o ponto no qual essas duas transmissões convergem. É o ponto no qual o esforço de um indivíduo é focado mais especificamente na tarefa específica e o desperdício no sistema é mínimo.

Em um mundo sem servidor, os desenvolvedores criam soluções em vez de infraestruturas e monitoram a execução e não a integridade do ambiente. A finança paga por fatias de tempo, não um farm de máquina virtual (VM) principalmente ocioso. No Microsoft Azure, há vários serviços consumíveis que podem ser colocados em cadeia para formar uma solução inteira. Um novo componente importante é o Azure Functions, que fornece o recurso de computação sem servidor em um ecossistema completo de solução. Neste artigo, exploraremos o que significa ter uma arquitetura sem servidor e também as ferramentas do Azure Functions.

Arquitetura sem servidor com o Azure Functions

Há várias definições para a arquitetura sem servidor. Apesar da nomenclatura, a arquitetura sem servidor não é código que é executado sem servidores. Na verdade, os servidores ainda são muito necessários. Você apenas não precisa pensar neles. Você pode pensar que é a próxima iteração da Plataforma como um serviço (PaaS), e embora esteja perto, não é bem isso. O que exatamente é isso? Basicamente, a arquitetura sem servidor é a próxima evolução dos serviços de nuvem, criada sobre o PaaS, abstraindo as VMs, estruturas dos aplicativos, e dependências externas através de associações para que os desenvolvedores possam focar simplesmente no código para implementar a lógica de negócios.

É prudente discutir as propriedades típicas do Azure Functions e das arquiteturas sem servidor. O Azure Functions fornece o componente de computação sem servidor de uma arquitetura sem servidor. Conforme exibido na Figura 1, o Azure Functions foi criado sobre o Serviço de Aplicativo do Azure e o SDK do WebJobs, adicionando um pouco de mágica extra para hospedar e executar o código do Azure Function e fornecer algumas iguarias, como a associação do tempo de execução.

Figura 1 - Arquitetura do Azure Functions

Dessa forma, todos os benefícios que você obtém ao usar o Serviço de Aplicativo do Azure estão lá e podem ser encontrados logo abaixo dos serviços, nas configurações. Além disso, isso também significa que o SDK do WebJobs pode ser usado localmente para criar um ambiente de tempo de execução local. Embora não seja um benefício arquitetural, o Azure Functions é uma plataforma poliglota que oferece suporte a uma variedade de linguagens, incluindo Node.js, C#, PhP, Python e até mesmo o Windows PowerShell. Os tempos de execução e as dependências são tratados pela plataforma. Isto é uma vantagem para aqueles que estão trabalhando em ambientes mistos, pois permite que as equipes com diferentes preferências e habilidades aproveitem a mesma plataforma para a criação e entrega de funcionalidades. O uso do Azure Functions como o componente de computação sem servidor de uma arquitetura sem servidor oferece vários benefícios importantes:

Tempo de colocação no mercado reduzido: Como a infraestrutura de base é gerenciada pela plataforma, os desenvolvedores são livres para focar no código do aplicativo que implementa a lógica de negócios. O Azure Functions pode ser considerado uma decomposição adicional dos microsserviços para os nanosserviços. Ambos os paradigmas fornecem um recurso ao processo de desenvolvimento pois as atividades de desenvolvimento, teste e implantação são focadas em pequenos bits da funcionalidade que é gerenciada separadamente a partir de outros serviços discretos mas gerenciados.
Custo total reduzido de propriedade: Como há uma infraestrutura ou sistemas operacionais para manter, os desenvolvedores podem focar no fornecimento de valor para os negócios. Além disso, o investimento necessário para DevOps e manutenção são reduzidos e simplificados de forma significativa.
Pagar por execução: Uma poupança principal normalmente é encontrada ao pagar somente pelos ciclos consumidos juntamente com o aumento da densidade funcional dos recursos de computação utilizados.

Com base na sua abordagem ao compilar usando o Azure Functions, uma dica para realizar o valor completo é escrever somente a unidade de lógica menor para fazer um escopo único de trabalho e para manter as dependências em um mínimo. Ao trabalhar com o Azure Functions, é melhor seguir estas práticas:

Um Azure Function deve ter uma finalidade única na natureza. Pense neles como demonstrativos concisos e curtos em vez de sentenças compostas.
As operações são idempotentes na natureza. Isso significa que o estado resultante do sistema a partir de uma chamada para um ponto de extremidade de API não será alterado se for chamado várias vezes com os mesmos parâmetros.
Mantenha os tempos de execução breves. O objetivo deve ser receber entrada, realizar as operações desejadas e obter os resultados para os consumidores downstream. Para processos de execução demorada, você deve considerar o WebJobs do Azure ou até mesmo hospedar o serviço no Azure Service Fabric.
Em uma tentativa para manter a complexidade geral baixa e execução rápida, é melhor minimizar as dependências internas. Adicionar muito peso de tempo de execução irá diminuir os tempos de carga iniciais e adicionará complexidade ao sistema.
Integração externa através de associações de entrada e saída. Uma diretriz comum fornecida para sites de alto desempenho é escrever os serviços sem estado. Isso ajuda ao não complicar ou diminuir um serviço para manter, serializar e desserializar o estado de tempo de execução, bem como simplificar os esforços de depuração pois você não precisa descobrir e tentar reproduzir o estado para descobrir o que aconteceu. Sem o estado, é apenas uma questão de passar os valores do parâmetro de volta.

As propriedades da arquitetura sem servidor incluem o seguinte:

A unidade de trabalho em uma arquitetura sem servidor assume a forma de uma função sem estado invocada pelos eventos.
A colocação em escala, a capacidade e o gerenciamento de infraestrutura são fornecidos como um serviço.
Modelo de cobrança baseado em execução onde você paga somente pelo tempo que seu código está em execução.

Alguns desafios da arquitetura sem servidor incluem o seguinte:

Complexidade: Enquanto a arquitetura sem servidor simplifica várias coisas para o desenvolvedor, as abstrações da plataforma exigem que você pense novamente na forma como você cria os aplicativos. Gerenciar um aplicativo monolítico como uma unidade única é mais simples do que gerenciar uma estratégia de funções com finalidade específica e as dependências entre elas. É aqui que os recursos como esses fornecidos pelo Gerenciamento de API do Azure são necessários, oferecendo a você uma maneira de criar uma saída consistente do namespace que une todas as funções gerenciadas e discretamente definidas.
Ferramentas: Relativamente novas, as ferramentas para escrever, depurar e testar funções ainda estão em desenvolvimento. Deste esta escrita que elas estão em visualização, mas o Visual Studio 2017 terá as ferramentas internas. Além disso, as ferramentas de gerenciamento e monitoramento ainda estão evoluindo, mas há uma interface básica do Azure Functions onde você pode ver detalhes de solicitações, sucesso, erros e solicitação-resposta. Há muito trabalho pela frente quando se trata de juntar na plataforma com ferramentas de monitoramento de aplicativo e a equipe do Azure Functions está trabalhando para crescer e evoluir esse suporte.
Suporte institucional: É uma consideração não trivial para mover para um paradigma sem servidor. Várias organizações são desafiadas a mover para um pipeline de integração contínua (CI)/entrega contínua (CD) totalmente automatizadas e arquitetura de microsserviços. A mudança para um design sem servidor pode adicionar a essas dificuldades, pois irá sempre desafiar os padrões atuais e requer recursos educacionais sobre o que está disponível, como unir e como gerenciá-lo.
Nenhuma otimização de tempo de execução: Em um design tradicional, você deve otimizar o ambiente de execução para a carga de trabalho, alterando o tipo e a quantidade para itens como RAM, troca, conectividade de rede e disco. Com o Azure Functions, somente alterações mínimas podem ser feitas, tais como qual conta de armazenamento usar.

Arquitetura Tradicional vs. Arquitetura sem servidor

Um conjunto típico de artefatos de design para um sistema inclui um design lógico, design técnico e arquitetura de software. O design lógico normalmente define os recursos de um sistema e o que ele faz, enquanto o design técnico normalmente define o que o sistema é. Ao mudar para uma arquitetura sem servidor, você se torna mais preocupado sobre o que um sistema faz mais do que o que ele é. Em várias lojas de TI você pode encontrar mais diagramas de arquitetura que se parecem com a Figura 2.

Figura 2 - Arquitetura Técnica Tradicional

Este tipo de artefato é bastante importante para as pessoas no grupo DBA, rede e hospedagem, pois precisam saber o que provisionar e configurar. No entanto, em um ambiente de Plataforma como serviço (PaaS), o foco está nas propriedades funcionais e você deixa os detalhes de provisionamento para que a plataforma tenha somente que definir a configuração dos serviços de PaaS. Os detalhes sobre sua entrada na configuração serão mantidos em modelos e todas as conversas que você tem são focadas nos recursos, integração e funcionalidade em vez de discussões sobre quais são as quantidades ideais em RAM, CPUs e disco.

Os diagramas de resultado podem estar um pouco mais perto daquilo que você normalmente vê em um diagrama lógico, conforme representado na Figura 3. Esses diagramas podem começar a focar nas partes das funções e como elas se unem, em vez de focar na configuração dos hosts de aplicativo. Esta simplificação de mensagem e esclarecimento da finalidade ajudará não apenas nas discussões técnicas sobre intenção e implementação, mas inevitavelmente ajudará a transmitir o valor de um sistema para um escritório não técnico, pois o foco muda de o que o sistema é para uma discussão sobre o que ele faz para alguém.

Figura 3 - Arquitetura sem servidor

Azure Functions em ação

A plataforma do IoT do Azure fornece um conjunto avançado de serviços para oferecer suporte à coleção e à análise de dados. Nosso exemplo envolve uma implementação de IoT existente criada para coletar telemetria de veículo e armazená-la na nuvem, com funcionalidade analítica básica. Agora queremos explorar a adição de novos recursos à solução, tais como poder consultar os dados em tempo real para encontrar o veículo mais próximo de um determinado lugar. Você pode usar esse tipo de funcionalidade em um programa de compartilhamento de carro com negociação livre ou até mesmo para encontrar seu carro em um estacionamento.

Devemos observar algumas limitações nesta implementação de exemplo, pois estamos pegando alguns atalhos para demonstrar as ferramentas e a plataforma. Primeiro, estamos trabalhando diretamente com um DocumentDB de partição única. Em uma implementação no horário nobre, teríamos o DocumentDB com fragmentos mínimos com base no volume de dados esperado, mas também poderíamos ter escolhido fazer outras coisas, como adicionar o Cache Redis do Azure e a Pesquisa Elástica do Azure, como significado para otimizar alguns dos caminhos de leitura. Em segundo lugar, como a API do DocumentDB atual necessitaria de um processamento mais do lado do cliente para acessar os registros que queremos comparar, pegamos o atalho para pedir somente os 100 registros principais. Os recursos de particionamento e pesquisa seriam um caminho mais típico para encontrar os registros necessários em um grande conjunto. De qualquer forma, você ainda utilizaria a função para encontrar os potenciais registros e depois compará-los ao local fornecido e retornaria o veículo mais próximo ao conjunto.

Criando a Função

No momento em que isto foi escrito, as ferramentas do Visual Studio não estavam disponíveis para ajudar a acelerar o processo de desenvolvimento. Assim, iniciaremos ao criar a Função do Azure através da interface do portal. Após iniciar a criação do Azure Functions no portal do Azure, você será apresentado à folha para definir algumas configurações para sua função. Observe as opções para a seleção do plano do Serviço de Aplicativo: Plano de Consumo e Plano do Serviço de Aplicativo. Escolher entre esses dois planos parece ser simples, mas na verdade, você está sendo apresentado para escolher entre o estilo antigo do gerenciamento de recursos e as metas idealísticas de uma arquitetura sem servidor. Ao escolher um Plano do Serviço de Aplicativo, você deve tentar prever quanto poder de processamento será necessário. Se você escolher muito, vai pagar por recursos que não está utilizando, mas escolher pouco também levará a problemas com sua implementação que causa impacto em seus clientes e sua conclusão. Escolher o Plano de Consumo é o ideal, pois ele deixa o dimensionamento por conta do sistema e você, enquanto consumidor, paga somente por aquilo que seu aplicativo consumir.

Sua etapa final é para realmente criar a função. Você vai começar com a função preexistente do Webhook usando C#. Isso irá pré-configurar um Gatilho para processar a função baseada no recebimento de uma solicitação HTTP. Ao selecionar o item Integrar no menu à esquerda, várias opções podem ser escolhidas para configuração de Gatilho, Entrada e Saída. A página Seleção de gatilho contém algumas informações úteis, incluindo informações sobre as associações de WebHook, informações sobre como usar as Chaves de API, e alguns códigos de exemplo para chamar o WebHook a partir de C# e Node.js. Após ser apresentado com o diálogo, você irá configurar as associações de Entrada e Saída, conforme exibido na Figura 4.

Figura 4 - Configuração de Associação de Entrada

Enquanto você pode incluir bibliotecas e adaptadores para realizar chamadas para sistemas externos, o sistema funciona através de Associações e tem suporte de primeira classe para várias fontes de dados como EventHubs e DocumentDB. A experiência de desenvolvimento é aprimorada por meio da infraestrutura de Associações que faz parte do Azure Functions. As Associações abstraem a infraestrutura real de software de destino (DocumentDB, EventHubs, Armazenamento e assim por diante), deixando o código do desenvolvedor para o parâmetro representando o destino, enquanto permanece flexível porque o destino pode ser alterado ao alterar a configuração. Aqui, você configurou para falar para o DocumentDB de origem. A partir dessa configuração, você poderá escrever código diretamente no cliente do DocumentDB na função e não terá que fazer a conexão sozinho. Observe o nome de parâmetro do documento: inputDocument. Essa é a variável que foi aprovada na função que você utilizará para realizar chamadas para o DocumentDB.

Aqui, as opções de saída podem ser vistas e incluem armazenamento, enfileiramento e outros sistemas externos. Todos os itens que podem ser selecionados e configurados através da interface do usuário podem ser acessados posteriormente através da Interface do usuário nas Configurações do aplicativo de funções e podem ser configurados como parte de um modelo ou através de interfaces programáticas. Você está simplesmente retornando o resultado JSON sobre HTTP para o chamador. Como o HTTP (res) já está definido para Saída com um parâmetro de saída definido, você o aceitará assim.

Desenvolvendo o Código

Após selecionar Desenvolver no menu à esquerda, você é apresentado a um editor online. Isso é bom para alterações interativas rápidas e para ver seu log em tempo real, e ainda lhe oferece uma interface para disparar a Função de Gatilho. As ferramentas estão em andamento para o Visual Studio e o Visual Studio Code que irão fornecer uma experiência mais sofisticada. Se você está trabalhando com o Azure Functions hoje, talvez queira usar um IDE, e o Visual Studio conecta facilmente ao Aplicativo de funções através do Gerenciador de Servidores.

Há algumas coisas que você precisa fazer ao editar os arquivos. Logo abaixo da janela de Código há um link para Exibir arquivos. Abra o Gerenciador de arquivos diretamente à direita da janela de Código. Primeiro, você precisara do cliente do DocumentDB. Há várias bibliotecas que estão disponíveis automaticamente para serem referenciadas ao usar a diretiva #r na parte superior. A lista dessas bibliotecas, assim como outras informações de desenvolvedor, podem ser encontradas na referência de desenvolvedor online em bit.ly/2gaWT9x. Por exemplo, você precisará de acesso aos objetos cliente do DocumentDB porque há suporte de primeira classe para o DocumentDB. Você simplesmente adicionará a diretiva #r para esse assembly na parte superior do arquivo. Se uma biblioteca que você precisa não estiver incluída, informe uma que você mantém e publique no NuGet. Ela pode ser adicionada a um arquivo project.json (package.json no Node.js).

Nesse momento, você está pronto para editar o arquivo run.csx, que irá armazenar todo o seu código. Para fazer isso, você irá editá-lo diretamente no IDE online do Azure Functions, conforme exibido na Figura 5.

Figura 5 - Edição do Código de função

Começando com o código de modelo, primeiro adicione sua própria biblioteca externa personalizada à função, pois ela contém o código para a função haversine. Se você possui classes ou funções personalizadas que não são muito grandes e são específicas da função, adicione-as diretamente no arquivo run.csx. No entanto, se tiver itens reutilizáveis, faça um caminho diferente e inclua sua versão compilada em uma pasta \bin ou faça referência a eles como pacotes NuGet através do arquivo project.json e faça referência à biblioteca com #r. Como alternativa, coloque o código em um arquivo .csx diferente e use a diretiva #load.

São necessárias algumas funções para ajudar a determinar a distância entre os veículos dos quais você está verificando a proximidade e o ponto que eles foram aprovados na função. Já faz algum tempo desde que as aulas começaram e parece que você não precisa de uma fórmula haversine com frequência. A Wikipedia oferece uma boa referência para isso em bit.ly/2gCWrgb e nós pegamos emprestado a função C# de bit.ly/2gD26mK e fizemos algumas alterações. Criamos as funções necessárias como membros estáticos de uma classe haversine:

namespace SphericalDistanceLib
{
  public class Haversine
  {
    public static double CalculateDistance(
      double currentLong, double currentLat,
      double vehicleLong, double vehicleLat){…}
    public static double ToRadians(double degrees){...}
  }
}

O código é compilado e, em seguida, carregado para uma pasta bin relativa à pasta raiz da função. Em nosso caso, o caminho é FindNearVehicle/bin, mas a pasta bin deve ser criada pois ela não está la por padrão. Com esse bit de configuração concluído, você muda seu foco para o código necessário. Na parte superior da função, você precisará garantir que está fazendo referência a quaisquer bibliotecas necessárias. Em particular, você precisa dos tipos de objeto cliente do DocumentDB, Newtonsoft e da biblioteca personalizada que foi carregada para a pasta \bin. Eles são adicionados na parte superior do arquivo usando a diretiva #r:

#r "Microsoft.Azure.Documents.Client"
#r "Newtonsoft.Json"
#r "SphericalDistanceLib.dll"

Conforme observado anteriormente, você irá obter os últimos 100 registros com base no campo created_at timestamp. O DocumentDB possui uma boa sintaxe SQL que facilita bastante isso:

IQueryable<Document> telemDocs = inputDocument.CreateDocumentQuery<Document>(
  UriFactory.CreateDocumentCollectionUri(dbName, collectionName),
  new SqlQuerySpec("SELECT TOP 100 c.vehicle.vin, c.vehicle.model,
  c.location FROM c ORDER BY c.created_at DESC"), queryOptions);

Você está usando o tipo de Documento, que facilita um pouco as coisas, pois você irá convertê-lo para um tipo Dinâmico para adicionar facilmente propriedades ao objeto. O SQL está aprovado na forma de um SqlQuerySpec e você irá proteger somente o vin, o modelo e a localização em seu objeto. Nesse momento você deve iterar a lista de documentos, calcular a distância usando a função haversine na biblioteca externa e determinar a mais próxima e retorná-la. No entanto, isso fica um pouco complicado.

Você precisa acompanhar todos os vins que você viu, porque você só quer o registro de localização mais recente para esse vin. Como você irá ordená-lo de forma decrescente, o primeiro documento é o último documento recebido. Você irá verificar o vin para nulo, pois está procurando nos veículos que estão sendo conduzidos e se houver um nulo no vin, você pode assumir que esse documento é inválido. Se o elemento tiver um valor não nulo, você simplesmente tentará adicionar o vin a um HashSet. Se ele for único na lista, a adição terá êxito, mas se não, ela irá falhar e você saberá que já tem o registro mais recente para esse veículo na lista, conforme exibido na Figura 6.

Figura 6 - Última localização conhecida para vins distintos

HashSet<string> seen = new HashSet<string>();
foreach(dynamic doc in telemDocs){
  if(seen.Add(doc.vin)){
    // Calculate the distance
    if (doc.location != null) {
      doc.distance =
        Haversine.CalculateDistance(double.Parse(currentLong),
        double.Parse(currentLat), double.Parse(
        doc.location.lon.ToString()),
        double.Parse(doc.location.lat.ToString()));
      lastKnownLocations.Add(doc);
    }
    else{
      // Location is null, so we won't take this
      // record as last known location
      seen.Remove(doc.vin);
    }
  }
}

Você adiciona todo o documento à lista lastKnownLocations, facilitando a consulta do primeiro documento com base na ordem pelo valor de distância mínimo:

var nearestVehicle = lastKnownLocations.OrderBy(x => ((dynamic)x).distance).First();
return currentLat == null || currentLong == null
  ? req.CreateResponse(HttpStatusCode.BadRequest,
  "Please pass a lat and lon on the query string or in the request body")
  : req.CreateResponse(HttpStatusCode.OK, nearestVehicle);

O primeiro documento na lista ordenada pode ser retornado, conforme visto na última linha, onde também ocorre uma verificação de parâmetro null e a serialização do documento é realizada para você.

Executando o exemplo

A última etapa é ver isso acontecer. Na parte superior direita da exibição de desenvolvimento há um link com um ícone flash anexado ao Teste rotulado. Clicar nisto abrirá a interface do usuário de teste, conforme exibido na Figura 7. Lá você pode alterar o método HTTP, adicionar parâmetros, adicionar cabeçalhos e definir o corpo a ser aprovado no método HTTP selecionado. Normalmente utilizamos o Postman quando estamos fazendo muito deste trabalho, pois temos uma biblioteca de testes. No entanto, os recursos de teste interno para funções de HTTP são excelentes e imediatamente disponíveis para um trabalho interativo rápido.

Figura 7 - Testando uma função

Pegamos a latitude e a longitude e as formatamos no formato JSON esperado na janela de Execução. Após clicar em Execução, qualquer saída das chamadas para o objeto de log e saída do log geral pode ser vista na janela de Logs com a saída e o status vistos na parte inferior direita na janela de Saída. Ao anotar os tempos na saída do log, parece que levou cerca de 250 ms para que nossa função fosse executada. Isso é bom no modelo de execução no qual estamos tentando com o Azure Functions: tempos de execução relativamente curtos e finalidade única. Ao retirar o conteúdo da janela de Saída e formatá-lo, podemos ver mais claramente que temos o veículo, o carimbo de data/hora quando a localização foi gravada, a localização e a distância:

{
  "vin": "wmwrxxxxxxxx54251",
  "model": "Cooper Hardtop",
  "location": {
    "lat": 30.4xxxxxx,
    "lon": -97.8xxxxxx,
    "accuracy_m": 22.505,
    "ts": 1473116792970
  },
  "distance": 13.552438042837085
}

Quando fizemos o cálculo da distância, fornecemos a circunferência da Terra em quilômetros, assim a distância representada no retorno é de cerca de 13,6 km.

Conclusão

No exemplo, usamos uma mistura de ferramentas online para desenvolver e processar o Azure Functions, mas uma abordagem mais realística para uma equipe de desenvolvimento seria desenvolver localmente e configurar a integração e implantação contínuas através de um repositório Git. Ao usar o SDK WebJobs.Script e WebJobs você pode configurar a capacidade de desenvolver e executar o Azure Functions localmente. Um bom guia passo a passo de como fazer isso pode ser encontrado em bit.ly/2hhUCt2. Você também encontrará algumas fontes diferentes que podem ser configuradas como a fonte para implantações.

O Azure Functions é a novidade na plataforma do Azure. É um ingrediente principal da computação sem servidor que é necessário para atingir os benefícios de uma implementação PaaS na nuvem. O Azure Functions muda o foco para o valor do código e afasta-se da infraestrutura de gerenciamento. A plataforma, suporte a ferramentas, e suporte a idiomas continua a evoluir, mas já oferece suporte a vários idiomas e pode ser associado ao seu pipeline de CI/CD. Mais informações podem ser encontradas em bit.ly/2h7lo4C. Se você ainda não trabalha com o Azure Functions, deveria experimentar. Você pode começar acessando o link bit.ly/2glBJnC.

A mudança para a computação sem servidor

A computação sem servidor representa uma mudança fundamental no paradigma sobre como pensamos na computação na nuvem e na criação de aplicativos para a nuvem. A computação sem servidor oferece aos desenvolvedores um ambiente completamente abstrato e infinitamente escalonável para executar seu código e fornece um modelo de pagamento totalmente focado na execução do código.

A computação sem servidor pode ser vista como a próxima etapa na evolução da Plataforma como um serviço (PaaS). Ela preenche a promessa do PaaS de abstrair a infraestrutura do aplicativo a partir do código e fornecer recursos de escala automática. O principal diferencial sem servidor é o modelo de preços de execução (em vez de pagar pelo tempo que em o código é hospedado) e a escala ilimitada e instantânea. A computação sem servidor fornece uma experiência de computação (sem tarefas administrativas) totalmente gerenciada, escala (sem configurações de escala) instantânea e ilimitada e (processamento em tempo real) que reage a eventos. Isso possibilita os desenvolvedores a desenvolver uma nova classe de aplicativos que escala por design e, ultimamente, é mais resiliente.

Os desenvolvedores criando aplicativos sem servidores usam a computação sem servidor como o Azure Functions, mas também usam vários serviços de terceiros ou totalmente gerenciados pelo Azure para compor o trabalho em soluções sem servidores de ponta a ponta. Hoje em dia, os desenvolvedores podem facilmente configurar e executar arquiteturas sem servidor completas que escalam com facilidade, design e baixo custo. Os desenvolvedores também ficam livres da infraestrutura de gerenciamento e monitoramento. Eles podem focar na lógica comercial e resolver problemas relacionados aos negócios e não à manutenção da infraestrutura que está executando o código.

A computação sem servidor está aqui para alterar a forma como pensamos sobre a criação de aplicativos. E vai ficar por muito tempo. Junte-se à conversa em bit.ly/2hhP41O e bit.ly/2gcbPzr. Envie solicitações de recurso para bit.ly/2hhY3jq e acesse o nosso Twitter: @Azure com a hashtag #AzureFunctions. —Yochay Kiriaty

Darren Brust é um arquiteto de solução de nuvem na Microsoft, onde ele passa maior parte do tempo ajudando clientes corporativos conforme eles fazem a transição para o Microsoft Azure. Nos tempos livres, provavelmente você encontrará ele em um evento de esporte de um de seus três filhos ou em um café perto do escritório, em Austin, bebendo bastante café. Você pode contactá-lo através do email dbrust@microsoft.com ou no Twitter: @DarrenBrust.

Joseph Fultz é um arquiteto de solução de nuvem na Microsoft. Ele trabalha com clientes da Microsoft desenvolvendo arquiteturas para resolver problemas de negócios relacionados ao Microsoft Azure. Anteriormente, Fultz era responsável pela arquitetura e desenvolvimento do programa de compartilhamento de carro da GM (mavendrive.com). Contacte-o através do Twitter: @JosephRFultz ou por email em jofultz@microsoft.com.

Agradecemos ao seguinte especialista técnico da Microsoft pela revisão deste artigo: Fabio Calvacante