Trong bài đăng trên blog trước của tôi trong loạt bài này, một phương pháp khá thông minh để chuyển đổi ứng dụng sang mô hình SaaS mà không làm thay đổi quá nhiều thiết kế hoặc kiến ​​trúc ứng dụng hiện có. Điều này giúp giảm thiểu các rủi ro và chi phí liên quan đến việc thay đổi thiết kế hoặc kiến ​​trúc ứng dụng của tổ chức.

Một trong những cách tiếp cận để giảm thiểu sự thay đổi trong thiết kế hoặc kiến ​​trúc ứng dụng là sử dụng các dịch vụ AWS có sẵn để phát triển và triển khai ứng dụng. Ví dụ, bạn có thể sử dụng AWS Elastic Beanstalk để quản lý và triển khai các ứng dụng web của mình một cách dễ dàng và nhanh chóng mà không cần phải thay đổi thiết kế hoặc kiến ​​trúc ứng dụng hiện có.

Bạn cũng có thể sử dụng các dịch vụ AWS khác như AWS Lambda hoặc AWS App Runner để triển khai và quản lý các ứng dụng mà không cần phải quan tâm đến việc triển khai và quản lý máy chủ.

Tuy nhiên, khi chuyển đổi ứng dụng sang mô hình SaaS, bạn cần lưu ý rằng có thể có một số thay đổi về kiến ​​trúc hoặc thiết kế cần phải được thực hiện để đáp ứng các yêu cầu của mô hình SaaS. Vì vậy, trước khi triển khai bất kỳ giải pháp SaaS nào, bạn nên thực hiện một đánh giá kỹ lưỡng về thiết kế và kiến ​​trúc của ứng dụng của mình để đảm bảo rằng nó đáp ứng được các yêu cầu của mô hình SaaS.

Trong bài đăng trước đó của loạt bài viết này, tôi đã trình bày một số chiến lược để di chuyển ứng dụng sang mô hình phần mềm dưới dạng dịch vụ (SaaS). Bài đăng đầu tiên tập trung vào các phương pháp ít xâm phạm giúp tổ chức chuyển các giải pháp hiện có sang AWS mà không thay đổi các nguyên tắc thiết kế hoặc kiến trúc của ứng dụng.

Mặc dù việc giới hạn các bộ phận di chuyển là một chiến lược di chuyển hấp dẫn, nhưng nó cũng hạn chế khả năng của bạn để hiện thực hóa toàn bộ tiềm năng của SaaS và AWS. Để lại thiết kế và kiến trúc của bạn gần như không thay đổi có thể làm cho việc đón nhận toàn bộ phổ agility và tự động hóa thường được liên kết với các ứng dụng SaaS được sinh ra trên đám mây trở nên thách thức.

Mục tiêu của bài đăng này là xem xét các mô hình di chuyển SaaS cho phép bạn dừng lại và xem xét lại thiết kế và kiến trúc của ứng dụng của bạn. Sự tập trung chuyển sang việc giảm thiểu sự thay đổi để đưa giải pháp của bạn trên một con đường mà nó có thể bắt đầu điều chỉnh với các nguyên tắc và phương pháp thiết kế tốt nhất của AWS và SaaS. Điều này cũng đặt giải pháp của bạn ở vị trí tốt hơn để áp dụng các giá trị agility và tự động hóa giúp doanh nghiệp của bạn đáp ứng nhanh hơn với các áp lực thị trường và cạnh tranh.

Chủ đề di chuyển tăng dần được ủng hộ trong bài đăng trước đó được tiếp tục đưa vào cuộc thảo luận này. Ngay cả khi bạn xem xét thực hiện các thay đổi xâm nhập hơn đối với thiết kế ứng dụng của mình, bạn vẫn cần tiến lên theo từng bước nhỏ. Phương pháp này sẽ cho phép bạn nhanh chóng đánh giá và tái hình thành thiết kế của mình dựa trên kiến thức được thu thập trong quá trình di chuyển hệ thống của bạn.

Các phần tiếp theo trình bày một số xem xét chung đi kèm với phương pháp di chuyển này và làm nổi bật một số xem xét quan trọng thường đi kèm với các biến đổi của loại này.

Mức độ chi tiết thúc đẩy sự nhanh nhẹn

