devHọc Dev
Bài học

Tuần 10 - Ngày 1: Modernization Patterns

Tuần 10 – Ngày 1

Mục tiêu học tập

  • Hiểu modernization spectrum (VMs → managed services → containers → serverless) và trade-off
  • Nắm Strangler Fig pattern để tách monolith an toàn
  • Biết kiến trúc microservices/event-driven trên AWS và các pattern Gen AI (Bedrock, RAG)

1. Modernization Paths

┌─────────────────────────────────────────────────────────┐│MODERNIZATIONSPECTRUM││││Lift&Shift──────────────────────►Cloud-Native││││┌──────────┐┌──────────┐┌──────────┐┌──────────┐│││EC2││Managed││Containers││Serverless││││(VMs)││Services││(ECS/EKS)││(Lambda)│││└──────────┘└──────────┘└──────────┘└──────────┘││││LessChange───────────────────────MoreChange││LowerBenefit──────────────────────HigherBenefit│└─────────────────────────────────────────────────────────┘

2. Strangler Fig Pattern

┌─────────────────────────────────────────────────────────┐│STRANGLERFIGPATTERN││││Phase1:Facadeinfrontofmonolith││┌───────────┐┌───────────────────────┐│││Facade│────►│Monolith││││(ALB)│└───────────────────────┘││└───────────┘││││Phase2:Extractservicesgradually││┌───────────┐┌───────────────────────┐│││Facade│────►│Monolith(shrinking)││││(ALB)│└───────────────────────┘││││────►┌───────────┐│││││ServiceA│(newmicroservice)││└───────────┘└───────────┘││││Phase3:Completemigration││┌───────────┐┌───────────┐│││Facade│────►│ServiceA││││(ALB)│────►│ServiceB│││││────►│ServiceC│││└───────────┘└───────────┘│└─────────────────────────────────────────────────────────┘

3. Microservices on AWS

┌─────────────────────────────────────────────────────────┐│MICROSERVICESARCHITECTURE││││┌────────────┐│││APIGateway│││└─────┬──────┘│││││┌──────────────────┼──────────────────┐││▼▼▼││┌─────────┐┌─────────┐┌─────────┐│││ServiceA││ServiceB││ServiceC││││(ECS)││(Lambda)││(EKS)│││└────┬────┘└────┬────┘└────┬────┘│││││││▼▼▼││┌─────────┐┌─────────┐┌─────────┐│││DynamoDB││RDS││S3│││└─────────┘└─────────┘└─────────┘││││Communication:││-Sync:APIGateway,ALB││-Async:SQS,SNS,EventBridge││-ServiceMesh:AppMesh│└─────────────────────────────────────────────────────────┘

4. Event-Driven Architecture

┌─────────────────────────────────────────────────────────┐│EVENT-DRIVENPATTERNS││││Publisher──►EventBridge──►Subscribers││││Benefits:││-Loosecoupling││-Scalability││-Flexibility││││Components:││-EventBridge(eventbus)││-SNS(pub/sub)││-SQS(queue)││-Kinesis(streaming)│└─────────────────────────────────────────────────────────┘

5. Amazon MQ — Re-platform Messaging

Managed message broker cho Apache ActiveMQ và RabbitMQ. Đây là lựa chọn re-platform cho messaging: app on-prem đang dùng message broker với protocol chuẩn công nghiệp — JMS, AMQP 0-9-1, MQTT, OpenWire, STOMP — migrate lên cloud mà không sửa code ứng dụng, chỉ đổi connection endpoint sang broker của Amazon MQ.

┌─────────────────────────────────────────────────────────────┐│AMAZONMQ—MIGRATEWITHOUTCODECHANGE││││On-premAWS││┌──────────┐JMS/AMQP/MQTT┌─────────────────────┐│││App│───────────────►│AmazonMQbroker││││(không│(protocolgiữ│(ActiveMQ/RabbitMQ││││đổicode)│nguyên)│trongVPC)│││└──────────┘└─────────────────────┘││││HAoptions:││-ActiveMQ:active/standbymulti-AZ,sharedstorage││trênAmazonEFS→failovertựđộng,messagekhôngmất││-RabbitMQ:clusterdeployment3nodestrải3AZ│└─────────────────────────────────────────────────────────────┘

