Uma tradução do artigo foi preparada para os alunos do curso DevOps Practices and Tools no projeto educacional OTUS .

Quando os primeiros tutoriais começaram a usar o AWS Lambda e a API do Gateway em 2015, não era de surpreender que eles se concentrassem principalmente em copiar a arquitetura de microsserviço. Mas para aqueles que usaram o AWS Lambda em larga escala, ficou claro ao longo do tempo que havia limitações significativas na aplicação da abordagem de microsserviço ao AWS Lambda ... Pelo menos havia restrições sobre o que a maioria das pessoas queria dizer com a construção adequada de microsserviços.

Vamos falar sobre o porquê dos microsserviços

Os microsserviços apareceram principalmente devido à frustração com aplicativos monolíticos. Monolith é um aplicativo em que toda a lógica está em uma base de código lógica.

Houve momentos em que, devido ao alto custo dos servidores, era comum implantar o aplicativo inteiro em um único servidor. A implantação de um monólito significava que no servidor você estava implantando parte ou todo o aplicativo.

Além disso, implantar um monólito significava que você precisava ter certeza de que não quebraria nada. Muitas vezes, pequenas alterações levam à falha de todo o servidor e de todo o aplicativo.

Portanto, quando as nuvens apareciam com a capacidade de fornecer instâncias com um clique em questão de minutos (em vez de dias ou semanas), a possibilidade de separação de tarefas fica clara.
A destruição do monólito tornou-se uma idéia óbvia, e a idéia dos microsserviços nasceu.

Em vez de criar um monólito com toda a lógica em um servidor / instância, você pode colocar partes do aplicativo em diferentes servidores e conectá-los usando algum tipo de protocolo leve - geralmente uma API HTTP.

Assim, a arquitetura do aplicativo passou de monólitos para microsserviços.

Embora, eu me pergunto por quê? O valor dessa abordagem é que, ao editar o código, você altera a base de código não de todo o aplicativo, mas do microsserviço - apenas da parte componente do aplicativo. Isso significa que você não pode interromper o aplicativo inteiro.

Embora isso seja apenas teoricamente, mas essa teoria é melhor que um monólito, embora não seja ideal.

Um elemento chave para cada serviço é ...

Interface de serviço

Isso geralmente é uma forma de interface HTTP (pelo menos, essa é a abordagem mais comum). Como regra, isso não é um problema, exceto quando você possui um grande número de serviços e pode haver um problema de coordenação.

Avançando para a arquitetura sem servidor

Portanto, a abordagem inicial para criar aplicativos sem servidor na AWS foi "vamos criar microsserviços" ...

Isso significava criar uma API de gateway com a função Lambda por trás e uma instrução de switch que atua como um roteador.

Cada API do Gateway se tornou uma interface de serviço, e isso parecia lógico.

Você pode criar vários serviços que se dimensionam separadamente, o que, em alguns casos, pode ser muito importante.

Exceto que não faz sentido quando você percebe que as funções do AWS Lambda e FaaS em geral não devem ser consideradas como uma instância / servidor.

Porque, embora eles tenham servidores ocultos (ei, existem servidores com a maioria das coisas que funcionam na Internet, mas ninguém diz "S3 ainda tem servidores" ou "BigTable ainda tem servidores" ou "Azure Active Directory all ainda possui servidores "...), existe uma opinião de que você deve tratar a função FaaS da mesma forma que o serviço ..." minilith ", como alguns chamam.

O problema é que aqui está faltando o que, na minha opinião, é a chave para a arquitetura sem servidor:

Arquitetura sem servidor tem tudo a ver com eventos

Arquitetura sem servidor, eventos e gatilhos

Os sistemas sem servidor são inerentemente orientados a eventos e, portanto, são representantes da arquitetura orientada a eventos. Isso muda sua abordagem de design, gerenciamento e arquitetura.

No caso de microsserviços, o resultado final é responder a uma interface - este é o principal mecanismo de interação com a lógica.

A solução sem servidor é sobre responder a eventos, e a API é realmente apenas um mecanismo para gerar eventos.

Como parte do ecossistema da AWS, que é a mais madura das soluções sem servidor, a API não é vista como a interface principal. Eventos são muito mais importantes.

E é por isso que existem cerca de 50 eventos que podem disparar a função Lambda de outros serviços da AWS.