Trước khi chúng ta khám phá các chiến lược cụ thể của từng phương pháp, chúng ta cần xem xét hệ thống giá trị sẽ hình thành và hướng dẫn quá trình di chuyển của bạn. Sau tất cả, nếu bạn thực sự đào sâu vào mã của mình và thay đổi nó một cách đáng kể, bạn cần đảm bảo rằng bạn đang căn chỉnh với các nguyên tắc thiết kế sẽ tối đa hóa cơ hội của bạn để hoàn toàn hiện thực hóa các lợi ích của SaaS.

Sự tinh tế và phân tách dịch vụ thường nằm ở trung tâm của cuộc thảo luận này. Nhiều mục tiêu linh hoạt mà bạn đang nhắm đến thường được đạt được thông qua việc áp dụng mô hình microservices, trong đó ứng dụng của chúng ta được phân tách thành một loạt các dịch vụ nhỏ, tự động. Những dịch vụ này là chìa khóa để cho phép một tập hợp lớn các tùy chọn để tự động triển khai, tăng tính đàn hồi, tối ưu hóa hiệu suất và quy mô, và nhiều hơn nữa. Về cơ bản, việc chuyển đổi sang mô hình microservice có khả năng phân biệt đối với nhiều khách hàng trở thành một khái niệm cơ bản có thể ảnh hưởng đến cách tiếp cận di chuyển của bạn. Các ranh giới của dịch vụ của bạn sẽ bị ảnh hưởng bởi khả năng đàn hồi, khả năng mở rộng và hồ sơ triển khai của chúng. Những dịch vụ logic trong môi trường trước đó của bạn có thể không đại diện cho một dịch vụ hợp lệ trong mô hình mới của bạn. Khả năng tận dụng những điểm mạnh của các dịch vụ AWS kết hợp với khả năng của bạn để áp dụng các nguyên tắc thiết kế hiện đại hơn đại diện cho một cơ hội để xem xét lại cấu trúc cơ bản của hệ thống của bạn và các dịch vụ hỗ trợ của nó.

Thực tế là mỗi tổ chức có thể có con đường di chuyển di chuyển riêng của mình. Những yêu cầu của lĩnh vực của bạn, trạng thái của ngăn xếp công nghệ hiện tại của bạn và áp lực kinh doanh sẽ tất cả ảnh hưởng đáng kể đến cách di chuyển của bạn. Chìa khóa ở đây là tìm cách hoà nhập với những thực tế này trong khi vẫn đặt ra một lộ trình cuối cùng sẽ phù hợp với mục tiêu kỹ thuật, vận hành và linh hoạt của bạn. Điều này luôn luôn là trung tâm của sự căng thẳng cho các dự án di chuyển SaaS.

Chọn một mô hình thực thi

Khi bạn cân nhắc chuyển sang mô hình microservices, bạn cũng phải suy nghĩ về cơ sở hạ tầng và kiến trúc sẽ được sử dụng để lưu trữ các microservices này. AWS cho phép bạn chạy các dịch vụ của mình trên nhiều môi trường khác nhau, bao gồm Amazon Elastic Compute Cloud (Amazon EC2), Amazon EC2 Container Service (Amazon ECS), và dưới dạng các AWS Lambda functions.

Bất kỳ mô hình nào trong số này đều đại diện cho một con đường hoàn toàn hợp lệ cho dịch vụ SaaS của bạn. Hồ sơ cơ sở hạ tầng và các mô hình phát triển sẽ thay đổi, nhưng hệ thống giá trị cho mỗi mô hình vẫn giữ nguyên phần lớn. Con đường chuyển đổi của bạn chỉ cần đánh giá những lựa chọn này và xác định cách đội của bạn, nhu cầu kinh doanh của bạn, và con đường dài hạn của kiến trúc của bạn phù hợp với hồ sơ của mỗi dịch vụ.

Bạn cũng có thể xem xét sự kết hợp của các mô hình này cho giải pháp SaaS của bạn. Ví dụ, một số khối lượng công việc được kích hoạt bởi sự kiện hoặc hàng loạt từ lĩnh vực của bạn có thể phù hợp với Lambda, trong khi các phần khác có thể phù hợp hơn với ECS.

Phần tiếp theo trình bày một số chủ đề cơ bản thường được liên kết với việc di chuyển kiến ​​trúc hệ thống SaaS sang một mô hình mới. Có khả năng bạn sẽ kết hợp và kết hợp chúng dựa trên các yêu cầu độc đáo của môi trường của riêng bạn.