Amazon MQ vs SQS/SNS

Tiêu chíAmazon MQSQS/SNS
ProtocolJMS, AMQP 0-9-1, MQTT, OpenWire, STOMP (chuẩn công nghiệp)API riêng của AWS (HTTPS)
Migrate app cũKhông cần sửa codePhải rewrite messaging layer
Throughput/scaleGiới hạn theo instance size của brokerCloud-native, scale gần như vô hạn
NetworkChạy trong VPC (endpoint riêng)Public endpoint (hỗ trợ VPC endpoint)
AuthUsername/password của broker (+ LDAP với ActiveMQ)IAM policies
Operational overheadVẫn phải chọn instance size, quản lý broker configThấp nhất (fully serverless)
Use caseApp cũ dùng ActiveMQ/RabbitMQ/protocol chuẩnApp mới build trên AWS

Nguyên tắc chọn cho exam: app mới → luôn ưu tiên SQS/SNS (scale tốt hơn, rẻ hơn, ít vận hành hơn); app hiện có đang dùng messaging protocol chuẩn và yêu cầu "migrate messaging without rewriting application code" → Amazon MQ. Nếu đề bài cho phép sửa code và nhấn "unlimited scale" / "least operational overhead" thì SQS/SNS mới là đáp án — đừng chọn MQ chỉ vì thấy chữ "message broker".

8. Generative AI Modernization Patterns

AWS đẩy mạnh dịch vụ Gen AI từ 2023-2024. SAP-C02 (post-2024) bắt đầu xuất hiện scenario về kiến trúc AI-augmented application — cần nắm các lựa chọn chính.

Amazon Bedrock (managed Foundation Models)

┌──────────────────────────────────────────────────────────────┐│AMAZONBEDROCK││││FullymanagedserviceforfoundationmodelsviasingleAPI││││Availablemodels:││-AnthropicClaude(Sonnet,Opus,Haiku)││-AmazonTitan(text,embeddings,image)││-MetaLlama3││-Mistral,AI21Jurassic,Cohere,StabilityAI││││Keyfeatures:││-Serverless(noinfratomanage)││-Private—datakhôngdùngđểtrainbasemodel││-VPCendpointsupport(PrivateLink)││-IAM-basedaccess,KMSencryption││││BedrockfeaturesSAP-C02hayhỏi:││-KnowledgeBases(RAG:retrieval-augmentedgeneration)││-Agents(tooluse,multi-stepreasoning)││-Guardrails(contentfiltering,PIIredaction)││-Modelevaluation,fine-tuning,provisionedthroughput│└──────────────────────────────────────────────────────────────┘

Khi nào dùng Bedrock: cần thêm Gen AI vào application mà không muốn quản lý GPU/model serving. Multi-tenant, cross-account access qua IAM Identity Center hoặc resource-based policies.

Bedrock vs SageMaker JumpStart vs Self-managed

Tiêu chíBedrockSageMaker JumpStartSelf-managed (EC2/EKS)
Quản lý infraKhông (serverless)One-click deploy lên endpointToàn bộ tự quản
Customize modelFine-tuning có giới hạnFull fine-tuning, custom trainingToàn quyền
Cost modelPer tokenEndpoint + storageEC2/GPU hours
PrivacyData không leak ra base modelTrong VPC, isolatedFull control
Operational overheadThấp nhấtTrung bìnhCao nhất
Use caseProduction Gen AI app, RAG, agentCustom model, fine-tune sâuCó yêu cầu compliance đặc biệt

Pattern: RAG (Retrieval-Augmented Generation)

