Nos dias 22 e 23 de novembro, a próxima conferência DotNext 2018 para os amantes do .NET foi realizada em Moscou. Meu nome é Maxim Smirnov, chefio o .NET Competence Center no Alfa-Bank e quero apresentar uma versão em texto de uma das entrevistas realizadas à margem do DotNext.
Sobre a vida e as aventuras em nosso banco, sobre a coexistência com Java e problemas de implementação - sob o corte.
Quanto de .NET há em Alpha em geral e por que precisamos dele
Recentemente, crescemos bastante em termos de uso do .NET. Se, há cerca de cinco anos, não havia tantas subsidiárias na Alpha (principalmente em aplicativos corporativos, empréstimos para negócios corporativos, investimentos etc.), cerca de 16 a 20 pessoas lidavam com essa carga. E agora o banco está desenvolvendo ativamente segmentos de negócios corporativos de massa e médio porte, que se tornaram um bom impulso para o desenvolvimento de sistemas de crédito.
E enfrentamos uma escolha - reescrever tudo isso em Java, que historicamente sempre foi nosso ponto forte, e ainda prevalece no varejo, ou continuar desenvolvendo tudo no .NET, para o qual teríamos que contratar um monte de doadores e ir para a frente às mesmas tecnologias semelhantes para a arquitetura de microsserviço que em Java.
Obviamente, tal movimento foi imediatamente ameaçado, porque os riscos [de aplicar uma nova tecnologia aprox. Ed.]. Mas fomos capazes de assumir esses riscos, provamos a nossos colegas que o .NET poderia trabalhar adequadamente nos mesmos clusters e soluções de infraestrutura nas quais o Java é ótimo. Aqui estou me referindo ao chamado cluster da "frente unida", Apache Mesos - Marathon. E começamos a tomar decisões na linha de frente, incluindo a seção intermediária para elas. A frente permaneceu a mesma que em Java, a parte do meio permaneceu em algum lugar em Java, em algum lugar no .NET.
E lá vamos nós - há 5 anos, no máximo 20 pessoas lidam com o .NET, e agora existem tantas tarefas que temos 75 caras corajosos - e continuamos a expandir - agora estamos procurando um
arquiteto e mais
desenvolvedores . Embora o Java ainda seja um total de mais, um e meio a dois, porque domina de maneira estável os negócios de varejo e de massa. Estamos no .NET dominado na estrutura da média corporativa e regional, além de canais eletrônicos, é claro.
Verificar - provar - implementar
Para que algo funcione continuamente, é necessário implementar esse assunto nos processos do banco. Para implementá-lo normalmente, você precisa provar a todos os responsáveis que isso não estragará o estado atual das coisas e a implementação trará muitas vantagens.
O mais difícil foi com a infraestrutura. Tínhamos deles um requisito concreto reforçado - que tudo isso se desenrolaria na janela de encaixe e funcionaria normalmente no Linux. E aqui vale a pena notar que ainda não havia o .NET Core 2.0, então havia apenas a primeira versão, na qual não havia todo o bem que foi lançado na segunda; em geral, aconteceu que nós mesmos não sabíamos exatamente qual subaquático podemos encontrar icebergs, mas eles disseram que faremos tudo como deveria. Conseguimos provar isso aos negócios lançando os primeiros pilotos - Alfa-Credit, um aplicativo para empréstimos on-line, emissão de tranches e muito mais.
Então os apoiadores tiveram que provar a viabilidade da ideia. Eles precisavam explicar que eles próprios não precisavam conhecer o .NET para acompanhar nossos contêineres (por algum motivo, tinham certeza do contrário). Eles provaram a eles que não haveria problemas de desempenho, eu fui um dos primeiros a coletar tudo isso em um cluster - implantamos o contêiner, removemos várias métricas dele, observamos o quanto ele carrega a CPU, comparado tudo isso com o Java. Acabamos de colocar o código Java em um contêiner que emitia ajuda aos clientes do varejo. Bem, pela pureza do experimento, fizemos absolutamente o mesmo serviço, mas no .NET, para que possamos compará-los honestamente em termos de desempenho, velocidade de resposta e carregamento de memória. Como resultado, escrevi testes de estresse para tudo isso - tudo funcionou para nós e, no momento, 6 equipes estão trabalhando nesse modo.
Agora estamos nos livrando lentamente do Legacy - envolvemos-o em serviços e reescrevemos-o funcionalmente para microsserviços.
.NET Core x .NET Framework
Preste atenção novamente que implementamos o .NET Core. Portanto, existem vários problemas no sentido de que existem algumas coisas interessantes na estrutura .NET, mas elas não estão no .NET Core e ainda não existem. Por exemplo, serviços SOAP.
Imaginem. Você é um banco, você tem um sistema que consome outro. E ela se acostumou a consumir SOAP, e você não tem. Geralmente. Não encontramos uma única implementação normal dos serviços WCF com SOAP e coisas semelhantes. Talvez eles pareçam mal, tudo é possível. Portanto, tive que lançar e gravar camadas no antigo .NET Framework.
O segundo conjunto de rakes é a API REST. Não há problemas com novos serviços onde eles são implementados. E forçar serviços antigos a usar a API REST em vez de SOAP é outra história; eu teria que reescrever todos os outros sistemas dependentes. E, novamente, camadas, remendos, muletas.
E também comunicação com filas. Estamos usando ativamente o IBM MQ no Alpha, um barramento corporativo típico para filas de mensagens. Existe um cliente no .NET Framework, nativo da IBM. Mas eles não têm um cliente para o .NET Core. E, tanto quanto sabemos, não é planejado. existe apenas uma implementação no protocolo AMQP aberto, tentamos nos comunicar com as filas com sua ajuda, mas também houve vários problemas. Solução? Sim, novamente as camadas.
Em geral, tivemos uma iteração na tentativa de fazer com que todas essas coisas funcionassem normalmente através do protocolo AMQP e não fossem estúpidas. Mas os caras da IBM cancelaram a inscrição para nós, eles dizem desculpe, pessoal, mas ele se tornou obsoleto por nós, muito bem ele. E que eles usarão apenas o protocolo proprietário por certos motivos. Em geral, agora nos sentamos e pensamos em como refazer tudo isso. Provavelmente, escreveremos nosso cliente em vez do IBM, este é o código aberto.
Front, .NET e NodeJS
Na maioria das vezes, usamos o React JS para a frente; ele funciona com o nó normalmente. Quando começamos, tínhamos vários projetos MVC antigos. Lá, eu tive que encaminhar a frente para que a renderização do lado do servidor fosse normal, através do ReactJS.NET.
Agora, evitando isso, decidimos separar as moscas das costeletas; no final, verificou-se que há uma frente separada com o nó e que o NodeJS usa nossos serviços nas demais APIs do aplicativo da web. E, na verdade, é tudo. No .NET, já estamos implementando o meio. E não fazemos isso especificamente, porque observei com o .NET e o Angular que é fácil não separá-los, porque nos esforçamos para desenvolver especializações em pessoas.
Se você conhece bem a frente pura, pode ir com segurança com a equipe java para escrever a frente. Isso é conveniente, para que você possa fluir de equipe para equipe. E se você conhece a pilha cheia, pode criar aplicativos de ponta a ponta. E o back-end com o .NET, o meio e a frente na reação. Aqui temos um padrão de tecnologia unificado.
Integração de telefone móvel
Não temos muito disso. Onde houver, basta usar nossos serviços na API da Web. Nós não escrevemos aplicativos móveis no .NET, nem houve tentativas. Os nativos ainda são melhores para fazer. Se você pode pegar e escrever imediatamente o nativo, é melhor pegar e gravar imediatamente. Sim, existem coisas úteis como o Xamarin da Microsoft, mas isso faz sentido quando você precisa de um início rápido e universal. Mas se houver uma dúvida com a conveniência do aplicativo para cada plataforma, com o desempenho, você ainda continuará e normalmente escreverá nativo. E nós tínhamos nativos inicialmente.
Sobre a resistência ao novo
Quando você tem uma grande empresa (e apenas algumas equipes), sempre ficará insatisfeito com a introdução de novas ferramentas. Geralmente sempre, isso é normal. Artistas que veem isso, e isso é tudo.
Quando você apresenta algo não muito popular de cima, ou algo que os desenvolvedores não gostam, as pessoas sempre encontram várias maneiras de sabotar o processo e até mostram no processo que idiota você é que começou tudo isso. Foi assim quando lançamos o StyleCop for .NET. Mas com o tempo, todos aceitaram de qualquer maneira e agora o estão usando ativamente. Um argumento simples ajudou - as configurações do StyleCop são coisas bastante comuns. O resultado é bonito e mais ou menos claro para todo mundo. Embora, desconfie, alguns desenvolvedores ainda afiam um dente. Afinal, todos têm seus próprios padrões, todos têm sua própria compreensão da beleza do código, seus próprios editores e truques.
Uma coisa semelhante foi bem derrotada na série Silicon Valley. Lá, os caras tiveram um debate sobre o que deveria ser usado - abas ou espaços. Pessoalmente, eu não ligo, mas, como mostra a prática, para algumas pessoas, e isso pode ser um começo para o holivar.
Obviamente, se você escrever tudo no visual, essa questão geralmente será removida.
Alguém aqui escreve código no Visual Studio, enquanto outros não. Quando mudamos para o cluster, constatamos que existem várias tecnologias que não funcionam no Windows. Por exemplo, Ansible. Há uma parte do cliente no Windows, mas a parte do servidor não pode mais ser aumentada. Portanto, escolha uma máquina virtual no Linux ou faça tudo em um servidor Linux.
Em geral, vivemos assim. Se você tiver alguma dúvida sobre o .NET no banco e o .NET em princípio - escreva, terei o maior prazer em responder.