Επεξήγηση του cloud computing: οι 11 έννοιες αρχιτεκτονικής που πρέπει να γνωρίζετε (4K Masterclass).

Τι καλύπτει αυτό το βίντεο

• - Ο Τοίχος Αρχιτεκτονικής & το Κύριο Σχέδιο
• - 01. Κάθετη vs. Οριζόντια Κλιμάκωση
• - 02. Αρχιτεκτονική Εξισορρόπησης Φορτίου (L4 vs. L7 & Έλεγχοι Υγείας)
• - 03. Αυτόματη Κλιμάκωση & Ελαστικότητα
• - 04. Serverless (FaaS & Firecracker MicroVMs)

Μεταφρασμένη μεταγραφή

Μεταφράστηκε από την πρωτότυπη αγγλική αφήγηση. Ο διαθέσιμος ήχος και οι υπότιτλοι ελέγχονται από το YouTube.

- Ο Τοίχος Αρχιτεκτονικής & το Κύριο Σχέδιο

0:00 Κάθε μηχανικός λογισμικού αντιμετωπίζει τελικά τον τοίχο της αρχιτεκτονικής του cloud. Φτιάχνετε μια εφαρμογή στον φορητό υπολογιστή σας, την ανεβάζετε στην παραγωγή, και τη στιγμή που φτάνουν πραγματικοί χρήστες, οι διακομιστές καταρρέουν, οι συνδέσεις της βάσης δεδομένων εξαντλούνται και ο λογαριασμός σας στο AWS μοιάζει με αριθμό τηλεφώνου. Οι περισσότεροι προγραμματιστές προσπαθούν να λύσουν το cloud engineering απομνημονεύοντας τριακόσια διαφορετικά ακρωνύμια προϊόντων AWS. Αλλά το πραγματικό cloud computing δεν αφορά την απομνημόνευση καταλόγων προμηθευτών: βασίζεται σε έντεκα θεμελιώδεις αρχιτεκτονικές πρωταρχικές έννοιες.

0:34 Σε αυτό το masterclass, θα εξερευνήσουμε ολόκληρο το επιχειρησιακό σχέδιο: από την κλιμάκωση και την εξισορρόπηση φορτίου μέχρι το serverless, την αποσύνδεση με βάση τα γεγονότα, τις ιεραρχίες αποθήκευσης και τη δικτύωση cloud. Κατακτήστε αυτές τις έντεκα έννοιες και μπορείτε να σχεδιάσετε οποιοδήποτε backend σε AWS, GCP ή Azure. Αυτό είναι το The Daily Diff, «κάτω από το καπό».

- 01. Κάθετη vs. Οριζόντια Κλιμάκωση

0:57 Έννοια νούμερο ένα: Κλιμάκωση. Όταν η εφαρμογή σας βιώνει αύξηση στην κίνηση, έχετε δύο θεμελιωδώς διαφορετικούς τρόπους να χειριστείτε το φορτίο: κάθετη κλιμάκωση ή οριζόντια κλιμάκωση. Κάθετη κλιμάκωση, ή αύξηση, σημαίνει να πάρετε την υπάρχουσα μηχανή σας και να προσθέσετε περισσότερους πόρους: αναβάθμιση από τέσσερις πυρήνες CPU σε τριάντα δύο, ή ανταλλαγή τριάντα δύο gigabytes RAM για εκατό είκοσι οκτώ. Η κάθετη κλιμάκωση απαιτεί μηδενικές αρχιτεκτονικές αλλαγές: ο κώδικας

1:28 και η βάση δεδομένων σας παραμένουν ακριβώς οι ίδιοι. Αλλά φτάνει σε ένα βάναυσο όριο υλικού. Καμία μεμονωμένη μηχανή στον κόσμο δεν έχει δέκα χιλιάδες πυρήνες CPU, και οι κορυφαίες περιπτώσεις φέρουν εκθετικό premium τιμής. Οριζόντια κλιμάκωση, ή επέκταση, σημαίνει να διατηρείτε τους διακομιστές σας μικρούς και σε τιμή εμπορεύματος, αλλά να εκτελείτε πολλαπλές περιπτώσεις παράλληλα πίσω από έναν δρομολογητή. Εάν μια περίπτωση καταρρεύσει, οι υπόλοιποι κόμβοι απορροφούν την κίνηση με μηδενικό χρόνο διακοπής λειτουργίας. Ο χρυσός κανόνας της οριζόντιας κλιμάκωσης είναι η

