Beyond Monoliths: The Case for Microservices or Hexagonal Architecture

In software architecture, the days of monolithic applications ruling the roost are slowly but surely coming to an end. As modern software development faces ever-increasing complexity and demands for flexibility and scalability, architects and developers are turning to alternative architectural patterns to break free from the constraints of monolithic systems. Two such approaches gaining prominence are Microservices and Hexagonal Architecture.

In this blog, we delve deep into the realm of software architecture, exploring the advantages and considerations that come with both Microservices and Hexagonal Design.

The Monolith Problem

Traditionally, many software applications were developed as monoliths, where all the components of an application were tightly integrated into a single codebase. While monoliths have their advantages, such as simplicity in the early stages of development, they often become difficult to maintain and scale as the application grows.

This is where Microservices and Hexagonal Architecture come into play as potential solutions.

Microservices: Breaking Down the Monolith

Microservices architecture encourages breaking down your application into small, independent services that can be developed, deployed, and scaled independently. Each microservice handles a specific functionality, and communication between them usually occurs via lightweight protocols such as Json/rest or events/messaging systems.

Benefits of Microservices:

• Scalability: Microservices enable granular scaling, allowing you to allocate resources precisely where needed, resulting in improved efficiency and cost-effectiveness. 
• Flexibility: Each microservice can use the most suitable technology stack, programming language, and tools, making it adaptable to changing requirements and innovations in technology.
• Rapid Development and Deployment: Smaller, self-contained services are easier to develop, test, and deploy, resulting in faster development cycles and quicker feature delivery.
• Elasticity: Microservices are well-suited for containerization and orchestration platforms, facilitating dynamic scaling in response to varying traffic loads.
• Team Autonomy: Different development teams can own and operate individual microservices, promoting collaboration and enabling teams to choose the best approaches for their services.
• Fault Tolerance: Microservices architectures often incorporate redundancy and failover mechanisms, ensuring high availability and robustness. 

Hexagonal Architecture: A Structured Approach

Hexagonal Architecture, also known as Ports and Adapters, focuses on segregating the core business logic from external concerns like databases, user interfaces, and external services. It utilizes a hexagonal shape to visualize the flow of data and control between the core and external components. 

Benefits of Hexagonal Architecture:

• Clean Separation: Hexagonal Architecture neatly separates the core business logic from everything else, like databases, user interfaces, and external services. This makes the code easier to understand and manage.
• Flexibility: If your project's requirements change or you want to use different technologies, Hexagonal Architecture allows you to do that without having to rewrite the whole thing. It's adaptable.
• Teamwork: It's great for teamwork because different teams can work on different parts of the project without stepping on each other's toes. Everyone knows their role.
• Debugging Made Easy: If something goes wrong, it's easier to figure out where and why it went wrong because everything is organized and separated logically.
• Scalability: You can make parts of your application bigger or smaller as needed. It's like having Lego blocks that you can add or remove easily.
• Maintainability: Because everything is nicely organized and changes don't have unintended side effects, it's less of a headache to maintain your application over time. 

Choosing the Right Path

The decision to adopt Microservices or Hexagonal Architecture ultimately depends on your project's specific needs and constraints. Factors such as team expertise, project scale, and the nature of your application will play a crucial role in your choice.

If your primary concern is scaling and you have a large development team with diverse expertise, Microservices might be the right choice. On the other hand, if you prioritize maintainability, testability, and adaptability, Hexagonal Architecture could be a better fit.

Conclusion

In the era of modern software development, breaking free from monolithic constraints is essential for staying competitive and meeting evolving user demands. Whether you choose Microservices or Hexagonal Architecture or even a hybrid approach, it's clear that the days of monoliths are numbered. 

By carefully considering your project's requirements and objectives, you can make an informed decision and build software that's agile, scalable, and ready for the future.

Next-Gen Cross-Country Payment Platform: Blockchain-Powered International Payments

In today's interconnected world, cross-border transactions are essential for international trade, remittances, and financial interactions. Current payment platforms evolved decades ago and continue using the same old-fashioned method often suffer from inefficiencies, high costs, and delays; leaving individuals and businesses longing for a more efficient and cost-effective solution.

After extensive research on various technologies and solutions, I have developed a game-changing architecture, based on blockchain technology. This solution has the potential to revolutionize how we manage current cross-border payments.

In this blog, we'll explore a brief idea of implementing a blockchain-powered cross-border payment system. I have considered Amazon Managed Blockchain Service to design this solution, and it is a hyperledger-based solution.

Current Traditional Cross-Border Payments boundaries:

Before delving into the design of the new solution, it is important to understand some of the key issues associated with traditional cross-border payment systems. These problems include:

High Transaction Costs:

Conventional cross-border payment systems include numerous intermediaries like correspondent banks, which charge fees at different stages of the process. These fees can accumulate, making transactions expensive for individuals and businesses.

Slow Transaction Speed:

International transactions often require several days to complete due to the complex routing and settlement processes involving multiple banks and financial institutions. Delays can impact business operations and limit financial flexibility.

