RubyRussia 2019: Nikolay Sverchkov sobre sem servidor

28 de setembro na conferência RubyRussia Nikolai Sverchkov fará uma apresentação Serverless is Ruby Future. Ivan Solovyov discutiu em uma entrevista por que essa tendência é interessante e por que os rubistas devem prestar atenção nela.




Diga-me como você veio para Ruby?

Ele começou a programar na universidade. Toda a prática foi em C ++, mas fiz os últimos trabalhos e tese em Ruby. Por que escolhi o Ruby, não vou dizer com certeza, provavelmente porque o idioma da época estava na moda. Ninguém sabia na Universidade Ruby, muito menos ensinou. Mas depois da formatura, eu queria escrever em Java. Então me pareceu que o Java é especial, os desenvolvedores mais legais, uma espécie de casta superior de programadores, e eu queria ser um deles. Minha primeira entrevista de emprego foi em Java Junior, e eu falhei com sucesso. Mas ele conseguiu entrar em uma empresa onde Ruby era necessário. Talvez seja o melhor! Apenas alguns anos se mudaram para Elixir. Agora eu trabalho em marcianos maus, fazendo back-end.

Seu relatório sobre sem servidor. Como você começou a trabalhar nessa direção? A entrada para a tecnologia é difícil?

Ele começou a estudar em seu tempo livre. Eu tinha uma real, mas não relacionada à principal tarefa de trabalho. Então ele começou a usar o serverless nos projetos da empresa. O limiar de entrada é bastante baixo, acho que é apenas ligeiramente superior ao do Heroku. Escreva seu primeiro "Olá, mundo!" será muito simples - existem vários artigos, tutoriais, documentação extremamente rica da Amazon. E então, é claro, então haverá dificuldades. Existem armadilhas, vou falar sobre algumas delas no relatório.

Os iniciantes devem mergulhar no servidor e usá-lo na produção?

Eu acho que sim! Mas não é preciso se apressar para implementar tudo com o serverless. Para começar, você pode examinar seu aplicativo e encontrar nele um pequeno pedaço da lógica de negócios, que pode ser colocado em um serviço separado. Se esse novo microsserviço tiver uma interface de comunicação simples, com 99% de probabilidade, você poderá implementá-lo usando o mesmo AWS Lambda. Idealmente, se é uma parte da lógica de negócios sem estado, não é necessário pensar em como salvar os resultados, pensar nos artefatos da execução de sua função lambda. Como exemplo, enviar uma carta pode ser uma boa primeira tarefa. No meu relatório, levantarei separadamente a questão de qual espectro de tarefas o modelo de computação sem servidor é mais adequado.

A principal recomendação é separar o código da lógica de negócios das próprias lambdas. Essa é uma variação da regra dolorosamente familiar "controladores finos, modelos grossos". Primeiro, será mais fácil testar dessa maneira. Em segundo lugar, se você perceber que o servidor sem servidor não é adequado para sua tarefa, poderá migrar facilmente para uma solução comprovada, por exemplo, substituir a camada de entrada sem servidor por um servidor da web comum. A este respeito, jatos muito bons. Essa é uma estrutura Ruby Serverless que permite escrever um aplicativo que pode ser implantado imediatamente no AWS Lambda e em uma instância comum do Amazon EC2.

Conte-me mais sobre essa estrutura Ruby?

Jatos é único. Apesar de existirem outras estruturas sem servidor personalizadas para determinados idiomas, o Jets é o mais funcional. Agora ele tem mais de 2500 commits no master. A estrutura usa muitas convenções familiares para um desenvolvedor Ruby, é um "Ruby on Rails on Serverless". Mas isso tem suas desvantagens. Como com um modelo de computação sem servidor, você paga pelo tempo de execução do código, a inicialização e o carregamento de um grande número de dependências pesadas são caros no sentido literal da palavra. A divulgação deste tópico também terá um tempo no meu relatório.

Quais plataformas são mais comuns para o servidor agora, quais são as diferenças entre elas e qual é a melhor escolha? Pelo que entendi, agora você está se afogando no Amazon Web Services, pois na maioria das vezes você fala sobre isso.