┌─────────────────────────────────────────────────────────────┐│RAGARCHITECTURETRÊNAWS││││Userquery│││││▼││┌──────────────┐│││App(Lambda)│││└──────┬───────┘│││1.Embedquery││▼││┌──────────────────┐│││BedrockTitan│←Embeddingsmodel│││Embeddings│││└──────┬───────────┘│││2.Vectorsearch││▼││┌──────────────────┐│││Vectorstore│←OpenSearchServerless,│││(knowledgebase)│Aurorapgvector,Neptune,S3││└──────┬───────────┘│││3.Retrievedcontext+query││▼││┌──────────────────┐│││BedrockClaude/│←LLMgeneratesanswerusingcontext│││Llama/Titan│││└──────┬───────────┘│││4.Generatedresponse││▼││User││││Managedoption:BedrockKnowledgeBasestựđộnghoá││toànbộpipelineembed/store/retrieve.│└─────────────────────────────────────────────────────────────┘

Các dịch vụ AI/ML khác SAP-C02 hay hỏi

  • SageMaker: end-to-end ML platform (train, deploy, monitor models)
  • SageMaker JumpStart: pre-trained models + solution templates
  • Comprehend: NLP (sentiment, entity recognition, language detection)
  • Textract: OCR + form/table extraction
  • Rekognition: image/video analysis (faces, objects, moderation)
  • Transcribe / Polly: speech-to-text / text-to-speech
  • Translate: real-time translation
  • Lex: build chatbot/voice bot với ASR + NLU (intents/slots — cùng công nghệ Alexa); tích hợp Amazon Connect để tự động hoá contact center
  • Kendra: enterprise search bằng ML trên tài liệu nội bộ (connectors: S3, SharePoint, Salesforce...), trả lời câu hỏi ngôn ngữ tự nhiên; hay dùng làm retriever cho RAG với Bedrock
  • Personalize: recommendation engine (rất phù hợp với e-commerce)
  • Q Developer (formerly CodeWhisperer): AI code assistant cho IDE/CLI

Exam keyword cho Gen AI scenario

Yêu cầu trong câu hỏiService phù hợp
"Use foundation models với least operational overhead"Bedrock
"Customize model với enterprise data, không leak data"Bedrock fine-tuning hoặc Knowledge Bases
"Build chatbot với context từ internal docs"Bedrock + Knowledge Bases (RAG)
"Multi-step agent với tool use"Bedrock Agents
"Content moderation, PII redaction"Bedrock Guardrails hoặc Comprehend PII
"Train custom model từ đầu, full control"SageMaker (training jobs)
"Quick deploy pre-trained model"SageMaker JumpStart
"Automated customer service chatbot" (contact center)Lex (+ Amazon Connect)
"Natural language search across company documents"Kendra

