trừu tượng

Việc áp dụng AWS cho nền tảng phần mềm thương mại điện tử Magento mang lại nhiều lợi ích như tăng khả năng kinh doanh nhanh nhẹn, linh hoạt và giảm chi phí. Sách trắng này phác thảo những lợi ích của dịch vụ lưu trữ đám mây đối với Magento và những cân nhắc khi chuyển cài đặt Magento tại chỗ sang AWS. Ngoài ra, nó cung cấp hướng dẫn cho một tổ chức có kế hoạch tăng cường dấu vết trên đám mây của họ. Nội dung hướng đến các nhà lãnh đạo kỹ thuật và lãnh đạo doanh nghiệp chịu trách nhiệm triển khai và quản lý Magento trên AWS.

Giới thiệu

Tạo mới hoặc di chuyển thiết lập Magento hiện có sang Đám mây của Dịch vụ Web Amazon (AWS) mang đến cơ hội chuyển đổi tổ chức của bạn bằng cách giảm chi phí, tăng tính linh hoạt và phân phối một cách đáng tin cậy và toàn cầu. Sách trắng này trình bày chiến lược di chuyển trên đám mây và những cân nhắc khi di chuyển Magento sang AWS. Sách trắng này cung cấp hướng dẫn chung về di chuyển trên đám mây với hướng dẫn cụ thể liên quan đến việc di chuyển cài đặt Magento sang đám mây. Ngoài ra, bài báo còn cung cấp hướng dẫn để cho phép một tổ chức muốn mở rộng việc sử dụng đám mây của họ. Phần đầu tiên của báo cáo chính thức mô tả lý do chuyển sang đám mây và những thách thức chung mà các tổ chức phải đối mặt khi chuyển sang đám mây. Sau đó, quá trình di chuyển và các chiến lược di chuyển mà các tổ chức có thể lựa chọn cũng như các phương án triển khai sẽ được thảo luận. Cuối cùng, báo cáo chính thức kết thúc bằng cách thảo luận về bảo mật và tuân thủ, các thành phần kiến ​​trúc, kết nối và chiến lược bạn có thể sử dụng để di chuyển.

Trình điều khiển để di chuyển sang đám mây

Các động lực đằng sau việc bắt đầu thiết lập Magento mới hoặc chuyển thiết lập Magento tại chỗ hiện có sang đám mây là rất nhiều nhưng các động lực chiến lược phổ biến nhất bao gồm: giảm chi tiêu vốn, giảm chi phí liên tục, cải thiện khả năng mở rộng và độ đàn hồi, cải thiện thời gian tiếp cận thị trường, và đạt được những cải tiến về bảo mật và tuân thủ. Ngoài ra, các trình điều khiển tình huống và kinh doanh cũng ảnh hưởng đến việc chuyển sang đám mây.

DevOps

Hỗ trợ chiến lược DevOps của tổ chức bạn bằng cách chuyển sang đám mây có thể là động lực chính để chuyển sang đám mây hoặc có thể là một lợi ích không lường trước được. Trong cả hai trường hợp, việc di chuyển sang đám mây cung cấp nền tảng kỹ thuật để hỗ trợ chiến lược DevOps của tổ chức bạn bằng các khả năng tương tự như mong đợi của đám mây và theo định nghĩa của NIST1: theo yêu cầu và tự phục vụ, truy cập mạng rộng, tài nguyên tổng hợp, khả năng co giãn nhanh chóng, tất cả được phân phối dưới dạng dịch vụ được đo lường, cung cấp cho bạn khả năng kiểm soát cách tổ chức của bạn sử dụng dịch vụ đó. Mỗi khả năng trong số này ánh xạ trực tiếp đến các nhu cầu đặt ra đối với một tổ chức công nghệ, bất kể tổ chức của bạn có chấp nhận DevOps, Kỹ thuật đáng tin cậy của trang web (SRE), v.v. hay không, nhưng phần lớn khả năng nhập là khả năng xác định theo chương trình cơ sở hạ tầng và cấu hình (cơ sở hạ tầng dưới dạng mã [ IaC]) và sử dụng khả năng đó để tạo / chia nhỏ môi trường động như một phần của quy trình vòng đời phát triển phần mềm (SDLC) được triển khai tốt. Ngoài việc cung cấp nền tảng công nghệ hỗ trợ để kích hoạt các quy trình DevOps trên AWS xung quanh môi trường Magento của bạn, AWS cung cấp một bộ sưu tập các dịch vụ có thể cung cấp (nếu không có) hoặc tăng cường các giải pháp quản lý cấu hình phần mềm (SCM) hiện có của bạn, bao gồm AWS CodeCommit, AWS CodeBuild, AWS CodePipeline và AWS CodeDeploy, cung cấp các dịch vụ triển khai và kiểm soát nguồn được quản lý, xây dựng, tích hợp liên tục / liên tục (CI / CD).

Hợp nhất Trung tâm Dữ liệu

Hợp nhất trung tâm dữ liệu là một trình điều khiển yêu cầu quan trọng có thể đảm bảo nhu cầu chuyển sang đám mây. Ví dụ: trung tâm dữ liệu hiện tại của một tổ chức không còn có thể hỗ trợ nhu cầu tăng trưởng của doanh nghiệp về không gian, nguồn điện và hệ thống làm mát hiện tại. Ngoài ra, trung tâm dữ liệu hiện tại của một tổ chức có thể có quá nhiều điểm lỗi đơn lẻ và mang theo những rủi ro cố hữu về sự cố.

Sáp nhập và mua lại

Sáp nhập và mua lại là một động lực tình huống. Sáp nhập hoặc mua lại thúc đẩy một tổ chức tách và / hoặc hợp nhất thiết lập ứng dụng do sáp nhập hoặc mua lại. Ngoài ra, một tổ chức có thể phải đối mặt với việc bán tòa nhà, phí thuê hoặc tăng chi phí đồng địa điểm có thể dẫn đến nhu cầu tương tự để hợp nhất hoặc thiết lập ứng dụng riêng biệt, dẫn đến nhu cầu chuyển sang đám mây.

Chuyển đổi kỹ thuật số

Chuyển đổi kỹ thuật số không chỉ đơn giản là số hóa dữ liệu và liên quan đến việc chuyển đổi các hoạt động, quy trình, năng lực của tổ chức và doanh nghiệp để tăng tốc các sản phẩm phân phối nhằm tạo sự khác biệt cho tổ chức kinh doanh cốt lõi. Nhu cầu chuyển đổi kỹ thuật số trong các tổ chức đã dẫn đến sự phát triển của bộ phận CNTT của tổ chức để trở nên nhanh nhẹn và sáng tạo hơn để thích ứng với những nhu cầu thay đổi của tổ chức. Thiết lập cơ sở hạ tầng Đám mây AWS giải phóng bộ phận CNTT của tổ chức khỏi công việc nặng nhọc của việc xếp, xếp và cấp nguồn cho máy chủ để tập trung vào khách hàng của chính tổ chức. Tập trung vào các dự án giúp phân biệt hoạt động kinh doanh cốt lõi của tổ chức, thay vì cơ sở hạ tầng, cải thiện đáng kể sản phẩm, dịch vụ, giao hàng và cuối cùng là khả năng cạnh tranh.

Lợi ích của đám mây

