Η εβδομάδα της 7ης Σεπτεμβρίου ήταν η εβδομάδα που το AWS Transform for .NET έπαψε να είναι εργαλείο που κλικάρετε και έγινε βήμα που βάζετε σε ένα pipeline. Ένα CLI μίας γραμμής έγινε γενικά διαθέσιμο, η ίδια μετατροπή άρχισε να παράγει unit tests για τον κώδικα που ξαναγράφει, και το AWS Transform έφτασε στο GovCloud (US-West) για server migration. Γύρω του, τα Lambda Managed Instances απέκτησαν timeout 90 λεπτών και Graviton5, τα EBS Volume Clones έμαθαν να περνούν όρια λογαριασμών με επανακρυπτογράφηση, και ένα Outposts μονού rack 42U έγινε GA.

AWS Transform for .NET: CLI, tests, GovCloud

Τρία launches, μία κατεύθυνση. Στις 9 Σεπτεμβρίου το AWS Transform for .NET modernization έγινε γενικά διαθέσιμο μέσω CLI: μία εντολή πυροδοτεί μια μετατροπή που διαχειρίζεται η AWS στο AWS Transform custom, και μπορείτε να την τρέξετε διαδραστικά ή να την βάλετε σε script σε υπάρχον pipeline για να τρέχει χωρίς επίβλεψη. Η μετατροπή περιλαμβάνει 50.000 δωρεάν agent minutes τον μήνα και είναι διαθέσιμη σε οκτώ Regions: N. Virginia, Mumbai, Tokyo, Seoul, Sydney, Canada (Central), Frankfurt και London.

Στις 10 Σεπτεμβρίου το AWS Transform for .NET άρχισε να παράγει unit tests για εκσυγχρονισμένο κώδικα. Αξιολογεί την εφαρμογή ως προς την testability παράλληλα με την κανονική αξιολόγηση .NET, σχεδιάζει ποιες κλάσεις και μέθοδοι να καλυφθούν (business logic, controllers), και εκπέμπει τον κώδικα των tests ως μέρος του ίδιου job. Opt-in, ενεργοποιείται στην έναρξη του job ή μετά την ολοκλήρωση της μετατροπής, προς το παρόν μέσω του AWS Toolkit for Visual Studio.

Και στις 8 Σεπτεμβρίου το AWS Transform έφτασε στο AWS GovCloud (US-West). Το πεδίο έχει σημασία: πρόκειται για τη δυνατότητα server migration (VMware, bare metal, Hyper-V, workloads βάσεων δεδομένων, replication και cutover σε οποιοδήποτε από τα δύο GovCloud Regions). Το modernization, το custom transformation και το assessment μένουν προς το παρόν στα εμπορικά Regions.

Το CLI είναι αυτό που μετράει: ένα modernization που ζει σε IDE είναι project, ένα modernization που τρέχει σε CI είναι διαδικασία. Μπορείτε να τρέχετε τη μετατροπή σε ένα branch κάθε νύχτα, να κάνετε diff το output με το χθεσινό, και να αντιμετωπίζετε τον agent όπως κάθε άλλο build step που είτε περνά είτε όχι. Έτσι εκσυγχρονίζετε 80 services αντί για 8.

Ο τρόπος αστοχίας για τον οποίο πρέπει να σχεδιάσετε είναι τα tests. Ένα test suite που παράγεται από τον μετατραπέντα κώδικα κωδικοποιεί τη συμπεριφορά του μετατραπέντος κώδικα. Είναι δίχτυ regression για οτιδήποτε αλλάξετε μετά το migration, κάτι πολύτιμο, αλλά δεν αποδεικνύει ότι το migration διατήρησε τη συμπεριφορά του πρωτότυπου .NET Framework. Για αυτό χρειάζεστε ακόμα το παλιό suite, ή characterization tests γραμμένα έναντι του παλιού binary, να τρέχουν έναντι του νέου. Χρησιμοποιήστε τα παραγόμενα tests ως δάπεδο, όχι ως έγκριση.

Lambda Managed Instances: 90 λεπτά και Graviton5

Στις 9 Σεπτεμβρίου η Lambda πρόσθεσε timeout function 90 λεπτών στα Lambda Managed Instances για ασύγχρονες κλήσεις και κλήσεις event source mapping, έξι φορές το ταβάνι των 15 λεπτών που όριζε την αρχιτεκτονική Lambda για μια δεκαετία. Οι σύγχρονες κλήσεις κρατούν τα 15 λεπτά. Το μεγαλύτερο όριο ισχύει και για βήματα μέσα σε Lambda durable functions. Την ίδια ημέρα, τα Managed Instances απέκτησαν instances C9g, C9gd, M9g και M9gd με Graviton5, που η AWS βαθμολογεί με έως 25% καλύτερη απόδοση compute από το Graviton4.

