Interview with the head of the .NET Competence Center on DotNext 2018
On November 22 and 23, the regular DotNext 2018 conference for .NET fans took place in Moscow. My name is Maxim Smirnov, I manage the .NET Competence Center at Alfa-Bank and I want to present you a text version of one of the interviews taken on the sidelines of DotNext.
About life and adventures of dotnet in our bank, about coexistence with Java and problems of implementation - under the cut.
Recently, we have grown quite significantly in terms of using .NET. Even 5 years ago, there were not so many dot-nets in Alpha (mainly in corporate applications, corporate business lending, investments, etc.), about 16-20 people coped with this load. And now the bank is actively developing segments of the mass and medium corporate business, which was a good impetus to the development of credit systems.
And we had a choice - either to rewrite all this in Java, which historically has always been a strong point for us, and it still prevails in retail, or continue to develop everything in .NET, which would have to hire a bunch of dotnetchikov and go out for the front on the same technologies, similar for microservice architecture, as in Java.
Of course, such a move was immediately threatened, because the risks [of applying a new technology approx. Ed.]. But we were able to take these risks on ourselves, we proved to our colleagues that .NET is quite capable of working adequately on the same clusters and infrastructure solutions on which Java feels great. Here I mean our so-called “united front” cluster, Apache Mesos - Marathon. And we began to make front-line decisions, including the middle part for them. The front remained the same as in Java, the middle part remained somewhere in Java, somewhere in .NET.
And it started - 5 years ago, a maximum of 20 people coped with .NET, and now there are so many tasks that we have 75 such brave guys. And we continue to expand - now we are looking for an architect and more developers. Although Java is still a total of more than one and a half to two or two times, because it stably dominates retail and mass businesses. We on .NET have accustomed within the corporate and average regional, plus electronic channels still, by itself.
In order for something to work on a permanent basis, it is necessary to introduce this business into the bank processes. In order to properly implement - it is necessary to prove to all responsible guys that this will not spoil the current state of affairs and implementation will bring a lot of advantages.
The hardest thing was with infrastructures. We had a reinforced concrete demand from them - that all this was unfolding in Docker and working normally in Linux. And here it is worth noting that at that time there was no .NET Core 2.0, then there was only the first version, in which there was not all that kind of stuff that was released in the second, in general, it turned out that we ourselves didn’t know exactly which underwater ones Icebergs can collide, but they said that we will do everything as it should. We managed to prove this to business by launching the first pilots - Alpha-Credit, an application for online lending, issuing tranches and more.
Then it was necessary to prove the consistency of the idea and supporters. They had to explain that they themselves do not need to know .NET in order to accompany our containers (for some reason they were sure of the opposite). We proved to them that there would be no performance problems, I was one of the first to collect all this on a cluster - we deployed the container, removed a bunch of metrics from it, watched how heavily it loads the CPU, compared it with Java. We just had Java code in a container that gave help to retail customers. Well, for the purity of the experiment, we did absolutely the same service, but on .NET so that you can honestly compare them in performance, response speed, and memory load. I wrote load tests for all of this, in the end - we all had a ride, and at the moment there are 6 teams in this mode.
Now we slowly get rid of Legacy - we wrap it in services and functionally rewrite it on microservices.
Once again I will pay attention that we implemented .NET Core. Therefore, a number of problems remain in the sense that there are some cool things in the .NET framework, and in the .NET Core there are none, and there are not to this day. For example, SOAP-services.
Just imagine. You are a bank, you have one system that consumes another. And it used to consume SOAP, and you do not have it. At all. We did not find any normal implementation of WCF-services with SOAP and similar things. Maybe bad looking, everything is possible. Therefore, I had to run out and write layers on the old .NET Framework.
The second set of rakes - REST API. With new services, where it is implemented, there are no problems. And forcing old services instead of SOAP to use the REST API is another story, you would have to rewrite all other dependent systems. And again layer, patches, crutches.
And communication with queues. In Alpha, we are actively using IBM MQ, a typical enterprise queue of message queues. The client under the .NET Framework exists, native from IBM. But under the .NET Core they do not have a client. And, as far as we know, it is not planned. there is only an implementation on the open AMQP protocol, we tried to communicate with the queues using it, but there were also a number of problems. Decision? Yes, again interlayer.
In general, we had an iteration in attempts to make all this stuff work normally through the AMQP protocol and not to blunt. But the guys from IBM have unsubscribed us, they say, sorry, guys, but he is deprecated for us, so well, him. And that they will only use the proprietary protocol for certain reasons. In general, we sit now and think how to redo it all. Most likely, we will write our client instead of IBM-ovsky, such an open source will be here.
For the most part, we use React JS for the front, it works fine with the node. When we started, we had a number of old MVC projects. There we had to prokidykat front, to make the server side rendering normal, through ReactJS.NET.
Now we are avoiding this, we decided to separate flies from cutlets, as a result it turned out that there is a separate front with the node, and that NodeJS uses our services for rest api in the web app. And, in fact, everything. On .NET, we are already implementing Middle. And as for I’ve observed with .NET and Angular, there’s no hard linking, we don’t do it on purpose, because we strive to develop specializations in people.
If you are well aware of a pure front, then you can safely go with the java-team to write the front for it. This is convenient, so you can flow from team to team. And if you know fullstek, you can make applications end-to-end. And backend with .NET, and middle and front on the reactor. We got a uniform technology standard here.
We do not have much of it. Where there is, it's just using our services on the web api. We do not write mobile applications on .NET, there were not even attempts. Native is still better to do. If you can immediately take and write a native - it is better to immediately take and write. Yes, there are useful things like Xamarin from Microsoft, but it makes sense when you need a fast universal start. But if there is a question with the convenience of the application for each platform, with performance, you will still go and you will normally write native. And our native were originally.
When you have a big company (yes, even just a few teams), then always with the introduction of new tools will be dissatisfied. Generally always, this is normal. Artists who see it that way, and that’s all.
When you are introducing something not very popular from the top, or something that developers do not like, people will always have a lot of ways to sabotage the process, and also show in the process what kind of an idiot you are that it all started. We had it that way when we implemented StyleCop for .NET. But over time, it is still all accepted and is now actively yuzayut. A simple argument helped - the settings from StyleCop are fairly common things. The result is a beautiful and more or less clear code for everyone. Although, I have a suspicion, a couple of developers still sharpen a tooth. After all, everyone has their own standards, everyone has their own understanding of the beauty of the code, their own editors and tricks.
A similar thing was well beaten in the series "Silicon Valley". There, the guys had a dispute on what should be used - tabulation or spaces. Personally, I do not care, but, as practice shows, for some people, and this can be a start to the holivar.
Of course, if you write everything in a visual, this question is generally removed.
Someone is writing code in Visual Studio, and someone is not. When we switched to the cluster, it turned out that there are a number of technologies that do not work under Windows. For example, Ansible. The client part on Windows is, but the server is no longer to raise. Therefore, either go and pick up a virtual machine on Linux, or just do everything on a Linux server.
In general, and we live. If you have any questions about .NET in the bank, and .NET in principle - write, I will be glad to answer.
About life and adventures of dotnet in our bank, about coexistence with Java and problems of implementation - under the cut.
How much in Alpha in general .NET and why do we need it
Recently, we have grown quite significantly in terms of using .NET. Even 5 years ago, there were not so many dot-nets in Alpha (mainly in corporate applications, corporate business lending, investments, etc.), about 16-20 people coped with this load. And now the bank is actively developing segments of the mass and medium corporate business, which was a good impetus to the development of credit systems.
And we had a choice - either to rewrite all this in Java, which historically has always been a strong point for us, and it still prevails in retail, or continue to develop everything in .NET, which would have to hire a bunch of dotnetchikov and go out for the front on the same technologies, similar for microservice architecture, as in Java.
Of course, such a move was immediately threatened, because the risks [of applying a new technology approx. Ed.]. But we were able to take these risks on ourselves, we proved to our colleagues that .NET is quite capable of working adequately on the same clusters and infrastructure solutions on which Java feels great. Here I mean our so-called “united front” cluster, Apache Mesos - Marathon. And we began to make front-line decisions, including the middle part for them. The front remained the same as in Java, the middle part remained somewhere in Java, somewhere in .NET.
And it started - 5 years ago, a maximum of 20 people coped with .NET, and now there are so many tasks that we have 75 such brave guys. And we continue to expand - now we are looking for an architect and more developers. Although Java is still a total of more than one and a half to two or two times, because it stably dominates retail and mass businesses. We on .NET have accustomed within the corporate and average regional, plus electronic channels still, by itself.
Check - prove - implement
In order for something to work on a permanent basis, it is necessary to introduce this business into the bank processes. In order to properly implement - it is necessary to prove to all responsible guys that this will not spoil the current state of affairs and implementation will bring a lot of advantages.
The hardest thing was with infrastructures. We had a reinforced concrete demand from them - that all this was unfolding in Docker and working normally in Linux. And here it is worth noting that at that time there was no .NET Core 2.0, then there was only the first version, in which there was not all that kind of stuff that was released in the second, in general, it turned out that we ourselves didn’t know exactly which underwater ones Icebergs can collide, but they said that we will do everything as it should. We managed to prove this to business by launching the first pilots - Alpha-Credit, an application for online lending, issuing tranches and more.
Then it was necessary to prove the consistency of the idea and supporters. They had to explain that they themselves do not need to know .NET in order to accompany our containers (for some reason they were sure of the opposite). We proved to them that there would be no performance problems, I was one of the first to collect all this on a cluster - we deployed the container, removed a bunch of metrics from it, watched how heavily it loads the CPU, compared it with Java. We just had Java code in a container that gave help to retail customers. Well, for the purity of the experiment, we did absolutely the same service, but on .NET so that you can honestly compare them in performance, response speed, and memory load. I wrote load tests for all of this, in the end - we all had a ride, and at the moment there are 6 teams in this mode.
Now we slowly get rid of Legacy - we wrap it in services and functionally rewrite it on microservices.
.NET Core VS .NET Framework
Once again I will pay attention that we implemented .NET Core. Therefore, a number of problems remain in the sense that there are some cool things in the .NET framework, and in the .NET Core there are none, and there are not to this day. For example, SOAP-services.
Just imagine. You are a bank, you have one system that consumes another. And it used to consume SOAP, and you do not have it. At all. We did not find any normal implementation of WCF-services with SOAP and similar things. Maybe bad looking, everything is possible. Therefore, I had to run out and write layers on the old .NET Framework.
The second set of rakes - REST API. With new services, where it is implemented, there are no problems. And forcing old services instead of SOAP to use the REST API is another story, you would have to rewrite all other dependent systems. And again layer, patches, crutches.
And communication with queues. In Alpha, we are actively using IBM MQ, a typical enterprise queue of message queues. The client under the .NET Framework exists, native from IBM. But under the .NET Core they do not have a client. And, as far as we know, it is not planned. there is only an implementation on the open AMQP protocol, we tried to communicate with the queues using it, but there were also a number of problems. Decision? Yes, again interlayer.
In general, we had an iteration in attempts to make all this stuff work normally through the AMQP protocol and not to blunt. But the guys from IBM have unsubscribed us, they say, sorry, guys, but he is deprecated for us, so well, him. And that they will only use the proprietary protocol for certain reasons. In general, we sit now and think how to redo it all. Most likely, we will write our client instead of IBM-ovsky, such an open source will be here.
Front, .NET and NodeJS
For the most part, we use React JS for the front, it works fine with the node. When we started, we had a number of old MVC projects. There we had to prokidykat front, to make the server side rendering normal, through ReactJS.NET.
Now we are avoiding this, we decided to separate flies from cutlets, as a result it turned out that there is a separate front with the node, and that NodeJS uses our services for rest api in the web app. And, in fact, everything. On .NET, we are already implementing Middle. And as for I’ve observed with .NET and Angular, there’s no hard linking, we don’t do it on purpose, because we strive to develop specializations in people.
If you are well aware of a pure front, then you can safely go with the java-team to write the front for it. This is convenient, so you can flow from team to team. And if you know fullstek, you can make applications end-to-end. And backend with .NET, and middle and front on the reactor. We got a uniform technology standard here.
Mobile integration
We do not have much of it. Where there is, it's just using our services on the web api. We do not write mobile applications on .NET, there were not even attempts. Native is still better to do. If you can immediately take and write a native - it is better to immediately take and write. Yes, there are useful things like Xamarin from Microsoft, but it makes sense when you need a fast universal start. But if there is a question with the convenience of the application for each platform, with performance, you will still go and you will normally write native. And our native were originally.
Pro resistance to new
When you have a big company (yes, even just a few teams), then always with the introduction of new tools will be dissatisfied. Generally always, this is normal. Artists who see it that way, and that’s all.
When you are introducing something not very popular from the top, or something that developers do not like, people will always have a lot of ways to sabotage the process, and also show in the process what kind of an idiot you are that it all started. We had it that way when we implemented StyleCop for .NET. But over time, it is still all accepted and is now actively yuzayut. A simple argument helped - the settings from StyleCop are fairly common things. The result is a beautiful and more or less clear code for everyone. Although, I have a suspicion, a couple of developers still sharpen a tooth. After all, everyone has their own standards, everyone has their own understanding of the beauty of the code, their own editors and tricks.
A similar thing was well beaten in the series "Silicon Valley". There, the guys had a dispute on what should be used - tabulation or spaces. Personally, I do not care, but, as practice shows, for some people, and this can be a start to the holivar.
Of course, if you write everything in a visual, this question is generally removed.
Someone is writing code in Visual Studio, and someone is not. When we switched to the cluster, it turned out that there are a number of technologies that do not work under Windows. For example, Ansible. The client part on Windows is, but the server is no longer to raise. Therefore, either go and pick up a virtual machine on Linux, or just do everything on a Linux server.
In general, and we live. If you have any questions about .NET in the bank, and .NET in principle - write, I will be glad to answer.