Firma uruchamia procesy ML na lokalnym klastrze Kubernetes. Każda usługa ML jest spakowana jako samodzielny obraz Docker. Muszą przenieść i uruchomić te usługi w klastrze Amazon EKS przy minimalnym nakładzie operacyjnym. Które rozwiązanie spełnia to wymaganie?

Prawidłowa odpowiedź to wypchnięcie obrazów Docker do Amazon ECR i skonfigurowanie potoku wdrożeniowego. Firma już używa obrazów Docker i klastra Kubernetes lokalnie. Amazon EKS to zarządzana usługa Kubernetes, która jest kompatybilna z istniejącymi obrazami Docker. Przeniesienie obrazów do ECR i wdrożenie ich za pomocą potoku to minimalny wysiłek operacyjny, ponieważ wykorzystuje istniejącą architekturę kontenerową. Przeprojektowanie usług ML pod Kubeflow wymagałoby znaczących zmian w kodzie i architekturze, co jest dużym wysiłkiem operacyjnym. Przeniesienie danych treningowych do Amazon Redshift i ponowne trenowanie modeli za pomocą Redshift ML, a także tworzenie notebooka Amazon SageMaker i ponowne trenowanie modeli, to rozwiązania, które zmieniają całą platformę ML, co jest znacznie większym wysiłkiem niż migracja istniejących kontenerów.