Cloud

Evolução até a arquitetura serverless

Quando olhamos para o termo serverless, parece que ele está conseguindo a funcionalidade de um servidor sem um servidor. Sim, isso significa que você não tem um servidor, mas na verdade, alguém tem. Por exemplo, o Amazon AWS Lambda, o Google Cloud Functions e o Windows Azure Functions podem ser identificados como os principais concorrentes no momento.

Evolução

  • Monolitos > Arquitetura Orientada a Serviços > Cloud > Arquitetura de microsserviços > Arquitetura sem servidor (serverless)
  • Servidor físico > Máquinas virtuais > Contêineres

O Serverless pode ser identificado como resultado do casamento da Cloud and Microservices Architecture (MSA). Vamos ver como chegamos lá.

A arquitetura de software empresarial percorreu alguns passos no passado. O software costumava ser um enorme monolito que desenvolvia e adicionava continuamente a funcionalidade a um. Na maioria das vezes, esses softwares eram instalados em servidores do tipo mainframe, físicos e com recursos pesados. Em seguida, começou a evoluir em diferentes fases da arquitetura, à medida que as pessoas começaram a inventar novos padrões para obter mais flexibilidade, agilidade e produtividade, e a Arquitetura Orientada a Serviços (SOA) nasceu como resultado.

O SOA foi impulsionado por meio de técnicas de nuvem. O REST introduziu uma maneira simples de obter SOA com especificações bem menos complexas do que o SOAP e forneceu a liberdade de usar diferentes tipos de mensagens, como o JSON. Isso elevou o envolvimento da SOA na indústria. A adoção de máquinas virtuais também ajudava a SOA, pois atendia a requisitos dinâmicos adequados para essa arquitetura.

A MSA prosseguiu e muitos acreditavam que a SOA era correta. O Serverless está quebrando os serviços e é uma ótima maneira de fazer as coisas de maneira flexível e limpa. Mas por que a indústria esperou tanto para adotar tais paradigmas? Antes da enorme popularidade da MSA, que deve ser atribuída principalmente à ascensão de tecnologias como contêineres, a execução de um servidor não era uma tarefa sobrecarga baixa. Portanto, não permitia que os sistemas criassem e excluíssem servidores de maneira mais rápida e dinâmica. As tecnologias de VM não estavam à altura dos requisitos de adiantamento. A adoção do contêiner levou a uma série tão valiosa de padrões de arquitetura que vemos hoje.

Vantagens
Esta seção discutirá as vantagens da arquitetura sem servidor em comparação com as partes anteriores da cadeia arquitetônica. Algumas das vantagens a seguir se sobrepõem às vantagens da MSA, pois são parentes próximos.

  • Escolha de tecnologia – Você pode escolher diferentes idiomas para diferentes funções como suítes.
  • Escolha da arquitetura – Você pode ter decidido usar sem servidor, mas não precisa ser apenas sem servidor. Você pode decidir implementar um conjunto de serviços como sem servidor, outro definido em microsserviços locais ou usando seu sistema legado.
  • Retorno mais rápido e melhor para o marketing – pense em alterar um serviço existente para adicionar funcionalidade e adicionar a função criando um serviço completamente novo, independentemente. Mais tarde economizará muito tempo. Evita se preocupar com todo o serviço e permite que você obtenha a função pronta mais rapidamente. Você pode comercializar seu novo recurso em poucos dias, se não em horas.
  • Nunca pague por inatividade – Você não precisará pagar nada se não houver tráfego. Nenhum servidor frio será mantido. Servidores podem ser gerados em milissegundos quando o tráfego é iniciado.
  • Escalonamento de custo mais rápido e legal – Funções simples / pequenas e arquitetura semelhante a MSA ajudam a dimensionar os serviços horizontalmente, com rapidez. O baixo tempo de inicialização ajuda a disponibilizar a capacidade em milissegundos e a melhorar seus números de disponibilidade da plataforma. Você pode lidar com picos íngremes sem problemas, sem se preocupar com a disponibilidade.
  • Responsabilidades simplificadas da equipe – Equipes diferentes trabalhando em diferentes partes de um aplicativo complexo trarão discussões e interações complicadas e demoradas. Com as bordas claras nas APIs definidas, as equipes irão respirar um pouco mais facilmente nessas ocasiões.
  • Preocupação com a infraestrutura de descarregamento – Antes de ser sem servidor, os engenheiros ignoram todos os aspectos da execução do serviço on-line. Isso significa que eles precisam otimizar os recursos do nó de acordo com o planejamento de capacidade, a análise de configuração, o gerenciamento de escala e muito mais. Os provedores sem servidor geralmente acomodam tudo em um único pacote, incluindo todas as peças sobressalentes do ecossistema.
  • Salvando tudo – Enquanto você se esforça para manter sua plataforma disponível com a maioria dos 9s possíveis, pode ser necessário executar servidores em todas as regiões do mundo e manter uma margem de recursos para cobrir picos repentinos de tráfego. No processo, o mundo tem que pagar o preço com o desperdício de energia e alocação de recursos que podem ser ociosos às vezes. O Serverless utiliza melhor os recursos e economiza energia sem desperdiçar para servidores inativos.

Desvantagens
Podemos ver muitas vantagens sobre as desvantagens dessa arquitetura. No entanto, podemos identificar várias desvantagens quando comparado aos seus antepassados ​​arquitetônicos.

  • Menos controle – Como os serviços são gerenciados em uma nuvem pertencem a um provedor de nuvem de terceiros, podemos ter que depender deles. Mudar para uma nova plataforma seria dispendioso e você pode ter que se ater ao fornecedor, apesar do preço mais alto ou das mudanças da API. Pode-se usar soluções alternativas, como obter seu código em um contêiner e aplicar o AWS Lambda.
  • Complexidades arquiteturais – As pessoas podem misturar e combinar arquiteturas, mas elas terão sua parcela de complexidade nesse pacote. Não será um bom passeio lidando com diferentes arquiteturas e diferentes partes envolvidas.
  • Não para aplicativos de longa duração – Como essas funções são configuradas como funções dinâmicas e de vida curta, pode não ser adequado para sua aplicação se for necessária uma operação de longa duração.
  • Privacidade e multilocação – Principalmente essas funções podem ser executadas em um mesmo servidor de aplicativos para vários clientes diferentes. Pode haver invasores explorando quaisquer falhas de segurança no sistema.

Tipos de Casos de Uso
Quase todas as funcionalidades que você deseja colocar em funcionamento rapidamente podem ser identificadas como casos de uso sem servidor. É impossível nomear todos os casos que isto será útil. Algumas características dos casos de uso podem ser:

  • Novas oportunidades de arquitetura – Você pode querer dividir seu único aplicativo em várias funções ou pode ter um monte de utilitários, funções sem estado que não estão relacionadas entre si. Sem servidor pode ser sua resposta.
  • Adicionando funções seguras a componentes não seguros – Se houver uma função que você deseja executar com segurança, o que não pode ser feito no aplicativo cliente, basta criar um aplicativo sem servidor e usá-lo com a API ativada por segurança.
  • Novas funções ad-hoc para a arquitetura atual – Digamos que você já tenha sua arquitetura implementada e em execução usando arquiteturas SOA ou MSA e deseje introduzir uma função pequena, mas completamente nova. Você pode fazer uma função sem servidor rapidamente e implantar.