Các tổ chức đang cân nhắc chuyển đổi sang đám mây thường được thúc đẩy bởi nhu cầu trở nên nhanh nhẹn và sáng tạo hơn. Mô hình tài trợ chi tiêu vốn (Capex) truyền thống gây khó khăn cho việc thử nghiệm nhanh các ý tưởng mới. Mô hình Đám mây AWS mang lại cho bạn khả năng nhanh chóng tạo ra các phiên bản mới trên AWS và khả năng thử các dịch vụ mới mà không cần đầu tư vào chi phí trả trước lớn (chi phí đã phát sinh và không thể thu hồi được). AWS giúp giảm chi phí của khách hàng thông qua việc trả tiền cho những gì bạn sử dụng mô hình định giá.

Cải tiến hoạt động

Đề xuất giá trị của việc chuyển đổi Magento sang AWS được nâng cao hơn nữa nhờ sự sẵn có của một số dịch vụ cung cấp thông tin chi tiết và sự linh hoạt trong hoạt động. Thông tin chi tiết về hoạt động đối với nền tảng không chỉ từ góc độ kỹ thuật (ví dụ: yêu cầu mỗi giờ) mà còn cả quan điểm hoạt động kinh doanh (ví dụ: đơn đặt hàng mỗi giờ, v.v.), đặc biệt khi hai bộ dữ liệu có thể kết hợp với nhau, cung cấp một- thời gian xem xét hiệu suất chiến dịch, chi phí hoạt động nền tảng và gần như vô hạn các chỉ số khác. Dữ liệu này cung cấp cơ sở và hỗ trợ thay đổi cũng như sự nhanh nhạy mà AWS cung cấp, cho phép xây dựng đường dẫn triển khai chức năng và nội dung, các vòng lặp thử nghiệm a / b và phản hồi, cho phép cải tiến liên tục, đo lường và xoay vòng khi nói đến trải nghiệm người dùng của cửa hàng Magento.

Cải tiến công nghệ

Động lực của một cuộc di cư cho thấy thời điểm thích hợp để xem xét các cải tiến kỹ thuật. Được kích hoạt với AWS, những cải tiến kỹ thuật này có thể được thực hiện theo cách không cần cam kết, được đánh giá và hệ thống hóa. Cài đặt Magento điển hình, trên cơ sở, có thể tận dụng ít nhất một máy chủ hoặc nhiều máy chủ, dựa trên quy mô và kiến ​​trúc, nhưng ngoài máy chủ, các dịch vụ của bên thứ ba cũng có thể được tận dụng (mạng phân phối nội dung, dịch vụ lập chỉ mục, v.v.) . Chiều rộng và chiều sâu của các cung cấp dịch vụ AWS, cũng như cấu trúc thanh toán có sẵn trên AWS phục vụ để loại bỏ số lượng máy chủ cơ bản cần được chăm sóc và cung cấp cũng như cung cấp phương tiện để hợp nhất các nhà cung cấp, đạt được số lượng quy mô lớn hơn và có các mô hình chi phí bùng nổ và đường cơ sở có thể dự đoán được vì nó liên quan đến việc vận hành cơ sở hạ tầng. Điều này không bao gồm lợi ích tiềm năng về hiệu quả xung quanh việc quản lý nền tảng, giúp giảm chi phí vận hành.

Thách thức áp dụng đám mây

Đám mây đã trở thành trụ cột chính trong chiến lược chuyển đổi số của hầu hết các doanh nghiệp. Các tổ chức đều đang di chuyển các quy trình mới lên đám mây và tăng cường các hoạt động đám mây hiện có của họ để tận dụng các dịch vụ mới và đang phát triển. Tuy nhiên, đây là những sáng kiến ​​phức tạp mà nhiều tổ chức vấp phải vì những ràng buộc và lo ngại sau đây.

Ràng buộc về Chi phí / Ngân sách

Lý do cốt lõi khiến các tổ chức áp dụng cơ sở hạ tầng CNTT đám mây là để tiết kiệm tiền. Tuy nhiên, có những hạn chế về ngân sách và chi phí đối với các hoạt động di chuyển và chạy trên đám mây thường đặt ra những thách thức cho các tổ chức. AWS cung cấp các công cụ lập ngân sách và ước tính chi phí, chẳng hạn như Trình khám phá chi phí AWS, Báo cáo chi phí và sử dụng AWS và Ngân sách AWS, có thể hướng dẫn các tổ chức và giảm bớt những lo lắng này.

Mối quan tâm về bảo mật

Các tổ chức đã quen với việc có toàn quyền sở hữu từ tòa nhà vật lý chứa máy chủ đến phần mềm trên máy chủ. Quyền sở hữu này khiến mọi người yên tâm rằng dữ liệu được bảo mật. Quyền sở hữu và vị trí địa lý của dữ liệu đã trở thành chủ đề chính cho các sáng kiến ​​chính sách về an ninh mạng và đám mây trên toàn cầu. Tuy nhiên, khi công nghệ đã phát triển, hầu hết các mối đe dọa đều bị khai thác từ xa. Vị trí thực của dữ liệu có ít hoặc không ảnh hưởng đến các mối đe dọa được lan truyền trên Internet. Các tổ chức thường có quan niệm sai lầm rằng môi trường đám mây kém an toàn hơn. Ngoài ra, các tổ chức Bộ phận CNTT thành thạo với bảo mật của cơ sở hạ tầng tại chỗ nhưng thường gặp khó khăn trong việc triển khai bảo mật trên đám mây do thiếu kiến ​​thức hoặc kỹ năng.

Đáp ứng các yêu cầu kinh doanh

Các tổ chức đấu tranh để xác định các khách hàng cuối khác nhau như người mua sắm, người tạo nội dung, đại lý dịch vụ khách hàng, người bán hàng, v.v. trong một thiết lập ứng dụng thương mại điện tử điển hình. Điều này trở thành một thách thức trong sáng kiến ​​di chuyển đám mây để đáp ứng và làm việc ngược lại so với các yêu cầu đối với từng loại khách hàng.

Quản lý cơ sở hạ tầng kế thừa

Các tổ chức có thể không nhận ra khoản tiết kiệm chi phí ngay lập tức từ việc chuyển ứng dụng Magento lên đám mây vì trong một số trường hợp, cơ sở hạ tầng tại chỗ không thể ngừng hoạt động khi các dịch vụ / ứng dụng khác vẫn đang chạy bằng cơ sở hạ tầng đó. Điều này dẫn đến việc mở rộng phạm vi cho các tổ chức để quản lý cơ sở hạ tầng kế thừa hiện có cùng với cơ sở hạ tầng đám mây.

Các dự án cạnh tranh, Mối quan tâm về Nhân sự & Thiếu hụt Kỹ năng

Các tổ chức phải vật lộn với tình trạng thiếu kỹ năng liên quan đến đám mây trong đội ngũ nhân viên hiện có và mối quan tâm về nhân sự để thuê nhân viên được đào tạo về đám mây. Ngoài ra, các ưu tiên và dự án cạnh tranh giữa nhiều sáng kiến ​​đám mây tại một tổ chức dẫn đến việc phân chia nhân viên CNTT giữa các dự án. Trớ trêu thay, điều này dẫn đến các quy trình chậm và tốn kém để triển khai và tối ưu hóa các hệ thống nhằm mang lại tốc độ và sự nhanh nhẹn. AWS Cloud và các nhà cung cấp dịch vụ được quản lý, chẳng hạn như CloudHesive, cung cấp các dịch vụ hỗ trợ, đã trở nên chủ động hơn và tập trung vào chiến lược hơn nhiều để đáp ứng nhu cầu của thị trường về mức độ đáp ứng cao hơn, khả năng tiếp cận các công cụ và hướng dẫn chiến lược.

