Financial services is on the cusp of becoming an integral part of the API Economy. Market forces — both disruptive in terms of new offerings from FinTech and regulatory in the form of anti-competitive legislation — are resulting in an increasing number of financial service providers offering APIs. The ability to deliver in the API Economy naturally means that banking organizations will need to adapt or change their architectures to support this new role of API provider.

“[Nordic APIs] provided an enormous amount of value relative to the investment, both in terms of cost and time.” – Eyal Sivan, CIBC

We consulted CIBC on their microservices framework.

Nordic APIs recently worked with one such organization — the Canadian Imperial Bank of Commerce (CIBC) — who are setting out on their own microservices journey in order to decompose the existing monolithic backends. One feature of this journey is a microservices framework Light 4J, that CIBC chose to build themselves. They’ve assembled it from open source components and are building where it makes sense – versus trying to customize a commercial offering. Nordic APIs was tasked to review its features and functionality to both validate their progress and offer constructive feedback.

In this post we look at CIBC’s rationale in creating their own microservices framework and how this might give CIBC advantages for the future.

Why Adopt Microservices?

For any organization reengineering their existing monolithic applications, microservices is becoming a straightforward choice. Given the advantages we touched on briefly above, this architectural style offers the potential for accelerated development cycles and significant reuse opportunities. In the case of CIBC, Eyal Sivan, their Senior Director of Enterprise Architecture, outlined the benefits of a microservices approach as follows:

“The rise of mobile and the web as the dominant channels for engaging Customers has driven enormous demand for innovation throughout the Financial sector worldwide. In many cases, these new opportunities have been seized by smaller FinTechs and larger technology incumbents who increasingly encroach on what has traditionally been bank territory. Further, regulatory efforts like PSD2 and others are driving banks to open their data and make it public, often using technologies that are quite advanced and unfamiliar. All of these pressures demand a degree of speed and agility that our current technology architecture simply cannot support… CIBC determined that a microservices architecture was the best approach available today to meet our current need for agility and prepare us for what we expect to be a volatile future.”

Why Build a Microservices Framework In House?

The choice of a microservices architecture at CIBC therefore makes perfect sense. However, the rationale for creating that framework using open source parts appears less obvious, for two key reasons:

• Large retail banking organizations tend to use established vendors for their IT and software development. Creating building block technologies that are fundamental to how they operate their software applications is not typically part of their psyche.
• There are already a number of microservices building blocks in the ecosystem including microservices chassis such as Spring Boot. Using one of these microservices chassis would seem the most practical way of getting development underway.

However there were a number of clear advantages to going down the homegrown route. The advantages from Eyal’s perspective were clear:

“Our analysis of the industry determined that the market for microservices solutions is currently very volatile. There are no incumbents or clear leaders among the vendors, associated standards are relatively young and narrowly-focused, and the underlying technologies continue to evolve at a rapid pace. As a result, we determined that a ”build“ posture for our MSA framework would act as an effective hedge against this volatile market, and provide us with an opportunity to leapfrog our competitors by adding advanced features and services tailor-made for our needs.”

In the Nordic APIs review we also identified the following specific advantages in creating a homegrown microservices framework:

• It acknowledges the need for microservices in a common, repeatable development framework that can be adopted by the entire organization.
• Building a microservices framework in-house means it can develop alongside CIBC’s microservices maturity. This is critically important as it allows the organization to learn lessons and adjust their approach iteratively.
• This approach also helps to minimize technical debt by taking away the need to refactor services to run on another framework later on.

Such advantages mean CIBC is well placed to adjust and experiment with their architecture, both in terms of domain and technology. This kind of flexibility lends itself to the Evolutionary Architecture style discussed by ThoughtWorks and considered to be work hand-in-glove with a microservice architecture.

In practical terms, however there are other significant advantages to creating a homegrown microservices framework.

Deal with Cross-Cutting Concerns

In the microservices world a great deal of time is spent on discussing cross-cutting concerns and how to manage them. These are factors that sit across any application (“cutting across them”) and generally focus on the non-functional aspects of software development. Examples of cross-cutting concerns include:

In creating the Light 4J framework CIBC are implementing a standardized microservices chassis that deals with cross-cutting concerns as a key facet of the framework. The goal — and the authors of light–4j are clearly cognizant of this fact given their use of middleware — is to abstract cross-cutting concerns so they become pluggable components of the framework.

Abstracting cross-cutting concerns in this way allows them to be ignored (where applicable) during development and parameterized for execution through continuous integration and deployment. Such an approach helps ensure that they are appropriately mitigated and has the side effect of speeding up development time.

Embed Security Throughout

Security is also a good example of how the Light 4J mitigates a specific cross-cutting concern. However, it also shows how the homegrown approach has helped CIBC enforce a standardized security approach across their platform.

CIBC’s primary security standard is OAuth and is used for authorization of user access to components in the CIBC architecture. However, the Light 4J framework also uses a mechanism for secure intercommunication via the use of JSON Web Tokens (JWTs). When a new microservice is deployed a bootstrapping process ensures the microservice is seeded with a new private key so it can join the network. It leverages aspects of the JOSE suite – namely JSON Web Keys with key IDs and JSON Web Key Sets – so that as keys are added they automatically become available to the network and can be pulled from the OAuth server.

Whilst cross-cutting exists in this context – reliance on the OAuth server for resolving keys – unavailability of the OAuth service does not stop local development, start-up or serving requests from consumers that are already known to the service. This design decision means that from the security context the framework is massively scalable, automatically adding and resolving new keys as microservices roll into place.

Flexibility in API style

The homegrown approach also has advantages in introducing flexibility in the style of API that can be supported. Microservices are naturally exposed via an API, but there is a tendency in the vendor-supplied frameworks to only support one major architectural style, typically REST.

REST is of course not the only option when exposing an API. It may suit the needs of a significant portion of the developer community for an API provider to expose a GraphQL or gRPC API rather than being fixated on delivering a completely heterogeneous API offering. At the heart of being an API provider is giving the developer community what they want. Being able to do this relies on having a framework that will support exposing several API styles.

CIBC are clearly cognizant of this fact and have created GraphQL and RPC implementations in their framework. This approach gives architects and developers flexibility and choice in discerning a best fit for type of API they use to expose their microservice.

Final Thoughts

Building anything on your own in enterprise IT has its challenges. Many large corporate organizations first – and sometimes only – port of call is to their preferred supplier who they instruct to deliver their needs. In many such cases there is a significant lag between demand and supply, meaning these organizations lose first mover advantage and often get a poorer product as a result.

The move to create a microservices framework using an in-house team might be seen as a bold move in this context. However, the approach – together with a great team – allows CIBC a huge amount of choice and flexibility in how they choose to decompose their monolithic applications. Moreover, as new microservices are created and deployed they can continue to mature and refine their approach, supported by the ability to experiment with both their architecture and the services themselves. In this context CIBC are well placed to continue on both their microservices and API journey.