2:01 ακατάσταση: οι διακομιστές εφαρμογών σας δεν μπορούν να αποθηκεύουν συνεδρίες χρηστών, ανεβασμένα αρχεία ή κατάσταση στους τοπικούς τους δίσκους. Η κατάσταση πρέπει να ζει σε μια εξωτερική βάση δεδομένων ή κρυφή μνήμη, επιτρέποντας σε οποιοδήποτε κόμβο να χειριστεί οποιοδήποτε αίτημα χρήστη.

- 02. Αρχιτεκτονική Εξισορρόπησης Φορτίου (L4 vs. L7 & Έλεγχοι Υγείας)

2:17 Έννοια νούμερο δύο: Εξισορρόπηση Φορτίου. Η οριζόντια κλιμάκωση ακούγεται υπέροχη στα χαρτιά, αλλά εισάγει ένα άμεσο πρόβλημα: όταν δέκα χιλιάδες χρήστες χτυπούν το όνομα τομέα σας, ποιος συγκεκριμένος διακομιστής λαμβάνει την κίνησή τους; Ένας εξισορροπιστής φορτίου λειτουργεί ως αντίστροφος διακομιστής μεσολάβησης που βρίσκεται μεταξύ του δημόσιου διαδικτύου και του ιδιωτικού σας backend cluster. Δέχεται εισερχόμενες συνδέσεις TCP ή HTTP και διανέμει αιτήματα στις υγιείς περιπτώσεις σας.

2:47 Οι εξισορροπιστές φορτίου λειτουργούν σε δύο κύρια επίπεδα δικτύου. Οι Εξισορροπιστές Φορτίου Δικτύου Επιπέδου 4 λειτουργούν στο επίπεδο μεταφοράς, δρομολογώντας ακατέργαστα πακέτα TCP και UDP βάσει διεύθυνσης IP και θύρας με καθυστέρηση μικροδευτερολέπτων και εκατομμύρια αιτήματα ανά δευτερόλεπτο. Οι Εξισορροπιστές Φορτίου Εφαρμογών Επιπέδου 7 επιθεωρούν το πρωτόκολλο HTTP το ίδιο: διαβάζοντας διαδρομές URL, κεφαλίδες αιτημάτων, cookies και μεθόδους HTTP. Αυτό επιτρέπει τη δρομολόγηση βάσει διαδρομής: αποστολή αιτημάτων slash-api στο backend cluster σας και αιτημάτων slash-static σε ένα

3:25 αποθηκευτικό χώρο αντικειμένων. Καίρια, οι εξισορροπιστές φορτίου εκτελούν ενεργούς ελέγχους υγείας. Κάθε λίγα δευτερόλεπτα, ο εξισορροπιστής στέλνει ένα ping σε ένα σημείο τελικής λειτουργίας υγείας σε κάθε περίπτωση. Εάν μια περίπτωση εκτοξεύσει τρία συνεχόμενα σφάλματα πεντακοσίων ή αποτύχει να ανταποκριθεί, αυτόματα εκδιώκεται από την ομάδα με μηδέν χαμένα αιτήματα.

- 03. Αυτόματη Κλιμάκωση & Ελαστικότητα

3:45 Έννοια νούμερο τρία: Αυτόματη Κλιμάκωση. Εάν η εφαρμογή σας χρειάζεται δύο διακομιστές στις τρεις το πρωί, αλλά είκοσι διακομιστές κατά τη διάρκεια μιας μεσημεριανής εκτόξευσης, το χειροκίνητο κλικ κουμπιών στην κονσόλα cloud είναι ένας εγγυημένος δρόμος προς διακοπή λειτουργίας και χρεοκοπία. Η αυτόματη κλιμάκωση φέρνει δυναμική ελαστικότητα σε οριζόντιες δεξαμενές διακομιστών. Μια Ομάδα Αυτόματης Κλιμάκωσης παρακολουθεί μετρικές απόδοσης όπως η μέση χρήση CPU, η είσοδος-έξοδος δικτύου ή το βάθος της ουράς εκκρεμών εργασιών. Όταν η μέση CPU υπερβεί ένα καθορισμένο όριο — ας πούμε,