Quản lý nhà cung cấp

Các tổ chức thường thiếu tài nguyên để quản lý các nhà cung cấp và xem các nhà cung cấp dịch vụ đám mây là một bổ sung cho danh sách đó. Ngoài ra, việc nhận được tài liệu phù hợp, quản lý hợp đồng và báo cáo tuân thủ là các lĩnh vực đấu tranh khác làm tăng thêm sự phức tạp. Tuy nhiên, AWS đơn giản hóa những thách thức này bằng cách tiếp cận tự phục vụ và tính khả dụng của các báo cáo tuân thủ trực tuyến.

Quy trình di chuyển năm giai đoạn

Khi xem xét việc di chuyển khối lượng công việc Magento sang đám mây, nó thường chỉ là một phần của kế hoạch di chuyển tổng thể. Ví dụ: một công ty bắt đầu hành trình hiện đại hóa để chuyển từ trung tâm dữ liệu hoặc cơ sở đồng địa điểm sang AWS phải phát triển một kế hoạch di chuyển chi tiết có xem xét trình tự và chiến lược di chuyển các ứng dụng và nền tảng ít ảnh hưởng nhất đến hoạt động kinh doanh đang diễn ra. Phần này bao gồm quá trình di chuyển năm giai đoạn trong bối cảnh di chuyển khối lượng công việc Magento lên đám mây.

Giai đoạn 1: Chuẩn bị Di cư và Lập kế hoạch Kinh doanh

Trong giai đoạn này, bạn hiểu đầy đủ về lợi ích của việc chuyển sang đám mây cũng như thiết lập các mục tiêu kinh doanh của mình. Một trường hợp nghiệp vụ cho việc di chuyển được phát triển và các hạn chế của kiến ​​trúc và hệ thống hiện có được xem xét. Đây cũng là nơi các đối tác AWS chuyên về di chuyển đám mây và triển khai Magento có thể tham gia để giúp phát triển kế hoạch di chuyển.

Giai đoạn 2: Khám phá và lập kế hoạch danh mục đầu tư

Tiếp theo, bạn kiểm tra toàn bộ danh mục CNTT của mình, hiểu bất kỳ sự phụ thuộc nào tồn tại giữa các khối lượng công việc và xem xét các chiến lược di chuyển để đáp ứng các mục tiêu kinh doanh của bạn. Đối với Magento, giai đoạn này trình bày chi tiết cách Magento tích hợp với các khối lượng công việc khác, cả nội bộ và bên ngoài doanh nghiệp.

Giai đoạn 3 & 4: Thiết kế, di chuyển và xác thực ứng dụng

Đây là nơi chiến lược di chuyển cho từng ứng dụng được thiết kế, thực hiện và xác thực. Có sáu chiến lược di chuyển ứng dụng phổ biến sẽ được thảo luận chi tiết hơn trong phần tiếp theo.

Giai đoạn 5: Mô hình hoạt động hiện đại

Cuối cùng, giai đoạn này là nơi bạn lặp lại trên nền tảng mới của mình, loại bỏ các hệ thống cũ và tiếp tục cải thiện và hướng tới một môi trường hoạt động hiện đại.

Các chiến lược di chuyển

Phần này cung cấp sáu chiến lược di chuyển phổ biến để chuyển các ứng dụng và hệ thống lên đám mây và sau đó mô tả chiến lược nào trong số các chiến lược đó áp dụng cho khối lượng công việc của Magento. Sẽ rất hữu ích khi hiểu các chiến lược rộng lớn hơn này vì Magento thường chỉ là một thành phần của danh mục ứng dụng và do đó là một phần của kế hoạch di chuyển tổng thể.

Sáu chiến lược phổ biến: “Sáu Rs”

Sáu phương pháp tiếp cận được mô tả dưới đây là các chiến lược di chuyển phổ biến và được xây dựng dựa trên “5 R” do Gartner vạch ra vào năm 20112. Việc lựa chọn chiến lược di chuyển Magento phù hợp phụ thuộc vào các động lực kinh doanh cho việc áp dụng đám mây, cũng như cân nhắc về thời gian, hạn chế kinh doanh và tài chính, và yêu cầu tài nguyên.

Tổ chức lại

Rehosting hay còn gọi là “nâng và thay đổi”, thường được sử dụng khi một tổ chức đang tìm cách nhanh chóng di chuyển các ứng dụng lên đám mây để đáp ứng một trường hợp kinh doanh. Các ứng dụng được chuyển nguyên trạng lên đám mây mà không thực hiện bất kỳ thay đổi nào đối với ứng dụng hoặc các phụ thuộc của nó. Mặc dù chiến lược này không ngay lập tức mang lại toàn bộ lợi ích của đám mây, nhưng nó cho phép di chuyển nhanh chóng và tiết kiệm chi phí từ việc lưu trữ trên đám mây.

Nền tảng lại

Còn được gọi là “lift, tinker và shift”, tái nền tảng bao gồm việc sử dụng một ứng dụng hiện có, di chuyển nó lên đám mây và thay thế các phần phụ thuộc của ứng dụng cụ thể bằng các lựa chọn thay thế được quản lý đầy đủ có sẵn trên đám mây. Ví dụ: thay vì lưu trữ trực tiếp cơ sở dữ liệu quan hệ trên các phiên bản EC2, cơ sở dữ liệu cho nhiều ứng dụng có thể dễ dàng được thay thế bằng Dịch vụ cơ sở dữ liệu quan hệ của Amazon (Amazon RDS). Lợi ích của chiến lược này là trách nhiệm vận hành của các thành phần không phân biệt có thể được chuyển tải cho AWS mà không yêu cầu thay đổi đáng kể đối với ứng dụng cốt lõi.

Mua lại

Chiến lược mua lại liên quan đến việc chuyển từ giấy phép vĩnh viễn sang mô hình phần mềm dưới dạng dịch vụ (Saas). Trong bối cảnh của Magento, chiến lược Mua lại sẽ liên quan đến việc chuyển từ giấy phép Magento tại chỗ truyền thống (thường được gọi là M1) sang Magento Commerce Cloud (một dịch vụ được lưu trữ dưới dạng phần mềm).

Tái yếu tố / Kiến trúc lại

Chiến lược tái cấu trúc hoặc Tái kiến ​​trúc mang lại nhiều cơ hội nhất để tối ưu hóa và tái tạo hoặc hình dung lại kiến ​​trúc ứng dụng từ đầu. Điều này tạo cơ hội để cung cấp các tính năng sử dụng công nghệ gốc đám mây. Chiến lược này thường được thúc đẩy bởi nhu cầu kinh doanh mạnh mẽ để thêm các tính năng, quy mô hoặc hiệu suất mà nếu không sẽ khó đạt được trong môi trường hiện tại của ứng dụng.

Về hưu

Trong ngữ cảnh của Magento, chiến lược này liên quan đến việc hoàn thành việc khám phá môi trường hiện có và loại bỏ các ứng dụng / tính năng không còn cần thiết. Ví dụ: có thể không cần giám sát phần cứng nếu bạn định chuyển sang giải pháp thương mại Magento được quản lý.

