Les 22 et 23 novembre, la prochaine conférence DotNext 2018 pour les amateurs de .NET s'est tenue à Moscou. Je m'appelle Maxim Smirnov, je dirige le .NET Competence Center chez Alfa-Bank et je souhaite vous présenter une version texte d'une des interviews réalisées en marge de DotNext.
Sur la vie et les aventures dans notre banque, sur la coexistence avec Java et les problèmes d'implémentation - sous la coupe.
Combien de .NET est en Alpha en général et pourquoi en avons-nous besoin
Récemment, nous avons considérablement augmenté en termes d'utilisation de .NET. S'il y a 5 ans, il n'y avait pas autant de filiales à Alpha (principalement dans les applications d'entreprise, les prêts aux entreprises, les investissements, etc.), environ 16 à 20 personnes ont fait face à une telle charge. Et maintenant, la banque développe activement des segments des grandes et moyennes entreprises, ce qui est devenu un bon élan pour le développement des systèmes de crédit.
Et nous avons eu le choix - soit de réécrire tout cela en Java, qui a toujours été notre point fort historiquement, et qui prévaut toujours dans le commerce de détail, soit de continuer à tout développer sur .NET, pour lequel nous devions embaucher un groupe de donateurs et aller de l'avant aux mêmes technologies similaires pour l'architecture de microservices qu'en Java.
Bien sûr, une telle décision a été immédiatement menacée, car les risques [liés à l’application d’une nouvelle technologie env. Ed.]. Mais nous avons pu prendre ces risques sur nous-mêmes, nous avons prouvé à nos collègues que .NET peut très bien travailler sur les mêmes clusters et solutions d'infrastructure sur lesquels Java se sent bien. Je me réfère ici à notre soi-disant cluster «front unique», Apache Mesos - Marathon. Et nous avons commencé à prendre des décisions de première ligne, y compris la section centrale pour eux. Le front est resté le même qu'en Java, la partie centrale est restée quelque part en Java, quelque part en .NET.
Et c'est parti - il y a 5 ans, un maximum de 20 personnes ont fait face à .NET, et maintenant il y a tellement de tâches que nous avons 75 gars courageux. Et nous continuons à nous développer - maintenant nous recherchons un
architecte et plus de
développeurs . Bien que Java soit encore un total de plus, un an et demi à deux, car il domine de manière stable les commerces de détail et de masse. Nous sommes à .NET maîtrisé dans le cadre de la moyenne corporative et régionale, plus encore des canaux électroniques, bien sûr.
Vérifier - prouver - mettre en œuvre
Pour que quelque chose fonctionne de manière continue, il est nécessaire de mettre en œuvre cette question dans les processus de la banque. Pour l'implémenter normalement, vous devez prouver à tous les gars responsables que cela ne gâchera pas la situation actuelle et que la mise en œuvre apportera un tas d'avantages.
La chose la plus difficile a été avec l'infrastructure. Nous avions une exigence concrète renforcée de leur part - que tout cela se déroule dans le docker et fonctionne normalement sous Linux. Et ici, il convient de noter qu'il n'y avait toujours pas de .NET Core 2.0, puis il n'y avait que la première version, dans laquelle il n'y avait pas tout le bien qui était sorti dans la seconde, en général, il s'est avéré que nous-mêmes ne savions pas exactement quel sous-marin nous pouvons rencontrer des icebergs, mais ils ont dit que nous ferons tout comme il se doit. Nous avons pu le prouver à l'entreprise en lançant les premiers pilotes - Alfa-Credit, une application de prêt en ligne, l'émission de tranches et plus encore.
Ensuite, les partisans ont dû prouver la viabilité de l'idée. Ils devaient expliquer qu'ils n'avaient pas besoin de connaître .NET pour accompagner nos conteneurs (pour une raison quelconque, ils étaient sûrs du contraire). Ils leur ont prouvé qu'il n'y aurait pas de problèmes de performances, j'étais l'un des premiers à collecter tout cela sur un cluster - nous avons déployé le conteneur, en avons retiré un tas de métriques, regardé combien il charge le CPU, comparé tout cela avec Java. Nous venons d'avoir du code Java dans un conteneur qui a fourni de l'aide aux clients de détail. Eh bien, pour la pureté de l'expérience, nous avons fait absolument le même service, mais sur .NET, afin de pouvoir les comparer honnêtement en termes de performances, de vitesse de réponse et de chargement de mémoire. J'ai donc écrit des tests de résistance pour tout cela - tout a fonctionné pour nous, et en ce moment 6 équipes travaillent dans ce mode.
Maintenant, nous nous débarrassons lentement de Legacy - nous l'enveloppons dans les services et le réécrivons fonctionnellement dans les microservices.
.NET Core VS .NET Framework
Je ferai de nouveau attention à la mise en œuvre de .NET Core. Par conséquent, il reste un certain nombre de problèmes dans le sens où il y a des choses intéressantes dans le framework .NET, mais elles ne sont pas dans le .NET Core, et ne le sont toujours pas. Par exemple, les services SOAP.
Imaginez. Vous êtes une banque, vous avez un système qui en consomme un autre. Et elle s'est habituée au SAVON à consommer, et vous ne l'avez pas. Généralement. Nous n'avons pas trouvé une seule implémentation normale des services WCF avec SOAP et des choses similaires. Peut-être qu'ils regardaient mal, tout est possible. Par conséquent, j'ai dû éliminer et écrire des couches sur l'ancien .NET Framework.
Le deuxième ensemble de râteaux est l'API REST. Il n'y a aucun problème avec les nouveaux services où ils sont mis en œuvre. Et forcer les anciens services à utiliser l'API REST au lieu de SOAP est une autre histoire; je devrais réécrire tous les autres systèmes dépendants. Et encore une fois, des couches, des correctifs, des béquilles.
Et aussi la communication avec les files d'attente. Nous utilisons activement IBM MQ dans Alpha, un bus d'entreprise typique pour les files d'attente de messages. Il existe un client sous .NET Framework, natif d'IBM. Mais ils n'ont pas de client pour .NET Core. Et, à notre connaissance, ce n'est pas prévu. il n'y a qu'une implémentation sur le protocole ouvert AMQP, nous avons essayé de communiquer avec les files d'attente avec son aide, mais il y avait aussi un certain nombre de problèmes. Solution? Oui, encore une fois les couches.
En général, nous avons eu une itération pour essayer de faire fonctionner tout cela normalement via le protocole AMQP et non pas pour être stupide. Mais les gars d'IBM ne se sont pas abonnés à nous, disent-ils, désolé, les gars, mais il nous a déprécié, si bien lui. Et qu'ils n'utiliseront le protocole propriétaire que pour certaines raisons. En général, nous nous asseyons maintenant et pensons comment refaire tout cela. Très probablement, nous écrirons notre client au lieu de celui d'IBM, c'est l'open source.
Front, .NET et NodeJS
Pour la plupart, nous utilisons React JS pour le front, cela fonctionne normalement avec le nœud. Lorsque nous avons commencé, nous avions un certain nombre d'anciens projets MVC. Là, j'ai dû transmettre l'avant pour que le rendu côté serveur soit normal, via ReactJS.NET.
Maintenant, nous évitons cela, nous avons décidé de séparer les mouches des côtelettes, à la fin il s'est avéré qu'il y avait un front séparé avec le nœud, et que NodeJS utilise nos services sur les autres api de l'application Web. Et, en fait, c'est tout. Sur .NET, nous implémentons déjà le milieu. Et nous ne le faisons pas spécifiquement, car j'ai observé avec .NET et Angular qu'il est simple de ne pas les séparer du tout, car nous nous efforçons de développer des spécialisations chez les gens.
Si vous connaissez bien le front pur, vous pouvez aller en toute sécurité avec l'équipe java pour écrire le front pour cela. C'est pratique, vous pouvez donc passer d'une équipe à l'autre. Et si vous connaissez la pile complète, vous pouvez créer des applications de bout en bout. Et le backend avec .NET, et le milieu, et l'avant sur la réaction. Nous avons ici une norme technologique unifiée.
Intégration de téléphone portable
Nous n'en avons pas beaucoup. Là où il y en a, il s'agit simplement d'utiliser nos services sur l'API Web. Nous n'écrivons pas nous-mêmes d'applications mobiles sur .NET, il n'y a même pas eu de tentatives. Les natifs sont encore mieux à faire. Si vous pouvez immédiatement prendre et écrire le natif, il est préférable de prendre et d'écrire immédiatement. Oui, il existe des choses utiles comme le Xamarin de Microsoft, mais cela a du sens lorsque vous avez besoin d'un démarrage rapide et universel. Mais s'il y a une question avec la commodité de l'application pour chaque plate-forme, avec les performances, vous irez toujours déjà et vous écrirez normalement en natif. Et nous en avions initialement des natifs.
À propos de la résistance au nouveau
Lorsque vous avez une grande entreprise (et même seulement quelques équipes), vous serez toujours insatisfait de l'introduction de nouveaux outils. Généralement toujours, c'est normal. Des artistes qui voient ça, et c'est tout.
Lorsque vous introduisez quelque chose qui n'est pas très populaire d'en haut, ou quelque chose que les développeurs n'aiment pas, les gens trouveront toujours un tas de façons de saboter le processus, et montreront même dans le processus quel idiot vous êtes qui a commencé tout cela. C'était comme ça quand nous avons introduit StyleCop pour .NET. Mais au fil du temps, tout le monde l'a accepté de toute façon et l'utilise maintenant activement. Un argument simple a aidé - les paramètres de StyleCop sont des choses assez courantes. Le résultat est beau et plus ou moins clair pour tout le monde. Bien que je soupçonne, quelques développeurs ont encore aiguisé une dent. Après tout, chacun a ses propres normes, chacun a sa propre compréhension de la beauté du code, ses propres éditeurs et astuces.
Une chose similaire a été bien battue dans la série Silicon Valley. Là, les gars ont eu un débat sur ce qui devrait être utilisé - les tabulations ou les espaces. Personnellement, je m'en fiche, mais, comme le montre la pratique, pour certaines personnes, et cela peut être un début d'holivar.
Bien sûr, si vous écrivez tout dans le visuel, cette question est généralement supprimée.
Quelqu'un ici écrit du code dans Visual Studio, tandis que d'autres ne le font pas. Lorsque nous sommes passés au cluster, il s'est avéré qu'il existe un certain nombre de technologies qui ne fonctionnent pas sous Windows. Par exemple, Ansible. Il existe une partie client sous Windows, mais la partie serveur ne peut plus être augmentée. Par conséquent, allez chercher une machine virtuelle sous Linux ou faites tout simplement sur un serveur Linux.
En général, nous vivons comme ça. Si vous avez des questions sur .NET en banque, et .NET en principe - écrivez, je serai heureux de répondre.