A dica é que, se você puder executar a função Lambda sem passar pela API do Gateway, será muito mais rápido e eficiente do que usar a API do Gateway, especialmente se você executá-la a partir de outra interface da AWS.

Dê uma olhada nas Práticas recomendadas sem servidor , você verá vários pontos diferentes de quantos microsserviços de design.

Primeiro de tudo, funções unidirecionais. A maioria dos microsserviços geralmente usa uma arquitetura de solicitação-respone porque a maioria dos aplicativos da Web funciona dessa maneira. As funções em um aplicativo sem servidor, como regra, são unidirecionais e as filas são usadas como um "disjuntor", de modo que a resposta à solicitação se torna menos comum.

A camada de dados também é gerenciada e entendida de diferentes maneiras. A melhor prática é ter várias funções, em vez de uma função de proxy com uma instrução switch.

A ideia de múltiplas funções também oferece vantagens adicionais sobre microsserviços. Se uma função gerar um erro, isso afetará apenas essa função, e não o restante do aplicativo, porque a função não possui estado (pelo menos deveria ser!). E esta é uma boa razão para não fazer "minilith"!

Portanto, embora a experiência na criação de microsserviços ofereça algumas vantagens ao projetar soluções sem servidor, na realidade, você pode perder a maior parte do que torna os aplicativos sem servidor valiosos.

Os microsserviços geralmente diferem de um aplicativo sem servidor bem projetado de várias maneiras. Isso significa que, embora seja possível criar microsserviços com um back-end sem servidor, na realidade não há caminho direto dos microsserviços para uma arquitetura sem servidor.

O caminho dos microsserviços para a arquitetura sem servidor

Então, qual é o caminho dos microsserviços para as soluções sem servidor? Existe uma maneira rápida de aprender o básico para simplificar a transição de um para o outro, uma vez que os microsserviços são generalizados?

Eu acho que é isso que o mundo sem servidor está intrigando. Recentemente, houve uma grande discussão no Twitter, na qual conversamos sobre esse tópico. Aqui vale a pena se referir a ele, apenas para ver do que a comunidade está falando (veja as várias respostas e você verá várias opiniões sobre esse tópico, embora ninguém mencione diretamente os microsserviços).

Eles falam sobre algumas ferramentas que serão instruídas para facilitar a criação de aplicativos sem servidor, mas no final elas se tornarão a plataforma na qual você precisará criar tudo. Não acho que isso traga benefícios ou ajude alguém a entender melhor o estilo arquitetônico.

Como comunidade, entendemos que a arquitetura sem servidor é o futuro. Mas a transição de estilos arquitetônicos antigos nem sempre será fácil, mesmo quando a arquitetura sem servidor é a escolha certa (e às vezes não é a certa).

Há uma razão para isso. Não é tão fácil mudar o pensamento de uma pessoa. É fácil criar uma função Lambda. Mas criar um aplicativo sem servidor bem projetado não é fácil. Porque requer uma mudança de pensamento e é relativamente difícil.

E, como eu já disse várias vezes, devemos parar de ensinar às pessoas o “olá mundo” e parar com isso, porque muitas pessoas pensam que isso será suficiente para elas.

A razão pela qual escrevi as Práticas recomendadas sem servidor foi ajudar as pessoas a entender que elas não deveriam fazer suposições sobre como criar aplicativos sem servidor com base no conhecimento atual.

As ferramentas que usamos agora para criar soluções sem servidor são as mesmas que usamos para criar aplicativos "cloud 1.0", mas não são completamente adequados para esses fins. Essas ferramentas são imperfeitas, mas estamos tentando explicar e torná-las o melhor possível.

O que precisamos de você

Eu acho que a comunidade, de fato, é muito aberta para ajudar as pessoas em treinamento e desenvolvimento na criação de soluções sem servidor.

Portanto, como comunidade, precisamos de suas perguntas:
- Quais são as suas dificuldades?
- Onde estão as lacunas?
- Quais tutoriais estão faltando?

E algo assim.

Estou pronto para ajudar as empresas a fazer essa transição. Trabalhei com a gerência sênior, CTOs e CEOs para ajudar a determinar o valor que uma empresa cria usando uma abordagem sem servidor, e fico feliz em ajudar outras empresas.

Estou muito feliz em ajudar. Entre em contato com o LinkedIn aqui .