One day at Alpha Lab: Java development

We often take technical interviews with companies represented at our conferences. But with the IT department of Alfa-Bank, they decided to go further: not just send questions to one developer, but spend a whole day in the office, asking questions about back-end vendors, front-end vendors, and mobile workers. So that the whole picture emerged - from the technologies used to the company's overall approach.

They thought to make one “full-stack” text, but there was so much material that I had to divide it into parts. And now before you is the “morning” first part, in which Maxim Gorelikov and Kirill Tolkachev communicated with Java developers. Both of them just recently spoke at our Joker conference.
')

Maxim Gorelikov

- First, tell me how much time you have in the company, what position you originally came from, and what are you doing now?

- I came to Alpha in the middle of 2015. At the old place, I developed a lot of things, worked on architecture, and then I came and realized that I was a kettle. The guys from the Sense team talked to me and called to me, but I could not refuse, the technology stack was very interesting.

If you have not heard, Sense - it was such a startup inside the bank, a personal financial assistant in the form of a mobile application. He was born on one of the annual hakatons. The idea and prototype went well, allocated money to the project and the team that invented it. Sense is still alive, but in general its functions are now slowly transferred to the main application of the bank.

In general, I started here as a Java developer in a purely product team. For a couple of years I learned a lot of new things, participated in various projects, now I work mainly on infrastructure, tools for developers and stability tasks.

- Interestingly, was such a transformation of a hackath idea into a real product of the bank single, or are there other examples?

- Not a single one. For example, last year we participated in the hackathon with a team consisting of some developers (without a product owner, a designer, and so on). The team got quite upset: we actually didn’t move away from laptops for 24 hours, so by the end they were squeezed like a lemon. And so there was a project aimed at other Alpha developers ... I'm afraid to say the word "Platform", because all companies, if they grow a little, mold something under that name. Why we started our “platform”:

The company is actively growing, we do not always hire people immediately with the desired experience. Sometimes newcomers come who have little experience, but their eyes are burning. After JUG-mitapes people come, look around: “Oh, Kirill went by!”. They come here just to learn. And so that such a person did not break the firewood at first and quickly entered, we at some point decided to make such a platform that lowers the entry threshold. It allows you to quickly create services using templates and libraries.

At some point, we figured and realized that new teams spend a lot of time on setting up projects in JIRA, raising Jenkins for themselves (sitting on all one Jenkins is a big risk, so more often than not every team we raise it for ourselves) . And we did a thing that integrates all of these things: the developer clicked the button, and she set up the project in JIRA, created a job in Jenkins, and so on, to the point that she generated the code and created a pull request with some kind of service foundation. When the assembly of this thing appears, the developer can click deploy, and everything will roll out to the test. Thanks to this, the developer quickly begins to understand how everything happens, and sees the basic structure of the service that is adopted in this product, understands his style.

- Are projects on hackathons required to be in line with the real needs of the bank, or can you do something else completely different there?

- There were some absolutely crazy ideas that were made solely for the sake of fun; there is no point in promoting them seriously, but in the process everyone got a lot of fun. For example, on one of the hackathons, we made a smart refrigerator with Cyril and a large team. It generally does not fit with the main products of the bank, but it was 24 hours fun. We sat, soldered, parsili some grocery store. In the middle of the night, they suddenly remembered that there was no refrigerator, so one person from the team got it at night and brought, deserved such, ZIL:



I generally perceive Alpha as a place where there is an experimental spirit. When there are seven people in a team, they are developers on all layers (from Java to iOS), and according to Devops religion they can also organize the infrastructure themselves, this preserves the atmosphere of a startup. This team itself can solve all their problems and make decisions.

- Usually, the word “bank” is associated with people not with the words “spirit of experiment”, but, on the contrary, with security, caution and conservatism. How much is it possible to experiment in your conditions? Can you use something “interesting, but not yet the industry standard”, like Kotlin? And how quickly when you release new versions of Java or Spring, go to them?