Lack of Transparency:

Traditional systems often lack transparency in terms of fees, exchange rates, and processing times. Customers might not have a clear understanding of the total cost or the status of their transaction.

Risk of Errors and Fraud:

The involvement of multiple intermediaries increases the risk of errors, discrepancies, and fraud during the transaction process. This can lead to funds being lost or delayed.

Limited Working Hours:

Traditional banking systems operate within specific business hours, leading to further delays for cross-border transactions that fall outside these hours.

Inconsistent Payment Hours:

Due to time zone differences and varying business hours, some international payments can only be processed during limited windows, leading to additional delays.

Vulnerability to Economic and Political Changes:

Economic or political changes in a country might have an impact on the stability and availability of cross-border payment services.

Why Blockchain based:

Some of my colleagues have expressed the need for blockchain technology while there are already available other options such as VISA Direct, Western Union, and Open API from Banks and questioning the necessity of this new solution. They are concerned that it may only replicate the functions of the existing alternatives. In some way It is true but if you look at proprietary solution like VISA Direct, it works only when the debit/credit card is issued with VISA, Western Union have its own limitation like limits in the transactions and it is not made for account to account transfer, Open API is a kind of proprietary solution from the individual bank that has its own facilitation issues like  authentication, authorization, and message integrity etc.,

However, the key advantages of a blockchain-based solution are decentralization, transparency, and immutability. These characteristics help to establish trust and confidence among all parties involved.

Reduced Transaction Fees:

Blockchain operates by utilizing multiple nodes. Those who become part of the network will possess their individual nodes, and the cost associated with this will be charged to their respective banks. A minimum maintenance fee will be applied by the central hosting company, which will not be dependent on transaction volume. Since there are no multiple hops involved, transaction fees can be noticeably lowered.

         Immutability:

Once data is recorded on the blockchain and confirmed by the network's consensus mechanism, it becomes part of the permanent historical record. It cannot be deleted or modified without the consensus of the majority of the network participants, which is highly unlikely in a well-established and secure blockchain network.

         Transparency: 

Every transaction on a blockchain is recorded in a transparent and immutable manner. This transparency enhances accountability, reduces the risk of fraud, and ensures that both parties have a clear view of the transaction's status.

         Decentralization:

Blockchain networks are typically decentralized, meaning that copies of the blockchain ledger are distributed across many nodes in the network. This distribution makes it extremely challenging for a single entity of group of entities to alter the data on a majority of nodes and simultaneously. 

         Security:

In a blockchain, each block contains a cryptographic hash of the previous block's data, along with its own data. This creates a chain of blocks where each block's hash depends on the data in the previous block. If even a small change is made to the data in a block, its hash will change significantly. This linkage ensures that any tampering with the data in a block will be immediately detectable.

A High-Level Logical Representation:

The diagram below showcases the logical representation of a simple fund transfer requirement. Please note that this diagram does not cover the additional checks and systems on the participant banks' side like Financial Crime protection systems like Name Screening, Transaction Screening, AML, and Fraud Management systems that notify regulatory Banks which come under the jurisdiction of the respective countries.

To put this solution into action, there needs to be a centralized organization that facilitates payment technology and acts as the primary intermediary between banks. 

Personas

Sender	The person who is sending / Transferring the money.
Sender Bank	The Bank where the Sender hold the account and initiating Fund Transfer.
ChainRemit	Blockchain based payment platform.
Beneficiary	The person who receives the money.
Beneficiary’s Bank	The Bank where the Beneficiary hold the account.

Components Layer-wise

Sender Layer
1	Mobile Banking / Internet Banking / ATM / Branch	Channel services provided by the Sender’s Bank
Sender’s Bank Layer
1	Payment System	Platform developed/owned by Sender’s Bank which caters payment transactions.
2	Reconciliation System	Reconciliation system owned by Sender’s Bank
3	Settlement System	Settlement System owned by the Sender’s Bank, which helps to settle the Correspondent’s Bank by the end of the payment cycle, it could be via traditional SWIFT payment.
ChainRemit – Blockchain Platform
1	AWS Managed Blockchain Service	Hyperledger Blockchain managed by AWS and it is owned by ChainRemit Payment Platform
2	On-Boarding Application	Microservices based application owned by ChainRemit and deployed on AWS EKS.
3	Compliant Registration & Tracking Application	Microservices based application owned by ChainRemit and deployed on AWS EKS.
4	AML	Anti Money Laundering System owned by ChainRemit Payment Platform
5	Fee Collection System	Fee Collection System to collect commission from the Banks
6	Notification Engine	Microservices based application owned by ChainRemit and deployed on AWS EKS.
Beneficiary Bank
1	Payment System	Platform developed/owned by Sender’s Bank which caters payment transactions.
2	Reconciliation System	Reconciliation system owned by Sender’s Bank
3	Settlement System	Settlement System owned by Sender’s Bank, which helps to settle the Correspondent’s Bank by end of the payment cycle, it could be via traditional SWIFT payment.
Beneficiary
1	SMS, Email	Notification Medium which is provided by Beneficiary’s Bank

