O futuro do Serverless

É 2017 e a revolução Serverless já tem um pouco mais de dois anos. Essa revolução não está causando um impacto tão grande como o Docker causou, mas está crescendo de forma sólida. A Amazon Web Services lança novas funcionalidades em seu produto Lambda com regularidade, outros grandes vendors estão lançando versões prontas para produção dos seus produtos e novos projetos open-source estão frequentemente se juntando a essa iniciativa.

Enquanto chegamos ao fim da fase de adoção inicial, é um exercício interessante tentar prever para onde o movimento da computação Serverless está se direcionando, como está evoluindo e, o mais importante, quais mudanças precisamos que nossas organizações façam para suportá-lo.

Uma visão das potencialidades da Computação Serverless

Computação

A última década presenciou o surgimento e, em seguida, o crescimento meteórico da computação em nuvem. Há nove anos atrás, servidores virtuais na nuvem eram 'brinquedos' para startups, mas em um tempo relativamente curto, a computação em nuvem se tornou a principal plataforma para grande parte da indústria de software, ao planejar arquiteturas de implantação.

A Computação Serverless ou a Funções-como-um-serviço (Faas), faz parte de uma fase mais recente da massiva mudança sobre como qualificamos Tecnologia da Informação (TI). É a evolução natural do desejo incessante de remover toda bagagem é inventário de infraestrutura da entrega de aplicações para clientes.

Um grande número de aplicações que desenvolvemos consiste de vários pequenos comportamentos. Cada um destes comportamentos recebe um conjunto de entradas e um contexto informacional, realiza um trabalho por alguns décimos ou centésimos de segundo e finalmente pode responder com um resultado e/ou atualizar o 'mundo' em torno deles. A computação serverless se baseia nestes comportamentos.

Previmos que muitas equipes irão adotar FaaS devido a facilidade, agilidade e baixo custo que ela proporciona para a implantação, gerenciamento e escalabilidade da infraestrutura necessária para este tipo de lógica. É possível estruturar o uso de FaaS de várias formas, incluindo:

• Pipelines de dados consistindo de múltiplos processadores de mensagens em sequência;
• Serviços síncronos acessíveis por uma API HTTP;
• Partes independentes de código de integração para realizar operações lógicas customizadas para a implantação, monitoramento, etc;
• Sistemas híbridos formados por servidores tradicionais de alta disponibilidade que invocam diretamente funções de plataformas escaláveis para tarefas mais computacionalmente mais intensas.

As organizações que adotarem a FaaS terão uma vantagem competitiva sobre aquelas que não o fizerem devido à redução de custo e a agilidade que o FaaS proporciona.

Gerenciando o estado de aplicações

Um dos pré-requisitos da adoção em larga-escala da FaaS é prover uma solução, ou conjunto de soluções, para gerenciamento de estado ágil e simples. Computação serverless é um paradigma stateless. Não podemos assumir que qualquer manutenção de estado exista no ambiente de execução que esteja disponível entre a invocação de duas funções. Algumas aplicações estão preparadas para esta restrição. Por exemplo, componentes orientados a mensagens que são puramente transformacionais, não necessitam de acesso a um estado externo, ou web services sem grandes restrições de performance que podem se conectar a um banco de dados remoto em cada vez que são invocados. Mas, para outras aplicações, isso é insuficiente.

Uma possibilidade para resolver isso é uma arquitetura híbrida que gerencia estado em componentes que não executam código FaaS. A abordagem híbrida mais popular é disponibilizar funções FaaS através outros serviços disponibilizados na nuvem. Isso já ocorre em componentes como o AWS API Gateway que disponibiliza um endpoint HTTP, com funcionalidades como caching, monitoramento, controle de acesso e performance. Essas funcionalidades que geralmente são codificadas em um web service típico são definidas através de configurações. A Amazon já demonstraram seu comprometimento com a computação Severless com uma abordagem mais genérica para o gerenciamento de estado disponibilizando o AWS Step Functions, que permite definir aplicações através da configuração de máquinas de estados. O Step Functions pode não ser largamente utilizado mas soluções como estas estão se tornando bastante populares.