SaaS Design Migration Themes

Các mô hình để di chuyển thiết kế của bạn rơi vào một vài nhóm. Một số phương pháp được thúc đẩy bởi nhu cầu đạt được chuyển đổi tại chỗ trong khi những phương pháp khác được ảnh hưởng bởi nhu cầu tạo ra một đường dẫn tách biệt, song song cho chuyển đổi.

Đối với tất cả các trường hợp, phương pháp chính là tách ra một phần của hệ thống hoặc một khả năng mới và cung cấp phần đó của hệ thống với các nguyên tắc đa khách hàng, thiết kế và kiến trúc mới. Sau khi khu vực mới được tách ra, chúng ta sẽ tìm cách để cắt hoặc hợp nhất các thành phần bổ sung của hệ thống với mô hình mới. Điều này có thể dẫn đến việc viết lại toàn bộ hệ thống hoặc có thể liên quan đến các dịch vụ được di chuyển chiến lược chạy trên một mô hình lai nào đó. Quan trọng là lưu ý rằng không có giải pháp ưa thích nào. Động lực và thực tế kinh doanh của môi trường của bạn sẽ quyết định chiến lược phù hợp nhất với nhu cầu của bạn.

Các phần tiếp theo sẽ nêu ba ví dụ về chiến lược di chuyển thiết kế: di chuyển từng dịch vụ, di chuyển hệ thống song song và di chuyển sản phẩm mới.

Mô hình di chuyển dịch vụ theo dịch vụ

Nếu mục tiêu của chúng ta là phân rã hệ thống thành các microservices, và những dịch vụ này chạy trong mô hình độc lập, thì bạn có thể tận dụng tính độc lập này để thuận tiện cho việc di chuyển thiết kế gia tăng. Ý tưởng ở đây là bắt đầu với một khái niệm cơ bản về cách bạn mong đợi phân rã hệ thống thành các dịch vụ. Với mô hình sơ bộ này, bạn có thể xác định một hoặc nhiều dịch vụ sẽ là những ứng viên tốt cho việc di chuyển.

Khi xác định các ứng cử viên ban đầu này, chúng ta thường tìm kiếm các dịch vụ hoặc chức năng đại diện cho một khả năng không quan trọng của hệ thống của bạn. Ví dụ, nếu bạn đang di chuyển một giải pháp thương mại điện tử, bạn có thể bắt đầu với một dịch vụ đánh giá sản phẩm. Dịch vụ này sẽ phù hợp với hồ sơ của chúng ta vì sự tồn tại của nó có thể được xem xét là tùy chọn. Nếu vì một lý do nào đó, dịch vụ đánh giá sản phẩm gặp khó khăn, hệ thống vẫn có thể tiếp tục hoạt động với tính năng cụ thể này tắt (hoặc được lưu vào bộ nhớ cache của khách hàng).

Sơ đồ sau đây cung cấp một cái nhìn khái niệm về cách chúng ta có thể thực hiện chiến lược di chuyển từng dịch vụ.

Bên trái của biểu đồ là một cơ sở hạ tầng đơn vị (được triển khai theo mô hình silo). Bên phải là một kiến trúc đích sử dụng Amazon ECS để chứa các dịch vụ nhỏ hỗ trợ đa khách hàng. Những dịch vụ mới này được tạo ra dựa trên trạng thái mục tiêu của hệ thống và nên được mã hóa và triển khai theo mô hình thể hiện thiết kế và kiến trúc ưa thích của chúng ta.

Việc chuyển đổi này thường đòi hỏi ta phải suy nghĩ lại cách cơ bản mà ta đang xây dựng các dịch vụ của hệ thống. Giải quyết các giá trị microservice và các phương pháp tốt nhất về SaaS trong một lần thường đòi hỏi ta phải xem xét và áp dụng nhiều phương pháp mới. Đây là cơ hội để ta nghĩ về các mô hình SLA, đo lường, bảo mật, logging, phân tích và tính khả năng phục hồi lỗi được thực hiện trong mỗi dịch vụ mới. Ta cũng cần suy nghĩ về cách áp dụng quyền sử dụng trong các dịch vụ này – đặc biệt là nếu ta chuyển sang một mô hình chia sẻ hoàn toàn.

