Nas palavras "código aberto", muitos parecem ser um entusiasta que se compromete à noite com seu projeto favorito ou uma pequena empresa que ganha dinheiro com o suporte de um produto aberto. Mas se você pensar apenas neles, perderá um segmento importante e interessante da comunidade. No passado, as palavras "empresa" e "código aberto" pareciam ser antônimos, mas agora as grandes empresas não apenas usam ativamente os projetos OSS, mas elas próprias contribuem para eles.
Com o tempo, a Sbertech tem sido cada vez mais ativa na comunidade OSS, e decidimos perguntar a eles sobre isso. Como a especificidade bancária estrita se combina com o espírito de liberdade de código aberto? Quais são os requisitos para o código aberto que outras empresas podem não ter? Existem funcionários da Sbertech que escrevem código aberto como suas principais tarefas de trabalho? Quais são seus planos e desejos para o futuro?
Anton Churaev , que supervisiona o Free & Open Source, nos contou sobre tudo isso e muito mais.
Oleg: Olá Anton. Vamos apresentar um pouco aos Khabrovitas. Fale sobre você: quem é você, o que você está fazendo?Anton: Eu sou um engenheiro que, no entanto, desenvolve apenas em seu tempo livre. Agora, estou desenvolvendo práticas e competências da Sbertech para o desenvolvimento e aplicação de produtos Free & Open Source. Você precisa entender que essas são coisas ligeiramente diferentes.
- Sim, entendo, algumas vezes, quando conversei com Stallman, liguei para Livre como Aberto e depois ouvi uma palestra que me lembrava para sempre :-) Bem, qual é a sua posição?- Curador do desenvolvimento de Free & Open Source. E entusiasta de código aberto :)
- Você pode decodificar um pouco mais sobre as "competências para a implementação do código aberto"? Parece algum tipo de conhecimento secreto.- Poucas pessoas imaginam o que o código aberto significa para as empresas. Por um lado, são inovações e a ausência da necessidade de desenvolver commodities, focar nas vantagens competitivas de seus produtos, reutilizar e reduzir custos. Frequentemente, esses são projetos que realmente se tornaram padrões da indústria. Pegue o mesmo Hadoop - todo mundo sabe, todo mundo sabe, há muito tempo é um padrão. Ou os bancos de dados mais comuns - os cinco principais são três produtos de código aberto - MySQL, PostgreSQL e MongoDB.
Mas poucas pessoas pensam que o uso do OpenSource envolve muitos custos ocultos. Isso não quer dizer que encontramos algo de código aberto e resolvemos todos os nossos problemas. Por exemplo, existem grandes questões sobre "higiene legal". Ao trabalhar com software de fornecedor, tudo fica muito claro: tirei uma licença, você trabalha nela e usa o suporte. Ao trabalhar com código aberto, muito fica à mercê de desenvolvedores e usuários. Nesse caso, questões legais e legais são um dos primeiros lugares. Além disso, na Rússia existem nuances. Se em todo o mundo o conceito de propriedade intelectual é bastante desenvolvido e todos entendem que é muito importante que exista um proprietário específico, então, historicamente, na Rússia, tudo ficou diferente. Aqui, não somos tão cuidadosos e respeitamos a propriedade intelectual, embora isso seja extremamente errado. E se você não pode garantir a "higiene" do uso de código aberto, não pode garantir a qualidade de seu uso.
- Posso esclarecer? Qual é o status legal das licenças GPL na Rússia? Por exemplo, a GPL não permite modificações nas leis locais e não indica restrições territoriais. Portanto, esse acordo não é compatível com o regime legal estabelecido no território da Federação Russa, e isso é muito, muito ruim.- Não quero dividir licenças em algumas zonas. O Sberbank é uma empresa global, portanto, o software pode ser usado nos Estados Unidos e na União Europeia. E, pelo que entendi (não sou advogado, mas tanto quanto sei), em caso de violação das restrições das licenças do detentor dos direitos autorais no território de, por exemplo, EUA, seremos responsáveis pelas leis dos EUA. Diante disso, você precisa ter muito cuidado para garantir direitos e cumprir os requisitos da propriedade intelectual de terceiros. Respeite os autores que nos permitiram usar nosso trabalho, por meio do qual aceleramos, otimizamos soluções, resolvemos nossos problemas e, finalmente, prestamos um serviço de qualidade aos nossos clientes. Vamos cumprir os direitos e requisitos. Esta é a primeira tarefa.
- e o segundo?- A segunda tarefa é segurança da informação. É claro que a maioria das licenças contém um aviso de isenção de responsabilidade declarando que o autor / desenvolvedor / colaborador não é responsável pelos possíveis danos que serão causados pela operação deste software. Isso é certo, é uma responsabilidade que se transfere para o consumidor e requer maturidade dele. Tudo não é de graça.
Você deve pagar por essa responsabilidade e, é claro, trabalhar com esses riscos. Nem todas as empresas podem fazer isso. Temos um departamento muito forte de segurança da informação - temos sorte. Portanto, levamos a sério a presença de vulnerabilidades e códigos maliciosos em geral. Todo mundo que planeja usar o código aberto deve levar em consideração todos os riscos - não apenas legais, mas também em termos de segurança da informação.
- Quais licenças você gosta?- Acadêmico.
O! Sejamos mais específicos. Há MIT / BSD, etc., e existem licenças de copyleft de vírus como o Affero GPL. Qual destes?Bem, bom. Você não pode amar ou não gostar de uma licença. O produto é feito para uma tarefa específica e será usado de uma maneira específica. Ao usar o código aberto, sua tarefa é garantir que você forneça seu produto ou serviço sem violar os direitos de terceiros. Nesse caso, é claro, você pode usar copylefts (por exemplo, a GPL), se garantir o uso deles para que eles não violem as restrições e os direitos de outras pessoas. Obviamente, há menos dificuldades ao usar licenças acadêmicas, simplesmente porque elas carregam menos restrições e, portanto, são mais fáceis de seguir. Para resumir, chamo de MIT "acadêmico", BSD, Apache, etc.
- Ok, os desenvolvedores comuns precisam lidar com a segurança da informação? Ou é alocado para um departamento separado?- Todos os desenvolvedores devem entender os conceitos básicos de segurança da informação e os princípios de sua segurança para seus sistemas. Porém, no nosso caso, trabalhamos com desenvolvedores individuais especializados em ameaças à segurança da informação. Além disso, recorremos a eles não apenas para a análise de produtos de código aberto, mas também para a análise de algoritmos e soluções de design.
"Está claro que esses guardas de segurança especiais sabem tudo." E o que um desenvolvedor comum precisa saber a esse respeito? Quais são os pontos básicos?- Modelo de ameaças, proteção de canais, proteção de dados. O que é propenso a ameaças: talvez seja uma interface de usuário ou transmissão de dados em uma rede (tudo é distribuído conosco, portanto, esse é um problema muito importante). Ferramentas básicas como criptografia, SSL, TLS, autenticação, autorização, manipulação de token e assim por diante. Você não precisa saber muito.
- Há rumores de que você tem algo a ver com o Apache Ignite :-)- Em termos de contribuição, este é o principal projeto em que estou trabalhando atualmente. A participação no Apache Ignite pertence à minha segunda tarefa - garantir um investimento equilibrado em projetos livres e de código aberto. Isso implica tanto o uso competente de produtos (é claro que o uso de bibliotecas é um investimento, nós, como usuários, aumentamos a atratividade do produto), quanto o desenvolvimento e a contribuição.
Para mim, provavelmente, essa tarefa é ainda mais significativa. Prestamos homenagem aos produtos que usamos em nossa empresa e, graças aos quais construímos muitos produtos e sistemas. Tentamos melhorá-los e garantir a possibilidade de uso em empresas como a nossa: otimizar, trazer para um estado corporativo.
O Apache Ignite não é o único projeto, mas o incluiremos de maneira muito intensa, porque uma das principais plataformas do banco está sendo construída com base no Apache Ignite. O Ignite é uma grade de computação distribuída que permite armazenar e processar dados na memória e, de fato, é a base do cenário de TI de nossos negócios. Portanto, estamos extremamente interessados em seu desenvolvimento.
- Muitas pessoas sabem que Sbertech usa GridGain, e você está falando sobre o Apache Ignite. Qual é a diferença entre os dois?- GridGain é um produto de núcleo aberto criado com base em um núcleo aberto, que é o Ignite. E o GridGain é um conjunto de plug-ins para esse núcleo, que simplifica os procedimentos de manutenção e operação, fornece vários requisitos importantes de segurança e confiabilidade das informações. Mas, de fato, o núcleo é a parte mais significativa, e os plug-ins permitem que você explore tudo isso em uma empresa real. E o banco já opera o GridGain.
- Como o Ignite está aberto, você pode falar um pouco sobre isso, certo? Você apenas explora ou faz algo para finalizar, interage com os desenvolvedores?- Nós o modificamos intensivamente. As instruções das tarefas são claramente definidas, por exemplo, garantindo o desempenho levando em consideração as especificidades do Sberbank: dados em grande escala, oceano de dados, alta atividade operacional. Portanto, deve ser rápido e muito. Com isso, quero dizer latência e taxa de transferência.
O segundo é garantir a confiabilidade, ou seja, disponibilidade e tolerância a falhas.
Terceiro: eficiência operacional, gerenciamento de TCO. Dado o tamanho do Sberbank, mesmo uma pequena redução no uso de recursos, por exemplo, discos em uma certa porcentagem, em nossas escalas, gera uma economia tremenda.
E o quarto é a tarefa do desenvolvimento funcional. De fato, o principal é o desenvolvimento de interfaces e a integração com outros componentes da pilha tecnológica do Sberbank. Isso é útil e importante em termos de construção de uma arquitetura de TI madura e integrada.
Separadamente, há a tarefa de eliminar dívidas e defeitos técnicos (que sempre existem). Provavelmente pode ser atribuído à confiabilidade.
- Vamos examinar esses pontos para esclarecimentos. Você diz que está trabalhando para melhorar o desempenho, latência, taxa de transferência, só isso. A questão é: o Ignite tem algum problema com isso? Quero dizer, há algo para modificar ou é um produto ideal?- Não, o produto não pode ser considerado ideal. Em cada versão, direcionamos benchmarks gerais e microbenchmarks em componentes específicos, estamos trabalhando constantemente no desempenho - não devemos parar por aqui. A tarefa é difícil, porque os componentes e soluções já estão bem apertados, o desempenho está quase no limite do ferro. Isso aumenta a complexidade, mas sempre há espaço para melhorias. Temos diferentes casos de uso, novas tarefas do usuário aparecem, nas quais há a possibilidade de otimização. Por exemplo, otimize a unidade de fita para a natureza específica dos dados. Existem tarefas para otimizar a camada de rede, que, novamente, depende de casos individuais. Portanto, você sempre precisa manter o dedo no pulso.
"Você disse que contribuiria de volta para a comunidade." E todas essas decisões sobre vários casos e otimização para eles são algum tipo de compensação. Quando tomamos nossas compensações e as trazemos para a comunidade, pode acontecer que as pessoas na comunidade tenham condições ligeiramente diferentes, prioridades diferentes. Como organizar a interação e ainda copiar o código necessário para seus casos?- Outros clientes com outras tarefas. É absolutamente verdade que este é um problema padrão. Tudo depende da arquitetura da solução. Se a solução incluir, por exemplo, a capacidade de criar extensões de plug-in, plug-ins, bibliotecas para diferentes soluções de usuário - você pode sair. Por exemplo, se houver um comparador, o usuário sempre poderá desenvolver uma solução que passará esse comparador para a entrada e resolverá o problema com base em condições específicas. Mais uma vez, os recursos dependem muito da arquitetura. É errado simplesmente codificar e esculpir nossa tarefa sem pensar em outros clientes - essas solicitações pull não passam por uma revisão.
Todo mundo entende o que é um projeto de código aberto e, em geral, você pode influenciá-lo. É claro que existem comunidades nas quais as empresas estão claramente presentes que influenciam o desenvolvimento em seus próprios interesses, mas se jogarmos de código aberto puro, ele será comparado com a meritocracia (a autoridade dos dignos). Prove que sua decisão é boa e será tomada. Atuar, como costuma acontecer no desenvolvimento fechado, ou seja, da posição de "eu sou o chefe, eu disse que sim" não funcionará.
- Um dos casos mais interessantes que Sbertech contou em público é a Camada Semântica Única. Uma enorme quantidade de dados espalhados por uma grade na memória. Como isso afetou a parte aberta do Ignite e quão interessantes são esses desenvolvimentos para a comunidade?- Sim, esses desenvolvimentos estão em andamento e estamos trabalhando intensamente em tarefas para garantir escalabilidade e acessibilidade. Encontramos casos em que o atual esquema de gerenciamento de topologia não é ideal, porque sua complexidade temporal cresce a partir do número de nós, não exatamente como gostaríamos. Isso complica um pouco a consecução do objetivo.
- Pelo que me lembro, a arquitetura do cluster é um anel. Ou seja, quando entramos no ringue, no começo vamos ao coordenador e depois seguimos o ringue até encontrar a cauda. E quanto mais elementos, mais tempo, certo?"Sim, mais ou menos." Ao mesmo tempo, com um aumento no número de nós na topologia, aumentam o tamanho das mensagens transmitidas ao longo do anel e o número de transições entre os participantes. Isso não quer dizer que um anel seja uma má decisão, mas em alguns casos ele não se encaixa. Portanto, desde o final de 2017, nós, na comunidade, estamos finalizando o gerenciamento de topologia para que os usuários possam escolher um esquema de gerenciamento de topologia: um anel (às vezes se encaixa perfeitamente) ou uma estrela no Zookeeper.
- E de onde veio o anel? Por que é isso? Onde é perfeito?- Esta é uma solução maravilhosa para as topologias de 100-200 nós em um data center. Permite sincronizar de forma simples e confiável todos os nós, eles apenas estão em ordem. Se formos à estrela, eles começarão a trabalhar em paralelo, mais rápido, mas ao mesmo tempo sincronizá-los se torna muito mais difícil. Ou seja, o anel pode ser mais estável e confiável, concorda?
"Sim, claro." Mas isso pode ser feito para que essa topologia possa ser alterada por algum parâmetro na configuração, como está a configuração?- Sim, estamos fazendo isso agora, incluímos as duas topologias no lançamento. Provavelmente, as implementações já propostas não abrangem todos os casos de usuários e, assim que surgirem novos, tentaremos garantir seu processamento efetivo.
- Pelo que entendi, esta é uma revisão bastante complicada. E essa revisão é feita por pessoas em Sbertekh, durante o horário de trabalho ou à noite por prazer?- Isso é feito pela comunidade, que inclui funcionários da PBT, cuja principal tarefa durante o horário de trabalho é contribuir para este projeto. O problema da topologia afeta uma das principais soluções no núcleo do produto, portanto o principal ônus recai sobre os mantenedores do DiscoverySPI, mas espero que a participação de nossos desenvolvedores também tenha afetado positivamente o resultado.
- Bem, ou seja, são pessoas que resolvem um problema durante o horário de trabalho, mas ao mesmo tempo são membros da comunidade.- Sim, a parte mais significativa do trabalho de nossos desenvolvedores ocorre na comunidade. Mas também vejo pelos nossos caras tais compromissos que apareceram em uma hora, duas, três noites.
- E esses funcionários não terão problemas pelo fato de trabalharem em um banco, em um sistema fechado e ao mesmo tempo se comprometerem com um código aberto?- Não, não vai. Todos os participantes são colaboradores corporativos oficiais. A criação da direção e a decisão sobre investimentos foram tomadas no nível da administração da empresa e, sim, esse grupo de colaboradores corporativos dedicados que, de acordo com todos os padrões da empresa e da TC, desenvolvem produtos de código aberto nos interesses da empresa. Sim - isso é desenvolvimento e código aberto, sim - isso ocorre durante o horário de trabalho e também fora do horário de trabalho, mas isso já acontece se a comunidade solicitar.
- Acabamos de falar sobre alguns assuntos externos que a comunidade decide. Mas o mais provável é que a empresa precise fazer suas próprias integrações, melhorar em alguns de seus casos ... Você já escreveu muito? Ou é apenas um pouco de dopilka?- Falando sobre o projeto Apache Ignite, no último trimestre, nossa contribuição para o projeto foi de 8 a 10% de todas as alterações, e nos esforçamos para aumentar esse percentual. Escrevemos muito, e isso não é apenas o desenvolvimento e a otimização da funcionalidade existente, também estamos trabalhando na nova funcionalidade do projeto. Este é um desafio para a comunidade e uma responsabilidade para nós, pois, após sua inclusão, a comunidade, em certa medida, tem a tarefa de apoiá-la.
As tarefas podem aparecer não apenas da comunidade, mas também de usuários da empresa: arquitetos, equipes de desenvolvimento e manutenção. O desenvolvimento do projeto nessas tarefas também afeta significativamente o produto.
- Mas, digamos, houve vários relatórios do programa Sbertekh do PRPRB sobre seu "feng shui especial". Preciso escrever ferramentas adicionais e páginas de administrador para dar suporte a isso?- As interfaces para operação estão em constante evolução. O console de gerenciamento do mesmo Oracle é mais familiar de manter e tem mais funcionalidade. Se precisa ser totalmente reproduzido é outra questão.
- E de forma aberta, você pode ver o console de gerenciamento?"Sim, claro." Console da Web publicado, Visor, CLI - tudo é público.
- E se você olhar para isso de maneira mais global, quais são as direções e metas gerais?- Agora, estamos mais focados no desenvolvimento do Apache Ignite, que atende às prioridades da empresa. Mas nossa pilha tecnológica não termina aí. Open Source , , . , , . ( ), , . . , . . .
— , . - ?— — , availability, durability, fault tolerance ..
— , .— , — . , Open Source . . , .
— - , , ? , - , ceph?— , ceph — . , , , .
— - ? ?— OpenStack.
— , OpenStack — , . - , , ?— OpenStack , , , Cloud Foundry, .
— ?— :-) , ( ) . , — , , .
— .— , - Open Source .
, . , , -.
— -?— , , , -: , .. , , , , . . , Open Source, , , .
. , . -, , . . , , , .
, , ( -, , , ) — . , , , .
— .
— , . , «», , « , » «, ». , . , , . , , , . — , .
— , ? , … , , .— . , , , , . , , ( ). , , , .
, , - .
Open Source . , . . , .
— ? ?— , . , , – . — , ROI, .., .
— , - . , : , . , - Spring Hibernate, , , , . , , , . , .Talvez seja por isso que existem mais candidatos bons no mercado do que desenvolvedores de sistemas. Estou muito feliz por termos conseguido montar a equipe atual, onde todos os caras são muito brilhantes. É incrível como eles pensam e trabalham, eles podem resolver quase qualquer problema. Espero que possamos atrair desenvolvedores ainda mais talentosos. Portanto, não se pode dizer com certeza que na Rússia ninguém precisa de desenvolvedores de sistemas.