DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

SBOMs are essential to circumventing software supply chain attacks, and they provide visibility into various software components.

Related

  • MuleSoft: Do You Have an Extra Mule Under the Hood?
  • Monolithic First
  • The Pros and Cons of API-Led Connectivity
  • Common Performance Management Mistakes

Trending

  • Scrum Smarter, Not Louder: AI Prompts Every Developer Should Steal
  • What Is Plagiarism? How to Avoid It and Cite Sources
  • Microservices for Machine Learning
  • The QA Paradox: To Save Artificial Intelligence, We Must Stop Blindly Trusting Data—And Start Trusting Human Judgment
  1. DZone
  2. Software Design and Architecture
  3. Microservices
  4. Decision Support Matrix for Microservice Architecture

Decision Support Matrix for Microservice Architecture

This guide will help you decide if you need to convert your monolith to microservices and plan how to design your new software architecture.

By 
Onur Taner user avatar
Onur Taner
·
May. 10, 18 · Tutorial
Likes (8)
Comment
Save
Tweet
Share
7.3K Views

Join the DZone community and get the full member experience.

Join For Free

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.

N/A

PARTIAL

APPLICABLE

Application Technology Diversity

0

10

15

Technology Architecture & Flexibility

0

10

15

Measurement & Monitoring

0

10

15

Security

0

10

15

Team Competencies & Responsibilities

0

10

10

Size & Scope

0

5

10

Change Frequency & Dependency

0

15

20


  • 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.
microservice Architecture application Matrix (protocol)

Opinions expressed by DZone contributors are their own.

Related

  • MuleSoft: Do You Have an Extra Mule Under the Hood?
  • Monolithic First
  • The Pros and Cons of API-Led Connectivity
  • Common Performance Management Mistakes

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • [email protected]

Let's be friends: