Category: AWS

bookmark_borderAWS-Edu1

Posted on by Jay Jo

Main Topic: Modern application & Micro Service Architecture

  • What is a modern application for?
  • Where to Start?
  • What is the best way to build a modern application?
  • Open to whom?
  • Decoupled & Purpose Built-Data Management
  • MicroServices
  • Coupling
  • Microservices are Not the Goal
  • Migration Patterns
  • Strangler fig
  • Database Decomposition Patterns
  • Strangler pattern strategy with AWS
  • Key points
  • Domain
  • Domain-Driven Design.
  • Code as a Model
  • Microservice Architecture Case Study.
  • Modern Application
  • 마이크로서비스 식별기준
  • 단일 DB의 맹점
  • The Advantages of Decentralized Data Stores
  • Problem: 히스토리 데이터 등 여러서 비스에서 데이터를 모두 조인하여 보여 보여줘야 한때 데이터를 어떻게 가져오는가?

What is modern application for?

  1. Scales to millions of users
  2. Global availability
  3. Response in milliseconds
  4. Handles petabytes of data
  • Modern architecture for business agility

https://pages.awscloud.com/rs/112-TZM-766/images/MAD_AWS_AAG_Microservices_5.pdf

Where to start?

  1. Wrapping the existing monolith in APIs
  2. Refactoring the monolith to microservice

What is the best way to build a modern application?

  1. Modular services – Architectural patterns [Step Functions]
  2. As serverless as possible – [Operational model]
  3. Automated, Abstracted & Standardized Developer Agility [CI/CD / GitOps modern Architecture]
  4. Programmatic Guardrails – Management & Governance

Open to whom?

  • Free for all: fast dev time, but risk to legal & app reliability (Chaos)
  • In win Guardrails: Fast time & low risk to the business
    • Monitoring (quota), Provisioning, Deployment(time window), Cost Management, Security & compliance
  • Old: Central Contol Low risk but very slow to release

Decoupled & Purpose Built-Data Management

  • Purpose-built database at AWS

Elements of Modern Application

  • Serverless service: low management

MicroServices

  1. Small independent services that communicate over well-defined APIs
  2. Independently deployable services modeled around a business domain
  3. *** Loosely coupled: Explicit, well-defined, and stable contracts between services
  4. more state machines that manage domain aggregates 1) make (cross-boundary) changes 2) organize a team (상품팀, 오더팀, 카트팀. 팀구조도 바뀜..)

Coupling

“A structure is stable if cohesion is high, and coupling is low”- Larry Constantine.

Microservices are Not the Goal.

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

Migration Patterns

  • Strangler fig
  • UI composition
  • Branch by abstraction
  • Parallel run
  • Decorating collaborator
  • Change data capture

Strangler fig

“An alternative route is to gradually create a new system around the edges of the old, letting it grow slowly over several years until the old system is strangled.”

  • step 1. Insert proxy- do noting with additional network hop
  • step 2. Migrate functionality- incremental implementation- Returns 501 not implemented
  • step 3. Redirect calls- Incremental rollout /parallel run

Database Decomposition Patterns

  • Database View
  • Wrapping service
  • DB as a service interface
  • Aggregate exposing monolith
  • Change data ownership
  • Data Synchronization
  • Tracer write
  • Split data/code first
  • Transactions
  • ….

Strangler pattern strategy with AWS

  1. Step 1: Re-host application: HA 구성
  2. Step 2: Facade with Amazon API Gateway: API endpoint.
  3. Step 3: Create AWS Lambda for top hot spot
  4. Step 4: Canary release5. Step 6: Iteratively strangulate6. Step 7: Not with a bang but a whimper
  • 점진적.

Key points

  • Incremental adoption of (microservices, technologies, practices) is key
  • Small incremental steps ensure that the mistakes we make will small and easier to recover from
  • The smaller the change, the smaller the potential negative impacts you will see, and the faster you can address them when they occur.
  • 빅뱅 후 남는 것은 빅뱅뿐이다.

Domain

  • 보안 / DevOps / Third Party Software. ETC CAST, Cloudamize, ModelizelT
  • Monolith to Microservices: Evolutionary Patterns to Transform Your Monolith: Micro Frontends in action.

Domain Driven Design.

  • Monoritic to MSA – Average Timeline 2 years 4 months

Code as a Model 잘 기술된 코드가 모델을 가장 잘 나타낸다.

Microservice Architecture Case Study.

  • Event storming
  • 시스템에 필요한 업무 흐름을 식별학고, 이들의 도메인(서비스)를 파악함으로써 차세대 시스템으로 이행을 위한 청사진.

질문 사항

*** 네~ event storming은 프로젝트 분석/요구사항 수렴 단계에 전체 시스템을 도메인이라는 개념으로 파악하고 도메인 간의 바운더리를 구분하기 위한 과정입니다. 스프린트 planning은 전체 프로젝트의 scope이 정해진 이후에 점진적으로 backlog를 정제하면서 스프린트내 해야할 일감을 정의/수행해나가는 과정이구요~

Reactive

https://miro.com/welcomeonboard/p5Ji2hsURoddthBrHte2NfUd1VWVH2339R6sGq5py2obYVNtx2OP2DWvUkjoGDHD

마이크로서비스 식별기준

  1. 마이크로서비스 전환 – Refactor or Redesign?
  2. 기능적 요건
    1. 정성적 분석 context Gravity aggregate bounded context *
    2. 정량적 분석
  3. 비기능적 요건
    1. 조직 요건
    2. DevOps

적절 한 팀의 크기: 2 Pizza Team

  1. 각각의 서비스는 단일 책임(single responsibility)
  2. 두개의 서비스가 다수의 동작에 걸쳐 빈번한 동기 통신 ..

단일 DB의 맹점.

Centralized Database

Many locks and latches

  • Undo Segment Block
  • Row Lock
  • Rede Log BufferTransaction Table.

For example 스타벅스. 30억건 (Not possible)

The Advantages of Decentralized Data Stores

  • Polyglot Persistence
  • 각 서비스는 각 서비스 성격에 맞는 data store
  • 스키마 변경시 다른서비스 낮은 영향
  • 독립적으로 확장 가능
  1. 주문서비는 여러서비스의 데이터를 수정하는데, 서비스간 데이터 일관성 유지
  2. Saga pattern.
  3. Saga orchestration (Example step Function)
  4. Message channels
  5. CQRS Pattern

문제 히스토리 데이터 등 여러 서 비스에서 데이터를 모두 조인하여 보여 보여줘야 한때 데이터를 어떻게 가져오는가?

  • 각각에 트렌젠션의 무결성
  • 비벗 트렌젝션: 페이 / 이메일.
  • Step Function 주문 backend
ANOTE.DEV