Architecture

Architecture decisions

Andrii Chykharivskyi

Micro-architecture

Advantages:

Technology diversity (allows to use best-suited tools)
Scalability (horizontal scalability, improved resilience)
Flexibility (faster development cycles, easier updates, adaptability to business)
Fault isolation (failures in one microservice do not necessarily affect the entire application)
Team Collaboration (cross-functional team can works independently)
Continuous Delivery (independent deploying, reducing the time-to-market)
Reusability (another project can use concrete microservice)

Micro-architecture

Disadvantages:

Pricing
Requires a zero-trust policy
Complexity(monitoring, versioning, APImanagement)

Monolith architecture

Advantages:

Complexity (easy to test and debug)
Logging
Monitoring
Deploying (easier to configure deploying, reducing the time-to-market)
Pricing (mostly)

Monolith architecture

Disadvantages:

Uniformity (same technology)
Codebase (difficult to understanding, harder to support with team increasing)
Fault isolation (failures can affect the entire application)
Team Collaboration (cross-functional team should works jointly)
Continuous Delivery (not independent deploying, increasing the time-to-market)

Macro-architecture

Macroservices are large or unwieldy microservices, services from the SOA (service-oriented architecture) or partial monoliths

What are macroservices?

Macro-architecture

Advantages:

Scalability (combining of horizontal and vertical scalability)
Modularity (like in microservices)
Monitoring (easier than microservices but harder than monolith)
Data sharing (share DB across multiple functions)
Pricing (better than microservices)

Macro-architecture

Disadvantages:

More closely integrated than microservices
Deployment takes longer compared to microservices
May raise security concerns
Still susceptible to performance problems
Occasionally serves as an interim measure rather than a complete solution

Differences

Diversity

Each microservice can also be done in a different language

Some technologies are much better suited for certain tasks

For projects with a monolithic architecture, there is now a simple solution - FaaS (Function as a service)

Deploying

Migration Planning

Microservices are not the goal. You don’t “win” by having microservices. Adopting a microservice architecture should be a conscious decision, one based on rational decision-making.

What are you hoping to achieve?
Have you considered alternatives to using microservices?
How will you know if the transition is working?

Three Key Questions

Reusing

Reuse is one of the most oft-stated goals for microservice migration, and in my opinion is a poor goal in the first place

The Customer Services team needs to format a PDF in order to provide customer invoices. Another part of the system already handles PDF generation: produce PDFs for printing purposes in the warehouse for orders shipped to customers.

What to choose? Own implementation or coordinate with other people and get the changes made?

When Microservices is a bad idea?

Unclear Domain
Startups
Customer-Installed and Managed Software
Not Having a Good Reason!

Trade-Offs

Reversible and Irreversible Decisions

What to do?

Organize codebase around business domain concepts (modular monolith)
Choose migration pattern(Strangler Fig Application/UI Composition/Branch by Abstraction/Parallel Run/Decorating Collaborator)