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

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

A

B

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?

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

Strangler Fig Application Pattern

Decomposing the Database

• Shared Database
• Database View
• Database-as-a-Service Interface
• Aggregate Exposing Monolith
• Change Data Ownership

Decomposing the Database

• Shared Database
• Database View
• Database-as-a-Service Interface
• Aggregate Exposing Monolith
• Change Data Ownership

Decomposing the Database

• Shared Database
• Database View
• Database-as-a-Service Interface
• Aggregate Exposing Monolith
• Change Data Ownership

Decomposing the Database

• Shared Database
• Database View
• Database-as-a-Service Interface
• Aggregate Exposing Monolith
• Change Data Ownership

Decomposing the Database

• Shared Database
• Database View
• Database-as-a-Service Interface
• Aggregate Exposing Monolith
• Change Data Ownership

Data Synchronization

Pattern Synchronize Data in Application

Data Synchronization

Pattern Tracer Write

Data Synchronization

Pattern Monolith as data access layer

Data Synchronization

Pattern Multischema storage

Data Synchronization

Pattern Split Table

Data Synchronization

Pattern Move Foreign-Key Relationship to Code

Data Synchronization

Pattern Move Foreign-Key Relationship to Code

Static Data

- we can duplicate data

- we can move data to package

Transactions

Two-Phase Commits

Transactions

Sagas

Communication

Event-driven communication

Sync communication

Apache Kafka

Text

More services, more pain

Thanks

Andrii Chykharivskyi