Giữ lại

Đây cũng được gọi là chiến lược “thăm lại” hoặc không làm gì cả. Chiến lược này liên quan đến việc truy cập lại ứng dụng Magento hiện có vào thời điểm sau đó vì việc chuyển sang đám mây có thể không phù hợp với nhu cầu kinh doanh hiện tại.

Phiên bản Magento

Magento có sẵn trong hai phiên bản:

1. Mã nguồn mở (trước đây gọi là phiên bản cộng đồng) và 2) Magento Commerce. (Xem so sánh tính năng trên trang Adobe Magento để biết sự khác biệt về phiên bản.) Mã nguồn mở Magento chỉ có sẵn để tự lưu trữ trong khi Magento Commerce có sẵn để tự lưu trữ hoặc là một phần của Magento Hosted Cloud (hay còn gọi là Magento Commerce Cloud).

Kiến trúc tham khảo

Hình sau cho thấy kiến ​​trúc tham chiếu để triển khai một trong hai phiên bản Magento trên AWS. Để biết thông tin chi tiết về kiến ​​trúc tham khảo, hãy xem Phần mềm thương mại điện tử của Lưu trữ Magento® trên AWS.

Hình 1 – Kiến trúc tham chiếu cho Magento Commerce và Magento Open Source

Tùy chọn triển khai

Có một số tùy chọn triển khai có sẵn để chạy Magento (cả phiên bản Mã nguồn mở và Magento Commerce) trên AWS. Sự lựa chọn thích hợp nhất phụ thuộc vào yêu cầu của bạn về chi phí, quy mô, tính khả dụng và tính linh hoạt cũng như các kỹ năng AWS và Magento của tổ chức của bạn. Phần này phác thảo toàn bộ các tùy chọn triển khai cùng với một số đặc điểm chính cần ghi nhớ khi đánh giá từng tùy chọn.

Tự quản lý

AWS cung cấp ba tùy chọn để nhanh chóng bắt đầu với việc triển khai Magento tự quản lý. Bằng cách tự quản lý, chúng tôi có nghĩa là AWS hoặc đối tác AWS cung cấp tập lệnh hoặc Hình ảnh máy Amazon (AMI) để triển khai Magento và các phụ thuộc cơ sở hạ tầng cần thiết, chẳng hạn như phiên bản EC2, trong tài khoản AWS của bạn. Sau khi được triển khai, bạn chịu trách nhiệm quản lý việc triển khai về sau bao gồm theo dõi, vá lỗi và nâng cấp.

Amazon Lightsail

Amazon Lightsail cung cấp các máy chủ ảo, bộ lưu trữ, cơ sở dữ liệu và mạng dễ sử dụng và được thiết kế để cho phép bạn nhanh chóng bắt đầu với đám mây. Các ngăn xếp ứng dụng phổ biến hoặc bản thiết kế có sẵn có thể được triển khai trên máy chủ ảo Lightsail. Các ngăn xếp này được cấu hình sẵn với tất cả các thành phần cần thiết để bắt đầu với một ứng dụng trong vài phút. Ngăn xếp ứng dụng Magento được cung cấp bởi Bitnami và bao gồm Apache, Varnish, Memcached, MySQL và Magento Community Edition được đóng gói trong AMI. Từ bảng điều khiển Lightsail trong tài khoản AWS của bạn, bạn chỉ cần chọn Khu vực AWS và khu vực khả dụng nơi bạn muốn khởi chạy Magento, chọn gói phiên bản và khởi chạy phiên bản của bạn. Sau một vài phút, phiên bản của bạn được triển khai và sẵn sàng truy cập. Mặc dù Magento và tất cả các phụ thuộc của nó đều được định cấu hình trước, bạn vẫn có thể truy cập an toàn vào phiên bản bằng giao diện SSH dựa trên trình duyệt hoặc ứng dụng khách SSH yêu thích của bạn để thực hiện các thay đổi cấp thấp hơn. Giao diện người dùng Magento Administration dựa trên web cũng có thể được sử dụng để tạo và tùy chỉnh các cửa hàng của bạn. Với sự đơn giản và hiệu quả về chi phí của việc triển khai Magento thông qua Lightsail cũng có một số đánh đổi quan trọng. Những sự cân bằng này rất quan trọng cần ghi nhớ khi nói đến khả năng mở rộng, tính khả dụng và duy trì trang web thương mại điện tử của bạn. Đầu tiên, Magento AMI do Bitnami cung cấp được sử dụng bởi Lightsail sẽ cài đặt Magento và tất cả các phụ thuộc vào một phiên bản duy nhất. Mặc dù điều này giúp việc triển khai đơn giản, nhưng nó cũng hạn chế khả năng mở rộng trang web thương mại điện tử của bạn, tạo ra nhiều điểm lỗi đơn lẻ (SPOF) và khiến bạn có trách nhiệm vá lỗi và cập nhật các phần phụ thuộc như Memcached và MySQL. Do đó, việc chọn Lightsail làm tùy chọn triển khai chỉ nên được xem xét đối với các trang web thương mại điện tử nhỏ hơn, nơi bạn mong đợi mức lưu lượng truy cập luôn thấp từ khách truy cập.

Thị trường AWS

AWS Marketplace là một trang web thương mại điện tử nơi khách hàng AWS có thể khám phá, mua sắm và triển khai các giải pháp do các đối tác AWS cung cấp. Hàng nghìn giải pháp có sẵn trên hơn 1.000 danh mục bao gồm cơ sở hạ tầng, ứng dụng kinh doanh, máy học và nhiều giải pháp khác. Các tùy chọn triển khai được hỗ trợ trên Marketplace bao gồm các ứng dụng được triển khai trực tiếp vào tài khoản khách hàng thông qua AMI hoặc Docker container, Amazon SageMaker hoặc các giải pháp SaaS. Tất cả phần mềm được mua thông qua Marketplace sẽ xuất hiện trên hóa đơn AWS của khách hàng cùng với bất kỳ tài nguyên AWS nào khác được tiêu thụ. Các tùy chọn triển khai Magento hiện có trên Thị trường AWS dựa trên AMI. Các dịch vụ này bao gồm Magento và tất cả các phụ thuộc cần thiết như MySQL, máy chủ web và các thành phần bộ nhớ đệm. Do đó, khách hàng AWS có thể triển khai Magento trực tiếp vào tài khoản AWS của họ và thiết lập và chạy Magento trong vài phút. Tương tự như tùy chọn Lightsail, khách hàng chịu trách nhiệm vá và nâng cấp Magento và các phụ thuộc của nó. Ngoài ra, khách hàng chịu trách nhiệm định cấu hình môi trường mạng, hoặc Amazon Virtual Private Cloud (Amazon VPC), trong đó Magento được triển khai. Cuối cùng, khách hàng nên điều tra kỹ và hiểu đặc điểm về khả năng mở rộng và tính khả dụng cao của từng tùy chọn, phiên bản Magento đi kèm với từng tùy chọn và mọi tùy chỉnh đi kèm như bộ nhớ đệm nâng cao hoặc thiết lập nhiều cửa hàng. Ví dụ: một số là gói tất cả trong một nhằm triển khai trên một phiên bản Amazon EC2 duy nhất. Mặc dù điều này cung cấp một cấu hình đơn giản hơn và chi phí thấp hơn, nhưng nó dẫn đến một số điểm lỗi duy nhất và thiếu khả năng tận dụng tính đàn hồi và khả năng sẵn sàng cao của đám mây.

