AWS Transform potrafi teraz konwertować kod Azure SDK w aplikacjach .NET na kod AWS SDK
AWS twierdzi, że jego agent modernizacji .NET przepisuje teraz wywołania wybranych usług Azure na ich odpowiedniki w AWS, obejmując kod aplikacji, ale nie infrastrukturę.
Najważniejsze informacje
- 1AWS udostępnił w ramach ogólnej dostępności konwersję kodu Azure SDK na AWS SDK w AWS Transform, co ogłoszono 16 października.
- 2Obsługiwane ścieżki według AWS: Azure Functions na Lambda, Blob Storage na S3, Queue Storage na SQS; Cosmos DB na DynamoDB jest w wersji zapoznawczej.
- 3Funkcja konwertuje wyłącznie kod aplikacji i nie migruje infrastruktury chmurowej, według podręcznika użytkownika.
- 4Opcje konwersji pojawiają się w raporcie z oceny i planie modernizacji i można je dostosować lub z nich zrezygnować.
- 5Kod niemożliwy do konwersji jest oznaczany komentarzami TODO, kodem zastępczym (stub) lub w wygenerowanym pliku Next Steps, twierdzi AWS.
Cały tekst
AWS udostępnił w ramach ogólnej dostępności konwersję kodu z Azure SDK na AWS SDK w AWS Transform, według ogłoszenia opublikowanego 16 października. Firma przedstawia tę funkcję jako szybszy sposób przeniesienia na AWS aplikacji .NET natywnych dla chmury, zbudowanych dla Microsoft Azure. Według AWS agent modernizacji .NET w AWS Transform lokalizuje kod wywołujący usługi Azure i przepisuje go tak, aby korzystał z odpowiadających im usług AWS.
AWS wymienia cztery obsługiwane konwersje: Azure Functions są przepisywane na funkcje AWS Lambda, kod Azure Blob Storage jest przenoszony do Amazon S3, a kod Azure Queue Storage jest przenoszony do Amazon SQS, natomiast konwersja kodu Azure Cosmos DB na Amazon DynamoDB jest oferowana w wersji zapoznawczej (preview). Podręcznik użytkownika stwierdza, że konwertowane są wyłącznie te wymienione usługi, i sugeruje dla innych usług AWS Transform custom lub asystenta kodowania AI, takiego jak Kiro. AWS zaznacza też, że funkcja obsługuje wyłącznie kod aplikacji i nie migruje infrastruktury chmurowej.
Według AWS usługa wykrywa Azure SDK w przesłanym kodzie źródłowym i przedstawia opcje konwersji w swoim raporcie z oceny oraz planie modernizacji, które użytkownicy mogą zaakceptować lub dostosować przed uruchomieniem modernizacji. AWS twierdzi, że następnie sprawdza, czy zmiany zostały uwzględnione w przekształconym kodzie. Dokumentacja opisuje konwersję jako automatyczną dla kwalifikujących się nowoczesnych aplikacji .NET, a jej zachowanie można regulować poprzez czat z agentem, edycję planu lub dokument sterujący, na przykład aby pominąć niektóre lub wszystkie konwersje, ustalić konwencje nazewnictwa, zmienić szczegółowość komentarzy albo skierować kod Blob Storage na DynamoDB zamiast na S3.
Kod, który nie ma odpowiednika w AWS, jest oznaczany, a nie konwertowany: podręcznik użytkownika podaje, że jest on opatrywany komentarzami TODO, pozostawiany jako kod zastępczy (stub) lub odnotowywany w pliku markdown Next Steps generowanym przez AWS Transform. AWS twierdzi, że AWS Transform jest oferowany w ośmiu regionach AWS, a mianowicie we Frankfurcie i Londynie w Europie, w Bombaju, Tokio, Seulu i Sydney w regionie Azji i Pacyfiku, a także w regionach Canada (Central) i US East (N. Virginia).
Dlaczego to ważne
Przepisywanie wywołań SDK specyficznych dla poszczególnych usług to znacząca część pracy przy przenoszeniu aplikacji .NET z Microsoft Azure. AWS automatyzuje część tej pracy dla niewielkiego zestawu usług, choć zespoły nadal muszą osobno migrować infrastrukturę i zająć się wszelkim kodem, który narzędzie oznaczy jako nieskonwertowany.
Oś czasu
· Opublikowano
Tematy#AWS Transform#Microsoft Azure#.NET#migracja do chmury#AWS Lambda#modernizacja kodu
Źródła
Ten tekst opiera się na poniższych źródłach. Przeczytaj je, aby poznać pełny kontekst.