- It is clear that we need stability in any case. But at the same time it is not necessary to take a new one right away in production. There are a lot of tasks in the technical backlog. We write some tools, if there are no ready ones that completely satisfy us - you can experiment on them.

In addition, projects like Sense in the bank sometimes have the status of a pilot. That is, there is a small customer base, and there you can try some things. And some of the stack, which is now in Alpha, came from Sense, some from other projects. Let's just say there is room for experimentation. Of course, we don’t sit in a battle on release candidates and technologies that have three stars on GitHub. But in order to bring in a new technology, there is no fundamental problem.

Decisions are made by the teams working on the product. If there is a product over which three development teams are sitting, and one wants to drag Kotlin into battle, he will have to convince the javistes from the other teams. And in order to popularize him throughout the company, and this was recommended to beginners, he would need to convince people on other products.

About the speed of transition to new versions - from time to time, depends on how much we really need it. On Java 9, it seems, so far, no project has yet moved, but its release was not so long ago. But with Spring 5 we are actively conducting experiments, at the recent Joker I was just talking about him. The time is nearing, there are interesting features, and as soon as Spring Boot 2.0 comes out, for example, it will be possible to overtake some of the microservices. Most likely, there will be a rather rapid migration of some microservices, from the category “a release appeared - next week or at the end of this week some microservice will appear on it”. Because I have already tried the milestone version, and I will be more confident in the release, because I will know which bugs they have already closed and which critical ones remain.

- And the strict requirements of the legislation (“to keep such information”) and security (“so that this information is not made available to outsiders”) do not lead to the fact that instead of flying imagination you have to deal with items of a thousand boring requirements?

- On the contrary, this is exactly the perfect space for the experiment. At the past Joker, Ilya Sergeev made a report about our logging infrastructure, on which we tried a bunch of all sorts of different technologies that we had not tried before. And this infrastructure was born when there was a requirement to store a certain set of information with a certain storage duration and with access for a certain circle of people.

Before that, we loaded logs directly into Elastic, but in this case it is convenient to build dashboards and monitor, but if you let someone who tries to unload a lot of data from there, then there is a chance that they will put it all. And we built the logging infrastructure through Kafka and the queue just so that those who have to work with this can come in this queue at any time and download the latest data from there. And how much they will be stored and in what form - this is, let's say, their task.

A person who wants to experiment, we will always find on what.

Of course, due to security, we have restrictions on the issue of access. From the category "not from each cluster of production you can access the entire Internet." On pilots a little more freedom of action. The products are more serious, where many clients are sitting, the risks are greater - the harder there. Sometimes we agree with bezopasnik. Sometimes we build the infrastructure and tools for working with it so that access is not needed - we manually try not to tune anything at all, everything is automated.



- On the part, the bank can be represented by a strict organization with penalties for a minute delay - but in practice, do you have the working hours rigid or not?

- Not. Now Kirill has not yet appeared in the office, because yesterday came new hardware, we started transferring new logging to new clusters, tested new schemes, everyone parted late, and Cyril got carried away and stayed until the night - today it will come later than usual.

But with this freedom, individual teams often introduce some disciplining practices of their own. Now there will just be a daily scrum meeting of the team, where it was decided to take small penalties for being late to DSM. DSM team at 11:30, and the amount in the bank has accumulated tangible. A little more to accumulate and go for the money team in a bar.

- How does the communication between the IT department and Alfa-Bank as a whole work? Does an ordinary developer have to interact a lot with non-IT people and receive instructions from them?

- Usually, the product owner of a specific product discusses plans for the bank's product committee, and with the team understands the technical details of the implementation of this plan. At the same time, he doesn’t just “get two sheets of paper from a bank,” everything is much more flexible. Our product-gunners themselves bring ideas, and do not work well according to directives.

In fact, the decision is made not only by the product-ouner. Usually the whole team is involved in the creation of the product, and sometimes the main question is:



If the whole team understands what is being done and why, it becomes easier to create something qualitative. Responsibility is the entire team, so everyone has the right to vote.

- And how much does a developer at Alpha need to dive into some kind of banking specifics like the features of issuing loans?