Bắt đầu nhanh AWS cho Magento

AWS Quick Starts là việc triển khai các giải pháp phần mềm bằng nút bấm do AWS và các đối tác AWS xây dựng và duy trì. Quick Starts tận dụng các mẫu AWS CloudFormation để viết kịch bản cho tất cả các khía cạnh của việc triển khai theo các phương pháp hay nhất của AWS và bao gồm khả năng được khởi chạy trong VPC hiện có hoặc mới. Tuy nhiên, miễn phí cho Bản thân Quick Start, chi phí cấp phép cho Magento Enterprise và chi phí phát sinh cho các tài nguyên AWS do Quick Start khởi chạy là trách nhiệm của khách hàng. Quick Start cũng hỗ trợ Magento Community Edition. Các tài nguyên AWS được khởi chạy với AWS Quick Start cho Magento bao gồm Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic File System (Amazon EFS), Amazon Relational Database Service (Amazon RDS) cho MySQL hoặc Amazon Aurora, Amazon ElastiCache cho Redis và Elastic Cân bằng tải. Máy chủ web được cài đặt bằng Magento bởi Quick Start là NGINX. Nhiều máy chủ Magento được triển khai trong các mạng con riêng tư trên hai Vùng sẵn sàng của AWS trong Đám mây riêng ảo Amazon (VPC) để nâng cao tính khả dụng. Khách hàng có thể sử dụng Nhóm chia tỷ lệ tự động AWS để tự động chia tỷ lệ số lượng máy chủ lên và xuống dựa trên tải cũng như thay thế các phiên bản không khả dụng. Truy cập ra ngoài vào internet cho các máy chủ Magento được cung cấp bởi một cổng dịch địa chỉ mạng (NAT) được quản lý AWS. Một máy chủ pháo đài cũng được triển khai trong một mạng con công cộng để cho phép khách hàng truy cập vào các máy chủ bằng SSH.

Hình 2 – Kiến trúc tham chiếu được AWS Quick Start cho Magento triển khai

Lưu trữ được quản lý

Đối với những khách hàng không cảm thấy thoải mái hoặc không có đủ tài nguyên để quản lý việc triển khai Magento của riêng họ trên AWS, có một số công ty chuyên cung cấp triển khai lưu trữ được quản lý của Magento trên AWS. Các công ty này, chẳng hạn như CloudHesive, đảm nhận các khía cạnh triển khai, bảo mật, vá lỗi và bảo trì Magento. Một số cũng cung cấp dịch vụ thiết kế và phát triển tùy chỉnh cho mặt tiền cửa hàng Magento. Bạn có thể sử dụng AWS Partner Finder để tìm và so sánh các nhà cung cấp chuyên về dịch vụ lưu trữ Magento.

Đám mây thương mại Magento

Một trong những tùy chọn lưu trữ được quản lý phổ biến nhất cho Magento trên AWS do chính Magento cung cấp. Magento Commerce, một phần của Adobe Commerce Cloud, là một nền tảng lưu trữ tự động được quản lý hoàn toàn cho phần mềm Magento Commerce. Magento Commerce Cloud đi kèm với nhiều tính năng triển khai và phát triển bổ sung ngoài các nền tảng Magento Commerce và Magento Open Source trên đám mây tự lưu trữ. Cơ sở hạ tầng cung cấp trước của Magento Commerce Cloud bao gồm các công nghệ PHP, MySQL, Redis, RabbitMQ và Elasticsearch. Ngoài ra, nó cung cấp quy trình làm việc dựa trên Git với việc xây dựng và triển khai tự động để phát triển nhanh chóng hiệu quả và triển khai liên tục mỗi khi bạn đẩy các thay đổi mã trong môi trường nền tảng như một dịch vụ (PaaS). Magento Commerce Cloud có dịch vụ lưu trữ AWS cung cấp môi trường có thể mở rộng và an toàn cho việc bán hàng và bán lẻ trực tuyến.

Bảo mật và Tuân thủ

Bất chấp quan niệm sai lầm phổ biến rằng môi trường đám mây kém an toàn hơn cơ sở hạ tầng tại chỗ, các mục tiêu chiến lược liên quan đến bảo mật và tuân thủ thường là động lực chính để các tổ chức chuyển sang đám mây. Các nhà cung cấp dịch vụ đám mây siêu cấp hàng đầu, chẳng hạn như AWS, đầu tư rất nhiều vào bảo mật và tuân thủ, đồng thời cung cấp hồ sơ bảo mật tốt hơn những gì các tổ chức lớn nhất và bảo thủ nhất có thể cung cấp trong nội bộ. Bảo mật là ưu tiên hàng đầu tại AWS. Là khách hàng của AWS, bất kể quy mô hoặc khoản đầu tư của bạn là gì, bạn thừa hưởng tất cả các lợi ích của trải nghiệm AWS, được thử nghiệm dựa trên các khuôn khổ đảm bảo của bên thứ ba nghiêm ngặt nhất.

Mô hình trách nhiệm chung của AWS

Theo Mô hình trách nhiệm chung của AWS, AWS cung cấp cơ sở hạ tầng và nền tảng an toàn toàn cầu cho các dịch vụ máy tính, lưu trữ, mạng và cơ sở dữ liệu cũng như các dịch vụ cấp cao hơn. AWS cung cấp một loạt các dịch vụ và tính năng bảo mật mà khách hàng AWS có thể sử dụng để bảo đảm tài sản của họ. Khách hàng của AWS chịu trách nhiệm bảo vệ tính bí mật, tính toàn vẹn và tính khả dụng của dữ liệu của họ trên đám mây và đáp ứng các yêu cầu kinh doanh cụ thể về bảo vệ thông tin. Nói một cách dễ hiểu, AWS chịu trách nhiệm về bảo mật của đám mây và khách hàng chịu trách nhiệm về bảo mật trên đám mây.

Khi tận dụng Đám mây AWS, khách hàng có thể chọn giải pháp bảo mật được thiết kế để bảo vệ nội dung, nền tảng, ứng dụng, hệ thống và mạng của tổ chức đồng thời đáp ứng nhu cầu kinh doanh của họ. AWS cung cấp một loạt các công cụ và tính năng giúp các tổ chức tăng cường quyền riêng tư và kiểm soát quyền truy cập mạng để họ có thể dễ dàng đáp ứng nhu cầu của mình hơn trong Mô hình trách nhiệm chung của AWS. Amazon Virtual Private Cloud (Amazon VPC) cho phép bạn tạo một phần riêng biệt hợp lý của Đám mây AWS, từ đó bạn có thể khởi chạy các phiên bản Amazon EC2 trong mạng ảo mà bạn xác định. Các nhóm bảo mật cho phép bạn xác định tường lửa ảo xung quanh các phiên bản EC2 của bạn, tường lửa này chứa các quy tắc kiểm soát lưu lượng truy cập vào và ra tới các phiên bản của bạn. Danh sách kiểm soát truy cập mạng (ACL) cung cấp một lớp tùy chọn cho phép bạn kiểm soát lưu lượng truy cập vào và ra khỏi một hoặc nhiều mạng con trong VPC của bạn.