4:19 εβδομήντα τοις εκατό για τρία συνεχόμενα λεπτά — ο αυτόματος κλιμακωτής αυτόματα εκκινεί νέες εικονικές μηχανές, τις καταχωρεί στον εξισορροπιστή φορτίου σας, και αρχίζει να δρομολογεί την κίνηση. Εξίσου σημαντική είναι η κλιμάκωση προς τα κάτω: όταν υποχωρεί το κύμα κίνησης, ο αυτόματος κλιμακωτής τερματίζει τις επιπλέον περιπτώσεις ώστε να σταματήσετε να πληρώνετε για αδρανή υπολογιστική ισχύ. Για να αποφευχθεί το 'flapping' — όπου οι διακομιστές δημιουργούνται και καταστρέφονται γρήγορα σε έναν ατελείωτο βρόχο θραύσης — οι αρχιτέκτονες cloud διαμορφώνουν περιόδους ψύξης. Έννοια νούμερο τέσσερα: Serverless.

- 04. Serverless (FaaS & Firecracker MicroVMs)

4:53 Για χρόνια, οι ομάδες μάρκετινγκ παρουσίαζαν το serverless ως μαγικό κώδικα που τρέχει στον ουρανό. Στην πραγματικότητα, το serverless εξακολουθεί να χρησιμοποιεί διακομιστές — αλλά δεν τους κατέχετε, δεν τους ενημερώνετε ή δεν τους πληρώνετε όταν δεν εκτελείται κώδικας. Με το Function-as-a-Service, όπως το AWS Lambda ή το Google Cloud Functions, γράφετε μια αυτόνομη συνάρτηση χειριστή. Όταν συμβαίνει ένα αίτημα HTTP, μια μεταφόρτωση αρχείου S3 ή μια αλλαγή βάσης δεδομένων, το cloud runtime εκκινεί μια εφήμερη

5:23 micro-virtual-machine όπως το Firecracker σε λιγότερο από πέντε χιλιοστά του δευτερολέπτου. Ο κώδικας σας εκτελείται, επιστρέφει μια απάντηση και απενεργοποιείται. Εάν κανείς δεν επισκεφτεί τον ιστότοπό σας για τρεις μήνες, ο λογαριασμός σας για υπολογιστική ισχύ είναι ακριβώς μηδέν δολάρια και μηδέν λεπτά. Εάν ένα εκατομμύριο χρήστες το επισκεφτούν ταυτόχρονα, ο πάροχος ξεκινά ένα εκατομμύριο ταυτόχρονες microVMs. Οι μηχανικές ανταλλαγές είναι πραγματικές: καθυστέρηση ψυχρής εκκίνησης κατά την εκκίνηση νέων runtimes, ένα σκληρό όριο εκτέλεσης δεκαπέντε λεπτών στο Lambda, και αυστηρή ακαταστασία.

5:55 Το Serverless είναι ασυναγώνιστο για event pipelines και σποραδικά API, αλλά κακό για persistent WebSockets ή πολυώρες εκπαιδευτικές εκτελέσεις.

- 05. Αρχιτεκτονική Καθοδηγούμενη από Γεγονότα (EDA & Αποσύνδεση)

6:05 Έννοια νούμερο πέντε: Αρχιτεκτονική Καθοδηγούμενη από Γεγονότα, ή EDA. Στις παραδοσιακές αρχιτεκτονικές, οι υπηρεσίες επικοινωνούν συγχρονικά. Η υπηρεσία πληρωμής σας καλεί την πληρωμή, η πληρωμή καλεί την απογραφή, η απογραφή καλεί την απάτη, και η απάτη καλεί το email. Αυτό δημιουργεί τον συγχρονικό καταρράκτη της καταστροφής. Εάν ο τρίτος πάροχος email αντιμετωπίσει ένα πρόβλημα δικτύου και χρειαστεί δέκα δευτερόλεπτα για να ανταποκριθεί, ολόκληρο το αίτημα αγοράς του πελάτη σας λήγει με ένα σφάλμα. Σε μια αρχιτεκτονική βασισμένη σε γεγονότα, οι υπηρεσίες είναι πλήρως αποσυνδεδεμένες.

