Banking Microservices Orchestration

The introduction of micro-services in cloud infrastructure yields flexible, elastic and distributed software components.The idea behind microservices architecture is to develop a single large, complex application as a suite of small, cohesive, independent services. On the other way, monolithic systems get larger over the time, deviating from the intended architecture, and becoming risky and expensive to evolve. One of the characteristics of this new promising paradigm, compared for instance to monolithic architectures, is scalability. More Services equals to more complexity. With the enhancements in the field of software-defined networking and virtualization technologies, novel networking paradigms such as network function virtualization (NFV) and the Internet of things (IoT) are rapidly gaining ground. In this work, we have given a short overview of the services within the system, how they are implemented, how they integrate and their fail-over servers on the cloud, which are important to how they are deployed.

As more organizations are placing cloud computing at the heart of their digital transformation strategy, it is important that they adopt appropriate architectures and development methodologies to leverage the full benefits of the cloud. A mere “lift and move” approach, where traditional monolith applications are moved to the cloud will not support the demands of digital services. While, monolithic applications may be easier to develop and control, they are inflexible to change and lack the scalability needed for cloud environments. Microservices architecture, which adopts some of the concepts and principles from serviceoriented architecture, provides a number of benefits when developing an enterprise application as compared to a monolithic architecture. Microservices architecture offers agility and faster development and deployment cycles, scalability of selected functionality, and the ability to develop solutions using a mixture of technologies. Microservices architecture aims to decompose a monolithic application into a set of independent services which communicate with each other through open APIs or highly scalable messaging. In short, microservices architecture is more suited for building agile and scalable cloud-based solutions. This chapter provides a practicebased view and comparison between the monolithic and microservices styles of application architecture in the context of cloud computing, and proposes a methodology for transitioning from monoliths to cloud-based microservices.

Digital transformation requires organizations to be nimble and adopt accelerated innovation methods which enable the delivery of new digital services to customers, partners and employees. To achieve this, organizations are looking towards building flexible cloud-based applications, whereby it is easier to add and update digital services as requirements and technologies change. Legacy monolithic applications might be operationally acceptable on a day-to-day basis but these applications are not well suited for building digital services. Traditional monolithic architecture and software development methods remain a stumbling block for driving digital transformation. In order to efficiently drive digital transformation, organizations are exploring a new software development methodology and architecture, “cloud-based microservices architecture”, whereby IT solutions can be organized around granular business capabilities which can be rapidly assembled to create new cloud-based digital experience applications. The “microservices” architecture is a style and method of developing software applications more quickly by building them as collections of independent, small, modular services. Organizations are currently faced with two challenges, namely; how to build new applications using a microservices architecture, and how to migrate from a monolith to a cloud-based microservices architecture. This chapter provides practical guidance and a methodical approach to address these two challenges.

A single monolith is typically composed of tens or hundreds of business functions, which are deployed together in one software release. Microservices on the other hand typically encapsulate a single business function which can be scaled separately and deployed separately. It is possible to develop a large enterprise application for cloud deployment by assembling and orchestrating a set of microservices, as an alternative to developing a monolith.

A common characteristic of all forms of monolithic application is the presence of three distinct architecture layers; the user interface layer, the business logic layer, and the database layer.  Many established banks are still relying on 1970’s mainframe technology for their core banking systems.

An atomic microservice is a fine-grained service which encapsulates the functionality and data of a single business entity such as Product. In this example, the Product service owns product data, i.e.; if any other service requires product data it must access it via the Product service interface. The Product service exposes functions or operations via its interface such as; GET product data, POST (create) new product data, PUT (update) existing product data, and DELETE product data. Atomic microservices represent the smallest reusable software modules which cannot usefully be further sub-divided or decomposed.

While adhering to the single responsibility principle comes first and foremost as a consideration, microservice boundaries should be aligned with the business value chain. The concept of a business function within the value chain is an excellent way to think about how services are partitioned but, as a concept, it is still just a starting point. In practice, some microservices may be ‘smaller’ than a specific business function within the business value chain. Others may provide lower level, crossbusiness-functionality. Does aligning with business value chains in fact detract from business agility? Not really. While some enterprises may change their fundamental service offerings, and expand or contract their business value chains, our experience suggests that the value chains themselves are quite stable. We address this issue further in the section on key ingredients for success, since these necessarily influence how (micro-)services are partitioned.

For a start, the microservices approach will not, on its own, fix a ‘broken’ organizational software delivery process. Yet the real benefits it brings – of scalability and flexibility – are eminently achievable. And, as organizations make the transition to a cloud-based infrastructure and the internet of things (IoT), structuring their application architecture using a microservices approach will indeed be a natural and logical fit.

Microservices are demonstrably capable of delivering macro benefits. Alone, they cannot make organizations work. With the correct understanding, expectations and disciplines in place however, organizations can most assuredly make microservices work for them, reaping the rewards of agility and scalability, and ultimately, profit and growth.