Quando serviços disponibilizados por vendors são insuficientes, uma abordagem híbrida alternativa é continuar utilizando componentes que gerenciam estado que podem ser implantados em plataformas CaaS (Container-como-um-serviço) ou PaaS (Plataforma-como-um-serviço) e integrá-los com funcionalidades implantadas em FaaS.

Estes sistemas híbridos combinam lógica com manutenção de estado (stateful) e lógica FaaS sem manutenção de estado (stateless). Uma alternativa é focar toda lógica FaaS e disponibilizar mecanismos extremamente rápidos de obtenção e persistência de estado. Uma implementação possível seria garantir que uma certa função ou conjunto de funções FaaS tenham acesso a um cache externo de baixíssima latência, como por exemplo o Redis. Isso poderia ser viabilizado viabilizando uma funcionalidade similar aos placement groups da Amazon que conectam logicamente componentes através de infraestrutura de rede de baixa latẽncia e elevada largura de banda. Apesar desse tipo de solução depender mais da latência de rede do que memória (ou disco) para manutenção de estado e contexto, em várias situações essa solução pode ser aceitável.

Os benefícios de uma abordagem híbrida são que as informações de estado que são acessadas frequentemente podem permanecer no próprio ambiente que a lógica, e soluções complicadas e caras para conectar a lógica e os repositórios de dados contendo o estado seriam dispensáveis. Por outro lado, os benefícios de uma abordagem puramente FaaS seriam um modelo de programação mais consistente além de uma possibilidade maior de se utilizar benefícios operacionais e de escalabilidade que a computação Serverless proporciona. O momento atual sugere que abordagens híbridas devem prevalecer, mas devemos ficar atentos para soluções como Lambdas com Placement Groups agregados e outras similares.

Serviços colaborativos Serverless

Além da orquestração e gerenciamento de estado, percebemos a comoditização e "servicificação" de outros componentes que tradicionalmente seriam desenvolvidos e/ou gerenciados internamente, mesmo que na nuvem. Por exemplo, seria possível parar de usar nossos servidores MySQL em instâncias EC2 e utilizar o Amazon RDS, poderíamos substituir nossas instalações do Kafka message-bus e utilizar o Kinesis. Outros serviços relacionados com infraestrutura computacional incluem sistemas de arquivos e data warehouses enquanto que exemplos mais orientados a aplicações incluem autenticação e análise de fala.