6:37 Όταν ένας πελάτης κάνει κλικ στο 'αγορά', η υπηρεσία πληρωμής δεν καλεί τις επόμενες υπηρεσίες. Απλώς δημοσιεύει ένα γεγονός με τίτλο OrderPlaced σε ένα κεντρικό Event Bus όπως το Amazon EventBridge ή ένα θέμα SNS. Η πληρωμή ολοκληρώνεται σε πενήντα χιλιοστά του δευτερολέπτου. Οι downstream εργασίες για πληρωμή, αφαίρεση αποθέματος και αποδείξεις email αντλούν μηνύματα ανεξάρτητα από τις δικές τους αποκλειστικές ουρές SQS. Εάν η υπηρεσία email τεθεί εκτός λειτουργίας για μια ώρα, τα μηνύματα περιμένουν με ασφάλεια στην ουρά χωρίς καμία χαμένη παραγγελία.

- 06. Ενορχήστρωση Κοντέινερ (Docker & Kubernetes)

7:13 Έννοια νούμερο έξι: Ενορχήστρωση Κοντέινερ. Το Docker έλυσε τη συσκευασία: τυλίγει τον κώδικα της εφαρμογής σας, τις βιβλιοθήκες συστήματος, τη διαμόρφωση και το runtime σε μια αμετάβλητη εικόνα που τρέχει πανομοιότυπα στο MacBook σας και στο cloud. Αλλά η συσκευασία ενός κοντέινερ είναι εύκολη. Η εκτέλεση πεντακοσίων κοντέινερ σε πενήντα φυσικές εικονικές μηχανές είναι εκεί που η μηχανική καταρρέει. Γι' αυτό υπάρχουν οι ενορχηστρωτές κοντέινερ όπως το Kubernetes και το AWS ECS.

7:41 Ένας ενορχηστρωτής παρέχει ένα επίπεδο ελέγχου: έναν διακομιστή API, ένα κατάστημα κατάστασης etcd και έναν έξυπνο προγραμματιστή. Δηλώνετε την επιθυμητή κατάσταση: Θέλω δέκα αντίγραφα της υπηρεσίας ελέγχου ταυτότητας με δύο gigabytes RAM το καθένα. Ο προγραμματιστής επιθεωρεί το cluster, τοποθετεί pods σε κόμβους με ελεύθερη μνήμη, διαμορφώνει την εσωτερική δικτύωση και συμφιλιώνει συνεχώς την πραγματικότητα. Εάν ένας κόμβος υποστεί βλάβη υλικού, το Kubernetes ανιχνεύει την απώλεια και αμέσως επαναπρογραμματίζει όλα τα εκτοπισμένα pods σε

- 07. Οι 4 Πυλώνες Αποθήκευσης Cloud (S3, EBS, DBs & Redis)

8:16 υγιείς κόμβους. Έννοια νούμερο επτά: Η Ιεραρχία Αποθήκευσης Cloud. Οι αρχάριοι συχνά αντιμετωπίζουν την αποθήκευση στο cloud ως έναν ενιαίο κάδο όπου πετάτε αρχεία. Στην αρχιτεκτονική παραγωγής, η αποθήκευση χωρίζεται σε τέσσερις διακριτούς πυλώνες με βάση τα πρότυπα πρόσβασης και την καθυστέρηση. Πρώτα είναι το Object Storage, όπως το Amazon S3 ή το Google Cloud Storage. Έχετε πρόσβαση σε αρχεία μέσω HTTP REST API χρησιμοποιώντας απλές κλήσεις PUT και GET. Προσφέρει άπειρη οριζόντια χωρητικότητα με δύο σεντς ανά gigabyte το μήνα,