Thực hành tốt nhất

AWS và Magento cung cấp một loạt các công cụ để giúp bảo mật tài nguyên đám mây của bạn và giúp bạn đáp ứng các nhu cầu tuân thủ của mình theo các tiêu chuẩn của tổ chức và ngành. Các phương pháp hay nhất bao gồm:

An ninh mạng

Amazon VPC cho phép bạn tạo mạng riêng trong AWS và kiểm soát quyền truy cập mạng vào các phiên bản và mạng con của bạn. Sử dụng các tùy chọn kết nối riêng tư hoặc chuyên dụng như AWS Direct Connect để kết nối văn phòng / trung tâm dữ liệu tại chỗ của bạn với AWS. Nếu bạn đã sử dụng AWS trong tổ chức của mình thì hãy sử dụng AWS Private Link để kết nối đám mây được lưu trữ trên Magento với VPC hiện có của bạn. Cuối cùng, luôn bao gồm tường lửa ứng dụng web (AWS WAF) và các công nghệ giảm thiểu từ chối dịch vụ (DDoS) phân tán (AWS Shield) như một phần của chiến lược phân phối nội dung hoặc quy mô tự động của bạn.

Mã hóa dữ liệu

Luôn mã hóa dữ liệu của bạn cả khi ở trạng thái nghỉ và khi truyền. Bạn có thể sử dụng TLS để mã hóa dữ liệu đang chuyển tiếp. Mã hóa ở trạng thái nghỉ được thực hiện thông qua khả năng mã hóa dữ liệu có sẵn trong các dịch vụ lưu trữ AWS như Amazon Elastic Block Store (Amazon EBS), Amazon Simple Storage Service (Amazon S3) và Amazon Relational Database Service (Amazon RDS). Ngoài ra, có các tùy chọn lưu trữ khóa mật mã dựa trên phần cứng chuyên dụng có sẵn cho khách hàng để giúp đáp ứng các yêu cầu tuân thủ của họ.

Kiểm soát truy cập

Bảo vệ thông tin đăng nhập người dùng AWS và Magento của bạn. Thông tin đăng nhập AWS được sử dụng để truy cập các dịch vụ AWS trong đó thông tin đăng nhập Magento được sử dụng để quản lý mặt tiền cửa hàng của bạn trong Magento. Sử dụng các quyền thích hợp trên các tài khoản người dùng truy cập tài nguyên AWS và tài khoản người dùng truy cập các khả năng tùy chỉnh mặt trước cửa hàng Magento. AWS Identity and Access Management (IAM) cho phép bạn tạo nhiều người dùng và quản lý các quyền. AWS cung cấp hai loại thông tin xác thực bảo mật: khóa truy cập AWS và chứng chỉ X.509. Truy cập các khóa và chứng chỉ để xác thực các dịch vụ AWS. Một phương pháp hay, bạn nên kết hợp cơ chế xoay khóa vào kiến ​​trúc ứng dụng của mình. Cuối cùng để tăng cường bảo mật, AWS khuyên bạn nên sử dụng xác thực đa yếu tố (MFA) cho tất cả các tài khoản người dùng, bao gồm các tùy chọn cho trình xác thực dựa trên phần cứng và tích hợp với các nhà cung cấp danh tính liên kết, chẳng hạn như thư mục công ty có sẵn để giảm chi phí quản trị và cải thiện người dùng cuối trải qua. Nếu người dùng đã có danh tính (thông tin xác thực người dùng) bên ngoài AWS, chẳng hạn như trong thư mục công ty, thì bạn có thể sử dụng liên kết danh tính cùng với đăng nhập một lần AWS (AWS-SSO) để đơn giản hóa quy trình quản lý người dùng. Bạn có thể sử dụng thông tin nhận dạng từ hệ thống thư mục công ty bên ngoài và sử dụng các vai trò thích hợp bên trong IAM để quản lý quyền. AWS Secrets Manager có thể được sử dụng để xoay, quản lý và truy xuất thông tin đăng nhập cơ sở dữ liệu, khóa API, cũng như bí mật Magento (tên người dùng / mật khẩu). Bạn có thể định cấu hình Trình quản lý bí mật để xoay vòng bí mật tự động, điều này có thể giúp bạn đáp ứng các nhu cầu về bảo mật và tuân thủ của mình. Secrets Manager cung cấp các tích hợp được tích hợp sẵn cho Amazon Aurora Amazon RDS và có thể xoay vòng thông tin xác thực cho các cơ sở dữ liệu này. Để truy xuất bí mật cho ứng dụng Magento, bạn có thể thay thế bí mật bản rõ bằng lệnh gọi tới API Trình quản lý bí mật, loại bỏ nhu cầu mã hóa bí mật trong mã nguồn hoặc cập nhật tệp cấu hình và triển khai lại mã khi bí mật được xoay vòng.

Giám sát và Ghi nhật ký

Luôn bật các công cụ theo dõi và ghi nhật ký phù hợp để cung cấp cho bạn khả năng hiển thị mà bạn cần để phát hiện các vấn đề trước khi chúng ảnh hưởng đến doanh nghiệp của bạn. AWS có nhiều dịch vụ cung cấp cho bạn khả năng hiển thị sâu (ai, cái gì, khi nào và từ đâu) chẳng hạn như 1) AWS CloudTrail cho các lệnh gọi API (yêu cầu truy cập), 2) Cấu hình AWS (lịch sử cấu hình), 3) Amazon CloudWatch để đạt được khả năng hiển thị trên toàn hệ thống về việc sử dụng tài nguyên, hiệu suất ứng dụng và tình trạng hoạt động và 4) nhật ký luồng VPC ghi lại tất cả lưu lượng mạng đi qua VPC. Ngoài ra, bạn có thể cấu hình CloudWatch Events để tự động cảnh báo cũng như ứng phó với các sự kiện bất lợi. Cuối cùng, Amazon GuardDuty là một dịch vụ phát hiện mối đe dọa tự động theo dõi liên tục hoạt động độc hại và hành vi trái phép bằng cách sử dụng máy học.

Hướng dẫn bảo mật

AWS cung cấp cho khách hàng hướng dẫn và kiến ​​thức chuyên môn thông qua các công cụ, tài nguyên, hỗ trợ trực tuyến và các dịch vụ chuyên nghiệp do AWS và các đối tác cung cấp. AWS Trusted Advisor is an online tool that inspects your AWS environment to help close security gaps, and finds opportunities to save money, improve system performance, and increase reliability. AWS Advisories and Security Bulletins provide advisories around current vulnerabilities and threats, and enable customers to work with AWS security experts to address concerns like reporting abuse, vulnerabilities, and penetration testing. Magento security center provides advisories around latest Magento patches and security updates. Magento security scan tool, a free tool from Magento Commerce, can be used to monitor your websites for security risks, update malware patches, and detect unauthorized access.

PCI DSS

