How microservices are used

This section provides you the guidance when you can implement a solution as a microservice.

Business Benefits

A key business benefit stems from the independently deployable characteristic and allows a business capability to be deployed, upgraded and tested in isolation. As the services are loosely coupled, the impact on other services is negligible. This improves business agility and speed of change. As each service scales independently and it can be architected for specific use cases, the scalability and efficiency of a microservice is better than other implementation options.

Such encapsulation improves modularity and leads to a clean separation of concerns. The SDLC is simplified as that the separate teams need only concern themselves with API contracts, and not implementation details.

Business Functions of Microservices

The business functions of microservice are given below:

Microservice acts as a highly available and performant proxy to a downstream system. Although these services could offer CRUD operations through APIs, data stream provides and ingestes the data. Such services are consumed by Infinity. Examples are Holdings (contains transaction and balance information) Party (contains customer information)

Microservice offers operations through APIs and implements the business logic in entirety. Examples are Traceability (implements the tamper evident log used by Non-Repudiation) Call Back Registry (implements a registry of call backs used by the API framework)

A business capability requires the combination of these two approaches. The Marketing Catalog acts as a highly available proxy to a core banking product catalog, and also includes marketing data mastered in the service itself.

When can you implement a microservice

Microservice is not a solution if:

• It introduces a cross cutting concern, that is, across products (such as traceability) or is refactoring a business capability that exists in multiple products (such as secure messaging or access control)
• It introduces an entirely new business capability
• It’s performance is sensitive so that the data model and query model can be optimized for the specific business capability

When not to implement a microservice

• The business that changes to existing business capabilities are not good candidates for microservices, unless a major refactoring exercise is considered.
• If the business capability is product specific, then needlessly distributing the business capability is likely to negatively impact both the complexity and performance of the solution.

Organisation Impact

Each microservice must be owned by a distinct team, and it should have its own deployment and delivery pipeline.

Restrictions

• Java is the only run-time supported for Temenos microservices.
• All jdbc complaints RDBMS are supported.
• Selected NoSQL data models are supported for both on premise and cloud deployments.
• Other data storage paradigms such as graph should be considered on request.