This time, we focused on an investment app called JUNE. It is currently available for Danske Bank customers in Denmark and Sweden. Our Lithuania-based developers' team contributed to the development of this product significantly. Saulius Vysniauskas, Cloud Specialist Chapter Lead at Danske Bank, shares his experience of three years working with JUNE. 

Saulius Vysniauskas joined Danske Bank 6 years ago as a mid-level Software Developer. Currently works as Cloud Specialist Chapter Lead.

Technology Saulius enjoys working with the most: "I have tried quite a few different things in my life development wise, but what makes me most happy is backend work on .NET code. There is always something new to discover and interesting problems to resolve - I guess anything that challenges you as a developer, makes you better and feels rewarding when done well."

Saulius, could you tell more about the product?

JUNE is an app designed to simplify the investment process. The algorithm of JUNE is constructed to provide personalized investment recommendations based on the user's financial situation and risk tolerance. Because of the tech stack, complex and challenging technical tasks, it is an enjoyable product to work with from a developer's standpoint.

What tech stack is behind JUNE?

The front-end part is built with React, and native iOS app is built using Swift. It is a distributed application, so many different backend services operate on Docker Containers in the OpenShift Container Platform with Microsoft SQL used for storage. Most of these services were developed using C# on .NET Core 3. In the upcoming year, we plan to migrate it into .NET 6. There are also a few services developed using Python, Node.js, Kotlin. However, C# is the main language, and our current colleagues prefer working with it.

RabbitMQ messaging broker is used quite extensively for communication between services. Of course, it increases the system complexity both from development and infrastructure perspectives. Developers need to take care of different possible messaging scenarios, with messages going out of order or being delivered multiple times. We use the MassTransit message bus to make our work with RabbitMQ more convenient. On the other hand, DevOps also need to set up the RabbitMQ cluster from the infrastructure side.

In the end, we still think it is worth it, as messaging makes services decoupled and very resilient. JUNE developers find it quite interesting working in a technical setup like this.

When it comes to choosing the tech stack for a project like this, who makes the decisions?  

Of course, we have software architects who consult and provide blueprints for different applications. However, the developers can strongly influence the final decision, and they have a lot of authority to make decisions. Therefore, a well-reasoned opinion will surely be heard and valued. For example, the blueprint may indicate that messaging should be used in some instances, but our developers can use their preferred technology. In this case, RabbitMQ, Apache Kafka, etc.

 

Which of JUNE's technical solutions, in your opinion, makes a significant impact?

Quite a lot is going on in June from the technical side. We have a distributed system, where all the parts need to work together reliably. The whole infrastructure is set up as a code via Terraform. There is an underlying investment engine, integrations with external partners, many unit tests, extensive common code libraries covering various development areas. In a complex project, a small solution can make a big difference.

For example, I quite like our logging setup, where we have interceptors set up via Autofac or MVC middleware. They automatically log incoming and outgoing requests in the services, including conventional API calls and messaging.

In general, it is good to keep logging slim and as automated as possible. You get clean, correlated logs across the whole application distributed in many different services. This makes it easy to track any request in the system, despite all the layers and underlying services. In addition, it saves developers' time resolving issues. Simply put, it is nice to have code that works for you in the background.

How do you maintain the quality of such a highly complex project? Could you share any of the best practices or learnings?

Good code review practices are one of the most important things. It's great to see good pull request discussions. If developers take it seriously, such practice improves code quality, allows new team members to get up to speed quicker, and helps the whole team grow. This is what we are looking for - better team, better code, the best possible quality of the end product.

Of course, code reviews are just one piece of the big picture. JUNE also entails unit tests, infrastructure work by DevOps, manual testing, lots of preparatory work by business specialists, legal team, etc.

To sum it up, for me, it's the people that make complex projects work. Therefore, it's always the team and its improvement where I would invest the most.

What aspect of JUNE development is the most challenging?

The JUNE Squad is one of 17 squads that make up Danske Bank's Retail Investment Tribe. Typically, each squad is responsible for a particular stage of the customer's investment journey. Yet when it comes to JUNE, we are responsible for the entire customer journey, including investment recommendations, customer onboarding, and operations. This gives an end-to-end overview; however, requires a wide variety of expertise among our developers. For example, in the customer onboarding section, JUNE development efforts must adhere to many compliance regulations, whereby working with investment recommendations requires completely different skills.

Therefore, we try to streamline our development process, transfer some functions, allowing the experts of a particular field to handle the respective part of product development. Enabling people to do what they are best at results in smoother processes and improves developers' experience.

What are the three things you learned working on JUNE?

1. Be open when seeking the best result. We had three teams of backend developers working on this project during the active development phase of the product for the Swedish market – one in Lithuania and two in Denmark. That means a lot of different opinions. We spent lots of time discussing the best ways of doing things. While it was occasionally time-consuming, many valuable decisions were implemented based on the suggestions, while others were reasonably challenged. Accepting a different point of view might not always be pleasant, but necessary to achieve the best possible outcome. Therefore, we strongly encourage feedback and openness in our squad.

2. Adaptiveness is crucial. Early on, a part of JUNE's infrastructure was hosted on Amazon Public Cloud. A few years later, an internal cloud setup became available in the bank. Consequently, developers migrated JUNE into the bank's cloud infrastructure. It was a serious technical challenge and a valuable learning experience.

Naturally, circumstances often change as technologies rapidly evolve and new and better solutions become available. As developers, we must be adaptive and perceive the changing environment as an opportunity to sharpen our technical and problem-solving skills.

3. Compliance impacts the way we develop things. In the past few years, GDPR and compliance regulations have become an essential element of product development. As a bank, we are in the epicentre of these regulations. Compliance in data handling, collaboration with legal experts has already become natural for us. However, it is the upcoming reality for most IT specialists, regardless of the industry.

Curious to know more about what our tech colleagues do @Danske?
Visit this page. 🧐