How to create an online banking service that will not only respond to the ever-changing users´ needs but also increase the efficiency and capabilities of the system? The answer is simple - you should choose a microservice architecture. What technologies allow us to use this solution, how teams need to self-organize and what implementation challenges await - we discuss all these topics with a solution architect - Wojciech Kordeusz, and a Project Manager and team leader, Szymon Kopciuch.Is it true that Comarch and BNP Paribas Bank have been working together for over ten years?
[Szymon] Yes, we first started our cooperation back in 2006, which is when we began to work on an internet banking project for individual clients. For the biggest and the most important of them (code name GOonline Biznes), we have picked the most cutting-edge technologies, just like we always do. GOonline Biznes is carried out with the use of microservice technology, which is the most current trend in many different sectors, finance included.
How did you start building this new internet banking project? What made you go for microservice in GOonline Biznes?
[Szymon] We first started discussing the project in 2019. One of our main goals was to give BNP Paribas Bank a platform that would be in the avant-garde of the existing internet banking standards. Our key focus was to create an open-style platform that could be easily expanded by adding new functional modules created either by the internal developer or third-party companies (the so-called Fintechs). After long hours of meetings, we decided that our best choice would be microservice and cloud technologies. By microservice, I don’t only mean backend, but also frontend, which is something we tend to call “microfrontend.” Another advantage of changing the used technology from monolithic (as in previous versions of internet banking) to microservice has allowed us to significantly shorten the Time-to-market ratio of new business value for final customers and to reduce development costs( e.g., cost of comprehensive regression tests).
What does working on this project look like from the technological point of view?
[Wojciech] The technical side looks very interesting. We had the freedom to choose from among the most modern solutions, which has allowed us to pick the technologies that were the best suited for our needs and the competencies of our teams. A big part of our job is carried out with the use of the Spring and the Spring Boot framework, and as for our frontend applications, they are based mainly on the Angular Framework. All microservices are containerized (here, we’ve opted for Docker). Containers are launched in the Openshift cluster, whose primary purpose is cluster management and orchestration. An undoubted advantage of the microservice architecture is that each application works as a separate project. Each project can be built with the stack that seems the best-tailored for each project’s needs and competencies. It is a huge step forward from monolithic applications that required using the same technology and - to make matters worse - in the same versions. The flexibility we have now allows us to implement and test various individual microservice solutions and versions gradually. The use of modern and verified technology has meant a higher efficiency, more possibilities, and better security for the GOonline Bizness project, making it even more competitive. Containerization, on the other hand, has improved the delivery process and the application launching.
What design patterns did you choose, and what best practices did you follow when using the microservice technology?
[Wojciech] Each application is, in fact, a separate project, which is independent of others and has its own life-cycle. The only form of communication between microservices is invoking services provided by a given module, defined in its API.
As part of our projects, we make every effort to comply with the principles of Clean Architecture, which is why our activities are always divided into appropriate layers. Domains are one of the layers especially worth mentioning. We use Domain-Driven Design (DDD), and, following the principles of this layer, we model the domain for which a given microservice is responsible.
On the other hand, we use the CQRS (Command Query Responsibility Segregation) pattern, thanks to which we create a separation between the read and the write stack. We also avoid over-configuration by following the rule of Convention over configuration.
We are well aware that communication is one of the most important aspects of distributed systems. How did you address this issue, and what tools did you use?
[Wojciech] As I mentioned before, microservices communicate with each other according to what has been defined in their API. This communication can be synchronous and carried out by a service call (REST or HTTP). The second option is asynchronous communication (e.g., Event), in which we use an Apache Kafka-based solution. We also use the API Gateway pattern, whose task is to provide services for client applications (web/mobile) by directing requests to the responsible microservices. It relieves other microservices from the so-called cross-cutting concerns such as authentication.
Have you had any implementation challenges with this project?
[Wojciech] Of course, we have. The microservice architecture is beneficial on various levels, but it also implies certain challenges that need to be addressed. One of these challenges has been to ensure the right level of system transactionality for the data to be consistent. After all, we are dealing with a banking system. We managed to achieve this by introducing and implementing appropriate mechanisms (e.g., an event bus operating as part of a transaction and a proper data exchange process between microservices). Another crucial task was to ensure the scope of activities of each given microservice module was not too small (to avoid unnecessary overhead on communication and ensure data consistency). An excessively large scope of activities, on the other hand, would imply going back to the monolith architecture, which is something we definitely don’t want.
Do microservice bring any real advantage other than being technological novelties?
[Szymon] Apart from the undoubted business and technological advantages, we should also consider the positive influence that such new architecture has on the work of people involved in the project. Microservice is a natural way to support and strengthen a swift application design and to manage self-organizing teams. We chose to carry out the project in Scrum; we created autonomous teams in charge of only one specific business domain (e.g., payments or loans). This choice, along with the enormous trust that BNP Paribas Bank has put in us, has brought about lots of positive effects. One of these effects has certainly been an increase in all team members’ motivation, which resulted in excellent results for the system users and our daily work satisfaction, and a smile on our coworkers’ faces. The recipe to enjoy working with microservice architecture is very simple: all you need to do is to allow scrum teams to come up with their own ideas and implement them. On the other hand, you need to give them some room for experimenting and making mistakes and let them pick the technology that works best within their own microservice. The microservice architecture allows teams to focus on their own area without worrying that it can negatively interfere with other teams’ work, which was the case in a monolithic architecture.
You’ve mentioned teams, but how many people work with the project? And how did you build your teams?
[Szymon] Picking the right people is crucial. One of our main criteria was to meet one of the primary Scrum assumptions, which is to create self-sufficient teams. To achieve that, you have to make sure that each team has specialists from different areas (analysts, developers, architects, QA, etc.). When the project was at its busiest moment, we had over 50 people working on it. Without the scrum approach and the microservice, we wouldn’t have been able to create so many functionalities in such a short time.
From your perspective, is Comarch a good place for those wishing to develop their professional career?
[Wojciech] It most definitely is. I hope our conversation has made it clear how fascinating the projects we get to work on here at Comarch are. From my personal experience, I know how important this aspect of work is. Comarch is a big company with many similar projects, subsidiaries, and clients worldwide, which means there are lots of opportunities and everyone can find something they like, whether they have been working in the industry for years or are just starting.
[Szymon] You could name many reasons why it is worth working at Comarch, but I will only mention the three that I consider the most relevant. The first one is the opportunities that await each employee as soon as they cross the door (or turn on their computer, to be more exact ). As soon as you get on board, you are assigned to one of the current projects, and you don’t have to wait for long weeks to see the results of your work. Of course, you can count on the support and supervision of an experienced mentor for the first couple of months.
The second factor is the cutting-edge technologies we use in our projects and the knowledge exchange within teams, which boosts employee development and broadens their knowledge. Last but not least, Comarch offers a great working environment. Seeing your co-workers’ friendly and smiley faces (either in person or - in today’s reality - virtually) is very motivating.