Esta tendência deve continuar, reduzindo ainda mais o trabalho necessário para se criar e manter nossos produtos. Podemos imaginar que mais lógica embarcada vem pela frente (imagine um tipo de 'Apache Camel como um serviço embutido no Amazon Kinesis ou SQS) e ainda outros novos desenvolvimentos em serviços de aprendizado de máquina.

Uma ideia interessante é que funções FaaS, devido à leveza da sua arquitetura, podem por si próprias serem usadas para se definir um serviço levando a um ecossistema de funções FaaS chamando serviços que também chamam outras funções FaaS e assim por diante. Isto leva a problemas 'interessantes' com o cascateamento de erros, para os quais são necessárias ferramentas de monitoramento melhores, a serem discutidas mais adiante neste artigo.

Além do datacenter

Grande parte da computação Serverless tem se se baseado em plataformas disponibilizadas por vendors e hospedadas em seus próprios datacenters. É uma forma alternativa para executar o seu código mas não te dá opções de onde executá-lo. Um projeto novo e interessante da Amazon deve permitir que funções Lambda sejam executadas nos pontos de presença mais próximo da sua CDN usando o Lambda@Edge e até mesmo em ambientes sem servidores, como por exemplo dispositivos IoT usando o AWS Greengrass . Isso é viável porque o Lambda é um modelo de programação extremamente leve que é inerentemente orientado a eventos e assim é fácil se utilizar as mesmas ideias e estilo de codificação. O Lambda@Edge é um exemplo interessante pois permite criar uma customização programada onde nunca tinha sido feito anteriormente.

Uma desvantagem desse modelo é um maior aprisionamento tecnológico ao fornecedor (vendor lock-in). Para organizações que não desejam usar os serviços de um vendor mas que querem os benefícios da computação Serverless poderão fazer isso usando uma solução em sua própria infraestrutura (on-premises) como o CloudFoundry tem feito para PaaS. Galactic Fog, Iron Functions e Fission, da Kubernetes são exemplos em uma estágio preliminar.

Ferramentas e técnicas necessárias

Como eu escrevi anteriormente, existem obstáculos, limitações e contrapartidas quando se usa a abordagem Serverless. Não existe almoço de graça. Para os usuários do Serverless ir além dos que a adotaram inicialmente, nós precisamos mitigar estes problemas. Felizmente já existem iniciativas nessa área.

Ferramentas para implantação (deployment)

Fazer o deploy de funções no AWS Lambda utilizando ferramentas padrão pode ser complexo e sujeito a falhas. Acrescente ainda o uso do API Gateway para expor funções Lambda usando HTTP e você terá ainda mais setup e configuração a fazer. Os projetos open-source Serverless e ClaudiaJS estão trabalhando em melhorias no deployment por aproximadamente um ano e a AWS juntou-se a festa com o SAM em no final de 2016. Esses projetos simplificam a criação, configuração e a implantação de aplicações Serverless adicionando uma automação considerável ao ferramental padrão da AWS. Mas ainda há muito o que ser feito aqui. No futuro duas atividades chave serão altamente automatizadas:

1. A criação inicial de uma aplicação e/ou ambiente (ex: ambientes de produção, desenvolvimento e testes)
2. Entrega Contínua (Continuous Delivery) e implantação (Deployment) de aplicações multi-componentes

A primeira deles é importante para permitir de forma mais abrangente a otimização do tempo entre a concepção e colocar o serviço em produção, que foi mencionado no início do artigo. Implantar uma aplicação Serverless nova precisa ser tão fácil quanto criar um novo repositório Github - preencher alguns poucos campos, pressionar um botão e ter algum sistema criando tudo que você precisa para permitir o 'one-click deployment'.

Mas implantação inicial fácil não é suficiente. Nós também precisamos de boas ferramentas para suportar a Entrega Contínua (CD) a adoção de aplicações híbridas que eu mencionei anteriormente. Isso significa que devemos ser capazes de implantar um conjunto de componentes FaaS, CaaS e PaaS juntos, com mudanças em quaisquer dos serviços encapsulados (como por exemplo: configuração de rotas HTTP em um API Gateway ou tabela Dynamo DB usada apenas por essa aplicação) em um único click com downtime zero e capacidade de rollback de ambiente trivial. E além disso, nenhum deles deve ser intelectualmente difícil de entender ou demorar dias de trabalho para configurar e manter.

Esse é um apelo difícil mas as ferramentas que eu mencionei anteriormente (juntamente com ferramentas híbridas como Terraform) estão assumindo a liderança na resolução desses problemas e eu espero que esses problemas sejam totalmente resolvidos nos próximos meses e anos.

Este tópico não é somente sobre implantar o código e configurar serviços. Várias outras preocupações operacionais estão envolvidas. Segurança é uma grande delas. Atualmente configurar e manter suas credenciais AWS pode ser uma dificuldade. A AWS possui um modelo de segurança robusto mas precisamos de ferramentas para torná-lo ainda mais amigável para os desenvolvedores.

Resumindo, precisamos de uma experiência de uso para o desenvolvedor tão boa quanto a Auth0 tem para o seu produto Webtask mas para um ecossistema vasto (e valioso) como a AWS.

Monitoramento, Logging e Debugging

Estando a nossa aplicação instalada, também precisamos de boas soluções para monitoramento e logging, e ferramentas como essas estão em ativo desenvolvimento por várias organizações. Além de avaliar o comportamento de um único componente, nós também precisamos de boas ferramentas para rastrear requisições através uma cadeia inteira de um sistema distribuído de múltiplas funções Serverless e dispositivos que as suportam. A Amazon está começando a entrar nessa área com o X-Ray, mas ainda é cedo.

A depuração também é importante. Programadores raramente escrevem código corretamente para todo e qualquer cenário logo na primeira vez até agora e não há nenhuma razão para acreditar que isso irá mudar. Dependemos de monitoramento para avaliar problemas em funções FaaS em tempo de desenvolvimento mas essa é uma ferramenta de debug da idade das pedras.

Quando depuramos aplicações tradicionais, temos bastante suporte de IDEs para definir breakpoints, inspecionar variáveis, etc. Com IDEs modernas baseadas em Java, é possível conectá-la a um processo remoto que já está em execução, e fazer a depuração a distância. Já que nós pretendemos realizar a maior parte do desenvolvimento usando funções FaaS executando na nuvem, no futuro a sua IDE deve ter um comportamento similar para se conectar em uma plataforma Serverless em execução e depurar a execução de funções individuais. Para isso, vendors da plataforma e IDEs vão precisar de colaboração entre si e é necessário que isso ocorra para que o paradigma Serverless possa ser adotada de forma generalizada. Isto implica a implantação na nuvem mas vamos precisar disso de qualquer forma para testes.

Testes

Todos o ferramental Serverless que eu considerei até agora, o único que eu acredito que seja menos avançado é testes. Vale destacar que o Serverless tem vantagens expressivas em relação a testes em relação a soluções tradicionais: (a) as funções Serverless são propícias para testes unitários e (b) com serviços Serverless, você tem menos código para escrever e assim, menos código a ser testado, pelo menos em níveis unitários.

Mas isso não resolve o problema multi-funcional da 'jornada' de testes funcionais, de integração, e de aceitação. Com a computação Serverless, a nossa lógica está espalhada em diversas funções e serviços então teste de nível mais alto é ainda mais importante do que utilizar uma abordagem componentizada e monolítica. Mas como fazer isso se estamos tão dependentes da infraestrutura da nuvem para a execução ?

Este é, provavelmente, a previsão mais nublada para mim. Eu suspeito que os testes baseados em nuvem deverão prevalecer. Isso deve ocorrer parcialmente porque será bem mais fácil implantar, monitorar e depurar nossas aplicações Serverless do que é atualmente pelas razões que acabei de descrever.

Em outras palavras, para executar testes de alto-nível nós iremos implantar uma porção do nosso ecossistema na nuvem e executar os testes nos componentes lá mesmo, ao invés de executar em um sistema implantado em nossos ambientes de desenvolvimento. Isto traz consigo alguns benefícios.

• A fidedignidade de executar componentes implantados na nuvem é muito maior que nossa simulação local
• Poderemos executar testes com maior carta e com massas de dados mais ricas do que faríamos localmente
• Testar componentes em bases de dados de produção (como por exemplo, um service bus de publicação/subscrição ou um banco de dados) é bem mais fácil mas, obviamente, vamos precisar ser cuidadosos para não gerar problemas de capacidade e de segurança.

Esta solução também tem as suas desvantagens. Primeiro, o tempo para se executar os testes vão aumentar devido a problemas de implantação, latência da comunicação em rede entre o teste - que ainda deverá executar localmente - e o sistema sendo testado (SUT) executando remotamente. Segundo, não poderemos executar estes testes quando estivermos desconectados da internet (em um avião, por exemplo). Finalmente, já que os ambientes de produção e testes estarão implantados de forma muito semelhante, nós vamos precisar ser bem cuidadosos para evitar utilizar o ambiente de produção quando a intenção era utilizar o ambiente de testes. Se a AWS estiver sendo utilizada, esta segurança poderá ser implementada utilizando ferramentas como roles IAM (Identity and Access Management) ou utilizar contas totalmente diferentes para diferentes tipos de ambientes.

Testes não se tratam apenas de uma avaliação binária falhar/passar - também estamos interessados em saber como o teste falhou. Nós devemos ser capazes de depurar os testes em execução localmente assim como os componentes remotos que estão sendo testados, inclusive sendo capazes de depurar uma função Lambda executando na AWS passo-a-passo enquanto executamos o teste. E todas as ferramentas, depuração remota, etc que eu mencionei na seção anterior serão necessárias para testar também, não somente durante o desenvolvimento.

Note que não estou querendo dizer que nossas ferramentas de desenvolvimento precisam executar na nuvem, nem que os testes devam executar na nuvem mas que estas duas coisas deverão acontecer até um certo ponto. Estou meramente expressando que o sistema sendo testado deverá rodar na nuvem ao invés de um ambiente on-premises.

Usando Serverless como um ambiente orientado a testes pode levar a resultados interessantes. Um exemplo é o 'serverless-artillery'uma ferramenta de testes de carga criada a partir de várias funções AWS Lambda executando em paralelo para realizar testes de performance de forma fácil, barata e escalável.

Vale destacar que será possível, até um certo ponto, nos 'esquivar das balas' . Teste tradicional de nível mais alto está se tornando menos importante devido a avanços em técnicas onde nós (a) testamos em produção / usamos Monitoring-Driven-Development,(b) reduzimos significativamente o nosso tempo médio de resolução (MTTR - Mean-Time-To-Resolution) e (c) adotamos um mantra de implantação contínua (continuous deployment). Para muitas aplicações Serverless, testes unitários intensivos, monitoramento e alertas de produção extensivos em nível de negócio, uma abordagem dedicada de reduzir o MTTR e a adoção de Continuous Deployment serão estratégias suficientes de validação de código.

Arquitetura: Muitas questões a serem respondidas

Como uma aplicação Serverless bem elaborada se parece? Como ela evolui ?

Estamos presenciando um número crescente de estudos-de-caso de arquiteturas onde o Serverless está sendo utilizado efetivamente mas ainda não temos um agrupamento de padrões para aplicações Serverless. Por volta do ano 2000, tivemos livros como Patterns Of Enterprise Application Architecture, de Martin Fowler e Enterprise Integration Patterns de and Hohpe / Woolf. Com base em uma grande quantidade de projetos, os autores derivaram arquiteturas úteis nos mais diferentes domínios.

Estes livros se baseiam em vários anos de experiência nas ferramentas e antes de criar classificações e taxonomias. Serverless ainda não existe a um tempo suficiente como uma tecnologia para justificar livros como estes mas está chegando a perto e dentro de um ano ou um pouco mais, começaremos a ver algumas boas práticas emergirem (qualquer um que utiliza o termo 'best practice' nos dias atuais, merece um olhar no mínimo desconfiado).

Além da arquitetura de aplicações (como aplicações Serverless são construídas) também precisamos pensar em arquiteturas de implantação (como aplicações Serverless são operadas). Já discuti sobre ferramentas de implantação mas como devemos utilizar estas ferramentas? Por exemplo;

O que termos como 'ambiente' significam para este mundo ? 'Produção' parece menos bem delimitado do que costumava ser.

E como ficaria uma implantação lado-a-lado (side-by-side deployment) em que o tráfego fosse direcionado de uma certa versão de funções/serviços para uma nova versão diferente de funções/servicos (rolling deployment) ?

Será que existe o "blue-green deployment" nesse mundo ?

Como um roll-back funcionará agora ?

Como gerenciaremos a atualização / roll-back dos bancos de dados e outros componentes stateful quando podemos ter versões diferentes em produção de código rodando em funções simultaneamente?

Como um phoenix-server vai funcionar agora que teremos servicos de terceiros que você não poderá desativar e refazer o deploy simplesmente por precaução ?

Finalmente, quais sao os padrões de migração serão úteis durante a mudança de estilo arquitetural para algo que é ou que inclua componentes Serverless ? De que forma a nossa arquitetura pode mudar de uma forma evolutiva ?

Muitos destes padrões ainda a serem definidos (e anti-padrões) não são tão óbvios, mais claramente demonstrados pelas nossas ideias iniciais de como podemos gerenciar estado satisfatoriamente em sistemas Serverless. Não haverá dúvidas de que padrões surpreendentes e fascinantes irão surgir.

Como nossas organizações irão mudar

Enquanto beneficios financeiros sao um dos motivadores do Serverless, a vantagem mais interessante e a redução do tempo da 'concepção à produção'. Serverless permite esta redução atribuindo 'super poderes' a vasta maioria de nós, engenheiros que não são experts em administração de sistemas e no desenvolvimento de sistemas distribuídos. Aqueles de nós que sao 'meramente' especializados no desenvolvimento de sistemas serão capazes de implantar um MVP (Minimum Viable Project) completo sem ter que escrever uma linha de shell script, acrescentar instâncias a plataforma ou configurar um servidor nginx. Anteriormente eu mencionei que ferramentas de implantação (deploy) ainda estão sendo desenvolvidas e então não vemos essa solução de um 'MVP simples' como sendo viável para todos os tipos de aplicação nesse momento. No entanto, e isso já é possível para web-services simples e até mesmo para outros tipos de aplicações implantando algumas funções Lambda em que ainda pode ser mais fácil, na maioria dos casos, do que gerenciar processos ligados ao sistema operacional ou conteiners.

Além do MVP, também vislumbramos redução no tempo de desenvolvimento através da habilidade de se reimplantar aplicações sem ter que nos preocuparmos com a manutenção dos scripts do Chef/Puppet, patches em nível de sistema, etc.

O Serverless nos disponibiliza os meios técnicos para fazer isso mas isso não é o suficiente para viabilizar estes benefícios em uma organização. Para que isso ocorra as empresas deverão se batalhar e adotar o seguinte.

DevOps 'real'

DevOps ganhou um significado em vários lugares como a 'administração sistemas acrescentando técnicas geralmente usadas no desenvolvimento'. Apesar de eu gostar da ideia de se aumentar o nível de automação e testes na administração de sistemas, esta é uma pequena parte do que Patrick Debois estava pensando quando ele criou o termo DevOps

O DevOps verdadeiro, na verdade está relacionado com uma mudança de mentalidade e na cultura. E sobre ter apenas um time, trabalhando junto para desenvolver e operar um produto. Significa colaborar ao invés de negociar o trabalho a ser feito. Significa desenvolvedores prestando suporte. Significa que o pessoal tecnico de operacoes se envolvendo com a arquitetura da aplicação. Significa em outras palavras, uma mesclagem de conhecimentos e responsabilidades.

Organizacoes nao vao ver um ganho de eficiência no Serverless se eles tiverem times distintos de desenvolvimento (Dev) e operações (Ops). Se um desenvolvedor codificar uma aplicaç ao e aí precisar de alguém de fora do seu grupo para fazer o deploy do sistema, então os ganhos devidos aos feedbacks que poderiam ser recebidos são exterminados. Se um engenheiros de operações não está envolvido com o desenvolvimento de uma aplicação, eles não poderão se adaptar ao modelo de 'deployment on-the-fly'.

Em outras palavras, no futuro as companhias que conseguiram os real ganhos do Serverless serão aquelas que adotaram o DevOps real.

Mudanças em políticas e controles de acesso

Mas mesmo uma mudança na cultura de relacionamento entre as equipes não é suficiente. Em algumas ocasiões, em grandes organizações, uma equipe mais empolgada pode se posicionar contra a 'muralha de pedra' imposta pelas políticas organizacionais. Isso pode levar a impossibilitar a implantação de novos sistemas sem aprovação externa. Isso pode levar a restrições de acesso a dados para todas as novas aplicações. Pode significar severos controles de gastos.

Não estou sugerindo que as empresas joguem suas preocupações com segurança e custos pela janela para tirar o máximo do Serverless. eles vão precisar adaptar suas políticas para permitir que os times mudem seus requisitos operacionais sem a necessidade de aprovação de pessoas fora da equipe para cada pequena atualização. Políticas de acesso à informação devem existir, não somente para o contexto atual mas também para cenários futuros. As equipes precisarão ter uma certa liberdade sobre o orcamento alocado. E principalmente, experimentos deverão possuir um sandbox onde tudo é possível sem deixar de proteger as reais necessidades de uma organização.

Ferramental para controle de acesso tem melhorado através do uso de papéis (roles) IAM e múltiplas contas na AWS, como eu mencionei anteriormente. No entanto, isso ainda não é simples e demanda melhor automacao. Similarmente, controles rudimentares de orçamento existem para o Serverless, novamente, na maioria das vezes através de múltiplas contas, mas precisamos de um controle mais fácil no que concerne os limites de uso por cada time e para os diferentes ambientes de execução.

A boa notícia é que tudo isso é possível através dos avanços nas ferramentas de controle de acesso e veremos mais progressos nos padrões de alocação de orçamento, dentre outros.. a medida que as ferramentas do Serverless continuem a evoluir. Na verdade, acredito que a automação de controles de custos e acessos vão se tornar o novo shell scripting - em outras palavras, quando algum time pensar nos problemas operacionais do seu software, eles nao vao pensar em iniciar ou parar servicos, executar patches ou utilização de disco - ao invés disso, eles vão pensar sobre quais acessos a dados eles precisam e qual o orçamento que será necessário. Isso porque os times vão pensar nisso com tanta frequência que os engenheiros vão automatizar tudo relacionado a isso, assim como foi feito com procedimentos de implantação (deployment) no passado.

Dada esta habilidade e rigor no futuro, mesmo para as empresas com maiores preocupações quanto a confidencialidade de informações, times mais empolgados vão usar as tecnologias Serverless para exercitar novas ideias que não seriam viáveis antes e farão isso sabendo que estão protegidos quanto a qualquer dano a propriedade intelectual ou financeiro.

Propriedade do Produto

Outra mudança que presenciamos em vários times de engenharia altamente eficientes nos últimos poucos anos e uma mudança de foco de projetos para produtos. Estruturalmente isso vem do menor foco nos roadmaps de projeto, iteração e gráficos de Burndown. Ao invés disso, há um maior foco em um processo estilo kanban, estimativas mais rápidas e simples e continuous delivery. Mais do que mudanças estruturais, estão ocorrendo mudanças de funções e mentalidades para responsabilidades mais sobrepostas, similarmente ao que temos presenciado no DevOps (o real).

A princípio, é bem provável que a partir de agora os product owners e desenvolvedores irão colaborar para conceber novas ideias - desenvolvedores criaram alguns protótipos e product owners podem se aprofundar na análise de dados técnicos, antes de fechar um projeto final para produção. E da mesma forma, as primeiras ideias inovadoras podem sair de qualquer integrante da equipe. Vários membros da equipe, não apenas um, passam a adotar a ideia por trás da afinidade com o cliente

Uma abordagem Serverless oferece um benefício decisivo aos times que adotam um mindset de voltado totalmente ao produto. Quando alguém no time pode ter uma ideia e implementar um protótipo rapidamente para ela, um novo modo de inovação é possível. A partir daí a experimentação no estilo Lean Startup se tornar o jeito padrão de se pensar e não algo reservado para os tempos de 'hackear' porque o custo e o tempo necessário para se fazer isso e reduzido massivamente.

Outra forma de se enxergar o Serverless e que os times que não adotarem um mindset voltado totalmente ao produto provavelmente perderão esse benefício decisivo. Se as equipes não forem encorajadas a pensar de uma forma diferente do orientado a projetos, será difícil para eles aproveitarem das possibilidade de entrega acelerada que o Serverless possibilita.

Conclusão

Serverless e relativamente um novo conceito na arquitetura de software mas é um que deve ter um impacto tão grande quanto outras inovações da computação em nuvem. Através de inovações tecnológicas, melhorias em ferramentas e aprendizado compartilhado em arquiteturas de aplicações Serverless, vários times de engenharia terão acesso aos recursos necessários para acelerar e até mesmo transformar como seus produtos sao desenvolvidos. As empresas que adotarem o Serverless e adaptarem sua cultura para superá-la, sao aquelas que irão nos liderar no futuro.

Agradecimentos

Agradeço a John Chapin, Chris Stevenson, Badri Janakiraman, Ben Rady, Ben Kehoe, Nat Pryce pelas suas contribuições com este artigo.