One of the most important stages in the creation of a neobank is the development of a mobile application. To acquire users, a modern service must respond to the current needs of the audience and solve their problems effectively. This is virtually impossible to achieve without the right architecture. Historically, many companies have stuck to a monolithic architecture, which, although it hinders movement, provides an opportunity for development.
The technological singularity frames new rules.
Some 15-20 years ago, science fiction writers told us about the distant future, an unbelievable digital world. There will come a time when the intensity of knowledge and information generation will be too high. Actually, it is already happening. Artificial intelligence and machine learning have entered the world. There are intelligent agents that have stronger intelligence, albeit artificial. They can generate ideas faster and more globally than common people. Ultimately this will lead to the fact that cycles of self-improvement will develop so rapidly, and new solutions will appear so quickly that humans will not be able to keep up with them. The technological singularity is already here. As soon as students cross the thresholds of their universities, their education actually depreciates and requires major upgrades. Keeping up with science is incredibly difficult. Along the way, we face a certain dilemma. On the one hand, the progress is moving at an incredible speed, and on the other hand, companies must somehow keep up with it. To maintain competitiveness, you have to increase the speed of development of hi-tech and useful features. To do this, you need to manage teams, and consequently, develop an acceptable IT architecture.
Despite all the internal issues, we should not forget about the main thing: our customers. A neobank mobile app is actually a bank’s representative office for them. Therefore, it should be convenient and should have high-speed internal services with flawless operation. The quantity and quality of services should correspond to the level of service offered by traditional banks or at least aim for it. People do not care about your problems, they just want to get a good product.
The implementation of software in neobanks is a specific element with its own ecosystem. This industry helps businesses grow, automate and digitalize all processes, generate profits and create virtual assets all at the same time. However, who will do it? There is a shortage of good programmers in the job market. This problem has always existed and will always exist. There is even a shortage of underskilled IT staff. The technology is evolving so fast that many simply do not have time to enrich their knowledge with updated information.
As we noted earlier, humanity cannot ignore the technological singularity. Sometimes things happen in science that are difficult for us to catch at the first attempt. We all strive to adjust our intellectual life to a new paradigm. We can see the gradual increase in demand for unique and specific human abilities.
Since the knowledge is changing quickly, the specificity is now coming to the fore. Teams that gain unique experience in a specific, focused area are in demand. Their services are highly valued and cost accordingly. However, in order to develop and create new solutions, you have to join other strong performers and enter into cooperation. Going forward in collaboration is much more effective than working alone. Nevertheless, we are faced with the question: What kind of architecture should we represent as part of a paradigm shift?
It is about the principles of building an application. The architecture depends on the goals and capabilities of the company (not vice versa). More than this, the architecture depends on the user and the value we want to convey to them. A neobank should focus on flexibility above all. This is the goal of the company. However, this approach does not de-emphasize security requirements. It is important to work with finances, fault tolerance, and requirements for rapid scaling. As practice shows, it is most effective to build a customer-oriented server by separating the customer software and the backend. Such an architecture can be of a monolithic or microservices type inside.
The architecture may be different at each stage, and this is completely normal. For instance, a monolithic architecture can be very convenient for startup companies at the MVP launch stage. It makes no sense for them to switch to microservices. You could even say that this would be the wrong decision. In the early stages, it is essential to bring an MVP to the market as soon as possible in order not to be late, and release the product with the minimum number of features. To achieve these goals, it is quite enough to implement a monolithic architecture.
For example, when a company needs to quickly enter the market, choose a tech stack, and gather a team, it is important to understand what kind of infrastructure can be built in one day. Microservices are completely unsuitable for this task.
Currently we are witnessing the rapid growth of companies that have concentrated their services around users and provide personalized service. Regular technological and functional updates help follow the trend for customer centricity. You should make the right bet and the right choice depending on the goals and available time. Everything should be developed with an eye on further expansion, not on meeting immediate needs. Of course, the process is costly.
A monolithic architecture will make your life easier.
A monolithic architecture combines all standard modules, user interface, business logic and data layer into a single service. Each request is processed through all levels. This architecture is much easier to develop. However, it has its major drawbacks: complex modernization and lack of flexibility. To introduce new services, you will have to actually rewrite the app code, which often requires a lot of time and effort. But it is worth it.
Despite its unhandiness, this kind of architecture can speed up product time to market. This is the right approach for companies with small goals. Neobanks have one main goal, which is to launch an MVP, so why not use a monolithic architecture? In my opinion, the desire of some startups to immediately switch to a microservices architecture looks unprofessional.
For my CFPS product, I have chosen a hybrid (transitive) architecture, but it cannot be called a microservices architecture. I have taken a monolith as a basis, and it is really very convenient. It allows you to maintain a good speed of deployment. When deployment does not occur very often, a monolithic architecture is indispensable. A bird in the hand is worth two in the bush.
Who is a microservices architecture suitable for?
When startups grow and gain power and speed, they are keen to launch many processes at once and move on to multi-team solutions. As a result, a microservices architecture is implemented. However, at the start, all these companies used a monolithic architecture anyway. It is just the next step. I believe that it is better to create an IT architecture based on proven principles and then split it into separate structures.
I also adhere to this system. When I was creating the CFPS architecture at the MVP development stage, I knew that I would definitely switch to microservices, but at the time it was inconvenient and simply unnecessary.
Microservices allow the employment of the TRUNC approach where features can be released every day. This is impossible in a monolithic architecture, but is easily implemented in small microservices. The rate of change is what distinguishes large neobanks from traditional banks.
The corporation, having a staff of about 400-500 highly qualified programmers, has a deployment frequency of about 200 to 300 per day. If we adhere to a monolithic architecture in such a structure, then every programmer who joins the team will slow down the process. In the end, this will lead to the continuous decline in the contribution of individual specialists. To prevent this, you should use a microservices architecture built on Application Programming Interface (API) technology.
The API allows you, for instance, to embed certain elements from social networks on the website page. Recall, for example, embedded Twitter or Facebook posts on third-party websites: this is a clear demonstration of the use of application programming interfaces. Another example is bots in messengers that notify you of incoming emails. And how do we comment on publications on websites via social networks? All this is due to the API, which is firmly established in microservices.
The essence of this approach is to split the app into multiple separate services. Thus you can significantly improve the quality and speed of introducing new features in large companies. From a practical standpoint, the microservices architecture allows development teams to design and test multiple projects at once. Ultimately we obtain a service where all components are in sync with each other.
Another advantage is the ability to increase accessibility and work on fault tolerance. For example, if a monolithic application fails, it will stop working completely. With the microservices architecture, only individual components can break, and they will not impact other structures. A neobank customer can use the app even if one of the functions fails.
Organic growth plays the key role.
Examples of companies using a microservices architecture that have evolved from those that implemented a monolithic architecture are not far to seek. Let’s go through the most remarkable ones:
1.Netflix is one of the first and most talked about users of microservices. The company embarked on a technology path back in 2009, when no one was talking about microservices yet. They just went ahead and set up their architecture on Amazon Web Services (AWS). Their transformation has been slow but steady. First of all, they migrated video encoding and other non-customer applications. Then they separated elements that customers interacted with, such as account creation, film selection, device selection, and configuration. It took about 2 years to split the monolithic architecture into microservices.
2.Uber is the company that began its journey with the creation of one application to solve a problem in one particular city. Of course, it was also built on a monolithic architecture. However, integration issues that arose during its active expansion forced Uber to transform its global IT system into microservices.
3.Before switching to microservices, Etsy began to experience significant performance issues on a monolithic architecture. The obvious reason for that was rapid growth. The engineering team tried to figure out how to reduce server processing time while dealing with concurrent API calls, which is not easily resolved in their Hypertext Preprocessor (PHP). At the same time, they had to constantly develop new features, mobile apps and everything that the platform required during its expansion. To put an end to these troubles, the Etsy team decided to redesign their platform and set up an API as a key component available to developers. The developers, in turn, created a two-tier API using meta endpoints (similar to the template used by Netflix).
The question remains whether these success stories apply to the neobanking industry.
I think that these success stories can be perfectly applied to the neobanking industry. Of course, the specifics are slightly different: we have assistant services on the one hand and the banking system on the other hand. However, these differences are relative. Nothing prevents the implementation of a microservices architecture in startups that have overcome the early stage. At the same time, I am totally against the creation of a microservices architecture in startups that are still in this stage. This is a major mistake like the construction of a spaceship that will never take off. There should be a technological continuity: at first something simple and then more and more complex. An important task of any successful company is to build capacity.
Neobanks have no blockers to evolution into microservices. There are a large number of startups that do not need it yet. But they will get there eventually.
Thus Revolut switched from a monolith to microservices in their time. Tinkoff has also taken this path with everyday releases as part of the TRUNC approach. There are companies that are directly built on microservices. Yandex Bank proved to be the best in this business.
Now we see a large number of startups that have not reached the scaling stage yet and do not think about splitting their monolith into microservices. However, the hybrid architecture and smooth transition approach is not limited to the industry. Any company can employ it.
I shall note that when you employ a hybrid approach, you should take it slow and keep the core of banking functions in the monolithic part. Only new functionality and secondary things should be switched to microservices. This will allow you to avoid critical mistakes in financial management.
Chameleons flooded the market.
Many companies, and even the vast majority of them on the market by my count, do not hesitate to declare that they have built a microservices architecture on their own. But it is not true!
Many IT teams think that if they use tools like Docker and Kubernetes, and cloud solutions such as AWS, Microsoft Azure, Google Cloud, then they have created a microservices architecture. I consider this a big misconception. The evidence is not long in coming. When such chameleon companies are joined by a team with a real tech stack that does not match the existing stacks, integration may take a few weeks or even months.
We have to deal with a microservices architecture in name only. In real practice, it cannot integrate different teams.
To sum up, I should note that a microservices architecture has a great impact on neobanks and the fintech industry in general. Large neobanks working with microservices rapidly join other successful teams with their technology. This is how even more interesting features appear.
By the way, teams that have little, if anything, to do with the neobank structure and come from other industries may join microservices companies. The future of microservices lies in bringing together teams that could not collaborate before, when the monolithic approach was employed. This suggests a forthcoming reinterpretation of the features in the future.
I believe that startups that have overcome the early stage can be ranked as strong businesses. So, if they switch to a microservices architecture, it gives them a strong edge over those companies that stick to a monolithic architecture even after they overcome their early stage. I think that the position of the latter is quite insecure as they will eventually bump into the glass ceiling. Yes, they will have a large number of developers, but the contribution of one of them will definitely decline in value. If the share of one employee decreases in an IT company where everything depends on a solid team, the features cease to be flexible and respond poorly to market changes. The company will gradually become vulnerable, and as a result, it will be an excellent target for stronger players. The fate of the monoliths is to be merged.