Fund Transfer Flow:

Below is the Fund Transfer Flow which shows how the Banks can be integrated with BlockChain-based technology. The diagram is self-explanatory and doesn't require any further explanation. 

Challenges expected during implementation:

Blockchain operates across borders, which can make it challenging to adhere to different regulatory requirements in various jurisdictions. Determining liability and legal recourse in case of disputes or errors can be challenging in a decentralized and global blockchain ecosystem. The immutability of blockchain transactions means that incorrect or fraudulent transactions are challenging to reverse. While this is a security feature, it can also make dispute resolution more complex. Overcoming these challenges requires a combination of technical innovation, regulatory adaptation, and user education. As the technology matures and more use cases are explored, solutions to these challenges are likely to evolve as well.

Conclusion:

By harnessing the unique attributes of blockchain technology, the global payment landscape can be transformed into one that is seamless, secure, and cost-effective. As this blueprint is refined and implemented, we can stand on the cusp of a future where international payments are no longer constrained by geographical boundaries, intermediaries, or excessive costs. The journey towards blockchain-powered international payments has begun, and the destination promises a world where financial transactions unite economies, empower individuals, and reshape the very fabric of global finance.

Exploring Distributed API Gateways and BFF with Spring Cloud Gateway

Following to my previous post on the comparison between Distributed API Gateway and BFF, I received many inquiries from friends about the possibility of implementing both distributed API Gateway and BFF features together and having them in a single implementation. I have decided to create another blog post to delve into this topic in greater detail.

In the era of microservices architecture, building and maintaining scalable, performant, and secure APIs is essential. A distributed API Gateway, coupled with a Backend-for-Frontend (BFF) pattern, can empower your microservices-based applications to deliver a seamless and efficient user experience. In this blog, we will explore how to achieve this using Spring Cloud Gateway, a powerful tool in the Spring ecosystem.

Why Spring Cloud Gateway:

Spring Cloud Gateway is a lightweight and extensible API Gateway built on Spring Boot. Leveraging the range of features from Spring Cloud Gateway with BFF pattern implementation could be an excellent choice for managing microservices-based applications. Below are some of those features:

• Security: Incorporate authentication and authorization mechanisms.
• Customized Responses: Craft API responses tailored to each frontend's (Mobile App, Web App, Kiosk, ATM, etc.,) requirements.
• Aggregation: Aggregate data from multiple microservices into a single response.
• Versioning and Deprecation: Manage API versions and deprecation strategies.
• Routing and Filtering: Define routing rules and apply filters for request and response modification.
• Dynamic Configuration: Adapt to changing requirements by updating routing and filtering rules dynamically.
• WebSocket Support: Proxy WebSocket connections for real-time applications.
• Payload Dump: Integrate with pub-sub like Kafka to flush out the payload which helps for operational investigation purposes 

Understanding the Need for Distributed API Gateway + BFF in Container Orchestration Engine.

Let us explore how BFF and Distributed API Gateway take place in a Banking environment from the below diagram.

In a typical Kubernetes environment, microservice applications are deployed into multiple namespaces based on the domain. In the above diagram we can see Retail Banking microservices are deployed into the namespace called RetailBnkNS and Corporate Banking microservices are deployed to the namespace called CorporateBnkNS.

The Spring Cloud GW (BFF and distributed API GW) services are the only services exposed outside the respective namespace. So, the rest of the downstream microservices are secured and protected. All other calls to downstream microservices will route via Spring Cloud GW. 

Since Corporate bank accounting functionality is different from Retail Banking, the FundTransfer service in Corporate Banking is protected and not to be misused by any other domains.

Why not Enterprise API Gateway:

The above Spring Cloud Gateway example is the application environment for a Bank, which serves only the Bank's own customers. Furthermore, each domain has a unique authentication process like different OAuth JWT tokens, etc., just as distinct domain users should have unique authentication and authorization procedures, which is impossible with a centralized enterprise  API Gateway.

Enterprise API Gateway cannot be deployed within Kubernetes namespaces and it serves its own use cases to enable B2B service integration, Open Banking, and so on.

The Take Away:

In the world of microservices, Distributed API Gateways and Backend for Frontend services play critical roles in ensuring the efficiency, security, and maintainability of your applications. Spring Cloud Gateway, with its rich feature set and seamless integration into the Spring ecosystem, provides a powerful platform for implementing these architectural patterns.

By leveraging Spring Cloud Gateway for your API gateway needs and incorporating Backend for Frontend services into your architecture, you can create a flexible, scalable, and secure microservices ecosystem that meets the specific requirements of your clients. This combination unlocks the full potential of microservices while simplifying development and ensuring a stellar user experience.

So, if you're embarking on a journey into the world of microservices and distributed systems, consider Spring Cloud Gateway as your trusted companion for building robust API gateways and Backend for Frontend services that will help your applications thrive in the modern cloud-native landscape.