Τα Managed Instances είχαν ήδη αλλάξει το μοντέλο τιμολόγησης (οικονομικά EC2 instance, πολλαπλά παράλληλα requests ανά instance) και αυτή η αλλαγή ολοκληρώνει τη σκέψη: είναι ένα managed compute fleet με μοντέλο προγραμματισμού σε σχήμα function. Media transcodes, εκτελέσεις Monte Carlo και batch inference παύουν να χρειάζονται αλυσίδα Step Functions ή ECS task μόνο για να περάσουν το δεκαπεντάλεπτο.

Τι δεν αλλάζει: οι ασύγχρονες κλήσεις είναι at-least-once. Ένα job 90 λεπτών που ξαναδοκιμάζεται μετά από μερική αστοχία σάς κοστίζει 90 λεπτά δύο φορές και, αν γράφει καθώς προχωρά, αφήνει μισογραμμένο αποτέλεσμα. Τα idempotency keys και το checkpointing μετρούν περισσότερο στα 90 λεπτά, όχι λιγότερο. Και επειδή τα Managed Instances χρεώνονται ως χωρητικότητα EC2, κάντε τη σύγκριση κόστους έναντι ενός Fargate task ή ενός AWS Batch job ρητά πριν μετακινήσετε ένα workload μεγάλης διάρκειας. Το κέρδος είναι λειτουργικό, όχι αυτόματα οικονομικό.

Τα EBS Volume Clones περνούν accounts, με νέα κλειδιά

Στις 9 Σεπτεμβρίου τα EBS Volume Clones άρχισαν να υποστηρίζουν αντίγραφα μεταξύ λογαριασμών AWS, επανακρυπτογραφώντας με KMS key του λογαριασμού προορισμού. Η ροή: μοιράζετε τον source volume μέσω AWS RAM, μετά ο λογαριασμός προορισμού δημιουργεί αντίγραφο στην ίδια Availability Zone. Δουλεύει για όλους τους τύπους volume, μαζί με μη κρυπτογραφημένους volumes και volumes υπό customer managed keys.

Η περίπτωση χρήσης με την οποία ξεκινά η AWS είναι η σωστή: ένα φρέσκο αντίγραφο ενός production database volume σε έναν απομονωμένο development λογαριασμό. Ο παλιός τρόπος ήταν snapshot, share του snapshot, copy του snapshot με νέο κλειδί, δημιουργία volume, τέσσερα βήματα και πολλή αναμονή. Ο νέος τρόπος είναι ένα copy με ενσωματωμένο διαχωρισμό κλειδιών, που είναι αυτό που πραγματικά απαιτεί ο κανόνας "τα prod κλειδιά δεν φεύγουν ποτέ από το prod" ενός landing zone.

Δύο πράγματα που μια ομάδα platform πρέπει να γράψει. Πρώτον, "ίδια Availability Zone" σημαίνει την ίδια φυσική ζώνη, και τα ονόματα ζωνών (eu-west-1a) αντιστοιχίζονται διαφορετικά ανά λογαριασμό. Χρησιμοποιήστε AZ IDs (euw1-az1) σε κάθε αυτοματισμό, αλλιώς το αντίγραφο προσγειώνεται σε ζώνη που τα dev subnets σας δεν καλύπτουν. Δεύτερον, η κλωνοποίηση δεδομένων production σε dev είναι γεγονός data governance, όχι γεγονός storage. Βάλτε το RAM share πίσω από έγκριση και καταγράψτε ποιος αντέγραψε τι. Οι εύκολοι μηχανισμοί χρειάζονται ρητούς ελέγχους.

Επίσης αυτή την εβδομάδα

Το κοινό νήμα

Κάθε τίτλος αυτής της εβδομάδας μετακίνησε κάτι από το "το κάνει ένας άνθρωπος" στο "το κάνει ένα pipeline". Το Transform τρέχει από το CLI και γράφει τα δικά του tests. Η Lambda κρατά ένα job για 90 λεπτά ώστε να πάψετε να φτιάχνετε με το χέρι orchestration γύρω από το δεκαπεντάλεπτο. Το EBS αντιγράφει έναν prod volume σε dev με το σωστό κλειδί σε μία λειτουργία. Το Systems Manager σάς λέει γιατί το instance είναι unmanaged αντί να σάς βάζει να μαντεύετε. Καθένα αφαιρεί ένα ανθρώπινο βήμα από μια διαδικασία που παλιά το χρειαζόταν. Η δουλειά για μια ομάδα platform είναι να αποφασίσει ποια από αυτά τα βήματα υπήρχαν για κάποιον λόγο (η έγκριση πριν τα prod δεδομένα φύγουν από το prod) και να τα κρατήσει, συνειδητά, τώρα που τα εργαλεία δεν σάς το επιβάλλουν πια.

Διαβάστε στη συνέχεια

Για την ανάγνωση της ίδιας εβδομάδας από την πλευρά του AI και των agents, δείτε το ercan.ai. Αν η ομάδα σας χρειάζεται πρακτική βοήθεια με AWS, cloud αρχιτεκτονική, CI/CD pipelines, Linux, GitHub ή GitLab, και τη δουλειά platform γύρω τους, η συμβουλευτική πλευρά ζει στο ercanermis.com.

Αναφορές