A tecnologia avança rapidamente. Ou talvez pareça que tudo se move rápido porque novos movimentos, abordagens e arquiteturas estão surgindo por todos os lados. Este mês é a ascensão repentina das arquiteturas “sem servidor” para o primeiro plano do fluxo e da consciência do Twitter de todos. Pelo menos se você estiver no mundo Dev/Ops.
Para aqueles que se preocupam com infraestrutura, arquitetura de rede e operações e não foram inundados com essa nova arquitetura, é uma progressão lógica que precede de monólito -> microsserviços -> arquiteturas sem servidor. É uma análise mais aprofundada dos aplicativos de uso comercial -> serviço -> função.
Literalmente, é sobre funções. Funções detalhadas e orientadas a eventos.
E cada um tem foco em um escopo ainda menor de lógica de aplicação do que um microsserviço. Enquanto um microsserviço pode conter toda a lógica de aplicação necessária para implementar um “serviço de perfil”, a arquitetura sem servidor divide isso ainda mais em funções individuais. Um para login, um para logout, um para alterar sua senha e um para redefini-la. Basicamente, é como criar um serviço pequeno e focado para cada ação que você possa realizar em um aplicativo.
O motivo pelo qual isso é chamado de “sem servidor” é porque é basicamente uma forma altamente evoluída de PaaS. O que é bom para o PaaS, porque, como mercado, o PaaS nunca se tornou realmente o gigante que esperava ser. Ele simplesmente fica por aí, recebendo elogios de fãs que o adoram, mas, na maior parte do tempo, tem sido ignorado, crescendo a uma taxa que não chega nem perto de ser tão empolgante quanto a da nuvem privada ou pública, e certamente não como o SaaS. Em uma arquitetura sem servidor, o provedor de nuvem é responsável por tudo, exceto pelo código necessário para fazer algo quando um usuário clica em um botão, uma caixa de seleção ou um link. Essa é a parte do evento “orientado a eventos”: quando o usuário clica no botão, execute function_in_the_cloud . Essa função geralmente faz parte de uma API maior que é gerenciada por outro serviço na nuvem.
O importante aqui é que a pessoa que escreve a função não provisione, configure ou inicie uma VM ou contêiner. Eles não se preocupam com detalhes operacionais como escala. Eles simplesmente escrevem algum código e com o clique de um botão, voilà! Funcionalidade instantânea.
Isso é a nuvem levada ao seu extremo, já que os desenvolvedores da pilha agora são responsáveis por reduzi-la a uma única camada, a camada de aplicação. Nada mais importa, como diria o Metallica. Cada detalhe operacional é fornecido pela plataforma subjacente. É NoOps, ou pelo menos da perspectiva do desenvolvedor.
Porque você sabe que há servidores, serviços, infraestrutura e uma rede sob a plataforma que fornecem essa capacidade mágica. Simplesmente não é algo com que o desenvolvedor precisa se preocupar. Mas você, como profissional de infraestrutura ou operações de rede, sim.
É por isso que é improvável que as empresas adiram a essa tendência tão cedo. Tal feito requer um ambiente de computação em nuvem totalmente operacional que incorpore não apenas recursos de provisionamento de máquinas virtuais ou contêineres, mas também dimensionamento automático . Em outras palavras, dimensione sem parâmetros ou contribuição de desenvolvedores. Isso deveria simplesmente acontecer, droga, e é só isso. Não é autoatendimento, é autoatendimento . Não é apenas escala, é provisionamento automático também. E monitoramento, relatórios e praticamente tudo relacionado às operações hoje. É por isso que vemos isso amplamente em ambientes de provedores de nuvem bem estabelecidos; somente eles têm a infraestrutura subjacente, a automação e a orquestração necessárias para dar suporte a um modelo operacional tão pouco intervencionista.
Então, a maior parte da atenção no serverless agora está em senti-lo e descobrir como trabalhar com as encarnações atuais disponíveis na nuvem: Amazon Lambda , Google Cloud Functions , Microsoft Azure Functions e IBM OpenWhisk . Não que não haja ofertas para ajudar implementações locais, como Serverless e Iron.io. Mas ainda é cedo (cedo) para o serverless.
Ainda assim, você provavelmente começará a ouvir rumores sobre o serverless. Por enquanto, são apenas os motores de uma nova arquitetura começando. É improvável que isso tenha impacto na maioria das organizações no curto prazo (pelos próximos 12 a 15 meses), mas é bom entender do que se trata antes de parar no pit stop local.
O NewStack tem uma ótima visão geral se você quiser ler mais sobre os benefícios e desafios atuais e sem servidor.