Microservices cũng có thể sở hữu các mô hình lưu trữ của riêng mình. Trên thực tế, trong biểu đồ, ta sẽ thấy rằng hai microservices được đại diện bởi các vòng màu xanh và đen có khuôn mẫu lưu trữ riêng của chúng. Một dịch vụ sử dụng Amazon Relational Database Service (Amazon RDS) và dịch vụ khác sử dụng Amazon DynamoDB. Ta nên sử dụng nỗ lực di chuyển này để tìm ra những dịch vụ lưu trữ phù hợp nhất với yêu cầu của mỗi hồ sơ dịch vụ. Điều tốt cho một dịch vụ có thể không phù hợp cho dịch vụ khác.

Như bạn có thể tưởng tượng được, việc thiết lập môi trường cơ bản cho những dịch vụ ban đầu này sẽ đại diện cho một bước tiến lớn trong quá trình di chuyển của bạn. Một dịch vụ chạy trên mô hình mới này sẽ đòi hỏi bạn phải đưa nhiều phần cơ bản của dịch vụ và cơ sở hạ tầng của bạn vào hoạt động. Điều này cũng sẽ bắt buộc các yếu tố chính của môi trường xây dựng và triển khai của bạn phải được thể hiện rõ ràng.

Sau khi nền tảng này được đặt vào vị trí, nhiều dịch vụ có thể bắt đầu di chuyển với tốc độ nhanh hơn. Điều này được đại diện bằng các dịch vụ được thể hiện di chuyển từ trái sang phải trong biểu đồ. Trong quá trình chuyển đổi này, bạn sẽ hoạt động theo mô hình lai, trong đó một số khía cạnh của giải pháp sẽ được phục vụ bởi mô hình hiện có và một số khác sẽ được phục vụ bởi mô hình microservice mới.

Ví dụ này tôi đã chọn môi trường đích dựa trên ECS. Tuy nhiên, không có gì đặc biệt về phương pháp này bị ràng buộc với ECS. Bạn có thể tưởng tượng rằng cùng một kịch bản này có thể được hiện thực hành rất tương tự bằng cách sử dụng các dịch vụ nhỏ được đặt trên Amazon EC2 hoặc AWS Lambda. Các chi tiết sẽ khác nhau, nhưng các khái niệm và chiến lược sẽ rất giống nhau. Điểm chính ở đây là – như một phần của việc xác định những dịch vụ micro mới này – bạn cũng nên xem xét xem cấu trúc tính toán AWS nào phù hợp nhất với nhu cầu của giải pháp của bạn. Bạn có thể thấy rằng một số dịch vụ phù hợp hơn với mô hình EC2 trong khi các dịch vụ khác phù hợp hơn với Lambda.

Mặc dù mô hình di chuyển này tương đối đơn giản, tuy nhiên, nó không phải là một giải pháp toàn diện và nó đi kèm với một loạt thách thức riêng của nó. Tuy nhiên, nó cung cấp một cầu nối tự nhiên từ cũ sang mới, cho phép bạn thiết lập nền tảng microservice của mình và tiến hóa môi trường cơ sở hạ tầng chung của bạn dựa trên từng dịch vụ một.

Mô hình di chuyển hệ thống song song

Một số tổ chức thích tách rời hoàn toàn hệ thống hiện tại của họ. Hỗ trợ tương thích giữa môi trường cũ và mới đưa ra một mức độ phức tạp có thể làm chậm quá trình chuyển đổi sang mô hình mới. Ngoài ra, việc hỗ trợ thực thi song song của các môi trường mới và cũ có thể được coi là gánh nặng thêm.

Để thoát khỏi gánh nặng này, các nhóm có thể xem xét mô hình di chuyển song song, trong đó họ tạo ra một con đường phát triển hoàn toàn song song để xây dựng phiên bản mới của sản phẩm SaaS của họ. Với phương pháp này, nhóm sẽ dần dần đưa lên một sản phẩm mới hoàn toàn độc lập, áp dụng kiến trúc, cách chuyển giao và mục tiêu linh hoạt mới.

Khi các tính năng và chức năng của phiên bản mới đạt đến mức độ trưởng thành và chức năng chấp nhận được, tổ chức SaaS sẽ bắt đầu chuyển hướng một số khách hàng của họ sang hệ thống mới này. Ví dụ, khách hàng nào đáp ứng một hồ sơ nhất định hoặc khách hàng mới có thể được đưa vào hệ thống mới.