Câu hỏi ôn tập

  1. Strangler Fig pattern hoạt động thế nào và vì sao an toàn hơn big-bang rewrite?

    Xem đáp án

    Đặt facade (ALB/API Gateway) trước monolith, rồi tách dần từng chức năng thành service mới — facade route path đã migrate sang service mới, phần còn lại vẫn vào monolith, đến khi monolith "bị siết" hết. An toàn hơn big-bang vì: mỗi bước nhỏ có thể rollback (đổi routing), business chạy liên tục, học được từ service đầu trước khi tách tiếp, và giảm rủi ro "rewrite 2 năm không release gì". Keyword "gradually migrate monolith with minimal risk" → Strangler Fig.

  2. Chọn sync (API) hay async (event) cho giao tiếp giữa microservices?

    Xem đáp án

    Sync (API Gateway/ALB): khi caller cần kết quả ngay (query, validate) — nhưng tạo temporal coupling, service B chết kéo A chết theo. Async (SQS/SNS/EventBridge): khi xử lý có thể trễ (order processing, notification) — loose coupling, buffer spike, retry tự nhiên; trade-off là eventual consistency và khó debug hơn (cần tracing). Nguyên tắc Professional: mặc định async giữa bounded contexts, sync chỉ trong critical read path — nhiều câu exam thưởng cho việc chèn SQS giữa 2 tier để "decouple and absorb spikes".

  3. Khi nào Bedrock Knowledge Bases là đáp án thay vì fine-tuning?

    Xem đáp án

    Knowledge Bases (RAG): kiến thức nằm trong tài liệu thay đổi thường xuyên (policy nội bộ, docs sản phẩm) — model lấy context lúc query, cập nhật chỉ cần re-index, không train lại, dữ liệu kiểm soát được (citation). Fine-tuning: cần đổi hành vi/giọng điệu/format của model hoặc domain đặc thù mà prompt + RAG không đủ — tốn kém hơn, cập nhật kiến thức chậm. Keyword "chatbot answers from internal documents, always up to date" → Knowledge Bases; "model must follow company-specific style at scale" → fine-tuning.

  4. App2Container phù hợp scenario nào trong modernization?

    Xem đáp án

    App2Container (A2C): CLI phân tích app Java/.NET đang chạy trên VM/on-prem, tự đóng gói thành container image + sinh ECS/EKS artifacts và pipeline — dùng cho bước "containerize without code changes" (giữa Rehost và Refactor). Phù hợp: legacy app không có Dockerfile, team muốn chuẩn hoá lên ECS/EKS nhanh. Không phù hợp: app cần rewrite logic (Refactor thật sự) hoặc COTS app không hỗ trợ.

  5. Công ty migrate app on-prem đang dùng ActiveMQ với JMS lên AWS, yêu cầu không sửa code ứng dụng. Chọn Amazon MQ hay SQS/SNS, và thiết kế HA thế nào?

    Xem đáp án

    Amazon MQ (ActiveMQ engine) — hỗ trợ nguyên protocol JMS/OpenWire nên app chỉ cần đổi endpoint, đúng keyword "migrate messaging without rewriting application code" (re-platform). SQS/SNS bắt buộc rewrite messaging layer sang AWS API nên loại. HA: deploy active/standby multi-AZ với shared storage trên EFS — broker standby ở AZ khác tự động takeover khi active fail, message không mất. (Với RabbitMQ engine thì HA là cluster 3 nodes trải 3 AZ.) Ngược lại, nếu là app mới hoặc đề cho phép sửa code + nhấn "unlimited scale"/"least operational overhead" → SQS/SNS.

  6. Chatbot tự phục vụ khách hàng cần trả lời từ tài liệu nội bộ: khi nào dùng Lex, khi nào dùng Kendra, khi nào kết hợp?

    Xem đáp án

    Lex = giao diện hội thoại (ASR + NLU, intents/slots): nhận yêu cầu người dùng qua voice/text, phù hợp "automated customer service chatbot", tích hợp Amazon Connect cho contact center. Kendra = ML-powered enterprise search: index tài liệu nội bộ (S3, SharePoint, Salesforce...) và trả lời câu hỏi ngôn ngữ tự nhiên — keyword "natural language search across company documents". Kết hợp: Lex nhận intent, fulfillment (Lambda) query Kendra để lấy câu trả lời từ docs; hoặc pattern hiện đại hơn là Kendra làm retriever cho RAG với Bedrock. Lex không tự tìm trong tài liệu, Kendra không tự quản hội thoại — đề hỏi cả hai vế thì đáp án là kiến trúc ghép.

Bài tập thực hành

  1. Strangler Fig mini: dựng "monolith" (1 EC2/container với route /orders và /users), đặt ALB trước; tách /users thành Lambda + target group mới, đổi listener rule để /users đi Lambda — monolith không đổi code.

  2. Event-driven decouple: thay call trực tiếp giữa 2 service demo bằng EventBridge (publisher bắn event OrderCreated, consumer Lambda xử lý); tắt consumer và verify event không mất (archive + DLQ), bật lại xử lý tiếp.

  3. RAG với Bedrock Knowledge Bases: tạo Knowledge Base từ vài file PDF trong S3 (OpenSearch Serverless auto), hỏi qua console/API và kiểm tra citation trỏ đúng tài liệu nguồn.

Tài liệu tham khảo chính thức

Ngày tiếp theo: Serverless Patterns