AWS supports a variety of security standards and compliance certifications including the Payment Card Industry Data Security Standard (PCI DSS), which is a crucial requirement for organizations who process credit cards and store cardholder information. Organizations that fail to comply with PCI requirements can expect large fines, which can also result in canceling their ability to process payments. PCI compliance requires organizations to safeguard their customers’ payment card information following security requirements that include policies and procedures, software design, and network architecture. AWS is certified as a PCI DSS 3.2 Level 1 Service Provider, the highest level of assessment available. Magento Commerce (Cloud) is PCI certified as a Level 1 Solution Provider. Organizations can use AWS and Magento’s PCI Attestation of Compliance to aid their own PCI certification process. The PCI DSS certification for an organization involves attestation of the following 12 requirements, broken into 6 groups: 1) Build and Maintain a Secure Network, 2) Protect Cardholder Data 3) Maintain a Vulnerability Management Program, 4) Implement Strong Access Control Measures, 5) Implement Strong Access Control Measures and 6) Regularly Monitor and Test Networks. For more information on PCI Compliance, refer to PCI DSS resources on AWS website and PCI Security Standards Council website.

AWS Architecture Components

As you plan your migration from an on-premises environment to AWS, you may find yourself introduced to new concepts. The first of those is the concept of managed services, which, simply defined, is a specific capability delivered as a service. For example, Amazon Elastic File System (Amazon EFS) provides network file system (NFS) based storage, eliminating the need to otherwise manage a fleet of EC2 instances to accomplish the same. Another may be the scaling of shared services – so whereas before your on-premises environment may have consisted of a cluster of load balancing appliances, AWS offers (in a similar fashion as Amazon EFS described above) Elastic Load Balancing as a service, allowing you to manage the components used to deliver Magento in an end-to- end fashion. Yet another concept may be the physical architecture of AWS – where a singular AWS Region comprises numerous groups of physically isolated datacenters (each group of data centers is referred to as an Availability Zone), providing native support for not just N+1 or active/passive or active/active resiliency, but doing so in physically distributed manner without implementing complex solutions. In line with the above described services, where an on on-premises implementation of Magento may look like shared domain, networking, and load balancing services with an external content delivery network, all running on one or more servers (physical or virtual), in AWS, you may find yourself using any number of services to accomplish the same outcome from a service delivery perspective, while reducing cost and providing increased automation capabilities and increased scalability and resiliency capabilities.

Types of Services

Continuing the concepts described above, a typical collection of AWS services supporting your Magento environment, assuming no external or on-premises services are leveraged, might look like this: • Amazon Route 53 for DNS • Amazon CloudFront for content delivery network • Amazon S3 for static content storage • Elastic Loading Balancing through an Application Load Balancer for load balancing • AWS Auto Scaling Groups of Amazon EC2 (virtual machine) instances for the Magento execution environment • Amazon Elastic File System (Amazon EFS) for shared configuration/content storage • Amazon Relational Database Service (Amazon RDS) for the Magento database environment • Amazon ElastiCache for Redis for session and configuration caching • Amazon Simple Email Service (Amazon SES) as your mail gateway The above list, while detailed with regard to the Magento Environment itself, excludes numerous services providing supporting infrastructure of your platform (such as Amazon Virtual Private Cloud [Amazon VPC]) and as such this list should not be treated as a definitive list of services or requirements. Its intention is to illustrate the baseline AWS services you can leverage to host your Magento environment and eliminate unnecessary care and feeding of servers.

Monitoring

An additional benefit to leveraging managed services is that each service provides observability via metrics (CloudWatch Metrics), logs (CloudWatch Logs) and events (CloudWatch Events) providing the often-sought single pane of glass around each of your Magento environments. This data can include performance, exceptions (both technical measures) as well as business measures such as cost per transaction (via the CloudWatch API). This robust set of data, in addition to being available historically for reporting and near real time for dashboarding is also available for alerting – of both individuals in your organization and automations for self-healing processes. From an organizational operations perspective, each of the preceding services also support the application of arbitrary metadata (referred to as tags), which can be used to allocate costs (cost per environment, as an example), in conjunction with AWS configuration management service, AWS Config, as well as an AWS robust audit trail solution, AWS CloudTrail, which provides insight into user or service access and change to AWS services. Finally, services such as Application Load Balancer integrate into AWS X-Ray, which is the AWS distributed application tracing solution which provides for additional instrumentation into the execution environment of Magento and associated code.

DevOps