Phương pháp này không có gì đặc biệt. Tuy nhiên, nó tạo ra nhiều rủi ro hơn vì có thể cần nhiều thời gian và năng lượng hơn trước khi hệ thống mới có thể hỗ trợ khách hàng trực tiếp. Ngoài ra, việc thiếu sự tiến hóa tăng dần dựa trên phản hồi từ người dùng và các hoạt động có thể làm khó khăn cho việc đánh giá các giả định về thiết kế và kiến trúc.

Giá trị của mô hình di chuyển hệ thống song song là cho phép nhóm và toàn bộ tổ chức khám phá nền tảng SaaS mới mà không cần lo lắng về cách những thay đổi này có thể ảnh hưởng đến sự ổn định của các sản phẩm hiện có. Điều này có thể mang lại một mức độ tự do trong quá trình phát triển và thúc đẩy việc áp dụng nhanh chóng một số động lực văn hóa liên quan đến việc phát triển và cung cấp một ứng dụng SaaS.

Mô hình di chuyển sản phẩm mới

Trong kịch bản lý tưởng, bạn muốn cân bằng những lợi ích của hai phương án mà chúng ta đã khám phá. Phương pháp ưu tiên sẽ là một phương pháp cho phép chúng ta thực hiện các lợi ích của quá trình di chuyển lặp lại mà không yêu cầu tích hợp với giải pháp hiện tại của chúng ta.

Con đường này thường có nghĩa là bắt đầu với một sản phẩm hoàn toàn mới. Vì vậy, thay vì cố gắng tìm kiếm một cây cầu lai từ cũ sang mới, bạn có thể xác định một sản phẩm hoàn toàn mới và sử dụng sản phẩm đó như cơ hội Greenfield cho mô hình SaaS của bạn.

Phương pháp này thường đại diện cho sự cân bằng lý tưởng. Nó cho phép bạn tự do theo đuổi mục tiêu SaaS và tầm nhìn kiến trúc của mình mà không có bất kỳ rào cản nào. Nó cũng có thể giải phóng bạn khỏi việc phải phù hợp với tất cả các tính năng được cung cấp trong sản phẩm hiện tại của bạn. Quan trọng hơn, phương pháp này cho phép bạn củng cố và phát triển các nguyên tắc của kiến trúc đa khách hàng và mô hình cung cấp của bạn mà không ảnh hưởng đến khách hàng hiện tại. Sau khi nền tảng được thiết lập với sản phẩm mới này, bạn sẽ đứng trên một vị trí tốt hơn để xác định cách tốt nhất để di chuyển các sản phẩm SaaS khác sang mô hình mới.

Có những thách thức rõ ràng liên quan đến phương pháp này. Trước tiên, bạn có thể đơn giản không có một sản phẩm mới rõ ràng mà có thể được tách ra và cung cấp cho khách hàng của bạn. Nó cũng trì hoãn việc mang các khả năng SaaS mới đến cho các sản phẩm và khách hàng hiện tại của bạn, điều này có thể mang lại giá trị kinh doanh lớn hơn.

Cân nhắc khi di chuyển dữ liệu

Việc chuyển đổi thiết kế ứng dụng của bạn sang một mô hình mới cũng sẽ buộc bạn phải xem lại cách lưu trữ dữ liệu của khách hàng. Có rất nhiều yếu tố cần xem xét liên quan đến việc phân vùng dữ liệu khách hàng trên AWS. Tuy nhiên, những yếu tố này nằm ngoài phạm vi của bài viết này.

Bất kể bạn phân vùng dữ liệu của mình như thế nào, bạn cũng phải xem xét cách quản lý việc di chuyển dữ liệu này sang một biểu diễn mới có thể. Ví dụ, nếu bạn áp dụng mô hình microservices, bạn có thể di chuyển từ một biểu diễn dữ liệu đơn nhất và thống nhất sang một mô hình phân tán hơn, trong đó các dịch vụ sẽ độc lập và sở hữu quan điểm riêng của mình về dữ liệu.