8:49 καθιστώντας το ιδανικό για βίντεο, μεταφορτώσεις χρηστών, αρχεία καταγραφής και αντίγραφα ασφαλείας. Δεύτερον είναι το Block Storage, όπως το Amazon EBS. Αυτοί είναι εικονικοί σκληροί δίσκοι που τοποθετούνται απευθείας σε μια συγκεκριμένη εικονική μηχανή μέσω διασυνδέσεων υψηλής ταχύτητας. Μορφοποιούνται σε τυπικά συστήματα αρχείων όπως το ext4, υποστηρίζοντας γρήγορη τυχαία πρόσβαση ανάγνωσης και εγγραφής που απαιτείται από τις μηχανές βάσης δεδομένων. Τρίτον είναι οι Διαχειριζόμενες Βάσεις Δεδομένων: σχεσιακές μηχανές όπως η PostgreSQL στο RDS παρέχοντας συναλλαγές ACID και σύνθετες ενώσεις,

9:21 και μηχανές NoSQL όπως το DynamoDB που προσφέρουν μονοψήφιο χρόνο καθυστέρησης σε χιλιοστά του δευτερολέπτου σε μαζική κλίμακα. Και τέταρτον είναι οι Εν-Μνήμη Κρυφές Μνήμες όπως το Redis. Η ανάγνωση δεδομένων από τη RAM διαρκεί μικροδευτερόλεπτα αντί για χιλιοστά του δευτερολέπτου. Οι κρυφές μνήμες βρίσκονται μπροστά από τη βάση δεδομένων σας, προστατεύοντάς την από επαναλαμβανόμενη κίνηση ανάγνωσης και διαχειριζόμενες ασταθή tokens συνεδριών χρηστών.

- 08. Υψηλή Διαθεσιμότητα & Οι Εννιάδες (Multi-AZ Failover)

9:44 Έννοια νούμερο οκτώ: Υψηλή Διαθεσιμότητα, ή HA. Η διαθεσιμότητα απαντά σε μία ερώτηση: τι ποσοστό του χρόνου είναι η εφαρμογή σας λειτουργική και προσβάσιμη από τους χρήστες; Στα εταιρικά συμβόλαια, η διαθεσιμότητα μετριέται σε εννιάδες. Δύο εννιάδες, ή ενενήντα εννέα τοις εκατό διαθεσιμότητα, επιτρέπει πάνω από τρεισήμισι μέρες διακοπής λειτουργίας κάθε χρόνο. Τέσσερις εννιάδες μειώνουν τον επιτρεπόμενο χρόνο διακοπής λειτουργίας στα πενήντα δύο λεπτά, και πέντε εννιάδες επιτρέπουν μόλις πέντε λεπτά συνολικής διακοπής λειτουργίας ανά

10:15 έτος. Για να επιτευχθεί υψηλή διαθεσιμότητα, πρέπει να εξαλείψετε τα μοναδικά σημεία αστοχίας σε όλους τους τομείς σφαλμάτων. Στο cloud, αυτό σημαίνει ανάπτυξη σε πολλαπλές Ζώνες Διαθεσιμότητας. Μια Ζώνη Διαθεσιμότητας δεν είναι ένα μόνο rack: είναι ένα ή περισσότερα διακριτά φυσικά κέντρα δεδομένων μίλια μακριά με ανεξάρτητη παροχή ρεύματος και ψύξη. Με την εκτέλεση ενεργών περιπτώσεων στη Ζώνη Α και στη Ζώνη Β με συγχρονική αναπαραγωγή βάσης δεδομένων, μια κεραυνική απεργία ή διακοπή οπτικών ινών που θέτει εκτός λειτουργίας μια ολόκληρη φυσική εγκατάσταση έχει ως αποτέλεσμα μια αυτοματοποιημένη ανατροπή

10:50 σε τριάντα δευτερόλεπτα με μηδενική ανθρώπινη παρέμβαση.

- 09. Ανθεκτικότητα vs. Διαθεσιμότητα (Γιατί το 11 Nines Δεν Είναι Χρόνος Λειτουργίας)

10:53 Έννοια νούμερο εννέα: Ανθεκτικότητα έναντι Διαθεσιμότητας. Αυτή είναι η πιο συνηθισμένη εννοιολογική παγίδα στην αρχιτεκτονική νέφους συνεντεύξεις. Οι μηχανικοί συχνά χρησιμοποιούν τις λέξεις εναλλάξ, αλλά μετρούν εντελώς διαφορετικές ιδιότητες. Η διαθεσιμότητα μετρά τον χρόνο λειτουργίας: μπορώ να κάνω μια κλήση API για να διαβάσω ή να γράψω τα δεδομένα μου αυτή τη στιγμή; Η ανθεκτικότητα μετρά τη διατήρηση: θα επιβιώσουν τα δεδομένα μου χωρίς μόνιμη αλλοίωση, διαφθορά ή καταστροφή σε δέκα χρόνια;

