This document provides an overview of microservice architecture, including its key characteristics, benefits, problems, and solutions. Microservices are small, independent services that are organized around business capabilities. They communicate through APIs and can be developed and deployed independently. Benefits include scalability, flexibility, and ease of development and testing. Challenges include configuring and monitoring distributed services. Common solutions involve service discovery, load balancing, centralized logging/monitoring, and externalizing configuration. The document also discusses architectural patterns, anti-patterns, and references further resources on microservices.

1. Micro Service Architecture –
Session 1
Amin Arab
Tosan
Tir 98
https://www.linkedin.com/in/amin-arab-a653b13a/

2. • Monolithic
• Entire application are built into a single deployable archive
• Any change to a service result entire archive rebuild and redeploy
• Scaling
• More resource (Scale-Up)
• Horizontally Cluster (Scale-Out)
• Session Management (-> transaction management)
• Distribute Session (-> distributed transaction)

3. Monolithic Architecture

4. Micro Service Architecture

5. Micro Service Architecture
• Characteristics
• Benefits
• Problems
• Solutions

6. Characteristics
• Small independent service organized around business capability
• APIs expose service and its capabilities (REST , SOAP , Serializers)
• Service interact in different processes (from requester)
• Data stores are focused and specific to service
• Stateless (such as OAuth)
• Fault tolerant

7. Benefits
• Compartmentalizes business capability
• Services are loosely coupled and modular
• Highly scalable and replaceable(new version)
• Independent service management (CI/CDelivery/CDeployment)
• Supports concurrent processing
• Language agnostic (Multiple Technology Stack)
• Minimum code scope for developer
• Lightweight IDE
• Easy Refactor
• More Test ability TDD , BDD (Cucumber)

8. Benefits

9. Benefits

10. Problems
• Organizing the configuration of multiple service instances
• Routing calls to service instances
• Distributing traffic across available microservices
• Monitoring the health of microservices
• Secure across distributed services
• Service granularity and extraction

11. Solutions
• Externalize configuration in a centralize accessible repository
• Track new service instances in a service registry
• Route microservice traffic via service discovery
• Balance traffic across services with a load balancer
• Centralize cross cutting concerns such as security and service health
• DDD

12. Solutions
• ACID
• Atomicity
• Consistency
• Isolation
• Durability
• CAP Theorem
• Availability
• Consistency
• Partition Tolerance

13. Patterns

14. Patterns
• Application architecture patterns
• Monolithic architecture - architect an application as a single deployable unit
• Microservice architecture - architect an application as a collection of loosely coupled, services
• Decomposition
• Decompose by business capability - define services corresponding to business capabilities
• Decompose by subdomain - define services corresponding to DDD subdomains
• Cross cutting concerns
• Microservice chassis - a framework that handles cross-cutting concerns and simplifies the development of services
• Externalized configuration - externalize all configuration such as database location and credentials
• Reliability
• Circuit Breaker - invoke a remote service via a proxy that fails immediately when the failure rate of the remote call exceeds a threshold
• Data management
• Saga - use sagas, which a sequences of local transactions, to maintain data consistency across services
• Observability
• Log aggregation - aggregate application logs
• Exception tracking - report all exceptions to a centralized exception tracking service that aggregates and tracks exceptions and notifies
developers.
• External API
• Backend for front-end - a separate API gateway for each kind of client

15. Anti Patterns

16. Anti Patterns
• Microservices are a magic pixie dust - believing that a sprinkle of microservices will solve all of
your development problems
• Microservices as the goal - making the adoption of microservices the goal and measuring success
in terms of the number of services written
• Scattershot adoption - multiple application development teams attempt to adopt the
microservice architecture without any coordination
• Trying to fly before you can walk - attempting to adopt the microservice architecture (an
advanced technique) without (or not committing to) practicing basic software development
techniques, such as clean code, good design, and automated testing
• Focusing on Technology - focusing on technology aspects of microservices, most commonly the
deployment infrastructure, and neglecting key issues, such as service decomposition
• More the merrier - intentionally creating a very fine-grained microservice architecture
• Red Flag Law - retaining the same development process and organization structure that were
used when developing monolithic applications.

17. References
• O’Reilly Building Microservices with Spring
• http://shop.oreilly.com/product/0636920061946.do
• https://microservices.io/patterns/index.html
• https://microservices.io/microservices/antipatterns/-
/the/series/2019/06/18/microservices-adoption-antipatterns.html

18. Session 2 pre requirements
• Spring DI
• Spring REST
• Spring Boot
• Spring Profile
• Spring Security OAuth

19. Any Question ?