- It depends on the team and the developer. There are people who are deeply immersed in this, I even know those who began to master accounting simply because they were interested. But when I came to Alpha, the first year I almost did not dive into the specifics. I had some necessary set of documentation in order to interact with banking services, API, get some information, but it was not necessary to understand the specifics of the bank on the move.

It is clear that the longer you work here, the more you try to cover everything at once and build processes and architecture, the more you need to understand how it works from beginning to end. But in the initial stages there is no such thing that you dive into the pool with your head and begin to understand the payments, transactions ... The analyst in the team usually closes the issue.

- To the question “the more you try to cover everything at once with your eyes”: you have already said that you switched to a more general role “outside the grocery teams” —but more?

- Yes, as I gain experience, I don’t even call it a growth, say, a “change of direction” of a developer. Most often, when a developer arrives, he is immersed in the product team and gradually understands the specifics, principles, processes. When, after the first couple of months, he masters, and he no longer has a situation “everything around is new”, he begins to engage in some other auxiliary equipment. And when he grows up to the fact that he understands all the technologies and can attract new ones, he understands how to discuss this with other developers, most often at this moment he begins to stand out and stops working in the full-time team. He is more likely to experiment with technology, create some kind of prototypes, help newcomers get comfortable, work with technical backlog and attract others. Looks where something is unstable, where what needs to be pulled up, what technology or approach to implement.

At the same time, such roles do not fit into the standard definitions of “architect” or “team leader, who is a manager”. Because such a person is obliged to write code, he is obliged to deal with the infrastructure, because otherwise what for is he needed there? Just sit on top and hand out right and left tips? If you drop out of development processes for at least a month or two, it will no longer understand the developers in teams and introduce something new. And such people should bring something into the teams and reach others to this level, when a person already understands everything and can also bring something new.



- You talked about the independence of teams and interaction within the team - and how much interaction is the inter-team? And how often do people go from one team to another?

- There is enough interaction, of course. If there is only one javist in the team, he may be bored, he may want to communicate on Java topics. We have people actively going through meetings and conferences, so in any case you find yourself in the community, but we also have our own community of Java developers. We hold evening meetings when we simply discuss interesting issues: people throw topics, we vote for them, build and discuss. Either within an hour, or (if the desire to discuss is not over) indefinitely, it usually happens on Friday evening. Someone sometimes rehearses a report before a conference. Sometimes discussing banking topics, sometimes general technology, a Kotlin fan can come in and throw in: “Let's discuss the korutins in Kotlin”. And she went ...

Go to another team is usually not a problem. Teams communicate with each other, and if a person likes to do something else, two javista can change, and they can find a new one ... And a profile change is also possible: if you want to master something completely new to yourself, you can come to your teammate and say, “Petya, I would be interested to try development there. Can you teach me, can you be my mentor? ”. He gives you a little puzzle, and with you does. This happens regularly, and people evolve: for example, the developer develops in full stack, testers go into development.

If you want to do some new project at all, you can make a prototype on the hackathon or tell about it at one of the internal meetings.

- Alfa-Bank has products like a mobile application that are clearly visible to its ordinary customers (including among the readers of Habr). Can you give an example of a project that you are also leading or have been working on, but which is not obvious to ordinary individuals?

- Recently, in the news they wrote about a bank transfer via blockchain between Alfa-Bank and Sberbank, but it remained less noted that for us this is not the first experience with the blockchain: last year Alfa-Bank and S7 were the first to Russia conducted a letter of credit transaction with his help. The already mentioned Ilya Sergeyev was interested in working with the blockchain, but not launching a new product just to try. And then there was a need from the bank: to reduce paperwork. That met two loneliness.

- The prospects of the blockchain (both technological and legal) are still not completely clear - was it not terrible for the company to invest resources in this?

- We sometimes launch things that, at first glance, raise the questions of "take off / not take off." When you change something in a product that is used by millions of people, you can simultaneously get a lot of reviews “excellent, finally” and a lot of reviews “why remake”. And when you bring a new technology, you also don’t know exactly what will happen until you verify it on the prototype.