11:24 Δείτε το Amazon S3 Standard. Η Συμφωνία Επιπέδου Υπηρεσίας του προσφέρει ενενήντα εννέα κόμμα εννέα τοις εκατό διαθεσιμότητα, η οποία επιτρέπει περίπου σαράντα τρία λεπτά διακοπής λειτουργίας κάθε μήνα όπου μια αίτηση API μπορεί να επιστρέψει ένα σφάλμα πεντακοσίων. Αλλά το S3 υπόσχεται έντεκα εννιάρια ανθεκτικότητας: ενενήντα εννέα κόμμα εννέα εννέα εννέα εννέα εννέα εννέα εννέα εννέα εννέα τοις εκατό. Αν αποθηκεύσετε δέκα εκατομμύρια αρχεία στο S3, μπορείτε στατιστικά να αναμένετε να χάσετε ένα

11:56 μέσο όρο ενός αρχείου κάθε δέκα χιλιάδες χρόνια. Το S3 το επιτυγχάνει αυτό κωδικοποιώντας αντικείμενα με κώδικα διόρθωσης σφαλμάτων (erasure-coding) και αναπαράγοντας τμήματα σε τουλάχιστον τουλάχιστον τρεις γεωγραφικά διαχωρισμένες εγκαταστάσεις δεδομένων. Κατά τη διάρκεια μιας μεγάλης περιφερειακής διακοπής δικτύου, το S3 μπορεί προσωρινά να είναι μη διαθέσιμο, αλλά τα δεδομένα σας δεν καταστρέφονται ποτέ.

- 10. Υποδομή ως Κώδικας (Terraform vs. Console Drift)

12:14 Έννοια νούμερο δέκα: Υποδομή ως Κώδικας, ή IaC. Στις πρώτες μέρες του cloud computing, οι μηχανικοί συνδέονταν στην κονσόλα διαχείρισης της AWS μέσω web και έκαναν κλικ χειροκίνητα για να δημιουργήσουν εικονικές μηχανές, να ρυθμίσουν υποδίκτυα και να επισυνάψουν ομάδες ασφαλείας. Η βιομηχανία το ονομάζει ClickOps, και στην παραγωγή, είναι μια απόλυτη καταστροφή. Οι χειροκίνητες αλλαγές στην κονσόλα δεν έχουν ίχνος ελέγχου, μηχανισμό αναίρεσης, και αναπόφευκτα προκαλούν απόκλιση διαμόρφωσης μεταξύ των περιβαλλόντων προ-παραγωγής και παραγωγής. Με εργαλεία Υποδομής

12:48 ως Κώδικας όπως το Terraform, OpenTofu, Pulumi ή AWS CDK, ορίζετε την ολόκληρη την αρχιτεκτονική του νέφους σας σε δηλωτικά αρχεία διαμόρφωσης που αποθηκεύονται στο Git. Κάθε αλλαγή σε μια ανοιχτή θύρα ή αντίγραφο βάσης δεδομένων περνάει από ένα pull request και αξιολόγηση από ομοτίμους. Η εκτέλεση του terraform plan προεπισκοπεί την ακριβή διαφορά API πριν αγγιχτεί οτιδήποτε, και η ενεργοποίηση ενός πανομοιότυπου αντιγράφου της παραγωγής σας διαρκεί τέσσερα λεπτά αντί για τέσσερις εβδομάδες.

- 11. Δικτύωση Cloud (VPC, Subnets, NAT & Security Groups)