Biểu diễn dữ liệu, tối ưu hóa và di chuyển dữ liệu cũng phải đóng một vai trò quan trọng trong chiến lược phân tách ứng dụng tổng thể của bạn. Khi bạn thiết kế các dịch vụ mới của ứng dụng, bạn cần suy nghĩ về cách các chiến lược lưu trữ khác nhau và các tùy chọn lưu trữ AWS có thể ảnh hưởng đến cách tiếp cận của bạn. AWS cung cấp rất nhiều giải pháp lưu trữ và mỗi giải pháp đều có điểm mạnh và tính năng riêng mà bạn cần phải điều chỉnh cho phù hợp với dịch vụ SaaS của mình.

Tập trung vào bức tranh toàn cảnh

Trong quá trình xử lý thiết kế và kiến trúc giải pháp của bạn, điều quan trọng là bạn phải tiếp tục tập trung vào mục tiêu linh hoạt tổng thể của mình. Trong mỗi bước di chuyển của bạn, bạn nên xem xét làm thế nào thay đổi kiến trúc của bạn sẽ ảnh hưởng đến khả năng vận hành và linh hoạt của doanh nghiệp của bạn. Nếu bạn di chuyển kiến trúc SaaS của mình sang một mô hình microservice phân tách hơn mà không đặt các phần còn lại vào vị trí để thúc đẩy việc phân phối liên tục, thì bạn sẽ không đạt được mục tiêu.

Giữ các giá trị này luôn ở trung tâm thường có nghĩa là chọn một chiến lược tiến hóa tất cả các bộ phận di chuyển của môi trường của bạn song song. Tự động hóa xây dựng và triển khai, tự động hóa cơ sở hạ tầng, bảo mật, phiên bản hóa, di chuyển dữ liệu, công cụ vận hành – tất cả những phần cơ bản này nên được cung cấp trong các phần nhỏ cùng với các dịch vụ thực tế của ứng dụng của bạn. Nhìn thấy những phần này xuất hiện tổng thể sẽ đưa bạn vào vị trí tốt hơn để tích hợp linh hoạt vào cách tiếp cận của bạn từ đầu.

Tối đa hóa cơ hội của bạn

Trong nhiều khía cạnh, ứng dụng SaaS đại diện cho một ứng viên lý tưởng cho AWS. Những nhu cầu kinh doanh, kỹ thuật và tính linh hoạt của SaaS rất gần gũi với các công cụ, dịch vụ và giá trị đề xuất của AWS. AWS và hệ sinh thái của nó cung cấp cho các nhà cung cấp SaaS một cảnh quan rộng lớn các tùy chọn có thể được áp dụng để tối đa hóa thành công của các ứng dụng SaaS của họ.

Khi bắt đầu trên con đường di cư cách mạng này, bạn nên dừng lại và xem xét cách nhu cầu của ứng dụng và doanh nghiệp của bạn phù hợp nhất với menu rộng lớn các tùy chọn có sẵn. Khi ứng dụng của bạn chuyển sang mô hình phân tán hơn, bạn sẽ phải xem xét xem phối hợp nào của các dịch vụ AWS và tùy chọn cấu hình phù hợp nhất với nhu cầu của dịch vụ đó. Bạn cũng có thể bắt đầu suy nghĩ chi tiết hơn về cách bạn muốn cấu hình các chính sách mở rộng và khả năng chống lại sự cố cho các dịch vụ này.

Di cư cũng cung cấp cho bạn cơ hội để xem xét cách bạn có thể sử dụng các công cụ bên thứ ba để điền vào một số nhu cầu chung của môi trường SaaS của bạn. Các đối tác AWS cung cấp nhiều sản phẩm giúp giải quyết một số nhu cầu cốt lõi của giải pháp của bạn (bảo mật, giám sát, đo lường, v.v.). Những ưu đãi này có thể mang đến một tập hợp các khả năng phong phú cho giải pháp của bạn, giải phóng cho bạn thời gian để tập trung nhiều hơn vào việc cung cấp các tính năng của ứng dụng của bạn.

Cuối cùng, mục tiêu của việc di cư không phải là để làm mọi thứ hoàn hảo. Các công cụ và dịch vụ của AWS luôn tiến hóa và thêm các khả năng mới mà bạn muốn xem xét. Việc di cư nên hướng đến đặt bạn vào một vị trí để tận dụng những gì hiện có trong khi xây dựng một nền tảng hỗ trợ nhu cầu ngày càng phát triển của khách hàng.

---

Bài được dịch từ bài viết trên AWS Blogs, bạn có thể xem bài viết gốc tại đây.