Am 22. und 23. November fand in Moskau die nächste DotNext 2018-Konferenz für .NET-Liebhaber statt. Mein Name ist Maxim Smirnov, ich leite das .NET-Kompetenzzentrum der Alfa-Bank und möchte Ihnen eine Textversion eines der Interviews präsentieren, die am Rande von DotNext geführt wurden.
Über das Leben und die Abenteuer in unserer Bank, über das Zusammenleben mit Java und Implementierungsprobleme - unter dem Strich.
Wie viel .NET ist in Alpha im Allgemeinen und warum brauchen wir es
In letzter Zeit sind wir in Bezug auf die Verwendung von .NET deutlich gewachsen. Wenn es vor 5 Jahren nicht so viele Tochterunternehmen in Alpha gab (hauptsächlich in Unternehmensanwendungen, Kredite an Unternehmen, Investitionen usw.), waren ungefähr 16 bis 20 Personen mit einer solchen Belastung fertig. Und jetzt entwickelt die Bank aktiv Segmente des Massen- und Mittelunternehmens, was zu einem guten Impuls für die Entwicklung von Kreditsystemen geworden ist.
Und wir standen vor der Wahl - entweder all dies in Java neu zu schreiben, was historisch immer unsere Stärke war und im Einzelhandel immer noch vorherrscht, oder alles auf .NET weiterzuentwickeln, für das wir eine Reihe von Spendern einstellen und an die Front gehen müssten zu den gleichen Technologien, die für die Microservice-Architektur ähnlich sind wie in Java.
Ein solcher Schritt war natürlich sofort bedroht, denn die Risiken [der Anwendung einer neuen Technologie ca. Ed.]. Aber wir konnten diese Risiken auf uns nehmen. Wir haben unseren Kollegen bewiesen, dass .NET mit denselben Clustern und Infrastrukturlösungen, auf denen sich Java großartig anfühlt, angemessen arbeiten kann. Hier beziehe ich mich auf unseren sogenannten "United Front" -Cluster Apache Mesos - Marathon. Und wir fingen an, Entscheidungen an vorderster Front zu treffen, einschließlich des Mittelteils für sie. Die Front blieb die gleiche wie in Java, der mittlere Teil blieb irgendwo in Java, irgendwo in .NET.
Und los geht's - vor 5 Jahren haben maximal 20 Menschen mit .NET fertig geworden, und jetzt gibt es so viele Aufgaben, dass wir 75 mutige Leute haben. Und wir expandieren weiter - jetzt suchen wir einen
Architekten und mehr
Entwickler . Obwohl Java immer noch insgesamt mehr ist, eineinhalb bis zwei, weil es das Einzelhandels- und Massengeschäft stabil dominiert. Wir beherrschen bei .NET im Rahmen des Unternehmens- und Regionaldurchschnitts sowie natürlich noch elektronischer Kanäle.
Überprüfen - beweisen - implementieren
Damit etwas kontinuierlich funktioniert, ist es notwendig, diese Angelegenheit in die Prozesse der Bank umzusetzen. Um es normal umzusetzen, müssen Sie allen Verantwortlichen beweisen, dass dies den aktuellen Stand der Dinge nicht beeinträchtigt und die Implementierung eine Reihe von Pluspunkten mit sich bringt.
Das Schwierigste war mit der Infrastruktur. Wir hatten eine verstärkte konkrete Anforderung von ihnen - dass sich all dies im Docker entfalten und unter Linux normal funktionieren würde. Und hier ist anzumerken, dass es zu dieser Zeit noch keinen .NET Core 2.0 gab, dann gab es nur die erste Version, in der es nicht alles Gute gab, das in der zweiten veröffentlicht wurde. Im Allgemeinen stellte sich heraus, dass wir selbst nicht genau wussten, welche unter Wasser Wir mögen auf Eisberge stoßen, aber sie sagten, dass wir alles tun werden, wie es sollte. Dies konnten wir dem Unternehmen beweisen, indem wir die ersten Piloten starteten - Alfa-Credit, einen Antrag auf Online-Kreditvergabe, Ausgabe von Tranchen und mehr.
Dann mussten die Unterstützer die Realisierbarkeit der Idee beweisen. Sie mussten erklären, dass sie selbst .NET nicht kennen mussten, um unsere Container zu begleiten (aus irgendeinem Grund waren sie sich des Gegenteils sicher). Sie haben ihnen bewiesen, dass es keine Leistungsprobleme geben würde. Ich war einer der ersten, der all dies in einem Cluster gesammelt hat. Wir haben den Container bereitgestellt, eine Reihe von Metriken daraus entfernt, beobachtet, wie stark die CPU geladen ist, und dies alles mit Java verglichen. Wir hatten gerade Java-Code in einem Container, der Einzelhandelskunden half. Aus Gründen der Reinheit des Experiments haben wir absolut denselben Dienst ausgeführt, jedoch unter .NET, damit wir sie in Bezug auf Leistung, Antwortgeschwindigkeit und Speicherbeladung ehrlich vergleichen können. Infolgedessen habe ich Stresstests für all dies geschrieben - alles hat für uns funktioniert, und im Moment arbeiten 6 Teams in diesem Modus.
Jetzt werden wir Legacy langsam los - wir verpacken es in Services und schreiben es funktional in Microservices um.
.NET Core VS .NET Framework
Ich werde noch einmal darauf achten, dass wir .NET Core implementiert haben. Daher gibt es eine Reihe von Problemen in dem Sinne, dass das .NET Framework einige coole Dinge enthält, die sich jedoch nicht im .NET Core befinden und es immer noch nicht sind. Zum Beispiel SOAP-Dienste.
Stellen Sie sich vor. Sie sind eine Bank, Sie haben ein System, das ein anderes verbraucht. Und sie hat sich daran gewöhnt, zu seifen, um zu konsumieren, und Sie haben es nicht. Im Allgemeinen. Wir haben keine einzige normale Implementierung von WCF-Diensten mit SOAP und ähnlichen Dingen gefunden. Vielleicht haben sie schlecht ausgesehen, alles ist möglich. Daher musste ich Ebenen auf dem alten .NET Framework austreiben und schreiben.
Der zweite Satz von Rechen ist die REST-API. Es gibt keine Probleme mit neuen Diensten, in denen sie implementiert sind. Und alte Dienste dazu zu zwingen, die REST-API anstelle von SOAP zu verwenden, ist eine andere Geschichte: Ich müsste alle anderen abhängigen Systeme neu schreiben. Und wieder Schichten, Flecken, Krücken.
Und auch die Kommunikation mit Warteschlangen. Wir verwenden IBM MQ aktiv in Alpha, einem typischen Unternehmensbus für Nachrichtenwarteschlangen. Es gibt einen Client unter .NET Framework, der von IBM stammt. Sie haben jedoch keinen Client für .NET Core. Und soweit wir wissen, ist das nicht geplant. Es gibt nur eine Implementierung des offenen AMQP-Protokolls. Wir haben versucht, mit seiner Hilfe mit den Warteschlangen zu kommunizieren, aber es gab auch eine Reihe von Problemen. Lösung? Ja, wieder die Schichten.
Im Allgemeinen hatten wir eine Iteration, um all dieses Zeug dazu zu bringen, über das AMQP-Protokoll normal zu funktionieren und nicht zu dumm. Aber die Leute von IBM haben sich von uns abgemeldet, sie sagen, sorry, Leute, aber er hat für uns abgelehnt, so gut für ihn. Und dass sie das proprietäre Protokoll nur aus bestimmten Gründen verwenden. Im Allgemeinen sitzen wir jetzt und überlegen, wie wir das alles wiederholen können. Höchstwahrscheinlich schreiben wir unseren Client anstelle des IBM-Clients. Dies ist Open Source.
Front, .NET und NodeJS
Zum größten Teil verwenden wir React JS für die Vorderseite, es funktioniert normal mit dem Knoten. Als wir anfingen, hatten wir eine Reihe alter MVC-Projekte. Dort musste ich die Vorderseite über ReactJS.NET weiterleiten, damit das serverseitige Rendern normal war.
Jetzt, da wir dies vermeiden, haben wir beschlossen, die Fliegen von den Schnitzel zu trennen. Am Ende stellte sich heraus, dass es eine separate Front mit dem Knoten gibt und dass NodeJS unsere Dienste auf der restlichen API in der Web-App nutzt. Und eigentlich ist das alles. In .NET implementieren wir bereits die Mitte. Und wir stellen keine enge Verbindung her, wie ich bei .NET und Angular festgestellt habe, dass wir sie überhaupt nicht direkt trennen können, weil wir uns bemühen, Spezialisierungen für Menschen zu entwickeln.
Wenn Sie die reine Front gut kennen, können Sie sicher mit dem Java-Team die Front dafür schreiben. Dies ist praktisch, sodass Sie von Team zu Team wechseln können. Und wenn Sie den Full Stack kennen, können Sie End-to-End-Anwendungen erstellen. Und das Backend mit .NET und das mittlere und das vordere reagieren. Hier haben wir einen einheitlichen Technologiestandard.
Handy-Integration
Wir haben nicht viel davon. Wo es gibt, nutzt es einfach unsere Dienste auf der Web-API. Wir schreiben selbst keine mobilen Anwendungen auf .NET, es gab nicht einmal Versuche. Einheimische sind immer noch besser zu tun. Wenn Sie den Muttersprachler sofort nehmen und schreiben können, ist es besser, ihn sofort zu nehmen und zu schreiben. Ja, es gibt nützliche Dinge wie Xamarin von Microsoft, aber das ist sinnvoll, wenn Sie einen schnellen, universellen Start benötigen. Wenn es jedoch eine Frage zum Komfort der Anwendung für jede Plattform mit der Leistung gibt, werden Sie immer noch gehen und normalerweise nativ schreiben. Und wir hatten anfangs einheimische.
Über den Widerstand gegen das Neue
Wenn Sie ein großes Unternehmen (und sogar nur wenige Teams) haben, werden Sie immer mit der Einführung neuer Tools unzufrieden sein. Im Allgemeinen ist dies immer normal. Künstler, die das sehen, und das ist alles.
Wenn Sie etwas einführen, das von oben nicht sehr beliebt ist oder das Entwicklern nicht gefällt, werden die Leute immer eine Reihe von Möglichkeiten finden, den Prozess zu sabotieren, und dabei sogar zeigen, was für ein Idiot Sie sind, der all dies begonnen hat. So war es, als wir StyleCop für .NET einführten. Aber im Laufe der Zeit haben es alle akzeptiert und nutzen es jetzt aktiv. Ein einfaches Argument hat geholfen - die Einstellungen von StyleCop sind ziemlich häufig. Das Ergebnis ist schön und für jeden Code mehr oder weniger klar. Obwohl ich den Verdacht habe, schärfen einige Entwickler immer noch einen Zahn. Schließlich hat jeder seine eigenen Standards, jeder hat sein eigenes Verständnis für die Schönheit des Codes, seine eigenen Editoren und Tricks.
Ähnliches wurde in der Serie Silicon Valley gut geschlagen. Dort hatten die Jungs eine Debatte darüber, was verwendet werden sollte - Tabulatoren oder Leerzeichen. Persönlich ist mir das egal, aber wie die Praxis zeigt, für einige Leute, und dies kann ein Anfang für holivar sein.
Wenn Sie alles visuell schreiben, wird diese Frage natürlich im Allgemeinen entfernt.
Jemand hier schreibt Code in Visual Studio, andere nicht. Als wir zum Cluster wechselten, stellte sich heraus, dass es eine Reihe von Technologien gibt, die unter Windows nicht funktionieren. Zum Beispiel Ansible. Unter Windows gibt es einen Client-Teil, der Server-Teil kann jedoch nicht mehr ausgelöst werden. Holen Sie sich daher entweder eine virtuelle Maschine unter Linux oder erledigen Sie alles auf einem Linux-Server.
Im Allgemeinen leben wir so. Wenn Sie Fragen zu .NET in der Bank und zu .NET im Prinzip haben - schreiben Sie, werde ich diese gerne beantworten.