Stability is definitely important to us, we are still a bank, but if we don’t experiment and launch something new, we can fall behind.

Kirill Tolkachev

Later we didn’t ask Kirill who came up later that day, but later we caught Joker at our conference and asked a few questions after him:

“You already have“ Java authority ”in Alpha, you can hear from Alpha’s developers in context,“ and then I went to ask Kirill ”- but is most of the work in discussions with less experienced developers? Do you write a lot of code yourself?

- The existing technical stack has formed, including me, and of course, if the guys have questions about it, we answer. Often people come with such cases that we couldn’t think of, tell us interesting stories, and together we think how to fix it. A recently arrived developer can actively say what he doesn’t like, ask why we are doing like this, whether we are crazy. And through communication, we find some option that allows you to save him from pain. Or we understand that everything is not so simple at all, there are still a lot of other restrictions that affect this process.

About what I do myself - often I start some work, but I don’t always finish. My problem is that the time in the day is only 24 hours, and in order to use it effectively, you do not always have to do something yourself. If I sit down to do something for a week, then many tasks and important things will pass by me.

- To the words “decide how to fix it”: can you give a recent example of some tin that you had to fix?

- From the latter, which was unpleasant: we have internal balancers on HAProxy, which dynamically route traffic to applications. There is a nuance that lies in the fact that our application has a port for internal discovery, which is automatically selected in the system and tied to a whole group of applications.

Here we have this port crossed between two groups of applications that are responsible for different functions. People began to poke. At first, support began to poke, then the developers, and it was not immediately clear what had happened. And here Spring helped to solve the problem. In the endpoint, which returns information about the service (which commit, from which repository all this was collected - internal endpoint's), he returned this: you jerk once, gets on one application instance from one group, and there returns that it Appendix X (identified by the X-Application-id header). You jerk the same endpoint a second time, the balancer routes to another application Y. It took time to find out what someone had incorrectly configured, and we gave the opportunity to configure incorrectly and route the same requests to different applications.

- Maxim was already asked a similar question, but since here you and Yevgeny Borisov had such a powerful report on Spring Boot that he didn’t fit in one time slot, I would like to compare the testimony: what do you think about using the new Spring / Spring Boot versions in production? ? And how does Alpha solve the issue of transition to new versions?

- Reports about Spring Boot are not that they don’t fit in one slot, they don’t fit in one day of training, and Zhenya and I did two trainings - each one on the day - about Spring Boot, which flowed smoothly into Spring Cloud.

And about the transition - depends on the situation. There are technologies that we, of course, test, check the milestone versions. There are technologies that we just look at, for example, we are looking at gRPC now. We are trying to make a breeze in Spring - the starter wrote, checked, found some rough spots, understood that we need to wait for new releases. Waiting for new releases, bang, and in them features that I need. For example, abstractions associated with discovery, load balancing, and so on.

Often you have to keep track of parallel platforms. Of the worst - Node.js. For example, with the same gRPC, you look at the implementation of balancing and restoring connections for a node, and there are comments in the code in the spirit of "to do: implement this", with the note "maybe sometime, for anyone, yes, you will need it". Judging by the code, people generally did not think that in principle anyone would need it. Since I am not a professional in Node, I didn’t even bother to finish it - for too long, without any abstraction, to implement something in a system unfamiliar to me. And it turns out that even if the technologies satisfy us from the server's point of view, clients on different platforms cannot use them due to the lack of the necessary API for reliable operation. There are not always people ready to rule such things, ready to invest in public decisions, promote their ideas. We are always very happy when a developer appears who is able to conduct not only internal development, but also “sharpen” the external code for us. Thanks to such people, we can sometimes not wait for the maintainers of any solution, but release either a local fix or get fixes right in the official version.

From the point of view of the Spring infrastructure, we look at the Mylston towns, and we looked at Spring Boot 2.0 and Spring 5.0, when it had not yet come out.

- Thanks for answers! And we will prepare the continuation of the post .