Decision Support Matrix for Microservice Architecture

The main purpose of this document is to provide a decision-support mechanism to decision-makers at the point where there is or is not a real need for the conversion of monolithic applications into microservice architecture.

According to the requirement-based acquisition principle, evaluation of architectural transformations is appropriate when there is a sufficient need. There is no prejudice for any architectural pattern within the scope of the document. If the decision is an end-to-end conversion to a microservice-based application architecture, the advantages and disadvantages of the target architecture must be further evaluated.

Application Technology Diversity

Microservice architecture-based application development can be suitable when the use of different technologies in different layers of the application provides a cost advantage, increase in expertise, speed, and quality advantage. It may also be suitable if rapid adaptation to rapidly changing software development technologies is critical and if isolation of technologies is important; for example:

• If it is more appropriate to use Ruby on the web fronts of the application, but Java technologies on the business logic layer where more complex calculations are made.

• If applications need to be supported by different technologies at the data layer level (Oracle RDBMS and MySQL together, etc.).

Technology Architecture Flexibility

Microservice architecture can be suitable when different functions within the scope of the application need to be supported at different levels of importance at the level of technology architecture; for example:

• Depending on the intensive use of some functionalities provided by the application, there may be a need to support only a specific portion of the application with a more specialized technology architecture to gain cost advantage and performance.

Measurement & Monitoring

Microservice architecture can be suitable when the capabilities/functions within the application need to be tracked separately in terms of usage, customer experience, charging figures, etc.

Security

Different security needs may arise in different layers due to the critical data sets that the applications contain. In such cases, it is risky to fully access the critical database directly through the code blocks on the open servers on the internet.  To handle this issue, Data Access Code Blocks should be placed on internal servers and data access should be provided after applying security rules. Likewise, some of the functions within the scope of the application need to be authorized and submitted in smaller groups.

In such cases, microservice architecture can be suitable.

Team Competencies & Responsibilities

Microservice architecture can be suitable when the responsibilities of developers within the same team are vertically distributed among application layers such as presentation, business, and data access. For example:

• Some of the developers only deal with the data presentation, and some others deal with business logic.
• If developers who are working on the same application are frequently working independently at different locations.
• If there is a code level encapsulation, it means only a specific set of developers deal with critical code blocks.
• If the development team is familiar with distributed programming practices.

Size & Scope

As a good practice, a microservice should cover a specific business capability. It is necessary for microservices to be independent and autonomous. Microservice architecture can be suitable if

• The size of the application and its dependency on other applications make it difficult to use and configure some common software components.

• The size of the application directly affects time-to-market period in terms of development duration.

Change Frequency & Dependency

Microservice architecture can be suitable if

• The services offered within the application vary frequently depending on the requirements.

• Different versions of services need to be maintained for different customers.

• Different rules need to be executed for different clients.

• There is a need for services to be designed and released independently.

• If your Result Score is 60 or higher, microservice-architecture based development can be suitable. 
• In all cases, the advantages and disadvantages of the target architecture must be further elaborated and evaluated.