Access to on-demand compute and managed services, along with a common set of operational capabilities (authentication, authorization and auditing via AWS Identity and Access Management and CloudTrail, APIs and SDKs available on a variety of platforms and common metric, log and event ingestion services) support’s an organization’s goal towards automation. AWS provides numerous services that abstract procedural level automation of resource lifecycle management including AWS CloudFormation, AWS Elastic Beanstalk, AWS OpsWorks, Amazon Elastic Container Service (Amazon ECS), and Amazon Elastic Kubernetes Service (Amazon EKS), in addition to a rich ecosystem of third-party services such as Terraform, Ansible and others. There are multiple approaches with regards to managing a code base running in a compute environment. One such approach is using Amazon Machine Images (AMIs) where a machine image is programmatically configured at launch and cycled through with each code revision. Another approach is to statically maintain and configure managed machines leveraging agent or agent-based code deployment solutions. Lastly, container-based code deployments where a container is moved through different environments instead of code. Each of these have their own strengths and weaknesses, however, container-based code deployments are becoming more common and support additional compute services such as AWS Fargate, a serverless container solution. Regardless of the approach, the primary objective should be to maintain the compute environments in a hands-off approach with best security practices and monitoring solutions that provide good operational support. For Magento, the management of the application lifecycle involves many of the same concepts, considered best practices and leveraged by other development platforms such as the use of a code repository and versioning (Git), separate build environments (for code compilation) and separate runtime environments (eg development, production. In addition, Magento supports the management of stores, cron entries etc. via the command line. This management logic can be built into the deployment pipeline. Also the configuration files can be versioned similar to code. Magento recommends management of assets via the same code repository as the application and configuration files, but this may create additional complexity, depending on the size of your application’s assets. As an alternative approach, you can use one-way synchronization between environment specific Amazon Elastic File System (Amazon EFS) volumes.

Figure 3 – Reference architecture for DevOps using containers

Connectivity

The migration of Magento may be part of an enterprise cloud adoption strategy, driven by a compelling event or a combination of the two. Regardless of the reasons, make sure to consider systems dependent on Magento and the systems Magento depends on. Connectivity between the Magento systems running in AWS and these dependent systems (whether in AWS, a data center, or a SaaS/PaaS provider) is key to planning and successfully executing a migration. Make sure to also consider connectivity for Magento admin, System admin, Database admin and Infrastructure admin.

Types of Connectivity

Five connectivity channels are available in AWS: • API (serverless resources such as Amazon S3, Amazon DynamoDB, etc.) • Internet (publicly routed, typically brokered via SFTP based automation) • VPN (IPSEC/B2B) • AWS Direct Connect (Dedicated connectivity, via either a physical or logical connection) • Intra VPC (typically environment:tier <-> environment:tier), • Inter VPC (via Peering or Transit Gateway) and AWS PrivateLink (typically private connectivity, AWS based SaaS offerings). Whether your connectivity is between tiers, environments, other services within your enterprise on and off AWS or with a partner, each of these approaches has advantages and disadvantages associated with them.

Network Dependencies

Of most importance, however, is fully understanding the network dependency map that exists within your Magento environment ahead of migration. Having a dependency map can help better plan the steps required in the migration and avoid accelerated post migration changes required to account for missed dependencies, both building to support a successful migration. Investigation around this might begin with reviewing load balancer and firewall configurations as they relate to host names and IP Addresses of the servers Magento is running on, the Magento and related service configurations and any associated logs – particularly load balancer, firewall, and application performance management (APM) logs which may provide hints around third-party services not otherwise discoverable.

Service Congruency

For example, a typical Magento environment is likely accessed from the Internet via a Load Balancing appliance or a Firewall providing NAT Public IP Address space, and may have integrations to other internet-based services (eg a web service offered by a payment processor or shipping company) as well as legacy integrations via SFTP or a similar internet-based file sharing service.

These legacy integrations described earlier would translate into AWS services in the way of an Application Load Balancer on one set of subnets protected via a Security Group and Web Application Firewall, to a fleet of EC2 instances running Magento dependent services. A NAT gateway providing egress access to internet based services. Same or separate fleet of EC2 instances for providing integration with other internet services such as payment processors, or leverage serverless solutions such AWS lambda and AWS Transfer for SFTP for Amazon S3 based on the use-case.

Figure 4 – Reference architecture showing service congruencies for containers

Migration Plan

This section steps through an example migration, broken into four phases:

Planning

Planning in migration involves identifying goals, scope and business requirements. Often overlooked, and related to these items, are having quantifiable goals as measures of success, specifically with regard to performance (eg performance shall remain the same or be improved by x margin) as well as a full understanding of the components that comprise the to-be-migrated environment(s). To solve for the first, you can use the existing monitoring used in your enterprise or use AWS native monitoring capabilities. Rather than focusing on machine level statistics (CPU, memory, storage consumption, storage IO, network consumption, etc.), which are important with regard to machine configuration, focus on end-user experience – eg response times for key activities, such as adding to cart, checking out, payment, etc. To solve for the second, you can use existing financial records, inventories, or monitoring to identify the components that comprise each environment, including those that may not be evident (eg virtualized or delivered as a third-party solution, such as DNS or CDN).

Staging

After you have identified measures of success and completed the discovery, you should have a sense of the baseline services required to support your application. Compared to your existing AWS footprint (if there is one) you may opt to create an entirely new AWS Account or Amazon VPC, use an existing AWS Account or Amazon VPC, or go through the collective supporting characteristics for first time AWS adoption found in the AWS Landing Zone Solution. Once this work is complete, you can begin prototyping your environment on AWS – familiarizing yourself with some of the services mentioned above and identifying potential replacements to share service, appliance or server based services. This is the re-platforming approach. Once this is setup, you can begin to stage an environment for your first test migration. This environment would essentially replicate your current production environment from a software, configuration, code, and management perspective and aim to test both basic functionality of the platform as well as your data backup/restore and/or data replication processes that will be leveraged during the actual migration. This would be your second decision point for rehosting versus re-platforming: there are multiple approaches you can take to migrating your servers to AWS – from as basic as exporting a virtual machine and importing it into AWS, to using CloudEndure Migration for real time replication of the machine. While opinions vary on the subject, the reader is strongly encouraged to take an approach biased to re-platforming as it presents an opportunity to significantly improve operations of the platform with minimal (but not nonexistent) up front work. This first attempt at the migration provides you with a harness to execute, record, measure and modify the previously defined plans and tests, understand baseline performance as well as capture step-timings and improve the overall cutover plan. This step can be repeated as often or as frequently as needed until a comfort level is obtained to move into the next step.

Cutover

The final step of the migration process is the live migration from the current on-premises environment to the AWS based environment. Essentially the process is similar as the previous step, though you will likely place the store in maintenance mode and/or use a static maintenance site to prevent live transactions during the most critical parts of the cutover. An important part of this step is to have agreement with all participating parties around the maximum time to be spent on each step as well as critical milestone steps having pass/fail criteria along with rollback criteria in the event of a failure. Having these steps defined ahead of time avoid last minute decisions based on arbitrary criteria from being made in the event an unanticipated challenge is met (gamedays, tabletop exercises or simulations attempt to drive a similar thought process). At this point you’ve effectively migrated your Magento platform to AWS, and you can begin the decommissioning process – first through soft methods (eg stopping services) on to harder methods (decommissioning of virtual machines and servers). The cutover process varies based on the specific Magento installations architecture, but in general, you want to stop existing Magento processes as well as disable any scheduled cron jobs. You can redirect traffic by changing the current content delivery network (CDN) configuration, the current DNS configuration (ensuring as part of premigration you’ve lowered the TTL) or, optionally, using the EC2 instances on AWS as new upstream targets for your current load balancer (this being the least preferred option). Some customers may use this as an opportunity to change DNS or CDN providers and these migration activities can be performed as part of a pre-migration or post-migration, following their own migration process and steps.

Optimization

Previously made architecture decisions can also be revisited post-migration. For example, if you used a rehost approach, you can evaluate and re-platform post- migration services, or right-size services based on current and forecasted load. This period of time is an excellent period to evaluate potential opportunities for reserved instance purchases, which offer a discount to service cost in trade for commitment to use a service for a period of time (ideal for Amazon RDS, Amazon ElastiCache and permanent Amazon EC2 instances in production).

Magento M1 to M2 Migration

Magento 1.x versions (M1) to Magento 2.x versions (M2) migration consists of four main components:

1. Data Migration,
2. Extensions Migration,
3. Custom Code Migration
4. Theme migrations A deep dive into these four areas specific to how the organization has setup M1 outlines the challenges and the migration strategy. Magento has developed the Data Migration Tool for data migration and Code Migration Toolkit for code migration. These resources are described in detail in the Magento Migration Guide.

Magento Hardware Sizing Guidelines on AWS

As per Magento hardware recommendations, Magento recommends that one CPU core can effectively serve around two (up to four) Magento requests along with one cron process simultaneously. Determine your organization’s stable expected request rate to find the appropriate number of cores needed to support your application and use automatic scaling to dynamically extend web tier nodes as needed. N[Cores] = (N[Expected Requests] / 2) + N [Expected Cron Processes]

In addition, Magento recommends at least 2 GB memory on build servers and 1 GB on web nodes along with sufficient network bandwidth to prevent bottlenecks on read-write operations. Keeping these principles in mind, choose the appropriate instance from the Amazon EC2 instance types that balances your organization’s cost and business needs. Instance types from the Amazon EC2 general purpose family (especially M types) provide a good balance between compute, memory, and network resources for Magento applications.

Backups and Disaster Recovery

As a best practice, explore backup and disaster recovery options based on your business needs. Backup and disaster recovery options depend on the deployment option and database choices (Amazon RDS vs Amazon Aurora) you choose. Your organization’s business needs dictate the recovery point objective (RPO) (ie maximum time to last backup and the recovery time objective (RTO). RTO often varies depending upon the size of your organization’s storage. At a minimum, we recommend that you take regular database backups and have a working copy of the AWS CloudFormation template to provision the infrastructure when needed in case a recovery situation arises. Alternately, you can choose to have a working Amazon Machine Image (AMI) copy that has Magento installed along with your organization’s latest changes or customizations. You can use this AMI to provision infrastructure using an AWS CloudFormation template to reduce the overall RTO.

Conclusion

This paper presented the business drivers for migrating Magento to the AWS Cloud along with the strategies and considerations. Migrating Magento eCommerce software on AWS provides a secure and scalable foundation for delivering great digital experiences for customers. As you prepare for your Magento migration to AWS, we recommend that you consider the guidance outlined in this document and consult the additional references provided in the following Further Reading section.