13:20 Έννοια νούμερο έντεκα: Δικτύωση στο νέφος και Εικονικά Ιδιωτικά Σύννεφα. Όταν αναπτύσσετε διακομιστές στο νέφος, δεν εκτίθενται στο ακατέργαστο δημόσιο διαδίκτυο. Ζουν μέσα σε ένα καθορισμένο από λογισμικό απομονωμένο όριο που ονομάζεται VPC. Μέσα στο VPC σας, διαθέτετε έναν ιδιωτικό χώρο διευθύνσεων IP όπως δέκα-τελεία-μηδέν-τελεία-μηδέν-τελεία-μηδέν κάθετος δεκαέξι, και τον διαιρείτε σε δημόσια και ιδιωτικά υποδίκτυα. Ένα δημόσιο υποδίκτυο έχει μια απευθείας διαδρομή προς μια πύλη Διαδικτύου (Internet Gateway).

13:51 Περιέχει δημόσια προσβάσιμα στοιχεία όπως οι εξισορροπιστές φορτίου εφαρμογών (Application Load Balancers) και οι πύλες NAT Gateways. Είναι το μόνο τμήμα του δικτύου σας που διαθέτει δημόσιες διευθύνσεις IP. Οι διακομιστές εφαρμογών και οι βάσεις δεδομένων παραγωγής σας ζουν αυστηρά σε ιδιωτικά υποδίκτυα χωρίς δημόσιες IP και μηδενικές εισερχόμενες διαδρομές από το διαδίκτυο. Όταν οι διακομιστές υποστήριξης χρειάζονται να κατεβάσουν ενημερώσεις ασφαλείας, η εξερχόμενη κίνησή τους δρομολογείται μέσω της πύλης NAT στο δημόσιο υποδίκτυο. Γύρω από κάθε παρουσία υπάρχουν Ομάδες Ασφαλείας (Security Groups): τείχη προστασίας εικονικά τείχη προστασίας που επιβάλλουν την αρχή του ελάχιστου προνομίου.

- 12. Το Ολοκληρωμένο Επιχειρησιακό Σχέδιο & Ετυμηγορία

14:28 Η ομάδα ασφαλείας της βάσης δεδομένων σας δέχεται συνδέσεις μόνο στη θύρα 5432 αυστηρά από την ομάδα ασφαλείας των διακομιστών εφαρμογών σας, καθιστώντας τη διείσδυση από έξω μαθηματικά αδύνατη. Όταν κάνετε ζουμ προς τα έξω, αυτές οι έντεκα πρωτόγονες συνδέονται σε ένα συνεκτικό σύστημα. Το DNS σας δρομολογεί σε έναν Load Balancer σε ένα δημόσιο υποδίκτυο, οι ομάδες αυτόματης κλιμάκωσης χειρίζονται τις αυξήσεις της κίνησης σε πολλαπλές Ζώνες Διαθεσιμότητας, οι δίαυλοι συμβάντων αποσυνδέουν τους εργάτες υποστήριξης, και ολόκληρη η στοίβα σας αναπτύσσεται από το Git χρησιμοποιώντας την Υποδομή ως Κώδικα.

15:02 Η ετυμηγορία της σημερινής masterclass: SHIP IT. Σταματήστε να απομνημονεύετε εκατοντάδες ακρωνύμια μάρκετινγκ νέφους. Κατακτήστε αυτά τα έντεκα πρότυπα αρχιτεκτονικής, αποσυνδέστε την κατάστασή σας, και δημιουργήστε συστήματα που δεν μπορούν να αποτύχουν. Πείτε μου ποια έννοια του cloud σας προκάλεσε τον μεγαλύτερο πονοκέφαλο όταν πρωτοξεκινήσατε να κατασκευάζετε στα σχόλια. Και για να πάρετε το πλήρες φύλλο αρχιτεκτονικής cheat sheet, εγγραφείτε στο ενημερωτικό δελτίο στο the daily diff dot dev,

15:28 σύνδεσμος παρακάτω. Και αυτή είναι η διαφορά για σήμερα. Είμαι ο Νίκο από την Axrisi. Συγχωνεύστε υπεύθυνα.

Πηγές

1. AWS Well-Architected Framework (Reliability & Performance Pillars)aws.amazon.com
2. Kubernetes Architecture & Control Plane Conceptskubernetes.io
3. Martin Fowler: What is Event-Driven Architecture?martinfowler.com
4. Amazon S3 Data Durability & Availability Technical Whitepaperaws.amazon.com
5. HashiCorp: Declarative Infrastructure as Code with Terraformwww.terraform.io