Você pergunta por que eu costumo usar a palavra "lambda" em nossa conversa? Eu acho que a história é como com Karcher ou Xerox. Existem marcas cujo nome é habitual denominar todo um nicho de produtos. Em 2014, a Amazon foi a primeira a fornecer acesso público a um modelo de computação sem servidor - AWS Lambda. Todos os outros: Microsoft com Azure Functions, Google com Cloud Function, IBM com IBM Cloud Functions, ainda estão mentalmente no papel de atualizar. Embora o mercado sem servidor esteja em expansão, os preços de serviço da AWS geralmente são mais altos que os da concorrência. Portanto, novos lançamentos, como o Google Cloud Run , podem mudar o jogo da noite para o dia. Se realizarmos uma análise mais detalhada das comparações de plataforma, recomendo assistir a um vídeo de Ruslan Serkin, do DataArt, da conferência DUMP 2019 .

O que você acha, em que direção o servidor sem desenvolvimento?

Oh, esta é a parte mais interessante do meu relatório! Eu posso fazer sem spoilers - venha ouvir! Em vez disso, posso falar sobre seriedade e produção. Em abril deste ano, eu estava na conferência RubyConfBy em Minsk, na qual o autor dos mesmos Jets falou. Na pós-festa, discutimos o desenvolvimento sem servidor e por que, se houver suporte dos principais players do setor, não vemos a distribuição em massa das funções lambda. As vantagens do modelo são óbvias, o ecossistema é transparente, mas não há confiança generalizada por parte da comunidade de TI. Como resultado, chegamos à conclusão de que agora sem servidor é um tipo de jogador sombrio e a situação lembra um pouco o que estava com o Docker ao mesmo tempo. Há muito se acredita que Docker em produção é suicídio. Agora vemos que a conteinerização é a principal ferramenta para distribuição de software. Eu acho que no futuro, sem servidor está esperando o mesmo. Mais e mais pessoas confiarão nele.

Sem servidor matará monólitos?

Esta pergunta pode ser reformulada como "A arquitetura do microsserviço matará monólitos?" Como o servidor sem servidor é um microsservidor ideal - ele é pequeno, sem estado e possui uma interface mínima para se comunicar com o mundo externo. Assim como os microsserviços não matam monólitos, as lambdas não matam monólitos. Todas as três arquiteturas têm uma gama específica de tarefas às quais são ideais. E vice-versa - há tarefas em que, por exemplo, sem servidor é impraticável de usar. Procure detalhes no meu relatório.

O que fazer com o bloqueio de fornecedor? Por exemplo, você desenvolveu um lambda para a Amazon, mas decidiu mudar para o Google.

A migração entre plataformas é dolorosa se você não usar algum tipo de estrutura, por exemplo, sem servidor , que fornece uma API abstrata por provedores de nuvem e permite implantar a mesma função na Amazon e no Google. Se você, grosso modo, fizer tudo com as mãos, sim, será um pouco doloroso.

O que fazer com lambdas comuns ao usar código? Por exemplo, alguns componentes comuns, algumas funções utilitárias e assim por diante.

Ainda não existem práticas recomendadas sobre esse assunto. E a pergunta pode ser reformulada novamente em "Como atrapalhar um código comum entre microsserviços?", Porque o significado é o mesmo. Existe uma opção quando você mantém a lógica reutilizada em algum lugar compartilhada e na própria função a conecta. Essa abordagem funcionará bem, por exemplo, com Go, onde a saída obtida é um arquivo executável. Outra opção é se livrar da conectividade do componente e permitir a duplicação. Provavelmente vale a pena tentar e ver o que funciona melhor. A única coisa que posso aconselhar é não tentar universalizar as funções lambda. Em algum momento, pode parecer que uma única função seria a solução perfeita para o problema da duplicação de código. Mas com o tempo, você perceberá que esse é o caminho para lugar nenhum. Você obterá uma certa "versão monolítica de sem servidor" com todos os problemas da primeira e da segunda arquitetura.

Discutiremos mais detalhadamente após o relatório sobre o RubyRussia!

Venha e você, as inscrições ainda estão abertas, a conferência será realizada no próximo sábado, 28 de setembro.

Não haverá apenas relatórios, mas também estandes das melhores empresas:

Organizador - Evrone
Parceiro Geral - Toptal
Parceiro Gold - Gett
Parceiros Silver - Valarm , JetBrains , Bookmate e Cashwagon
Parceiro Bronze - InSales