Chào bạn! Bạn có bao giờ cảm thấy 'ngán ngẩm' với việc phải quản lý những con server lằng nhằng, cấu hình đủ thứ rồi lo lắng chuyện nâng cấp, mở rộng không? Nếu câu trả lời là 'CÓ', thì hôm nay chúng ta sẽ cùng khám phá một 'phép màu' trong thế giới công nghệ: **Serverless Computing**! Đây là một khái niệm đã thay đổi hoàn toàn cách chúng ta xây dựng các ứng dụng backend. Thay vì phải làm đủ thứ "việc vặt" đó, giờ đây bạn chỉ cần tập trung vào việc viết ra những dòng code quan trọng nhất – còn lại, 'chú' nhà cung cấp đám mây sẽ lo tất tần tật!Trong số các nền tảng serverless, bộ đôi **AWS Lambda** và **API Gateway** nổi lên như một 'cặp bài trùng' đáng tin cậy và được sử dụng rộng rãi nhất. Với sự kết hợp này, bạn có thể tạo ra những API không chỉ 'ngon, bổ, rẻ' mà còn sẵn sàng cho môi trường 'sản phẩm thật' (production-ready) và tự động mở rộng mà không cần bạn phải động tay động chân chút nào. Tuyệt vời đúng không?Loạt bài viết này sẽ 'giải mã' toàn bộ quá trình xây dựng một API serverless, từng bước một, cực kỳ dễ hiểu. Và trong **Phần 1** này, chúng ta sẽ 'nhập môn' với những kiến thức cơ bản về AWS Lambda: nó là gì, tại sao nó lại quan trọng đến thế, và làm cách nào để 'triệu hồi' hàm Lambda đầu tiên của bạn!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/serverless_concept.png' alt='Khái niệm Serverless: Phát triển mà không cần quản lý server'><h3>Tại sao chúng ta lại 'phải lòng' Serverless?</h3>Tưởng tượng mà xem, ngày xưa khi xây dựng backend, bạn sẽ phải làm đủ thứ: 'sắm sửa' server, cài đặt phần mềm, cập nhật hệ điều hành, rồi còn phải canh cánh lo lắng làm sao để hệ thống luôn 'sẵn sàng chiến đấu' (highly available). Nghe thôi đã thấy mệt rồi đúng không? Mặc dù cách làm truyền thống này vẫn 'chạy tốt', nhưng nó lại 'đeo' cho chúng ta vô số gánh nặng, làm chậm quá trình phát triển và đội chi phí lên không ít.Đấy là lúc Serverless xuất hiện như một 'vị cứu tinh'! Nó 'cuốn bay' mọi sự phức tạp đó. Bạn sẽ không cần phải bận tâm về việc có bao nhiêu server, liệu chúng có đủ mạnh không, hay phải vá lỗi hạ tầng nữa. Việc của bạn đơn giản là: **viết code, tải lên, và để AWS lo phần còn lại!**Đặc biệt, Serverless là lựa chọn 'siêu hạng' cho các trường hợp sau:<ul><li>Các startup và 'dev cô đơn' muốn triển khai sản phẩm thật nhanh chóng.</li><li>Các ứng dụng có lưu lượng truy cập 'lúc lên lúc xuống' thất thường.</li><li>Những API không cần phải chạy 'phè phỡn' 24/7 trên các server riêng biệt.</li></ul><img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/serverless_vs_traditional.png' alt='So sánh phát triển truyền thống và Serverless'><h3>AWS Lambda: 'Trái tim' của Serverless trên AWS</h3>À, vậy thì **AWS Lambda** chính là 'ngôi sao' của buổi tiệc serverless này! Nó là dịch vụ tính toán 'thần thánh' của AWS, giúp bạn biến những ý tưởng thành hiện thực mà không cần chạm vào server. Tưởng tượng Lambda như một đội quân robot siêu nhỏ, siêu hiệu quả, có thể:<ul><li>**Tiếp nhận 'mệnh lệnh' dưới dạng code:** Bạn chỉ cần 'giao' cho nó những đoạn code nhỏ (chúng ta gọi là 'hàm' – functions) để thực hiện một nhiệm vụ cụ thể.</li><li>**Chỉ hoạt động khi cần thiết:** Những 'robot' này sẽ 'ngủ đông' cho đến khi có ai đó 'gọi' chúng (trigger bởi một sự kiện). Không chạy = không tốn tiền! Quá tuyệt đúng không?</li><li>**Tự động 'nhân bản' khi đông khách:** Dù có hàng trăm, hàng nghìn yêu cầu đổ về cùng lúc, Lambda sẽ tự động 'tạo thêm' robot để xử lý hết, bạn không phải lo lắng gì cả!</li><li>**Trả tiền theo... thời gian chạy:** Bạn chỉ phải trả phí cho chính xác khoảng thời gian mà code của bạn chạy thôi. Không lãng phí một giây nào!</li></ul>Các hàm Lambda được thiết kế để 'phản ứng' với các sự kiện. Chúng có thể được kích hoạt bởi vô vàn thứ, ví dụ như:<ul><li>Có yêu cầu API đến (thông qua API Gateway – anh bạn thân của Lambda!).</li><li>Có file mới được tải lên kho lưu trữ S3.</li><li>Có sự kiện xảy ra trong cơ sở dữ liệu (qua DynamoDB streams).</li><li>Các tác vụ được lên lịch sẵn (qua CloudWatch – như một cái đồng hồ báo thức vậy).</li></ul>Với API của chúng ta, 'kẻ' chủ yếu kích hoạt Lambda chính là **API Gateway**. Nhưng trước khi chúng ta kết nối 'cặp đôi hoàn hảo' này, hãy cùng tạo ra hàm Lambda đầu tiên của mình đã nhé!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/lambda_event_driven.png' alt='Cách Lambda phản ứng với các sự kiện khác nhau'><h3>Bước 1: 'Triệu hồi' hàm Lambda đầu tiên</h3>Đừng chần chừ nữa, chúng ta cùng 'xắn tay áo' vào làm ngay thôi! Hãy mở **AWS Management Console** và tìm đến dịch vụ **Lambda** nhé.<ol><li>Nhấp vào nút **Create function** (Tạo hàm).</li><li>Chọn **Author from scratch** (Tự tạo từ đầu) – vì chúng ta là những người 'tự lực cánh sinh' mà!</li><li>Đặt tên cho hàm của bạn (ví dụ: `myFirstLambda`). Nghe có vẻ 'hoành tráng' đấy chứ!</li><li>Chọn một **runtime** (môi trường chạy code). **Python** hoặc **Node.js** là hai lựa chọn phổ biến và dễ dùng nhất.</li><li>Tạm thời cứ để mặc định phần quyền hạn (permissions) nhé.</li></ol>Sau khi hàm được tạo xong, AWS sẽ 'dâng tận tay' cho bạn một trình soạn thảo code có sẵn. Giờ thì, hãy 'thay máu' đoạn code mặc định bằng một cái gì đó thật đơn giản nhưng hiệu quả, như thế này:<pre><code class="language-python">def lambda_handler(event, context): return { "statusCode": 200, "body": "Hello from Lambda!" }</code></pre>Đoạn code 'bé tí tẹo' này có nghĩa là: mỗi khi hàm Lambda của bạn được kích hoạt, nó sẽ 'trả về' một phản hồi với trạng thái 'OK' (200) và một thông điệp siêu thân thiện: **"Hello from Lambda!"**.<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/create_lambda_function.png' alt='Các bước tạo hàm Lambda trên AWS Console'><h3>Bước 2: 'Kiểm tra hàng' – Xem thử hàm có chạy không?</h3>Trước khi 'kết nối' em Lambda của chúng ta với thế giới bên ngoài, hãy cùng 'thử sức' nó ngay trong giao diện AWS Console nhé. Dễ lắm!<ol><li>Nhấn nút **Test** (Kiểm tra) trên bảng điều khiển Lambda.</li><li>Cung cấp một **sample event** (sự kiện mẫu). Đừng lo, AWS có sẵn các mẫu để bạn dùng đó. Cứ chọn một cái bất kỳ, ví dụ `hello-world` chẳng hạn.</li><li>Chạy thử (Run test) và 'chiêm ngưỡng' kết quả! Bạn sẽ thấy một phản hồi với trạng thái **200 OK** và thông điệp **"Hello from Lambda!"**. Cảm giác thật 'phê' đúng không nào?</li></ol>Tuyệt vời! Đến đây, bạn đã thành công 'triển khai' và 'chạy thử' hàm Lambda của mình rồi đó. Tuy nhiên, nó vẫn đang 'một mình một cõi', chưa hề được 'phơi bày' ra thế giới bên ngoài. Để biến nó thành một API công khai mà ai cũng có thể truy cập, chúng ta cần 'sáp nhập' nó với **API Gateway**!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/test_lambda_function.png' alt='Màn hình kiểm tra hàm Lambda thành công'>Và đây chính là lúc 'hành trình thực sự' của chúng ta bắt đầu! Trong phần tiếp theo, chúng ta sẽ cùng 'thiết lập' API Gateway, tạo ra các 'con đường' (routes) và 'kết nối' chúng với Lambda – để bất kỳ ai cũng có thể 'gọi' hàm của bạn thông qua một endpoint REST công khai.Bạn muốn tiếp tục khám phá và xây dựng API serverless 'trong mơ' của mình không? Hãy đón đọc **Phần 2** của chuỗi bài viết này để không bỏ lỡ những bước tiếp theo siêu thú vị nhé!
Chào mừng bạn đến với phần 3 cực kỳ hấp dẫn của series bài viết về Amazon Bedrock AgentCore Gateway! Trong những phần trước, chúng ta đã cùng nhau khám phá AgentCore Gateway – một "cánh cổng thần kỳ" giúp biến các API và hàm Lambda hiện có thành những công cụ sẵn sàng cho Agent AI, mở ra khả năng truy cập thống nhất qua nhiều giao thức, bao gồm cả Model Context Protocol (MCP), và khả năng tự động khám phá công cụ trong thời gian chạy. Ở phần 2, chúng ta đã biến một REST API Gateway thành công cụ tương thích MCP. Hôm nay, chúng ta sẽ "độ" tiếp các hàm Lambda của mình để chúng cũng trở thành những "trợ thủ đắc lực" cho các AI Agent thông qua AgentCore Target! Chúng ta sẽ tiếp tục sử dụng hai hàm Lambda quen thuộc: `GetOrderByID` và `GetOrdersByCreatedDates`. Hãy cùng bắt đầu hành trình biến hóa này nhé!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/gVj3Y7o.png' alt='Sơ đồ tổng quan AgentCore Gateway và Lambda'>Bạn muốn "hô biến" các hàm AWS Lambda hiện có của mình thành công cụ MCP qua Bedrock AgentCore Gateway? Nghe có vẻ phức tạp nhưng thực ra chỉ là vài bước cấu hình thôi! Để minh họa, chúng ta sẽ tái sử dụng ứng dụng mẫu và API Gateway đã được mô tả chi tiết trong bài viết "Serverless applications with Java and Aurora DSQL - Part 1". Bạn có thể tìm thấy toàn bộ mã nguồn tại đây.Chúng ta sẽ dùng một Jupyter Notebook Python có sẵn từ kho lưu trữ GitHub chính thức của AWS (amazon-bedrock-agentcore-samples) và tùy chỉnh nó để phù hợp với yêu cầu của mình. Tôi cũng đã chia sẻ phiên bản cuối cùng của playbook này trên GitHub cá nhân của mình.Đây là kiến trúc tổng quan về cách chúng ta sẽ biến đổi các hàm AWS Lambda hiện có thành công cụ MCP sử dụng Bedrock AgentCore Gateway:<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/tY7g8Y4.png' alt='Kiến trúc biến Lambda thành công cụ MCP'>Quy trình hoạt động của Gateway để kết nối các agent của bạn với các công cụ bên ngoài bao gồm các bước sau:<ul><li><b>Tạo công cụ cho Gateway của bạn:</b> Định nghĩa các công cụ bằng schemas, bao gồm ARN của hàm Lambda, các tham số công cụ và kiểu dữ liệu của chúng.</li><li><b>Tạo một Gateway endpoint:</b> Xây dựng cổng gateway sẽ là điểm truy cập MCP với xác thực đầu vào.</li><li><b>Thêm target vào Gateway của bạn:</b> Cấu hình các target là hàm Lambda, xác định cách gateway định tuyến yêu cầu đến các công cụ cụ thể. Tất cả các hàm Lambda này sẽ trở thành một công cụ tương thích MCP và sẽ được cung cấp thông qua URL của Gateway endpoint của bạn. Cấu hình ủy quyền IAM đầu ra cho mỗi target Lambda.</li><li><b>Cập nhật mã agent của bạn:</b> Kết nối agent của bạn với Gateway endpoint để truy cập tất cả các công cụ đã cấu hình thông qua giao diện MCP thống nhất.</li></ul>Để thực hiện hướng dẫn này, bạn cần chuẩn bị:<ul><li>Jupyter Notebook (với kernel Python)</li><li>`uv` (một công cụ quản lý package Python siêu nhanh)</li><li>Thông tin đăng nhập AWS (đã cấu hình trong `.aws\credentials` là đủ)</li><li>Amazon Cognito</li></ul>Bây giờ, chúng ta sẽ cùng nhau đi từng bước qua các phần quan trọng của Python Jupyter Notebook. Để chạy được nó, bạn cũng cần tải file `agent_core_utils.py` và đặt nó cùng thư mục với notebook. Tôi đã copy file này từ kho mẫu của AWS để tiện tùy chỉnh sau này.<h3>1. Cài đặt các thư viện cần thiết</h3>Bước đầu tiên luôn là kiểm tra và cài đặt các 'nguyên liệu' cơ bản! Chúng ta sẽ kiểm tra xem `uv` đã có chưa, sau đó dùng nó để cài `botocore` và `boto3`. Đơn giản phải không nào?<h3>2. Cấu hình Môi trường</h3>Tiếp theo, chúng ta đặt biến môi trường `AWS_DEFAULT_REGION` là 'us-east-1' (tất nhiên bạn có thể chọn một region khác mà AgentCore được hỗ trợ). Nếu bạn đã cấu hình `AWS_ACCESS_KEY_ID` và `AWS_SECRET_ACCESS_KEY` trong `.aws\credentials` thì khỏi cần đặt lại nhé, các client của AWS sẽ tự động nhận diện từ đó!```pythonimport osimport agent_core_utilsos.environ['AWS_DEFAULT_REGION'] = 'us-east-1'```<h3>3. Tạo hoặc Tái sử dụng IAM Role cho AgentCore Gateway</h3>Đây là bước quan trọng để cấp quyền cho Gateway. Chúng ta sẽ dùng `agent_core_utils` để tạo một IAM role cho AgentCore Gateway, hoặc tái sử dụng role đã tạo ở phần 2. Role này sẽ cho phép Gateway thực hiện các thao tác cần thiết.<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F47m71a784rxwk1frqgyg.png' alt='IAM role và policy cho AgentCore Gateway'>```pythonimport agent_core_utilsagentcore_gateway_iam_role = agent_core_utils.create_agentcore_gateway_role("sample-lambdagateway")print("Agentcore gateway role ARN: ", agentcore_gateway_iam_role['Role']['Arn'])```Sau khi chạy bước này, IAM role và policy của bạn sẽ trông như thế này trong AWS.<h3>4. Cấu hình Amazon Cognito User Pool</h3>Để đảm bảo an toàn, chúng ta cần một cơ chế xác thực. Bước này sẽ tạo một Cognito User Pool (nếu chưa có, hoặc tái sử dụng nếu bạn đã tạo ở phần 2). Chúng ta cũng sẽ tạo hoặc lấy lại client ID và client secret cho ứng dụng machine-to-machine (M2M) của Cognito. Các thông tin này cực kỳ quan trọng để tạo ra token xác thực khi Agent muốn "nói chuyện" với Gateway.<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F7is538yqn95ue5c7lo4u.png' alt='Cognito User Pool đã cấu hình'>```pythonimport osimport boto3import requestsimport timefrom botocore.exceptions import ClientErrorREGION = os.environ['AWS_DEFAULT_REGION']USER_POOL_NAME = "sample-agentcore-gateway-pool"RESOURCE_SERVER_ID = "sample-agentcore-gateway-id"RESOURCE_SERVER_NAME = "sample-agentcore-gateway-name"CLIENT_NAME = "sample-agentcore-gateway-client"SCOPES = [ {"ScopeName": "gateway:read", "ScopeDescription": "Read access"}, {"ScopeName": "gateway:write", "ScopeDescription": "Write access"}]scopeString = f"{RESOURCE_SERVER_ID}/gateway:read {RESOURCE_SERVER_ID}/gateway:write"cognito = boto3.client("cognito-idp", region_name=REGION)print("Creating or retrieving Cognito resources...")user_pool_id = agent_core_utils.get_or_create_user_pool(cognito, USER_POOL_NAME)print(f"User Pool ID: {user_pool_id}")agent_core_utils.get_or_create_resource_server(cognito, user_pool_id, RESOURCE_SERVER_ID, RESOURCE_SERVER_NAME, SCOPES)print("Resource server ensured.")client_id, client_secret = agent_core_utils.get_or_create_m2m_client(cognito, user_pool_id, CLIENT_NAME, RESOURCE_SERVER_ID)print(f"Client ID: {client_id}")# Get discovery URLcognito_discovery_url = f'https://cognito-idp.{REGION}.amazonaws.com/{user_pool_id}/.well-known/openid-configuration'print(cognito_discovery_url)```Sau khi thực hiện, Cognito Pool của chúng ta sẽ hiển thị như hình trên trong AWS (các thông tin nhạy cảm như ARN và URL khóa ký token đã được ẩn đi).<h3>5. Tạo AgentCore Gateway</h3>Đây là trái tim của hệ thống! Chúng ta sẽ tạo một Gateway với tên `LambdaOrderGateway`, sử dụng Cognito Authorizer (không dùng CMK) dựa trên user pool đã tạo ở bước trước. Giao thức sẽ là MCP. Gateway này sẽ là điểm kết nối cho các Lambda của chúng ta.<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Frod0lhly9nuzc5ki20n0.png' alt='AgentCore Gateway đã tạo'>```pythonimport boto3gateway_client = boto3.client('bedrock-agentcore-control', region_name = os.environ['AWS_DEFAULT_REGION'])auth_config = { "customJWTAuthorizer": { "allowedClients": [client_id], # Client MUST match with the ClientId configured in Cognito. Example: 7rfbikfsm51j2fpaggacgng84g "discoveryUrl": cognito_discovery_url }}create_response = gateway_client.create_gateway(name='LambdaOrderGateway', roleArn = agentcore_gateway_iam_role['Role']['Arn'], # The IAM Role must have permissions to create/list/get/delete Gateway protocolType='MCP', authorizerType='CUSTOM_JWT', authorizerConfiguration=auth_config, description='AgentCore Gateway with AWS Lambda target type')print(create_response)gatewayID = create_response["gatewayId"]gatewayURL = create_response["gatewayUrl"]print(gatewayID)```Sau khi thực hiện bước này, AgentCore Gateway đã tạo sẽ xuất hiện như hình trên trong AWS.<h3>6. Tạo AgentCore Gateway Targets (cho từng hàm Lambda)</h3>Bây giờ là lúc kết nối các "trợ thủ" Lambda của chúng ta! Chúng ta sẽ tạo hai AgentCore Gateway Targets, mỗi target cho một hàm Lambda hiện có. Công việc này gồm hai phần chính: cấu hình target Lambda và cấu hình xác thực.<h4>6.1. Cấu hình Target Lambda cho `GetOrderByIdWithJava21Lambda`</h4>Chúng ta cần cung cấp ARN của hàm Lambda (nhớ thay bằng ARN của bạn nhé!), sau đó định nghĩa tên và mô tả của công cụ MCP. Quan trọng nhất là `inputSchema` – nơi chúng ta chỉ định các tham số đầu vào (ở đây là `id` cho order id) và đánh dấu chúng là `required` (bắt buộc).```pythonorder_by_id_lambda_target_config = { "mcp": { "lambda": { "lambdaArn": '${YourGetOrderByIdLambdaFunctionARN}', # Thay thế bằng ARN Lambda của bạn "toolSchema": { "inlinePayload": [ { "name": "get_order_by_id_tool", "description": "tool to get the order by id", "inputSchema": { "type": "object", "properties": { "id": { "type": "string" } }, "required": ["id"] } } ] } } }}```<h4>6.2. Cấu hình Target Lambda cho `GetOrdersByCreatedDatesLambda`</h4>Tương tự, với hàm `GetOrdersByCreatedDatesLambda`, chúng ta có hai tham số bắt buộc là `startDate` và `endDate`.<h4>6.3. Cấu hình Xác thực</h4>Phần này khá đơn giản, chúng ta chỉ cần đặt kiểu nhà cung cấp thông tin xác thực là `GATEWAY_IAM_ROLE`.```jsoncredential_config = [ { "credentialProviderType" : "GATEWAY_IAM_ROLE" }]```<h4>6.4. Tạo các AgentCore Targets</h4>Cuối cùng, chúng ta tạo hai AgentCore Targets bằng cách truyền cấu hình target Lambda và cấu hình xác thực đã chuẩn bị.Ví dụ cho target `GetOrderByIdLambda`:```pythonorder_by_id_targetname='GetOrderByIdLambda'response = gateway_client.create_gateway_target( gatewayIdentifier=gatewayID, name=order_by_id_targetname, description='Order by id Lambda Target', targetConfiguration=order_by_id_lambda_target_config, credentialProviderConfigurations=credential_config)```Đây là toàn bộ đoạn mã để thực thi hai target:```pythonorder_by_id_lambda_target_config = { "mcp": { "lambda": { "lambdaArn": '${YourGetOrderByIdLambdaFunctionARN}', # Thay thế bằng ARN Lambda của bạn "toolSchema": { "inlinePayload": [ { "name": "get_order_by_id_tool", "description": "tool to get the order by id", "inputSchema": { "type": "object", "properties": { "id": { "type": "string" } }, "required": ["id"] } } ] } } }}order_by_created_dates_lambda_target_config = { "mcp": { "lambda": { "lambdaArn": '${YourGetOrdersByCreatedDatesLambdaFunctionARN}', # Thay thế bằng ARN Lambda của bạn "toolSchema": { "inlinePayload": [ { "name": "get_orders_by_created_dates_tool", "description": "tool to get the order by created dates", "inputSchema": { "type": "object", "properties": { "startDate": { "type": "string" }, "endDate": { "type": "string" } }, "required": ["startDate","endDate"] } } ] } } }}credential_config = [ { "credentialProviderType" : "GATEWAY_IAM_ROLE" }]order_by_id_targetname='GetOrderByIdLambda'response = gateway_client.create_gateway_target( gatewayIdentifier=gatewayID, name=order_by_id_targetname, description='Order by id Lambda Target', targetConfiguration=order_by_id_lambda_target_config, credentialProviderConfigurations=credential_config)order_by_id_targetname='GetOrderByCreatedDatesLambda'response = gateway_client.create_gateway_target( gatewayIdentifier=gatewayID, name=order_by_id_targetname, description='Orders by created dates Lambda Target', targetConfiguration=order_by_created_dates_lambda_target_config, credentialProviderConfigurations=credential_config)```Sau khi chạy bước này, các AgentCore Gateway Targets của bạn sẽ được tạo ra như thế này:<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Frqv5n5huvkxi0s4pjwjl.png' alt='AgentCore Gateway Targets'>Và chi tiết hơn cho từng target:<ul><li>**`GetOrderByIdLambda`:**<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fkzzkc4ar46u8mna22m65.png' alt='Cấu hình GetOrderByIdLambda Target'></li><li>**`GetOrderByCreatedDatesLambda`:**<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fgp0nwfg5qgaaw10cgdt9.png' alt='Cấu hình GetOrderByCreatedDatesLambda Target'></li></ul><img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fqvw6ng37bi60q4vz9j27.png' alt='Chi tiết Target 1'><img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fx2rjjkisqa55jr05wg90.png' alt='Chi tiết Target 2'>Vậy là chúng ta đã hoàn tất việc tạo và cấu hình AgentCore Gateway! Bây giờ, hãy cùng "trò chuyện" với agent xem sao nhé.<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fy5x6q57pyxz4yaptd6rs.png' alt='Giao diện View invocation code'>Bạn có thể sao chép mã cho "Python with Requests", "MCP Python SDK", hoặc "Strands MCP Client" từ phần "View invocation code" của AgentCore Gateway.Trong trường hợp chúng ta sử dụng notebook này, nơi chúng ta dùng Strands MCP Client, bạn cần lặp lại các bước 2 (đặt AWS Region mặc định và import `agent_core_utils`) và bước 4 (lấy lại Cognito Pool hiện có để đặt các biến `client_id`, `client_secret` và `cognito_discovery_url`).Chúng ta sẽ chạy agent cục bộ và khám phá AgentCore Runtime trong một series bài viết khác. Amazon Bedrock AgentCore Runtime cung cấp một môi trường lưu trữ an toàn, không máy chủ và được xây dựng chuyên biệt để triển khai và chạy các agent hoặc công cụ AI. Đây là một ví dụ về cách triển khai Strands Agents lên Amazon Bedrock AgentCore Runtime.<h4>Lấy Token Xác thực</h4>Đầu tiên, chúng ta cần lấy token xác thực. Đây là chìa khóa để agent có thể "trò chuyện" với Gateway.```pythonimport agent_core_utilsprint("Requesting the access token from Amazon Cognito authorizer...May fail for some time till the domain name propagation completes")token_response = agent_core_utils.get_token(user_pool_id, client_id, client_secret,scopeString,REGION)token = token_response["access_token"]print("Token response:", token)```<h4>Tạo MCP Client và Agent</h4>Tiếp theo, chúng ta tạo một MCP client và một agent. Agent này sẽ sử dụng mô hình Amazon Bedrock (`us.amazon.nova-pro-v1:0` với `temperature=0.7`). Bạn có thể thử nghiệm với các cài đặt này. Strands Agent hỗ trợ tất cả các mô hình, kể cả những mô hình chạy cục bộ như Ollama. Nhưng nhớ đảm bảo rằng nếu dùng Amazon Bedrock, mô hình đó phải được kích hoạt trong Model Access nhé.Sau đó, chúng ta yêu cầu client liệt kê tất cả các công cụ (qua lệnh `client.list_tools_sync`). Đừng quên đặt `gateway_url` của AgentCore Gateway đã tạo trước đó.```pythonfrom strands import Agentimport loggingfrom strands.models import BedrockModelfrom strands.tools.mcp.mcp_client import MCPClientfrom mcp.client.streamable_http import streamablehttp_clientimport osimport requestsimport jsondef fetch_access_token(): return token;def create_streamable_http_transport(mcp_url: str, access_token: str): return streamablehttp_client(mcp_url, headers={"Authorization": f"Bearer {token}"})def get_full_tools_list(client): """ List tools w/ support for pagination """ more_tools = True tools = [] pagination_token = None while more_tools: tmp_tools = client.list_tools_sync(pagination_token=pagination_token) tools.extend(tmp_tools) if tmp_tools.pagination_token is None: more_tools = False else: more_tools = True pagination_token = tmp_tools.pagination_token return toolsdef run_agent(mcp_url: str, access_token: str): model = BedrockModel( model_id="us.amazon.nova-pro-v1:0", temperature=0.7) mcp_client = MCPClient(lambda: create_streamable_http_transport(mcp_url, access_token)) with mcp_client: tools = get_full_tools_list(mcp_client) print(f"Found the following tools: {[tool.tool_name for tool in tools]}")gateway_url = "${YOUR_Gateway_resource_URL}"run_agent(gateway_url, fetch_access_token())```Khi chạy đoạn mã này, kết quả sẽ hiển thị danh sách các công cụ mà agent đã tìm thấy:```textFound the following tools: ['GetOrderByCreatedDatesLambda_get_orders_by_created_dates_tool', 'GetOrderByIdLambda_get_order_by_id_tool']```Tuyệt vời! Agent đã nhận diện được hai hàm Lambda của chúng ta là các công cụ hợp lệ. Bây giờ, chúng ta sẽ làm tương tự như ở phần 2: "trò chuyện" với cùng hàm Lambda, nhưng lần này là trực tiếp qua AgentCore Gateway chứ không phải qua Open API.Tôi đã tạo sẵn một số đơn hàng và sản phẩm trong cơ sở dữ liệu. Giờ thì hãy tạo Strands Agent và hỏi về đơn hàng có ID là `12345` nhé!Dưới đây là đoạn mã bổ sung liên quan. Chúng ta truyền thông tin về mô hình Bedrock đã tạo và các công cụ MCP đã lấy được cho Strands Agent:```pythonwith mcp_client: tools = get_full_tools_list(mcp_client) print(f"Found the following tools: {[tool.tool_name for tool in tools]}") agent = Agent(model=model, tools=tools) agent("Give me the information about order with id 12345")```Khi chạy đoạn mã này, bạn sẽ thấy... không có gì cả! Agent bị "treo". Hãy cùng kiểm tra CloudWatch xem có chuyện gì nhé. Hàm Lambda (viết bằng Java) đã được thực thi (nghĩa là mapping hoạt động), nhưng một ngoại lệ đã được ném ra:<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fvbt022npm8mhj2fxnhx9.png' alt='Lỗi NullPointerException trong Lambda'>Lý do là `requestEvent.getPathParameters()` bị `null`, trong khi chúng ta mong đợi nó chứa tham số "id":```java@Overridepublic APIGatewayProxyResponseEvent handleRequest(APIGatewayProxyRequestEvent requestEvent, Context context) { String id = requestEvent.getPathParameters().get("id");...```Mặc dù đối tượng `APIGatewayProxyRequestEvent requestEvent` được tạo, nó lại hoàn toàn rỗng (không có thuộc tính nào được đặt: không có tham số đường dẫn, không có chuỗi truy vấn, v.v.). Vậy chuyện gì đã xảy ra? Hàm Lambda hiện có của chúng ta được kích hoạt bởi sự kiện HTTP GET của API Gateway, nhưng AgentCore Gateway không thể biết trigger nào được cấu hình (nó có thể là tất cả các trigger có thể như SQSEvent) và không thể đặt các tham số một cách chính xác.Với mong muốn tái sử dụng hoàn toàn hàm Lambda mà không cần sửa đổi, tôi đã hy vọng có một cấu hình nào đó để truyền vào trong trường hợp này (loại sự kiện là gì và đặt các thuộc tính công cụ ở đâu: dưới dạng HTTP path, query parameters, hay trong HTTP body...). Vì AgentCore hiện đang ở bản preview, tôi sẽ đề xuất loại thay đổi này trước khi ra mắt chính thức. Nhưng hiện tại, thật tiếc là tôi chưa tìm thấy cách nào để tái sử dụng hàm Lambda với một trigger cụ thể làm tham số.Điều tôi tìm thấy là định dạng đầu vào của hàm Lambda, trong đó nói rằng các tham số đầu vào sẽ được truyền vào hàm Lambda dưới dạng cặp khóa-giá trị trong một map/dictionary. Tôi cho rằng vấn đề này có thể chỉ liên quan đến một số runtime Lambda được quản lý nhất định như Java, và không liên quan đến các runtime khác như Python, nơi hàm Lambda đã nhận đối tượng sự kiện kiểu map hoặc dictionary.Vì vậy, tôi đã viết 2 hàm Lambda mới: `GetOrderById2Handler` và `GetOrdersByCreatedDates2Handler` để sử dụng `Map` trong Java làm kiểu sự kiện đầu vào cho Lambda. Các điều chỉnh cần thực hiện cho các hàm Lambda ban đầu là khá nhỏ. Đây là một ví dụ về cách nó hoạt động:```java@Overridepublic APIGatewayProxyResponseEvent handleRequest(Map<String, String> params, Context context) { String id = params.get("id"); .....```Vì vậy, hãy nhớ thay đổi ARN của các hàm Lambda sang các hàm mới này khi bạn tạo AgentCore Gateway Lambda Targets ở bước 6 nhé!Bây giờ, hãy "trò chuyện" lại với agent:```pythonwith mcp_client: tools = get_full_tools_list(mcp_client) print(f"Found the following tools: {[tool.tool_name for tool in tools]}") agent = Agent(model=model, tools=tools) agent("Give me the information about order with id 12345")```Và đây là kết quả!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F8q00quick84qtkmhgl7e.png' alt='Agent phản hồi về đơn hàng theo ID'>Tuyệt vời! Công cụ `getOrderById` đã được xác định chính xác và chúng ta đã nhận được thông tin chính xác về đơn hàng từ đầu ra của hàm Lambda.Hãy tiếp tục hỏi agent những câu hỏi khác như chúng ta đã làm ở phần 2:```pythonagent('Can you list orders created between 1 of August 2025 5am and 5 of August 2025 3am. ''Please use the following date format, for example: 2025-08-02T19:50:55')```Ở đây, chúng ta muốn lấy danh sách đơn hàng được tạo trong một khoảng thời gian cụ thể và gợi ý cho agent về định dạng ngày tháng. Hãy cùng xem kết quả:<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fqcq89m2ebyt12njyw5ss.png' alt='Agent phản hồi về đơn hàng theo ngày tạo'>Lại một lần nữa, công cụ `getOrdersByCreatedDates` đã được nhận diện chính xác và các ngày tháng đã được định dạng đúng (tôi đã kiểm tra trong log). Chúng ta đã nhận được thông tin chính xác về các đơn hàng. Tôi đã giới hạn số lượng đơn hàng trả về là 10 trong câu lệnh SQL để tiết kiệm token đầu ra. Và tôi cũng đã đặt lại timestamp tạo cho đơn hàng thành một giá trị nhất định. Nhưng câu trả lời hoàn toàn chính xác!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fpt8f9cbrz1ok9q55sirt.png' alt='Kết quả chi tiết đơn hàng theo ngày tạo'>Hãy hỏi agent thêm một câu hỏi nữa:```pythonagent('What is the total value of all these orders together?')```Câu trả lời hoàn toàn chính xác!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fbgwuquh4ewuflgbpvlc0.png' alt='Agent tính tổng giá trị đơn hàng'>Đúng vậy, agent đã tự động tính tổng giá trị của tất cả 10 đơn hàng (10*350) một cách chính xác.Thử hỏi về một đơn hàng không tồn tại xem agent xử lý thế nào nhé:```pythonagent("Give me the information about order with id 1234589090")```Chúng ta nhận được kết quả chính xác, vì hàm Lambda đã xử lý loại yêu cầu này mà không ném ra lỗi nào:<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fr5rxitmowm2gx7v7vnr3.png' alt='Agent phản hồi về đơn hàng không tồn tại'>Có một điều tôi nhận thấy, tương tự như phần I đã mô tả khi expose Open API làm target cho AgentCore Gateway, đó là trường hợp hàm Lambda gặp lỗi (ví dụ như Nullpointer exception). Trong trường hợp đó, Agent không trả về bất cứ điều gì và tiếp tục "suy nghĩ" trong nhiều phút, buộc tôi phải dừng nó. Chắc chắn vẫn còn rất nhiều điều để thử nghiệm và khám phá. Tôi sẽ dành phần này cho bạn đọc. Nhưng đây là một cái nhìn đầu tiên về chức năng của AgentCore Gateway với hàm Lambda là Target.Cuối cùng, hãy cùng xem xét một số chỉ số CloudWatch hữu ích được cung cấp cho Amazon Bedrock AgentCore Gateway:<h4>Đối với các hoạt động `ListMemory` và `InitializeMcp`:</h4><img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F23volrpjkdkakkosuvcn.png' alt='CloudWatch Metrics cho ListMemory và InitializeMcp'><h4>Đối với hoạt động `ListToolsMcp`:</h4><img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fuffj66ct5q6x6y22dcva.png' alt='CloudWatch Metrics cho ListToolsMcp'><h4>Đối với hoạt động `CallToolMcp`:</h4><img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F1wnv1ybjxe2foxa69qej.png' alt='CloudWatch Metrics cho CallToolMcp'>Trong phần này của series bài viết, chúng ta đã cùng nhau tìm hiểu cách "biến hình" hàm Lambda thành một AgentCore Target. Chúng ta đã sử dụng lại các hàm Lambda quen thuộc (`GetOrderByID` và `GetOrdersByCreatedDates`) mà ở phần 2 đã expose qua Open API thông qua API Gateway. Và đặc biệt, chúng ta đã dùng Strands MCP Client để "giao tiếp" với AgentCore Gateway endpoint này. Hy vọng bạn đã có một cái nhìn rõ nét và thú vị về cách "mở khóa" tiềm năng của Lambda với AI Agent!
Này bạn! Đội của bạn vừa tung ra một tính năng AI đỉnh cao, chưa ai có luôn! Người dùng thì đổ xô vào dùng, báo chí tưng bừng khen ngợi... rồi bỗng "RẮC!" – mọi thứ khựng lại một khoảnh khắc. Chuyện gì vậy? Hóa ra, chính cái kiến trúc serverless mà bạn chọn vì sự linh hoạt và khả năng mở rộng thần tốc, lại đang dính vào một mớ bòng bong của những vấn đề không ngờ tới: khởi động nguội (cold start) khó chịu, chi phí "trên trời" không giải thích được, và những nút thắt cổ chai mà bạn chưa từng gặp khi thử nghiệm. Chào mừng bạn đến với thế giới ngầm của việc triển khai AI Serverless – nơi hứa hẹn khả năng mở rộng mượt mà nhưng lại ẩn chứa vô vàn phức tạp mà ít ai để ý, đặc biệt là khi bạn phục vụ các mô hình AI thế hệ mới ở quy mô lớn. <img src="https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tv1t9es1d853qhyz85bx.jpg" alt="Hình ảnh kiến trúc Serverless AI gặp sự cố"> Ai mà chẳng mê cái vẻ ngoài "mở rộng dễ như ăn kẹo" của Serverless, đúng không? Các nền tảng suy luận AI Serverless như Amazon SageMaker Serverless hay Google Cloud Functions đúng là có ma lực thật! Chúng hứa hẹn khả năng tự động mở rộng (scale tự động), vận hành đơn giản, và mô hình "dùng bao nhiêu trả bấy nhiêu" siêu tiện lợi. Nghe hấp dẫn nhỉ? Thế nên mới có chuyện Gartner dự đoán đến năm 2025, một nửa khối lượng công việc AI của các doanh nghiệp lớn sẽ chạy trên kiến trúc serverless đấy. Nhưng khoan đã! Đằng sau cái vẻ hào nhoáng đó, khi "xắn tay áo" triển khai thực tế, chúng ta thường xuyên đụng phải những vấn đề mà nếu lơ là, nó có thể "giết chết" hiệu suất, làm "phình to" chi phí và kìm hãm luôn tham vọng của doanh nghiệp đó nha! Giờ thì cùng khám phá những "cái bẫy ẩn" mà các sếp công nghệ và anh em developer nhất định phải biết khi "chơi" với AI Serverless nhé! 1. **Khởi động nguội (Cold Start) – Kẻ thù thầm lặng của trải nghiệm người dùng** Bạn hình dung thế này: Serverless hoạt động kiểu "lười biếng", khi không có ai dùng thì nó... đi ngủ. Đến khi có yêu cầu, nó mới "tỉnh giấc" và khởi động. Cái khoảng thời gian từ lúc "tỉnh giấc" đến khi sẵn sàng phục vụ, đó chính là "khởi động nguội" hay *cold start*. Vấn đề là, với các mô hình AI khổng lồ (đặc biệt là mấy bạn LLM – Large Language Models như GPT ấy), việc này còn kinh khủng hơn nhiều! Có khi mất cả vài giây chỉ để tải dữ liệu mô hình và khởi động "bộ não" GPU. Thử nghĩ xem, bạn đang chat với AI mà mỗi câu trả lời phải chờ 5 giây thì có bực mình không? Hay hệ thống phát hiện gian lận mà chậm trễ vài giây thôi là "toi" rồi. Vài giây thôi mà có thể khiến người dùng bỏ đi hoặc làm gián đoạn cả quy trình kinh doanh đó nha! <img src="https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lyoe7kbz2imfvlzderhc.jpg" alt="Biểu đồ thể hiện độ trễ Cold Start"> 2. **Tài nguyên bị phân mảnh và mở rộng (scaling) không hiệu quả** Trong thế giới serverless, việc cấp phát tài nguyên vừa "bí ẩn" (bạn không thấy rõ) lại vừa "cứng nhắc". Nghe thì bảo là "tự động mở rộng" ngon lành lắm, nhưng thực tế, với những mô hình AI siêu to khổng lồ, nó lại "tạch" liền! Lý do là các mô hình lớn khó mà "cắt nhỏ" ra để nhét vừa vào từng "phiên bản" hàm serverless tí hon. Nhiều mô hình AI hiện đại "khủng" đến mức không thể vừa với dung lượng RAM hay GPU của một hàm duy nhất. Kết quả ư? Hiệu suất bấp bênh hoặc tệ hơn là không thể triển khai được luôn! 3. **Khóa chặt nhà cung cấp (Vendor Lock-In) – Cái bẫy "đi đâu cũng vướng"** Bạn cứ tưởng tượng thế này: khi bạn dùng serverless của một nhà cung cấp đám mây nào đó (như AWS Lambda hay Google Cloud Functions), bạn sẽ bị "dính chặt" vào các API (giao diện lập trình ứng dụng) riêng của họ. Điều này đồng nghĩa với việc, nếu sau này bạn muốn chuyển sang một nhà cung cấp khác, thì ôi thôi, nó cực kỳ khó khăn và tốn kém! Cứ như bạn mua điện thoại chỉ dùng được sim của một nhà mạng vậy. Đối với các doanh nghiệp lớn hay những ngành có quy định chặt chẽ, việc phải có chiến lược đa đám mây (multi-cloud) là cực kỳ quan trọng, và cái "bẫy" vendor lock-in này chính là một rủi ro chiến lược không hề nhỏ đâu nhé! <img src="https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/gK2T39H.png" alt="Hình ảnh minh họa Vendor Lock-in"> 4. **Khả năng quan sát, gỡ lỗi và vấn đề "hộp đen"** Tưởng tượng bạn đang cố sửa một chiếc xe hơi mà động cơ lại bị giấu kín trong một cái hộp đen thui, không nhìn thấy gì cả! Đó chính là cảm giác khi bạn phải gỡ lỗi các hàm serverless phân tán và "sống ngắn ngủi". Việc theo dõi xem hiệu suất bị tắc ở đâu, tìm ra lỗi hay đảm bảo tuân thủ các quy định trở nên khó hơn gấp vạn lần so với các cách triển khai truyền thống dùng máy ảo (VM) hay container. Đây là một khoản chi phí "ngầm" không nhỏ đâu nha! 5. **Chi phí bất ngờ – "Dùng bao nhiêu trả bấy nhiêu" không phải lúc nào cũng rẻ!** Nghe thì hay ho lắm chứ, "dùng bao nhiêu trả bấy nhiêu" kiểu như tiền điện nước vậy. Nhưng khoan đã! Các mô hình serverless tính phí cho *mỗi lần* được gọi, và đau nhất là nó tính cả cho cả những lần "khởi động nguội" hay những yêu cầu bị lỗi luôn! Một hệ thống được thiết kế không tối ưu có thể khiến thời gian tính toán và dung lượng lưu trữ tăng vọt. Khi mô hình AI của bạn lớn dần lên và lượng truy cập tăng vù vù, các doanh nghiệp thường thấy chi phí serverless lại "đua" theo, thậm chí còn VƯỢT XA so với các kiến trúc truyền thống, đặc biệt là khi tính thêm các công cụ theo dõi và chi phí truyền dữ liệu ra ngoài nữa. Thế nên đừng vội mừng nha! <img src="https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/g0tX8fV.png" alt="Hình ảnh hóa đơn chi phí bất ngờ"> 6. **Điều phối mô hình và sự phức tạp của "dây chuyền sản xuất" AI (Pipeline)** Việc suy luận AI từ đầu đến cuối hiếm khi chỉ là một cuộc gọi đơn giản đâu. Nó thường là cả một "dây chuyền" phức tạp, có thể bao gồm bước tiền xử lý dữ liệu, rồi nối nhiều mô hình lại với nhau (model chaining), và cuối cùng là hậu xử lý kết quả. Đôi khi, mỗi bước này lại chạy trên một hàm serverless riêng biệt. Mỗi bước bổ sung đều làm tăng độ trễ, tăng nguy cơ tắc nghẽn và khả năng "dây chuyền" bị đứt gãy giữa chừng. Đau đầu phết đấy! 7. **Tối ưu hóa phần cứng – Mê cung ẩn giấu trên đám mây** Chọn đúng loại "chip" (phần cứng) cho mô hình AI của bạn giống như lạc vào một mê cung vậy đó! Nên dùng A100 hay H100? CPU, GPU hay NPU đây? Và còn phải chọn cả công cụ suy luận (inference engine) tốt nhất cho từng loại nữa. Đây là một câu đố phức tạp và "nặng tiền" đấy nhé. Bởi vì, cái cấu hình tối ưu nhất cho hiệu suất hôm nay, có thể dễ dàng trở thành "cái hố đen" ngốn tiền của bạn vào ngày mai, khi mô hình lớn hơn và lượng truy cập thay đổi. Vậy làm thế nào để tránh những "cái bẫy" này và biến Serverless thành "siêu năng lực" thực sự? Dưới đây là vài "mẹo" hữu ích mà bạn nên bỏ túi: * **Sử dụng Đồng thời được cung cấp sẵn (Provisioned Concurrency):** Cứ như việc bạn chuẩn bị sẵn vài chiếc xe chạy nóng máy vậy! Cái này giúp các hàm của bạn luôn ở trạng thái "ấm" và sẵn sàng phục vụ, tránh được nỗi lo *cold start* khi có lượng truy cập đột biến (tất nhiên, không phải nền tảng nào cũng hỗ trợ tính năng này đâu nha). * **Kết hợp Kiến trúc lai (Hybrid Architectures):** Đừng "đặt hết trứng vào một giỏ"! Hãy dùng serverless cho những lúc lưu lượng truy cập tăng vọt không lường trước được, còn những công việc ổn định, liên tục thì cứ để các kiến trúc truyền thống hoặc container lo. Kiểu "linh hoạt lúc cần, ổn định khi thường xuyên" ấy. * **Tối ưu hóa mô hình AI của bạn:** Cứ như bạn đang "nén" file lại vậy! Hãy lượng tử hóa (quantize) và nén (compress) mô hình để chúng "nhẹ nhàng" hơn, giúp giảm thời gian khởi động nguội và tiết kiệm bộ nhớ. * **Ưu tiên Khả năng quan sát (Observability) ngay từ đầu:** Đừng đợi đến lúc "lâm trận" mới lo tìm cách nhìn vào "hộp đen". Hãy đầu tư sớm vào các công cụ theo dõi và dò lỗi mạnh mẽ, được thiết kế riêng cho môi trường serverless. * **Phân tích mẫu lưu lượng truy cập thường xuyên:** Cứ như bạn đang theo dõi báo cáo tài chính vậy! Hãy thường xuyên xem xét nhật ký các lần gọi hàm, thời gian chạy và cách hệ thống tự mở rộng. Việc này giúp bạn phát hiện ra những "cú sốc" về chi phí bất ngờ trước khi chúng kịp biến thành "thảm họa". Tóm lại là, tổ chức của bạn đã sẵn sàng để triển khai AI quy mô lớn mà không bị "sập bẫy serverless" chưa? Các chuyên gia của Cyfuture.ai có thể giúp các doanh nghiệp thiết kế những giải pháp suy luận AI bền vững, tối ưu chi phí – đảm bảo công việc kinh doanh của bạn luôn "chuẩn bị sẵn sàng" cho làn sóng AI tiếp theo. Hãy liên hệ Cyfuture.ai để được kiểm tra "sức khỏe serverless" và xem bạn có thể tăng tốc triển khai AI như thế nào – mà không cần đánh đổi quyền kiểm soát, hiệu quả hay sự minh bạch. Rõ ràng là, serverless inferencing đang thay đổi cuộc chơi triển khai AI. Nhưng những cái bẫy ẩn thì vẫn còn đó – và chỉ những ai chuẩn bị kỹ lưỡng mới là người chiến thắng cuối cùng! <img src="https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8x8j76z0ygvp4y5ij254.jpg" alt="Hình ảnh AI và gears minh họa sự chuẩn bị kỹ lưỡng">
Chào bạn! Bạn đã sẵn sàng để khám phá một cuộc cách mạng trong cách chúng ta xây dựng ứng dụng hiện đại chưa? Đó chính là sự kết hợp "đỉnh cao" giữa điện toán phi máy chủ (Serverless) và Trí tuệ Nhân tạo/Học máy (AI/ML)! Nghe có vẻ phức tạp, nhưng thực ra đây là "bí kíp" giúp các nhà phát triển và kiến trúc sư giải pháp xây dựng những ứng dụng AI/ML siêu hiệu quả, tiết kiệm chi phí và có khả năng mở rộng "vô biên" mà không cần bận tâm đến việc quản lý hạ tầng "phiền phức". Tưởng tượng mà xem, bạn muốn chạy một ứng dụng AI nhưng lại không muốn mua máy chủ, không muốn lo nghĩ về việc nó có "sập" không, hay khi có nhiều người dùng thì nó có "chịu tải" nổi không? Serverless chính là câu trả lời! Nó giống như việc bạn đi ăn buffet vậy, chỉ trả tiền cho phần bạn ăn (thời gian tính toán thực tế sử dụng), chứ không phải trả tiền thuê cả cái nhà hàng (máy chủ chạy không tải). Quá hời phải không? Đặc biệt, với mô hình "trả tiền theo dùng" siêu tiện lợi này, bạn chỉ trả đúng lượng tài nguyên AI/ML mà mình sử dụng. Bye bye chi phí "chết" cho máy chủ rảnh rỗi nhé! Tiết kiệm không tưởng, đặc biệt là với các tác vụ AI không liên tục. Khi ứng dụng AI của bạn bỗng dưng "nổi tiếng" và có hàng triệu người dùng truy cập cùng lúc, Serverless sẽ tự động "triệu hồi" thêm tài nguyên để xử lý mượt mà, không cần bạn phải động tay động chân. Cứ như có một đội quân tự động mở rộng theo nhu cầu vậy! Bạn có thể toàn tâm toàn ý tập trung vào việc tạo ra những thuật toán AI "đỉnh cao" thay vì đau đầu với việc cấu hình máy chủ. Quá trình triển khai sẽ nhanh như chớp, giúp bạn đưa sản phẩm AI ra thị trường sớm hơn bao giờ hết. Tài nguyên được sử dụng hiệu quả tối đa, chỉ hoạt động khi có tác vụ. Điều này không chỉ giúp bạn "bóp" chặt chi phí mà còn thân thiện hơn với môi trường nữa đó! Vậy Serverless AI/ML có thể làm được những gì trong thế giới thực? Rất nhiều điều thú vị đấy! Tưởng tượng bạn vừa tải một bức ảnh lên, và ngay lập tức AI đã tự động nhận diện đó là mèo, hay là bạn bè của bạn. Hay phát hiện các vật thể lạ trong video an ninh. Tất cả đều nhờ Serverless xử lý tức thì khi có dữ liệu mới. Như có "mắt thần" AI vậy!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/image_processing.png' alt='Xử lý ảnh và video thời gian thực với serverless AI'> Bạn đang nói chuyện với một chatbot thông minh đến mức nó hiểu được cảm xúc của bạn? Đó có thể là Serverless AI đang hoạt động! Nó giúp các chatbot phân tích ý định, cảm xúc của người dùng và đưa ra phản hồi nhanh chóng, mượt mà. Đảm bảo dịch vụ khách hàng "cực chất"!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/chatbot_nlp.png' alt='Chatbot sử dụng NLP và serverless'> Trong lĩnh vực tài chính, Serverless AI có thể "đánh hơi" các giao dịch gian lận ngay lập tức. Hay trong IoT, nó giúp dự đoán khi nào một thiết bị sắp hỏng để bảo trì kịp thời. Giống như một "thám tử" AI luôn trực chiến 24/7!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/predictive_analytics.png' alt='Phân tích dự đoán và phát hiện bất thường'> Thậm chí, Serverless còn có thể mang sức mạnh AI đến gần các thiết bị IoT hơn (Edge Computing). Tức là dữ liệu được xử lý ngay tại chỗ, giảm độ trễ, tiết kiệm băng thông. Ví dụ: một nhà máy thông minh có thể phản ứng tức thì với các sự cố mà không cần gửi dữ liệu về cloud. Tuyệt vời ông mặt trời!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com/uploads/articles/q74swpjsdd5nvu2ucxwa.webp' alt='Tích hợp Serverless AI và IoT tại biên'> Tuy Serverless tuyệt vời là thế, nhưng cũng có vài "chướng ngại vật" mà chúng ta cần vượt qua. Đừng lo, đều có "bí kíp" giải quyết hết! Bạn đã bao giờ bật máy tính lên và phải đợi một lúc không? Serverless functions cũng vậy, đôi khi cần thời gian để "khởi động" nếu lâu rồi không được dùng. Đây gọi là 'cold start'. Bí kíp: Dùng 'provisioned concurrency' (kiểu như luôn có sẵn vài cái máy đã "khởi động nóng" chờ bạn dùng ngay), hoặc tối ưu code thật gọn nhẹ để khởi động nhanh hơn. Ưu tiên các ngôn ngữ "nhẹ ký" như Python hay Node.js. Mỗi hàm Serverless có giới hạn về RAM, CPU và thời gian chạy. Không phải muốn bao nhiêu cũng được đâu nha! Bí kíp: Chia nhỏ tác vụ AI/ML "khổng lồ" thành nhiều phần nhỏ hơn. Dùng các cơ chế xử lý không đồng bộ (như hàng đợi tin nhắn) cho các tác vụ tốn thời gian. Chọn cấu hình bộ nhớ phù hợp – thường thì nhiều RAM cũng sẽ đi kèm với CPU mạnh hơn đó. Mô hình AI thường rất "nặng ký", việc đưa chúng vào hàm Serverless đôi khi hơi "khó nhằn". Bí kíp: Nén mô hình thật gọn gàng, chỉ lấy những gì cần thiết. Dùng container (kiểu như đóng gói cả mô hình và thư viện vào một "chiếc hộp") để dễ triển khai hơn. Luôn có "bản sao lưu" (versioning) cho hàm và mô hình để dễ dàng quay lại nếu có lỗi. Vì ứng dụng Serverless là tập hợp của nhiều hàm nhỏ, việc tìm ra lỗi có thể giống như đi tìm kim đáy bể vậy. Bí kíp: Dùng công cụ "bản đồ theo dõi" (distributed tracing) để xem luồng dữ liệu đi qua các hàm như thế nào. Tập trung tất cả "nhật ký" (logs) từ các hàm vào một chỗ để dễ dàng đọc và tìm lỗi. Mặc dù tiết kiệm, nhưng nếu không cẩn thận, chi phí vẫn có thể "bay" không kiểm soát! Bí kíp: Tinh chỉnh RAM và thời gian chạy của hàm dựa trên thử nghiệm thực tế. Đặt cảnh báo ngân sách để không bị "sốc" khi hóa đơn về. Và nhớ "dọn dẹp" thường xuyên các tài nguyên không dùng nữa nhé! Để bạn dễ hình dung, đây là một ví dụ "ảo" (conceptual) về hàm Serverless thực hiện phân tích cảm xúc văn bản bằng Python. Nó có thể được kích hoạt khi có yêu cầu từ API hoặc tin nhắn mới. ```python import json # Tưởng tượng ở đây là model AI đã được load rồi nhé! # Trong thực tế, bạn sẽ tải mô hình từ S3, Azure Blob, GCS... # và giữ nó trong bộ nhớ để tái sử dụng cho các lần gọi tiếp theo. def lambda_handler(event, context): """ Đây là một hàm AWS Lambda (tương tự Azure Functions, Google Cloud Functions) dùng để phân tích cảm xúc văn bản. Ví dụ này mang tính minh họa, trong thực tế sẽ phức tạp hơn. """ try: # Lấy dữ liệu văn bản từ yêu cầu body = json.loads(event['body']) text = body.get('text', '') if not text: return { 'statusCode': 400, 'body': json.dumps({'error': 'Bạn chưa cung cấp văn bản để phân tích!'}) } # Phần này là nơi gọi mô hình AI để xử lý # Ví dụ: result = sentiment_pipeline(text)[0] # Đây là kết quả "giả định" để minh họa result = {"label": "TÍCH CỰC", "score": 0.99} return { 'statusCode': 200, 'body': json.dumps(result) } except Exception as e: return { 'statusCode': 500, 'body': json.dumps({'error': f'Có lỗi nội bộ xảy ra: {str(e)}'}) } ``` Đoạn code trên là ý tưởng cơ bản. Đối với các mô hình AI lớn, bạn nên lưu chúng trên các dịch vụ lưu trữ đám mây (như S3 của AWS) và chỉ tải vào bộ nhớ khi cần, hoặc sử dụng tính năng container image để đóng gói cả môi trường phức tạp. Tương lai của Serverless AI/ML đang mở ra những chân trời mới, hứa hẹn các giải pháp "thông minh" và dễ tiếp cận hơn nữa! Khi Serverless và điện toán biên (Edge Computing) "kết đôi", AI sẽ đến gần dữ liệu hơn bao giờ hết, xử lý ngay tại chỗ. Giảm độ trễ, tiết kiệm băng thông và phản ứng siêu nhanh, đặc biệt cho IoT và ứng dụng di động. Các nhà cung cấp đám mây đang đầu tư mạnh vào những nền tảng ML chuyên biệt, giúp việc huấn luyện và triển khai mô hình trở nên dễ dàng hơn. Cứ như có một "phù thủy" giúp bạn làm hết mọi thứ vậy! Các công cụ hỗ trợ phát triển Serverless AI/ML ngày càng "xịn xò", giúp bạn triển khai và quản lý ứng dụng phân tán dễ dàng hơn rất nhiều. Serverless đang và sẽ tiếp tục là chìa khóa để mở khóa những khả năng AI "chưa từng có". Muốn tìm hiểu sâu hơn về tương lai này, bạn có thể nghía qua <a href="https://future-of-serverless-architectures.pages.dev/">đây nhé</a>. Tóm lại, xây dựng ứng dụng AI/ML "khủng" mà vẫn tiết kiệm chi phí với Serverless không còn là chuyện viễn tưởng nữa. Bằng cách "giao phó" gánh nặng hạ tầng cho Serverless, bạn có thể toàn tâm toàn ý tập trung vào việc tạo ra những mô hình AI "đỉnh của chóp". Dù có vài thách thức nhỏ, nhưng với sự phát triển không ngừng của công nghệ, Serverless chắc chắn sẽ đóng vai trò cực kỳ quan trọng trong việc đưa AI trở nên dễ tiếp cận và hiệu quả hơn cho mọi người!
Khám phá cách epilot nâng cấp AI với RAG để tạo ra các gợi ý email thông minh, giúp người dùng tiết kiệm thời gian và nâng cao hiệu quả giao tiếp với khách hàng.
Unpack the Serverless Paradox: learn how hybrid architectures, AI/ML for predictive warm-up, multi-cloud strategies, and abstraction layers are overcoming cold starts and vendor lock-in in modern serverless applications.
Tìm hiểu về 'Nghịch lý Serverless': Tại sao công nghệ này tiện lợi nhưng vẫn gặp phải 'cold start' và 'vendor lock-in'? Khám phá cách Kiến trúc Hybrid, AI/ML và Multi-cloud đang giải quyết những vấn đề nhức nhối này, giúp Serverless trở thành lựa chọn hoàn hảo cho phát triển ứng dụng hiện đại.
Hướng dẫn chi tiết cách xây dựng bot tạo blog tự động bằng AI và các dịch vụ serverless của AWS như Amazon Bedrock, Lambda, S3 và API Gateway. Tìm hiểu kiến trúc không máy chủ và tạo nội dung thông minh.
Bạn muốn triển khai AI/API lên AWS Lambda mà không đau đầu với Serverless? Khám phá Mastra Lambda Docker Deploy – giải pháp giúp bạn đưa ứng dụng vào sản xuất chỉ với Docker, đơn giản hóa mọi phức tạp và tăng tốc độ phát triển. Tạm biệt rắc rối, đón chào hiệu quả!
Khám phá nghịch lý Serverless: Làm thế nào kiến trúc lai và AI/ML giúp vượt qua thách thức cold start và vendor lock-in để phát triển ứng dụng hiện đại hiệu quả hơn.
Khám phá sự kết hợp đột phá giữa Generative AI (GenAI) và kiến trúc Serverless, hai yếu tố đang định hình tương lai phát triển ứng dụng thông minh. Bài viết đi sâu vào lợi ích vượt trội về chi phí và khả năng mở rộng, các trường hợp sử dụng thực tế từ tạo nội dung đến chatbot, các công cụ phổ biến (AWS Lambda, Azure Functions, Google Cloud Functions), cùng những thách thức và giải pháp khi triển khai. Nắm bắt xu hướng này để xây dựng các giải pháp thông minh, hiệu quả và đổi mới.
Thật lòng mà nói – ai trong chúng ta mà chẳng từng trải qua cảm giác đó, đúng không? Bạn đang cố gắng tìm một cái meme cực phẩm để diễn tả nỗi sợ hãi tột độ với sáng thứ Hai cà phê chưa pha, nhưng dù có gõ đủ kiểu từ khóa thì cũng chỉ toàn ra ảnh mèo không liên quan. Nào, xin giới thiệu 'tìm kiếm ngữ nghĩa' (semantic search) – công nghệ cuối cùng đã hiểu được những truy vấn tìm kiếm 'hỗn loạn' của bạn! Trong bài viết này, tôi sẽ bật mí cách tôi đã xây dựng một công cụ tìm kiếm meme mà nó thực sự 'bắt được sóng' câu chuyện, sử dụng chút 'phép thuật' công nghệ xịn sò (và những công cụ đỉnh cao của Upstash nữa đó!). Upstash không chỉ cung cấp một cơ sở dữ liệu vector (vector database) siêu xịn, cho phép bạn tìm kiếm sự tương đồng giữa các vector một cách cực kỳ linh hoạt và mở rộng. Nó còn có cả tính năng lọc metadata và các mô hình nhúng (embedding models) tích hợp sẵn, tiện lợi hết sức! Chưa hết, Upstash Redis còn là một 'phù thủy' trong việc lưu cache và giới hạn tốc độ truy cập (rate limiting), biến nó thành nền tảng lý tưởng cho các ứng dụng được hỗ trợ bởi AI hiện đại. Trong bài viết này, tôi sẽ cùng bạn khám phá hành trình chúng ta đã tạo ra một công cụ tìm kiếm meme ngữ nghĩa sử dụng Upstash Vector và Redis. Bạn sẽ thấy rõ những công cụ mạnh mẽ này có thể giúp chúng ta xây dựng trải nghiệm tìm kiếm hiệu quả và thân thiện với người dùng đến thế nào! Bạn có thể tự mình 'mò' mã nguồn của dự án trên <a href="https://github.com/akifitu/ai-meme-search-engine">GitHub</a> hoặc triển khai thẳng lên tài khoản Vercel của riêng bạn. <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/meme_search_problem.png' alt='Tìm kiếm meme truyền thống thất bại'> <b>Khi từ khóa 'bất lực': Nỗi niềm tìm kiếm meme</b> Tìm kiếm bằng từ khóa truyền thống sẽ 'ngon ơ' khi bạn biết chính xác mình muốn gì. Ví dụ: gõ 'Mèo cáu kỉnh' (Grumpy Cat) là ra ngay ảnh mèo cáu kỉnh. Dễ ợt! Nhưng meme thì lại sống trong một thế giới 'kỳ cục' giữa nghĩa đen và bối cảnh văn hóa. Thử tìm kiếm 'cảm giác khi WiFi chết giữa cuộc gọi Zoom' xem, bạn sẽ nhanh chóng thấy giới hạn của việc chỉ dựa vào từ khóa thôi là không đủ. Đó chính là lúc tìm kiếm ngữ nghĩa tỏa sáng! Nó giống như việc bạn có một người bạn cực kỳ am hiểu 'văn hóa meme'. Bạn chỉ cần nói 'Tao cần cái gì đó cho cảm giác trưởng thành khó quá', và họ sẽ đưa cho bạn 10 biến thể của meme 'Chó này vẫn ổn' (This is Fine) mà không cần chớp mắt. Và đó chính xác là thứ chúng ta đang xây dựng ở đây đó! <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/semantic_search_brain.png' alt='Tìm kiếm ngữ nghĩa hiểu bối cảnh'> <b>Bộ công cụ công nghệ: Vì sao lại chọn những cái tên này?</b> <ul><li><b>Next.js 15:</b> Vì ai mà muốn 'đau đầu' với những thiết lập phức tạp chứ? Tích hợp API routes siêu tốc + sự 'ngon lành' của React = lập trình viên hạnh phúc.</li><li><b>Upstash Vector:</b> Giống như một bộ não biết ghi nhớ mối quan hệ giữa các khái niệm (nhưng rẻ hơn não thật nhiều!).</li><li><b>Upstash Redis:</b> 'Con dao Thụy Sĩ' trong thế giới database – xử lý mượt mà việc lưu cache và ngăn người dùng 'spam' API của chúng ta.</li><li><b>LLM API:</b> Để tạo metadata (siêu dữ liệu) cho các hình ảnh meme. Có rất nhiều mô hình LLM khác nhau để bạn lựa chọn đó nha.</li><li><b>OpenAI Embeddings:</b> Không bắt buộc, bạn có thể dùng các mô hình AI khác (như của Hugging Face) nếu thích.</li><li><b>Vercel Blob:</b> Nơi 'cất giữ' tất cả những meme 'nóng hổi' mà không cần phải 'bơi' trong mớ cấu hình S3 phức tạp.</li></ul> <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/llm_metadata_generation.png' alt='LLM tạo metadata cho hình ảnh'> <b>Tạo metadata cho ảnh meme</b> Trước khi tạo vector nhúng (embedding vectors) cho các ảnh meme trong tập dữ liệu, chúng ta cần tạo metadata đầy đủ cho từng ảnh. Để làm được điều này, tôi đã tận dụng API LLM của OpenAI để tự động gắn nhãn cho tất cả ảnh với 9 thông số chính: đường dẫn (path - được lưu trữ trên Vercel), tiêu đề (title), mô tả (description), thẻ (tags), ngữ cảnh meme (memeContext), độ hài hước (humor), định dạng (format), nội dung văn bản (textContent), nhân vật (person) và đối tượng (objects). Thử thách ở đây là phải nắm bắt được cả nội dung hình ảnh lẫn văn bản được nhúng trong meme. Dưới đây là một ví dụ về việc gắn thẻ metadata: <code>{"path":"https://kqznk1deju1f3qri.public.blob.vercel-storage.com/another_%20Bugs%20Bunny_s%20_No_-D6ht580Nj0I8mri3hYLVIHnRx4DNIB.jpg","metadata":{"title":"Meme Bugs Bunny 'Không' với biểu cảm thách thức","description":"Meme này có hình Bugs Bunny, một nhân vật hoạt hình kinh điển từ series Looney Tunes, với biểu cảm thách thức. Bức ảnh là cận cảnh khuôn mặt Bugs Bunny, cho thấy anh ta với đôi mắt lim dim và miệng hơi mở, truyền tải sự thờ ơ hoặc từ chối. Từ 'không' được hiển thị bằng chữ trắng đậm, nhấn mạnh thái độ bác bỏ của anh ta. Meme này thường được dùng để thể hiện sự từ chối dứt khoát một cách hài hước. Phong cách hoạt hình giữa thế kỷ 20 làm tăng thêm sự hoài niệm.","tags":["Bugs Bunny","Looney Tunes","hoạt hình","meme","không","từ chối","thách thức","hài hước","hoạt họa","kinh điển","hoài niệm","biểu cảm","bác bỏ","khước từ","chữ đậm"],"memeContext":"Một khung hình từ Looney Tunes được tái sử dụng để truyền tải sự từ chối hài hước trong các cuộc trò chuyện trực tuyến, tận dụng tính cách hóm hỉnh của Bugs Bunny.","humor":"Sự từ chối phóng đại bằng một nhân vật được yêu mến, với sự đơn giản làm tăng hiệu ứng hài hước.","format":"Meme Bugs Bunny 'Không'","textContent":"không","person":"Bugs Bunny, nhân vật hoạt hình","objects":"Bugs Bunny, chữ 'không'"}}</code> LLM đã phân tích cả yếu tố hình ảnh (ví dụ: biểu cảm nhân vật, vị trí văn bản) và bối cảnh văn hóa (ví dụ: sức hấp dẫn hoài cổ của Bugs Bunny) để tạo ra metadata phong phú, thân thiện với tìm kiếm. <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/embedding_vectors.png' alt='Mô tả vector nhúng'> <b>Chuẩn bị các vector nhúng (Embeddings)</b> Đối với công cụ tìm kiếm meme của chúng ta, chúng tôi tự tạo các vector nhúng bằng mô hình <code>text-embedding-3-small</code> của OpenAI. Nhưng tôi khuyến khích bạn thử các mô hình nhúng khác để xem sự đa dạng nhé! Mỗi meme được đại diện bằng cách nhúng tiêu đề và mô tả của nó: <code>export const generateEmbedding = async (value: string): Promise<number[]> => { const input = value.replaceAll("\n", " "); const { embedding } = await embed({ model: embeddingModel, value: input, }); return embedding;};</code> <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://dev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F2ihm4e1fb3a9cxj8rsvj.png' alt='Thiết lập cơ sở dữ liệu vector với Upstash'> <b>Đánh chỉ mục các Vector</b> Đối với công cụ tìm kiếm meme, chúng tôi đã tạo một cấu trúc chỉ mục đơn giản, nơi mỗi meme được đại diện bởi: <ul><li>Một vector nhúng của tiêu đề và mô tả của nó.</li><li>Metadata bao gồm tiêu đề, mô tả và đường dẫn hình ảnh.</li><li>Một ID duy nhất để truy xuất.</li></ul> Quá trình đánh chỉ mục thực tế được xử lý thông qua API của Upstash Vector: <code>// Khởi tạo client Upstash Vector với chỉ mục meme export const memesIndex = new Index({ url: process.env.UPSTASH_VECTOR_URL!, token: process.env.UPSTASH_VECTOR_TOKEN!,});</code> Không giống như các dự án lớn hơn có thể yêu cầu xử lý hàng loạt, cơ sở dữ liệu meme của chúng ta đủ nhỏ để được đánh chỉ mục hiệu quả mà không cần tối ưu hóa đặc biệt. Sự đơn giản của API Upstash Vector đã làm cho quá trình này trở nên cực kỳ dễ dàng. <b>Xây dựng Công cụ Tìm kiếm Meme</b> Chức năng tìm kiếm kết hợp cả tìm kiếm tương đồng vector và đối sánh văn bản trực tiếp (và loại bỏ nếu có trùng lặp): <code>// Đối với các truy vấn dài, thực hiện cả tìm kiếm trực tiếp và ngữ nghĩa const directMatches = await findMemesByQuery(query);const semanticMatches = await findSimilarMemes(query);// Kết hợp các kết quả, loại bỏ trùng lặp const allMatches = uniqueItemsByTitle([...directMatches, ...semanticMatches]);</code> Tìm kiếm vector tìm thấy nội dung có ý nghĩa tương tự: <code>export const findSimilarMemes = async (description: string): Promise<Meme[]> => { const embedding = await generateEmbedding(description); const results = await memesIndex.query({ vector: embedding, includeMetadata: true, topK: 60, includeVectors: false, }); return results.map((result: any) => ({ id: String(result.id), title: result.metadata?.title
Bạn có bao giờ thấy 'đau đầu' với mớ chi phí điện toán đám mây lộn xộn không? Đừng lo lắng nữa! Giới thiệu người hùng mới của chúng ta: AWS AI Cost Optimizer! Tưởng tượng có một trợ lý siêu thông minh dùng công nghệ AI tạo sinh (generative AI) "đỉnh của chóp" từ AWS Bedrock. Anh bạn này sẽ "soi" từng ngóc ngách chi tiêu của bạn trên đám mây, từ cái nhỏ nhất đến cái lớn nhất. Sau đó, không chỉ tìm ra những chỗ lãng phí đâu nhé, mà còn "mách nước" cho bạn những giải pháp tối ưu cực kỳ thiết thực để cắt giảm chi phí một cách thông minh và hiệu quả nhất. Tiền của bạn sẽ được sử dụng "đúng nơi, đúng chỗ" hơn bao giờ hết! Muốn biết AWS AI Cost Optimizer hoạt động "xịn sò" thế nào? Xem ngay video dưới đây nhé: <video controls src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://www.youtube.com/embed/TCw85U-dmZs'></video> <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://d1.awsstatic.com/r2023/images/cloud-cost-management/Cloud-Cost-Management_Feature-Icon_Cost-Optimization.4a4387d8985c5b3d5b0c793f773a98e826b5c00e.png' alt='Tối ưu chi phí đám mây với AI'>.
Khám phá cách tạo một trò chơi đánh vần tiếng Anh và Hà Lan siêu thú vị sử dụng AWS Serverless (Bedrock, Step Functions, Polly, DynamoDB) và GenAI. Từ ý tưởng đến triển khai, và những bài học "xương máu" từ một lập trình viên "tay mơ" về frontend!
Này bạn! Bạn có thấy thế giới DevOps cứ xoay vù vù, công nghệ mới ra liên tục để làm mọi thứ "ngon" hơn không? Giới thiệu với bạn một "ngôi sao mới nổi" đang làm mưa làm gió: WebAssembly, hay còn gọi thân mật là Wasm! Ban đầu, Wasm được sinh ra để làm "phép thuật" cho các ứng dụng web, nhưng giờ đây, nó đang dần trở thành "kẻ thay đổi cuộc chơi" thực sự trong các lĩnh vực như điện toán đám mây, microservices, và cả điện toán biên (edge computing) nữa đó! Trong bài viết này, chúng ta sẽ cùng nhau khám phá xem Wasm "nhảy múa" thế nào trong thế giới DevOps, những lợi ích siêu to khổng lồ mà nó mang lại, và làm sao để "rước" em nó về đội của mình một cách hiệu quả nhất nhé!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/DevOpsWasmHero.png' alt='WebAssembly - Ngôi sao mới của DevOps'> Vậy rốt cuộc WebAssembly (Wasm) trong DevOps là cái gì mà nghe "hot" thế? Đơn giản mà nói, Wasm giống như một "ngôn ngữ bí mật" siêu nhanh, một dạng mã nhị phân cấp thấp. Nó cho phép những đoạn code "khó tính" được viết bằng C, C++, Rust hay Go... chạy "như bay" không chỉ trên trình duyệt web mà còn ở bất cứ đâu bạn muốn! Tưởng tượng thế này: các ứng dụng container truyền thống giống như bạn phải chở cả một căn nhà di động (bao gồm cả hệ điều hành) đi khắp nơi. Còn Wasm thì sao? Nó chỉ là một căn phòng nhỏ gọn, siêu nhẹ, cực kỳ hiệu quả và cực kỳ an toàn để code của bạn "làm việc" mà thôi! Nhẹ tênh mà mạnh mẽ, đúng không?<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/WasmVsContainer.png' alt='Wasm so với Container'> Tại sao Wasm lại được săn đón trong DevOps? Bởi vì em nó mang đến hàng loạt lợi ích mà ai cũng mê tít: Microservices siêu nhẹ, siêu nhanh: Thay vì phải gánh những "anh lính" microservices cồng kềnh, Wasm giúp chúng ta tạo ra những "chiến binh" gọn nhẹ nhưng vẫn cực kỳ mạnh mẽ. Tưởng tượng một xe đua công thức 1 thay vì một xe tải đường dài! Chạy mọi nơi, không kén chọn: Dù bạn dùng hệ điều hành nào, kiến trúc máy chủ ra sao, Wasm vẫn chạy "mượt như nhung" mà không cần phải tinh chỉnh gì nhiều. Kiểu như một ứng dụng "cắm là chạy" vậy! Bảo mật "xịn sò": Với cơ chế "sandbox" (hộp cát), Wasm giống như nhốt mã của bạn vào một phòng riêng biệt, không cho nó "lon ton" chạm vào các tài nguyên khác của hệ thống. An toàn tuyệt đối! Tiết kiệm tài nguyên: So với máy ảo (VM) hay container truyền thống, Wasm "ăn" ít tài nguyên hơn hẳn. Giúp bạn giảm chi phí máy chủ và tối ưu hóa hiệu suất. Ông trùm điện toán biên: Wasm cực kỳ phù hợp cho edge computing – nơi mà mọi thứ cần phải siêu nhanh và siêu gọn nhẹ. Nó giúp các ứng dụng chạy ngay gần người dùng, giảm độ trễ tối đa.<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/DevOpsBenefits.png' alt='Lợi ích của Wasm trong DevOps'> Vậy Wasm hoạt động như thế nào nhỉ? Nghe thì có vẻ phức tạp nhưng thực ra kiến trúc của nó lại khá "tinh giản" và "có tổ chức" đó: Định dạng Bytecode "thần tốc": Khi bạn viết code bằng C++, Rust hay Go, Wasm sẽ "biến hóa" chúng thành một định dạng nhị phân siêu nhỏ gọn, giống như một "ngôn ngữ máy" cực kỳ hiệu quả mà máy tính có thể hiểu ngay lập tức. Máy ảo (VM) "độc lập": Wasm có một máy ảo riêng, cho phép các module của nó chạy "ung dung tự tại" mà không cần quan tâm đến hệ điều hành bạn đang dùng là gì. Cứ như có một chiếc xe riêng, chạy trên mọi địa hình mà không cần phụ thuộc vào đường xá vậy! WASI (WebAssembly System Interface): Đây là "người phiên dịch" giúp Wasm module có thể trò chuyện với hệ thống bên ngoài, như đọc/ghi file hay kết nối mạng. Kiểu như một chiếc cầu nối để Wasm không bị "cô lập" vậy đó. Runtime "đắc lực": Để Wasm module có thể "cất cánh" và làm việc bên ngoài trình duyệt, chúng ta cần các công cụ "chạy" chuyên dụng như Wasmtime, Wasmer hay wasmCloud. Chúng chính là những "sân bay" giúp Wasm khởi chạy.<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/WasmArchitecture.png' alt='Kiến trúc WebAssembly'> Thôi nói lý thuyết nhiều rồi, mình thử xem một ví dụ thực tế xem sao nhé! Giả sử, một đội DevOps cần triển khai một microservice dùng để ghi lại nhật ký (logging). Thay vì dùng container truyền thống, họ quyết định "chơi lớn" với Wasm. Kết quả là: Khởi động "tức thì": Ứng dụng Wasm khởi động nhanh hơn rất nhiều, gần như ngay lập tức (cold start nhanh hơn). Tiêu thụ ít RAM hơn: Wasm "ăn" ít bộ nhớ hơn, giúp tiết kiệm tài nguyên máy chủ đáng kể. Bảo mật cao hơn: Với cơ chế sandbox, microservice ghi nhật ký được "nhốt" an toàn, không thể "táy máy" vào những phần khác của hệ thống. Nghe có vẻ "xịn sò" chưa?<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/FastLogging.png' alt='Ví dụ thực tế Wasm logging'> Cùng điểm qua những "tính năng siêu cấp" và "lợi ích tuyệt vời" của Wasm nhé! Tính năng (Features) của Wasm: Di động "muôn nơi": Wasm có thể chạy trên bất kỳ hệ điều hành hay kiến trúc phần cứng nào mà không cần chỉnh sửa gì cả. Cứ như có một chiếc va li "thần kỳ" chứa đủ mọi thứ, đi đâu cũng dùng được vậy! Bảo mật "vững chắc": Nhờ cơ chế "hộp cát" (sandboxed execution), Wasm đảm bảo rằng mã của bạn không thể "chọc ngoáy" vào những khu vực không được phép trên hệ thống. Yên tâm là không có chuyện "xâm nhập bất hợp pháp" đâu nhé! Hiệu suất "đỉnh cao": Tốc độ thực thi của Wasm gần như ngang ngửa với mã gốc (native code). Nói nôm na là nó chạy nhanh như gió vậy! Hòa nhập "tuyệt vời": Wasm không "kén cá chọn canh" ngôn ngữ lập trình đâu. Nó có thể làm việc với nhiều ngôn ngữ khác nhau, tạo sự linh hoạt tối đa. Khả năng mở rộng "vô biên": Với những ưu điểm trên, Wasm là lựa chọn lý tưởng cho các ứng dụng đám mây (cloud-native) và điện toán biên (edge computing) cần khả năng mở rộng lớn. Lợi ích cho anh em DevOps: Tiết kiệm tài nguyên: Điều này thì nói mãi rồi, nhưng nó thực sự là một lợi thế cực lớn, giúp bạn tối ưu chi phí và hiệu suất. Tăng cường bảo mật: An toàn luôn là ưu tiên hàng đầu, và Wasm làm rất tốt điều này với khả năng cô lập mã và hạn chế quyền truy cập hệ thống. Triển khai "dễ như ăn kẹo": Không còn phải đau đầu vì phụ thuộc vào hệ điều hành nữa! Wasm giúp quá trình triển khai (deployment) đơn giản hơn bao giờ hết. Tăng tốc độ thực thi: Với khả năng biên dịch Just-In-Time (JIT), Wasm giúp các ứng dụng chạy nhanh hơn, mượt mà hơn.<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/DevOpsBenefitsForEngineers.png' alt='Lợi ích của Wasm cho kỹ sư DevOps'> Vậy Wasm có thể làm được gì trong thực tế? Nó đang "tung hoành" ở đâu? Các trường hợp sử dụng (Use Cases) nổi bật: Microservices: "Siêu phẩm" cho việc triển khai các dịch vụ nhỏ gọn, tiết kiệm tài nguyên. Serverless Computing: Giúp cải thiện thời gian khởi động nguội (cold start) đáng kể trong các môi trường FaaS (Functions-as-a-Service). Tạm biệt sự chờ đợi! Edge Computing: Cho phép bạn chạy các tác vụ tính toán ngay gần người dùng, giảm thiểu độ trễ tối đa. Cứ như có một trung tâm xử lý dữ liệu nhỏ ngay cạnh bạn vậy! CI/CD Pipelines: Tăng tốc quá trình chạy thử nghiệm (test execution) trong môi trường sandbox an toàn. Pipeline của bạn sẽ chạy nhanh như "tên lửa"! API Gateways: Nâng cao hiệu quả xử lý các yêu cầu API, giúp cổng API của bạn hoạt động mượt mà hơn. Ai đã "đổ gục" trước Wasm? (Industry Adoption): Fastly: Gã khổng lồ về mạng lưới phân phối nội dung (CDN) này đã dùng Wasm cho các tác vụ điện toán biên hiệu suất cao. Cloudflare: Cũng không kém cạnh, Cloudflare tích hợp Wasm để thực thi các hàm (functions) một cách an toàn và siêu tốc. Shopify: Nền tảng thương mại điện tử đình đám này tin dùng Wasm để chạy các ứng dụng bên thứ ba một cách an toàn. Thấy chưa, toàn là những tên tuổi lớn đang "ôm" Wasm vào lòng đó!<img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/WasmBigCompanies.png' alt='Các công ty lớn áp dụng Wasm'> Giờ thì chúng ta hãy cùng đặt Wasm lên bàn cân với các đối thủ "sừng sỏ" khác như container hay máy ảo (VM) nhé. Xem ai "xịn" hơn ai!
Khám phá WebAssembly (Wasm) và cách công nghệ này đang định hình lại lĩnh vực DevOps. Tìm hiểu về lợi ích vượt trội về hiệu suất, bảo mật và khả năng tối ưu tài nguyên so với các giải pháp truyền thống như container và VM. Bài viết cũng đi sâu vào các trường hợp sử dụng thực tế và cách triển khai Wasm hiệu quả.
Bạn ơi, bạn có thấy không? Mình cũng thấy. Cả thế giới công nghệ đều đang mắt tròn mắt dẹt! Mới hôm nào chúng ta còn trầm trồ về mấy con chatbot viết thơ, thì giờ đây, ta lại ngỡ ngàng trước những hệ thống AI có thể tự động đặt vé máy bay, sửa lỗi code, hay thậm chí là xây dựng cả kế hoạch marketing mà chẳng cần ai nhúng tay.Những dự án đình đám như Auto-GPT, BabyAGI, và hàng loạt công cụ tương tự không tự dưng mà xuất hiện đâu nhé! Chúng là bước nhảy vọt logic tiếp theo trong thế giới AI: sự trỗi dậy của AI Agent.Vậy, chính xác thì AI Agent là gì? Tại sao bây giờ nó lại bùng nổ, và cái 'MCP Server' đóng vai trò 'bộ não' của nó là gì? Cùng mình bóc tách từng lớp một nhé!🤔 AI Agent là gì, thực sự?AI Agent không chỉ là một chatbot thông thường đâu. Chatbot thì chỉ là một đối tác trò chuyện thôi. Còn AI Agent, nó là một thực thể tự hành, có khả năng tự mình hành động để đạt được một mục tiêu nhất định.Cứ tưởng tượng AI Agent như một lập trình viên tập sự siêu giỏi, siêu nhanh vậy đó! Bạn không cần phải chỉ dẫn từng ly từng tí họ phải gõ cái gì. Thay vào đó, bạn chỉ cần giao một nhiệm vụ cấp cao, ví dụ như:"Ê, tìm giúp tôi 5 công cụ thay thế Stripe mã nguồn mở tốt nhất, phân tích hoạt động GitHub của chúng, rồi viết một bản tóm tắt cho tôi nhé."Một AI Agent sẽ tự động chia nhỏ nhiệm vụ này ra. Nó có bốn thành phần chính, cứ như là một cơ thể hoàn chỉnh vậy:🎯 Mục tiêu (Goal): Đây là mục tiêu lớn mà nó cần hoàn thành.🧠 Bộ não lý luận (Reasoning Engine): Đây chính là "bộ não" của agent, thường là một Mô hình Ngôn ngữ Lớn (LLM) mạnh mẽ như GPT-4 hay Claude. Nó sẽ quan sát tình hình hiện tại, suy nghĩ và quyết định bước đi hợp lý tiếp theo.🛠️ Công cụ (Tools): Đây là "đôi tay" của agent. Chúng là các hàm hoặc API mà agent có thể gọi để tương tác với thế giới bên ngoài. Ví dụ, một công cụ web_search để tìm kiếm trên mạng, một công cụ file_system để đọc/ghi tệp, hay một công cụ terminal để chạy lệnh.💾 Trí nhớ (Memory): Khả năng ghi nhớ các hành động, quan sát và phản hồi trong quá khứ. Điều này cực kỳ quan trọng để agent học hỏi và tránh bị "lặp vòng" vô ích.Agent hoạt động theo một vòng lặp liên tục: suy nghĩ, hành động, quan sát, rồi lại lặp lại – cho đến khi hoàn thành mục tiêu.🔥 Tại sao Agent lại bùng nổ mạnh mẽ bây giờ? Một "cơn bão hoàn hảo" đã hình thành!Khái niệm agent không phải là mới mẻ gì đâu, nhưng chúng ta vừa chạm tới một "điểm bùng phát" công nghệ. Bốn yếu tố then chốt đã tạo nên một "cơn bão hoàn hảo" cho sự bùng nổ của agent:1. Sức mạnh suy luận đỉnh cao của các LLM hiện đại: Đây chính là yếu tố "đinh" nhất! Các mô hình trước đây giỏi về ngôn ngữ, nhưng GPT-4 và các "đồng nghiệp" của nó lại cực kỳ xuất sắc trong việc suy luận và lập kế hoạch. Bạn có thể giao cho chúng một mục tiêu phức tạp, một bộ công cụ sẵn có, và chúng có thể tạo ra một kế hoạch từng bước rõ ràng, mạch lạc. Đây chính là "bộ não" còn thiếu bấy lâu nay! <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/LLM_brainpower.png' alt='Sức mạnh suy luận của LLM hiện đại'>2. Mọi thứ đều "API hóa": Agent cần phải làm mọi thứ! Ngày nay, hầu như mọi dịch vụ đều có API. Muốn gửi email? Có API. Đặt phòng khách sạn? API. Truy vấn cơ sở dữ liệu? Cũng API nốt! Hệ sinh thái API phong phú này cung cấp "đôi tay" để agent thao túng thế giới kỹ thuật số. <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/API_ecosystem.png' alt='Mọi thứ đều API hóa'>3. Sự trỗi dậy của Cơ sở dữ liệu Vector: Làm sao một agent có thể nhớ những gì nó học ở bước 2 khi đã đến bước 42? Lưu trữ văn bản thô trong cơ sở dữ liệu thì kém hiệu quả lắm. Cơ sở dữ liệu Vector (như Pinecone, Weaviate, Chroma) cho phép agent lưu trữ thông tin dựa trên ý nghĩa ngữ nghĩa của nó. Điều này giúp chúng có một "trí nhớ dài hạn" hiệu quả, để có thể nhớ lại ngữ cảnh liên quan từ các hành động trong quá khứ. <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/vector_database_memory.png' alt='Cơ sở dữ liệu Vector và trí nhớ AI'>4. Các framework mã nguồn mở (LangChain & LlamaIndex): Các framework như LangChain đã làm thay rất nhiều công việc nặng nhọc. Chúng cung cấp "hệ thống ống nước" để kết nối LLM, công cụ và bộ nhớ lại với nhau. Thay vì phải tự xây dựng toàn bộ vòng lặp agent từ đầu, giờ đây các nhà phát triển có thể sử dụng các thư viện này để lắp ráp các agent mạnh mẽ chỉ trong vài dòng code, biến việc tạo agent trở nên dễ dàng hơn bao giờ hết! <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/langchain_llamamaindex.png' alt='Framework mã nguồn mở LangChain và LlamaIndex'>🤖 "MCP Server": Chương trình điều khiển tổng thể!Điều này đưa chúng ta đến với "trái tim" của hệ thống. Bạn có thể nghe người ta gọi bộ điều phối của một AI agent là "MCP Server.""MCP Server" không phải là một thuật ngữ chính thức trong ngành đâu nhé. Nó là một cái tên mang tính khái niệm, và nếu bạn là fan phim khoa học viễn tưởng, đây chính là một sự "nháy mắt" trực tiếp đến Chương trình Điều khiển Tổng thể (Master Control Program) trong bộ phim TRON – một AI quyền năng quản lý toàn bộ hệ thống. Quả là một cái tên phù hợp!MCP Server chính là quá trình trung tâm chạy vòng lặp chính của agent. Nó là "nhạc trưởng" kết nối bộ não, các công cụ và bộ nhớ lại với nhau.Vậy, MCP Server làm gì ư?Quản lý Trạng thái: Nó nắm giữ trạng thái hiện tại của agent: mục tiêu cuối cùng, các tác vụ đã hoàn thành, và kết quả của các hành động trong quá khứ.Điều phối LLM: Nó lấy trạng thái hiện tại và định dạng thành một prompt (câu lệnh) cho LLM. Đây là một bước cực kỳ quan trọng. Prompt thường trông giống thế này:"Bạn là một trợ lý hữu ích. Mục tiêu của bạn là: [MỤC_TIÊU] Bạn có quyền truy cập vào các công cụ sau: [DANH_SÁCH_CÔNG_CỤ] Đây là lịch sử công việc của bạn cho đến nay: [LỊCH_SỬ_HÀNH_ĐỘNG_VÀ_QUAN_SÁT] Dựa vào đây, suy nghĩ và hành động tiếp theo của bạn là gì? Hãy phản hồi dưới dạng JSON: {"thought": "...", "action": "tool_name", "args": {...}}"Điều phối Công cụ: LLM sẽ phản hồi bằng một đối tượng JSON, ví dụ: {"thought": "Tôi cần tìm kiếm các đối thủ cạnh tranh.", "action": "web_search", "args": {"query": "Stripe alternatives"}}. MCP Server sẽ phân tích cái này và gọi hàm web_search() thực tế với các đối số được cung cấp.Quản lý Trí nhớ: Sau khi một công cụ được sử dụng, MCP Server sẽ lấy kết quả (ví dụ: danh sách kết quả tìm kiếm) và lưu nó vào bộ nhớ của agent (thường là cơ sở dữ liệu vector) để tham chiếu trong tương lai.Vòng lặp Thực thi (The Execution Loop): Server lặp lại quá trình này – gửi prompt cho LLM, điều phối một công cụ, quan sát kết quả – cho đến khi LLM phản hồi bằng một hành động "kết thúc" đặc biệt.Để bạn dễ hình dung, đây là các bước đơn giản mà MCP Server đang thực hiện:1. Chuẩn bị prompt: Tạo ra câu lệnh gửi đến "bộ não" LLM, tổng hợp mục tiêu, thông tin trong trí nhớ và các công cụ sẵn có.2. Nhận phản hồi: Hỏi LLM xem bước tiếp theo nên là gì (ví dụ: {"action": "web_search", "args": ...}).3. Thực thi hành động: Dựa vào phản hồi, kích hoạt công cụ phù hợp với các đối số tương ứng. Đây là lúc agent "hành động" thật sự!4. Lưu kết quả: Ghi lại hành động vừa rồi và kết quả quan sát được vào trí nhớ.5. Kiểm tra hoàn thành: Nếu LLM báo "xong việc" thì dừng, nếu không thì quay lại bước 1 và tiếp tục! <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/MCP_Server_diagram.png' alt='Sơ đồ hoạt động của MCP Server'>Tất cả kết nối với nhau như thế nào?Vậy đấy, sự bùng nổ của AI Agent đang diễn ra là vì các LLM mạnh mẽ (bộ não) giờ đây có thể sử dụng một hệ sinh thái API khổng lồ (các công cụ) và Cơ sở dữ liệu Vector (bộ nhớ). MCP Server là tên gọi khái niệm cho bộ điều phối trung tâm chạy vòng lặp của agent, kết nối tất cả các mảnh ghép này lại với nhau để đạt được một mục tiêu.Chúng ta đang ở giai đoạn rất sơ khai của mô hình mới mẻ này. Mặc dù các agent hiện tại có thể còn "mong manh" và tốn kém khi chạy, nhưng chúng đang chỉ ra một tương lai nơi chúng ta có thể tự động hóa các quy trình làm việc kỹ thuật số cực kỳ phức tạp.Bạn nghĩ sao về điều này? Loại AI agent nào làm bạn hào hứng nhất khi xây dựng hoặc nhìn thấy trong thực tế? Hãy chia sẻ ý kiến của bạn ở phần bình luận nhé! 👇 <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/AI_Agent_Future.png' alt='Tương lai của AI Agent'>
Khám phá cách WebAssembly (Wasm) đang cách mạng hóa DevOps, mang lại hiệu năng vượt trội, bảo mật cao và tối ưu tài nguyên cho microservices, serverless và điện toán biên. Tìm hiểu lợi ích và cách triển khai Wasm.
Khám phá giải pháp serverless đột phá sử dụng AWS Bedrock và DeepSeek R1 LLM để tự động phân tích và đưa ra phản hồi thông minh cho các commit trên GitHub. Nâng cao chất lượng mã nguồn, đảm bảo tuân thủ Clean Code và Domain-Driven Design, giúp đội ngũ phát triển tiết kiệm thời gian và tạo ra phần mềm tốt hơn.
Chào mừng các bạn dev backend ơi! Bạn đã sẵn sàng khám phá 'vùng đất' Serverless đầy hứa hẹn chưa? Nghe thì có vẻ 'cao siêu' nhưng thực ra nó là một 'phép thuật' giúp chúng ta xây dựng các ứng dụng backend xịn sò, 'có số má' (khả năng mở rộng tốt), 'tiết kiệm xăng' (chi phí hiệu quả) mà lại còn 'nhanh như điện' (hiệu năng cao), đặc biệt là KHÔNG CẦN BẬN TÂM ĐẾN MẤY CÁI SERVER ĐAU ĐẦU! Đúng vậy, Serverless chính là 'tương lai' của việc phát triển và triển khai ứng dụng, nhờ vào các nền tảng 'Hàm dưới dạng Dịch vụ' (FaaS) nổi tiếng như AWS Lambda, Azure Functions và Google Cloud Functions. <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/serverless_cloud.png' alt='Mô hình điện toán Serverless'> Trong 'cuốn cẩm nang' này, chúng ta sẽ cùng nhau 'bung lụa' và tìm hiểu sâu về những tài nguyên cực kỳ giá trị, giúp bạn trở thành 'phù thủy' Serverless backend. Chúng ta sẽ 'mổ xẻ' các kiến trúc nâng cao, những 'chiêu trò' bảo mật đỉnh cao, cách 'do thám' (giám sát) ứng dụng, mẹo tối ưu 'khởi động lạnh' (cold start) khó chịu, và cả những công cụ 'xịn xò' nhất để triển khai, kiểm thử nữa. Hãy chuẩn bị tinh thần để 'siêu nạp' hành trình Serverless của bạn nhé!Ba 'Ông Lớn': AWS Lambda, Azure Functions và Google Cloud FunctionsMỗi nhà cung cấp đám mây đều có một nền tảng Serverless 'siêu việt' với những điểm mạnh riêng biệt. Hiểu rõ chúng là chìa khóa để bạn khai thác tối đa tiềm năng đó.AWS Lambda: Sân Chơi Của Người Tiên PhongĐầu tiên, phải nhắc đến 'lão làng' AWS Lambda – nền tảng Serverless 'già dặn' và được dùng nhiều nhất hiện nay. Nó giống như một 'công xưởng' khổng lồ với hệ sinh thái cực kỳ phong phú, tích hợp 'tận răng' với các dịch vụ khác của AWS. Nếu bạn cần xây dựng kiến trúc định hướng sự kiện (event-driven), xử lý dữ liệu 'siêu tốc' hay phát triển microservices, thì đây chính là 'ông trùm' mà bạn đang tìm kiếm đó! <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/aws_lambda_icon.png' alt='Biểu tượng AWS Lambda'>Các tài liệu chuyên sâu về AWS Lambda:- Khám phá những khái niệm nâng cao về mô hình thực thi, vai trò và cấu hình của Lambda: <a href="https://codestax.medium.com/advanced-concepts-of-aws-lambda-dc400db8d3ca">https://codestax.medium.com/advanced-concepts-of-aws-lambda-dc400db8d3ca</a>- Kho tàng hướng dẫn và 'bí kíp' triển khai các kịch bản đám mây, bao gồm cả Serverless: <a href="https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/welcome.html">https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/welcome.html</a>- 20 mẹo 'nhanh gọn lẹ' để tối ưu hiệu suất và chi phí cho các hàm Lambda của bạn: <a href="https://dev.to/aws-builders/simple-aws-20-advanced-tips-for-lambda-1oif">https://dev.to/aws-builders/simple-aws-20-advanced-tips-for-lambda-1oif</a>- Nắm vững 5 mẫu thiết kế (design patterns) 'kinh điển' cho kiến trúc Serverless, giúp code gọn gàng và dễ mở rộng hơn: <a href="https://blog.bitsrc.io/mastering-aws-lambda-5-essential-design-patterns-for-developers-ff153051e0f9">https://blog.bitsrc.io/mastering-aws-lambda-5-essential-design-patterns-for-developers-ff153051e0f9</a>- Tìm hiểu sâu về quản lý đồng thời (concurrency), đồng thời được cung cấp (provisioned concurrency) và tự động mở rộng quy mô (auto-scaling) để Lambda hoạt động 'ngon' nhất dưới áp lực: <a href="https://codemax.app/snippet/advanced-aws-lambda-concurrency-and-scaling-strategies/">https://codemax.app/snippet/advanced-aws-lambda-concurrency-and-scaling-strategies/</a>Azure Functions: Xử Lý Luồng Công Việc Có Trạng Thái với Durable FunctionsAzure Functions 'tỏa sáng' với khả năng tích hợp sâu vào hệ sinh thái Azure và tiện ích mở rộng Durable Functions 'cực chất'. Nó giúp bạn viết các luồng công việc (workflows) có trạng thái, chạy dài trong môi trường Serverless. <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/azure_durable_functions.png' alt='Luồng công việc Durable Functions trong Azure'>Khám phá Azure Functions và Durable Functions:- Tổng quan về Durable Functions (Microsoft Learn): Điểm khởi đầu chính thức để hiểu về Durable Functions và khả năng của chúng: <a href="https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview">https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-overview</a>- Hướng dẫn 'từ A đến Z' về Azure Durable Functions: Tìm hiểu sâu về các quy trình chạy dài, những thực tiễn tốt nhất và so sánh thực tế: <a href="https://medium.com/@robertdennyson/the-ultimate-guide-to-azure-durable-functions-a-deep-dive-into-long-running-processes-best-bacc53fcc6ba">https://medium.com/@robertdennyson/the-ultimate-guide-to-azure-durable-functions-a-deep-dive-into-long-running-processes-best-bacc53fcc6ba</a>- Các loại hàm trong Azure Durable Functions: Hiểu các loại hàm khác nhau (orchestrator, activity, entity, client) và khi nào nên sử dụng chúng: <a href="https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-types-features-overview">https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-types-features-overview</a>- Xây dựng các luồng công việc phức tạp với Azure Functions và Durable Functions: Hướng dẫn chi tiết từng bước để điều phối các quy trình kinh doanh phức tạp: <a href="https://arindam-das.medium.com/building-complex-workflows-with-azure-functions-and-durable-functions-a-step-by-step-guide-with-ed65f4b517b0">https://arindam-das.medium.com/building-complex-workflows-with-azure-functions-and-durable-functions-a-step-by-step-guide-with-ed65f4b517b0</a>Google Cloud Functions: 'Quái Kiệt' Xử Lý Sự KiệnGoogle Cloud Functions là 'trái tim' của các kiến trúc định hướng sự kiện trên GCP, tích hợp 'mượt mà' với các dịch vụ khác của Google Cloud để xây dựng những ứng dụng phản hồi nhanh và có khả năng mở rộng. <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/gcp_event_trigger.png' alt='Cơ chế kích hoạt sự kiện của Google Cloud Functions'>Nâng tầm với Google Cloud Functions:- Tìm hiểu về các sự kiện và trình kích hoạt của Cloud Functions (Google Cloud Blog): Điều cần thiết để hiểu cách các hàm phản hồi với các sự kiện khác nhau: <a href="https://cloud.google.com/blog/products/serverless/learn-about-cloud-functions-events-and-triggers">https://cloud.google.com/blog/products/serverless/learn-about-cloud-functions-events-and-triggers</a>- Xây dựng các Cloud Functions định hướng sự kiện trên Google Cloud Platform: Những hiểu biết thực tế về thiết kế và triển khai các giải pháp định hướng sự kiện: <a href="https://keyholesoftware.com/event-driven-cloud-functions-on-google-cloud/">https://keyholesoftware.com/event-driven-cloud-functions-on-google-cloud/</a>- Khai thác sức mạnh của Google Cloud Functions: Hướng dẫn phát triển định hướng sự kiện: <a href="https://arindam-das.medium.com/harnessing-the-power-of-google-cloud-functions-a-guide-to-event-driven-development-8151fe0f6b50">https://arindam-das.medium.com/harnessing-the-power-of-google-cloud-functions-a-guide-to-event-driven-development-8151fe0f6b50</a>- Thiết kế kiến trúc định hướng sự kiện trên Google Cloud: Học các thực tiễn tốt nhất để thiết kế các hệ thống định hướng sự kiện có khả năng mở rộng và bền vững: <a href="https://dev.to/binyam/architecting-event-driven-architecture-on-google-cloud-a-journey-through-real-world-scenarios-46e0">https://dev.to/binyam/architecting-event-driven-architecture-on-google-cloud-a-journey-through-real-world-scenarios-46e0</a>Nâng Tầm Serverless Backend Của BạnNgoài những kiến thức cơ bản của từng nền tảng, việc thực sự làm chủ Serverless đòi hỏi bạn phải hiểu rõ các vấn đề xuyên suốt và kỹ thuật tối ưu.Bảo Mật Serverless: Trách Nhiệm Chia SẻAn ninh bảo mật luôn là ưu tiên hàng đầu, đúng không? Với Serverless, tuy 'ông lớn' đám mây đã lo phần hạ tầng, nhưng việc 'giữ nhà' (bảo mật mã nguồn) và cấu hình vẫn là 'nhiệm vụ' của bạn đó nha. Hãy cùng xem những 'mẹo' để ứng dụng của bạn 'kiên cố' như tường thành! <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/security_shield.png' alt='Biểu tượng bảo mật'>Tài liệu về Bảo mật Serverless:- Tổng quan tuyệt vời về các rủi ro phổ biến và cách giảm thiểu chúng: <a href="https://sysdig.com/learn-cloud-native/serverless-security-risks-and-best-practices/">https://sysdig.com/learn-cloud-native/serverless-security-risks-and-best-practices/</a>- 10 bước 'thực chiến' để bảo vệ các hàm Serverless của bạn khỏi các lỗ hổng phổ biến: <a href="https://snyk.io/blog/10-serverless-security-best-practices/">https://snyk.io/blog/10-serverless-security-best-practices/</a>- Hướng dẫn toàn diện bao gồm các mối quan tâm bảo mật cụ thể và chiến lược bảo vệ: <a href="https://www.simform.com/blog/serverless-security/">https://www.simform.com/blog/serverless-security/</a>Giám Sát & Quan Sát: 'Mắt Thần' Nhìn Xuyên Hàm Ứng DụngỨng dụng Serverless của chúng ta hoạt động theo kiểu 'rải rác' khắp nơi, nên việc 'theo dõi' (monitoring) và 'nhìn thấu' (observability) là cực kỳ quan trọng. Nó giống như bạn có một 'mắt thần' để giám sát mọi ngóc ngách, giúp bạn dễ dàng 'bắt bệnh' khi có lỗi, 'tối ưu tốc độ' và quan trọng là 'kiểm soát túi tiền' của mình nữa! <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/monitoring_dashboard.png' alt='Biểu đồ giám sát ứng dụng'>Tài liệu về Giám sát Serverless:- Hướng dẫn chi tiết để hiểu và triển khai giám sát Serverless hiệu quả: <a href="https://lumigo.io/serverless-monitoring-guide/">https://lumigo.io/serverless-monitoring-guide/</a>- Danh sách 'chọn lọc' các công cụ hàng đầu để bạn có cái nhìn rõ ràng về ứng dụng Serverless: <a href="https://www.withcoherence.com/articles/10-best-serverless-monitoring-tools-2024">https://www.withcoherence.com/articles/10-best-serverless-monitoring-tools-2024</a>- Học cách Datadog cung cấp khả năng hiển thị toàn diện cho ứng dụng Serverless: <a href="https://www.datadoghq.com/product/serverless-monitoring/">https://www.datadoghq.com/product/serverless-monitoring/</a>Giải Quyết 'Khởi Động Lạnh': Tối Ưu Hiệu NăngÀ, nhắc đến 'khởi động lạnh' (cold start) thì chắc chắn nhiều bạn sẽ 'ngứa mắt' lắm đây! Hiện tượng này có thể làm 'tụt mood' người dùng vì ứng dụng bị chậm đi một chút khi mới được kích hoạt lần đầu. Đừng lo, chúng ta sẽ cùng nhau 'giải mã' nguyên nhân và học cách 'xử lý gọn gàng' để ứng dụng của bạn luôn 'khởi động nóng' và 'mượt mà' như nhung nhé! <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/cold_start_optimization.png' alt='Biểu tượng khởi động lạnh và tối ưu'>Tài liệu về tối ưu Cold Start:- Các mẹo và công cụ thực tế để giảm thiểu độ trễ do khởi động lạnh và cải thiện hiệu quả: <a href="https://www.movestax.com/post/cold-start-optimization-a-guide-for-developers">https://www.movestax.com/post/cold-start-optimization-a-guide-for-developers</a>- Cái nhìn chuyên sâu về khởi động lạnh của AWS Lambda và các giải pháp hiệu quả: <a href="https://lumigo.io/blog/this-is-all-you-need-to-know-about-lambda-cold-starts/">https://lumigo.io/blog/this-is-all-you-need-to-know-about-lambda-cold-starts/</a>- Các kỹ thuật tối ưu cụ thể cho nền tảng container Serverless của Google Cloud: <a href="https://markaicode.com/google-cloud-run-cold-start-optimization-2025/">https://markaicode.com/google-cloud-run-cold-start-optimization-2025/</a>Triển Khai, CI/CD & Frameworks: Tối Ưu Luồng Công Việc Của BạnTriển khai tự động (Automated deployments) và các 'đường ống' CI/CD 'chắc chắn' (robust pipelines) là những 'vũ khí' không thể thiếu cho lập trình Serverless 'ngon lành cành đào'. Các framework thì sao? Chúng giống như những 'người trợ giúp' đắc lực, làm cho việc quản lý hạ tầng bằng code (Infrastructure-as-Code) và quá trình triển khai trở nên 'dễ thở' hơn rất nhiều! <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/ci_cd_pipeline.png' alt='Sơ đồ đường ống CI/CD'>Tài liệu về Triển khai & CI/CD Serverless:- So sánh chi tiết hai framework triển khai Serverless phổ biến: <a href="https://www.serverless.direct/post/serverless-framework-vs-aws-sam-a-detailed-comparison">https://www.serverless.direct/post/serverless-framework-vs-aws-sam-a-detailed-comparison</a>- Mở rộng so sánh để bao gồm AWS CDK, mang lại cái nhìn rộng hơn về hạ tầng dưới dạng mã: <a href="https://dev.to/tastefulelk/serverless-framework-vs-sam-vs-aws-cdk-1g9g">https://dev.to/tastefulelk/serverless-framework-vs-sam-vs-aws-cdk-1g9g</a>- Các thực tiễn tốt nhất và hướng dẫn thiết lập tích hợp liên tục và triển khai liên tục cho ứng dụng Serverless: <a href="https://www.serverless.com/guide-ci-cd">https://www.serverless.com/guide-ci-cd</a>- Các bước thực tế để tạo các đường ống triển khai Serverless tự động: <a href="https://dev.to/prodevopsguytech/serverless-cicd-how-to-build-a-pipeline-without-servers-fn2">https://dev.to/prodevopsguytech/serverless-cicd-how-to-build-a-pipeline-without-servers-fn2</a>Xây Dựng REST API với Serverless: Một Trường Hợp Sử Dụng Phổ BiếnBạn muốn xây dựng một API 'khủng' (có khả năng mở rộng cực cao) và 'kiên cường' (chống chịu lỗi tốt)? Vậy thì Serverless Functions chính là 'chân ái' của bạn rồi đó! Đây là một trong những ứng dụng phổ biến và 'chuẩn bài' nhất của Serverless. <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/rest_api_diagram.png' alt='Mô hình REST API Serverless'>Tài liệu về Xây dựng REST API với Serverless:- Hướng dẫn thân thiện với người mới bắt đầu để xây dựng API Serverless đầu tiên của bạn: <a href="https://www.freecodecamp.org/news/how-to-setup-a-basic-serverless-backend-with-aws-lambda-and-api-gateway/">https://www.freecodecamp.org/news/how-to-setup-a-basic-serverless-backend-with-aws-lambda-and-api-gateway/</a>- Hướng dẫn thực hành để xây dựng một API Serverless đầy đủ: <a href="https://www.serverless.com/blog/node-rest-api-with-serverless-lambda-and-dynamodb">https://www.serverless.com/blog/node-rest-api-with-serverless-lambda-and-dynamodb</a>Kiểm Thử Ứng Dụng Serverless: Thử Thách Độc Đáo, Chiến Lược Hiệu QuảKiểm thử ứng dụng Serverless? Nghe có vẻ 'khoai' hơn một chút vì bản chất phân tán của nó và việc 'phụ thuộc' vào các dịch vụ đám mây. Nhưng đừng lo, chúng ta sẽ có những 'chiến lược' và 'mẹo vặt' để biến việc này trở nên 'dễ như ăn kẹo'! <img src='https://truyentranh.letranglan.top/api/v1/proxy?url=https://i.imgur.com/testing_serverless.png' alt='Kiểm thử ứng dụng Serverless'>Tài liệu về Kiểm thử Serverless:- Hướng dẫn chính thức về các chiến lược kiểm thử khác nhau cho Serverless: <a href="https://docs.aws.amazon.com/prescriptive-guidance/latest/serverless-application-testing/techniques.html">https://docs.aws.amazon.com/prescriptive-guidance/latest/serverless-application-testing/techniques.html</a>- Những hiểu biết từ một chuyên gia Serverless về các phương pháp kiểm thử hiệu quả: <a href="https://theburningmonk.com/2022/05/my-testing-strategy-for-serverless-applications/">https://theburningmonk.com/2022/05/my-testing-strategy-for-serverless-applications/</a>- Nguồn tài nguyên dành riêng để giúp bạn xây dựng bộ kiểm thử vững chắc cho ứng dụng Serverless: <a href="https://testserverlessapps.com/">https://testserverlessapps.com/</a>Vượt Xa Chân Trời Phát Triển Serverless BackendVậy là chúng ta đã cùng nhau 'lượn một vòng' qua thế giới Serverless backend đầy thú vị rồi đó! Bạn thấy đó, hệ sinh thái này luôn 'tiến hóa' không ngừng, mang đến vô vàn cơ hội để bạn xây dựng những ứng dụng 'đỉnh của chóp': từ khả năng quan sát 'siêu việt' đến chiến lược triển khai 'mới toanh'. Hãy cứ tiếp tục 'đào sâu' vào kho tàng tài liệu khổng lồ này và 'phá vỡ mọi giới hạn' với FaaS, kiến trúc hướng sự kiện, và các mô hình tính toán Serverless trên AWS Lambda, Azure Functions, và Google Cloud Functions nhé! Và nếu bạn muốn 'nghiên cứu' sâu hơn về Serverless computing hiện đại và các công nghệ liên quan, đừng quên ghé thăm 'thư viện' tổng hợp tại <a href='https://techlinkhub.xyz/catalogue/serverless-computing'>TechLinkHub</a>. Đây là 'kho báu' chứa đựng những xu hướng mới nhất, 'bí kíp' hay ho, và các giải pháp 'sáng tạo' trong hệ sinh thái Serverless, bao gồm cả FaaS, kiến trúc hướng sự kiện, và BaaS nữa đó. Chúc bạn có một hành trình Serverless thật 'bùng nổ'!