6 myths about fintech development
When asked how a modern IT company differs from fintech in terms of development, the stack most often comes to mind. It is clear, because fintech and banks are processing, Legacy Mountain, many systems that are not updated as fast as we would like. And there is a feeling that it is from the Legacy suite and the need to work on those software versions that the teacher at the institute showed you, and the stack familiar to the fintech consists.
As usual, everything is a little different than it seems at first glance. Under the cut, we’ll talk about the 6 most common misconceptions, how everything works for us in Alpha, and where does Alfa Battle.
Myth # 1. Banks use only older versions of Java, 6–8
At the eight, we began to write about 5 years ago, it was the first version of our Internet bank, assembled on a microservice infrastructure. And now this is the minimally used version, the usual weekdays are 13 and 11.
What are the benefits:
- We get quick access to new JEP and the ability to use new features immediately, without delay when switching to a new version.
- We optimize the work in the docker container.
- We get more functional streams with each release.
So that the developer does not get bored while waiting for the project to be built and can tackle more interesting tasks, to start the java application we use jvm parameters (for example, * RAMPercentage), which allows us to quickly set the percentage of memory, starting from the container’s memory, and optimize the work applications in it.
We also store unpacked JAR archives in order to cache frequently used libraries that do not apply from assembly to assembly, and generally speed up the launch of the project. It used to take 40 seconds to start a container with Spring Boot, now it’s 15. Now we’re thinking of trying JEP 351 ZGC Uncommit Unused Memory (Java 13) to further optimize the work of our services.
We will talk more about Java in Alpha on the stream of our online championship Alfa Battle, it will be here on this page June 27 (Saturday).
Myth # 2. Orchestrators remember 30 dollar
We have Mesos Marathon and more than 10 large Mesos clusters for bank projects, of which there are several hundred. And all would be fine, but with modern requirements of development, Mesos answers, frankly, with difficulty. Is it possible to switch to a new orchestra within the bank?
Available. We are now at the active pilot stage of Kubernetes to manage our test benches, scaling services and network access more flexibly. And each developer, depending on their own sense of beauty, will be able to create their own testing environment with all the dependencies. And if Istio is also added to Kubernetes, then we quickly close the issue of data encryption and authentication between services, and within the cluster.
Myth # 3. Fintech is Legacy
It would be more correct to say that there are legacies in fintech too. Because fintech is about money, there are many large and highly interconnected pieces of the system that should work and work stably. To go and rewrite everything to a proven fresh one is a great idea, in principle. But for this we need to check everything several times: all interdependencies, scalability, fault tolerance, possible design problems. In general, you already know all this. Because if an attempt to jump to some fresh digit in the software version causes some kind of general failure, it will not be a good story.
Therefore, the partially monolithic legacy is still with us, but we continue to crack it up on microservices. Little by little, neatly and with a file instead of a punch, but the process is underway. And again, if we talk about “age” and critical projects. New projects are immediately written in Java 11 and 13, Kotlin, SpringBoot 2, Kafka, Project Reactor / Spring WebFlux.
Myth # 4. Fintech is corporate email only and the prohibition of other communications
To be honest, it’s not very clear where such a myth came from, but we often hear it. Of course, at least one large company can hardly do without corporate mail. At the very least, we need a common calendar with time slots, contact lists, and all this at an acceptable level of security. Therefore, yes, we have corporate mail, which is used for purely official correspondence, confidential information, and other bureaucratic things.
The most working channel in terms of activity in Alfa-Bank is Slack. Moreover, we use almost everything that the service allows us to do there: reminders, notifications, bindings to test environments, alerts from monitoring, and much more. It is really convenient.
Myth # 5. If monitoring is vendor and expensive
Almost no stories about corporations can do without stories about vendors and their attempts to get corporations to themselves so that every change in certain functions is paid. But this does not mean that we use only vendor expensive monitoring systems (although they too).
But we also have Zabbix, for example. Microservices are monitored using Grafana, Micrometer and Prometheus. The latter, by the way, bribed us with the fact that there are a lot of opportunities, and the integration at the same time is quite simple. In general, monitoring does not happen much, and with Prometheus we monitor almost everything, including the synchronization lag of Kafka clusters through MirrorMaker.
Myth # 6. Any delivery to production at the bank is a bureaucratic hell
Judging by the situation on the market, this is highly dependent on the bank. We followed the pipelines to Jenkins and Bamboo. When the delivery process is sufficiently automated using CI / CD, then almost never need additional letters, approvals, applications and other good. That is, the process looks something like this:
- The developer starts the process.
- Pass automatic tests.
- The support engineer approves the roll-out to the prod.
- The new feature flies to a limited number of users.
And that’s it. Then we gradually roll out new features to a larger number of users. An exception to this rule is only the process of opening new functions at once for a huge segment of customers, it already makes sense to further discuss the release plan with the departments of load testing and system support.
Alfa battle
As we already wrote, Alfa Battle will soon be held, an online championship in applied programming in Java from us and our partners – Beeline, X5 Retail Group and Jug.ru.
If you want to join and try your hand – here registration page. The selection is still ongoing, until June 25th.
If you just want to see, then June 27th will be stream, from 12.00 to 18.00.
