Displaying search results for ""

6 reasons why using microservices is the best way to experience engineering for banks

6 reasons why using microservices is the best way to experience engineering for banks

Successful digital transformation hinges on the ability to unlock the enormous business potential of customer experiences for a bank. It’s the focus on engineering superior customer experiences for banking leaders is the right step towards successful transformation.

According to Infoholic Research, the Microservice Architecture market is expected to reach $32.01 billion by 2023, growing at a CAGR of around 16.17% during the forecast period. It is not only a noticeable trend soon but also a way to grow in the years to come for the banking industry.

Let us look at how microservices will help the banks in this context.

  • Modify without fear
    Banks generally have large monolithic software architecture and are wary to quickly change the same. The bank’s architecture is mostly archaic, and the technology teams take ages to make any modifications. Microservices Enable developers to change and re-deploy software without fear of compromising the core application.
  • Zip through the release deadlines
    According to this Deloitte Insights report, 40% of North American banks and 29% of European banks’ IT budget is allocated to the new technologies. It is no surprise that new technologies will be based on a microservices architecture. With the new architecture in place, the release cycles could be decoupled and agility could be increased significantly. This means faster development to the deployment cycle.
  • On-demand growth
    The current pandemic situation has caught most of the technology owners in the banks unaware. The World Retail Banking Report 2020 (WRBR) suggests that almost 57% of the respondents prefer internet banking, which is significantly higher than the pre-COVID area.

    Microservices enable a banking operation to be scalable on-demand. For instance, if there is a high volume on internet banking, only that module could be scaled up to meet the demands, as the necessary infrastructure can easily be replicated.

  • Higher tolerance to faults
    The MCS is a fairly independent setup. It not only reduces the infrastructure’s failure footprint but also has a faster recovery rate since code is much less interdependent.

    Circuit breakers are good way to prevent the cascading failure effect between multiple microservices and also provide a default behaviour in case of failures.

  • Make applications redundant
    In 2020 and beyond, applications are going to be very code light and easy to develop and deploy. MCS architecture not only makes it easy to develop new applications in a faster and easier way, but it also makes it easy to refactor or replace them going forward.

    While designing need to make sure the components are loosely coupled and can be replaced with new tech stack with minimal changes.

  • Secure
    This latest report indicates 80% of the bank’s executives cited security as one of the obstacles of modernisation. Microservices do not only improve security since services can be isolated and a security breach does not necessarily threaten an entire application.

    Container based services should be out of public domian, use of API gateway and tools to monitor the application are best ways to keep app away from vulnerabilities. The jar files should always be looked forward to check on latest vulnerabilities (read: OWASP) and static/dynamic scanning of code is always advisable.

As banks move ahead on their modernisation journey, the microservices-based architecture will not only make the milestones achievable but will also make the journey pleasurable and less taxing.


Why Microservices is the need of the hour ?

Why Microservices is the need of the hour ?

Microservices have been the talk of the town for quite good reasons. Almost every big organizations like Google, Amazon, Netflix has adopted this architecture style. But the question arises what makes microservices the need of an hour?

Let’s go back to the traditional way when organizations used the monoliths approach and try to recall a few of the hurdles which we came across while doing development, deployment, debug, bug fixes, and scaling the application which will ultimately guide us to our quest on why we need microservices.

One of the common scenarios in today’s development world is a gradual decrease in the performance of the application with incremental usage even after adapting to microservices. This could be due to more data to fetch and process, heavy load on one the services which reduce its response time, network latency to name a few.

To make it easier for you, let’s take a closer look at how microservices are making complex processes into simple and easier ones.

Microservices: The foundation of today’s enterprise application:

According to Martin Fowler, the software guru “a microservice architecture consists of “suites of independently deployable services” organized “around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.”

In simpler terms, it means microservices architecture is easy to build, maintain, and can be broken down into small pieces if required. For instance, when your business grows then managing a single architecture can be a hassle task especially when different stakeholders are involved.

But with microservice architecture, you can easily divide the application into distinct independent services that can be easily managed by different developer teams without impacting the work of other stakeholders.

Here is another example for your understanding:

Do you remember the traditional way where there is a huge code base of a web application that serves numerous business functionalities with scattered references all over? Now to enhance any one of it, the first step is to find where all it has references, then analyze what impact it can make to current functionalities.

Not to forget for deployment, prepare instruction with all the related files. Now let’s add one more realistic scenario to it, given from the list of above files few common files have bug fixes for other business use cases.

Whereas in post-deployment let’s assume one of the bug fixes has resulted in another bug. There are two solutions to it either revert all the changes (this includes pull out the enhancement and other bug fixes as well) or fix the issue and test the entire application end to end with the outage.

But when it comes to the scaling part, since the code base is huge and the need for scaling arises for a single popular functionality, it means resources won’t be used effectively.

Now, let’s imagine the same with microservices in place.

All related functionalities and files are in one place, this reduces the effort to zeroed down the changes required and impact analysis. However, the Bug fixes file may or may not go to other files depending on the nature of functionality but certainly, it will be assured no two unrelated fixes are getting served from the same file.

I can create different builds for different fixes or enhancement as it would be less tedious this time. In advance, it’s known which file to open to debug and last but not the least scale the popular module only!

But one has to keep in mind that microservice has its own set of challenges which is constantly getting evolved in terms of design patterns, we will talk about it in some other blog.

Advantages of Microservices:

There are endless advantages of microservices that have attracted many big enterprises to adopt it. Compared to more monolithic design structures, microservices offer:

  1. Can scale up or down the services as per requirement very easily and minimum configuration.
  2. Services are responsible only for one task.
  3. Asynchronous calls, no need to wait for a response
  4. Replay or re-fire the events in case of failure as events can be stored.

Moving ahead with Microservices:

In REST way of calling a microservice from other binds the two tightly and hence the after-effects. What if it just publishes the required info and other services which needs it simply consumes.

Now a day there are many event-driven frameworks are available and make entire development very easy in terms of retry, replay, and event tracking comes out of the box. When has to understand the fact that the way application development is evolving, there will be a continues to fight whether to go for microservice architecture or leverage traditional monolithic way.

Before switching to microservices make sure to wisely evaluate what we can live within an application, its obstacles, and which technology or pattern should be used, etc.

Again, like coin has two sides, this also comes with some cons, managing transactions across services are not easy and need efforts to track it properly (further read: Saga pattern). Also, Kafka or Rabbit MQ can act as a single point of failure and before processing events sometimes they have to be stored somewhere in the database/cache which can lead to redundancy at times.

So, for smaller or mid-sized enterprises, microservices can be an easy and quick way to implement whereas the big companies with millions of users are the ones that can hugely benefit from it, as they need to ensure the uptime, scalability that the added modularity can provide.