Γεια σου, Χαμπρ! Σας παρουσιάζω την προσοχή σας μετάφραση του άρθρου από τον συγγραφέα .
Σε μια εποχή που ο κόσμος της πληροφορικής κινείται σταδιακά προς μικροϋπηρεσίες και εργαλεία όπως το Kubernetes, μόνο ένα πρόβλημα γίνεται όλο και πιο αισθητό. Αυτό το πρόβλημα - εκδόσεις microservice. Ωστόσο, η κοινότητα της πληροφορικής πιστεύει ότι η τρέχουσα κατάσταση είναι πολύ καλύτερη από προηγούμενης γενιάς τεχνολογιών. Ωστόσο, η έκδοση microservices είναι ένα πολύ περίπλοκο πρόβλημα. Μια απόδειξη αυτού μπορεί να είναι άρθρα όπως .
Αν πάλι δεν καταλαβαίνετε το πρόβλημα διαβάζοντας αυτό το κείμενο, επιτρέψτε μου να σας εξηγήσω. Ας υποθέσουμε ότι το προϊόν σας αποτελείται από 10 μικροϋπηρεσίες. Τώρα ας υποθέσουμε ότι κυκλοφορεί 1 νέα έκδοση για καθεμία από αυτές τις μικροϋπηρεσίες. Μόνο 1 εκδοχή - Ελπίζω να συμφωνήσουμε όλοι ότι αυτό είναι ένα πολύ ασήμαντο και ασήμαντο γεγονός. Τώρα, όμως, ας ρίξουμε μια άλλη ματιά στο προϊόν μας. Με μία μόνο νέα έκδοση κάθε στοιχείου, έχουμε τώρα 2^10 - ή 1024 μεταθέσεις για το πώς μπορεί να συντεθεί το προϊόν μας.
Αν υπάρχει ακόμα κάποια παρεξήγηση, επιτρέψτε μου να αναλύσω τα μαθηματικά. Έτσι, έχουμε 10 μικροϋπηρεσίες, η καθεμία λαμβάνει μία ενημέρωση. Δηλαδή, παίρνουμε 2 πιθανές εκδόσεις για κάθε microservice (είτε παλιά είτε νέα). Τώρα, για καθένα από τα στοιχεία του προϊόντος, μπορούμε να χρησιμοποιήσουμε οποιαδήποτε από αυτές τις δύο εκδόσεις. Μαθηματικά, είναι το ίδιο σαν να είχαμε έναν δυαδικό αριθμό 10 ψηφίων. Για παράδειγμα, ας πούμε ότι το 1 είναι η νέα έκδοση και το 0 είναι η παλιά έκδοση - τότε μια πιθανή μετάθεση μπορεί να συμβολιστεί ως 1001000000 - όπου το 1ο και το 4ο στοιχείο ενημερώνονται και όλα τα άλλα όχι. Από τα μαθηματικά γνωρίζουμε ότι ένας 10ψήφιος δυαδικός αριθμός μπορεί να έχει 2^10 ή 1024 τιμές. Δηλαδή, επιβεβαιώσαμε την κλίμακα του αριθμού που έχουμε να κάνουμε.
Ας συνεχίσουμε περαιτέρω το σκεπτικό μας - τι θα συμβεί αν έχουμε 100 μικροϋπηρεσίες και η καθεμία έχει 10 πιθανές εκδόσεις; Η όλη κατάσταση γίνεται αρκετά δυσάρεστη - έχουμε πλέον 10^100 μεταθέσεις - που είναι τεράστιος αριθμός. Ωστόσο, προτιμώ να χαρακτηρίσω αυτήν την κατάσταση με αυτόν τον τρόπο, γιατί τώρα δεν κρυβόμαστε πίσω από λέξεις όπως "kubernetes", αλλά αντιμετωπίζουμε το πρόβλημα ως έχει.
Γιατί με γοητεύει τόσο αυτό το πρόβλημα; Εν μέρει επειδή, έχοντας εργαστεί στο παρελθόν στον κόσμο του NLP και της AI, συζητήσαμε πολύ το πρόβλημα της συνδυαστικής έκρηξης πριν από περίπου 5-6 χρόνια. Μόνο αντί για εκδόσεις είχαμε μεμονωμένες λέξεις και αντί για προϊόντα είχαμε προτάσεις και παραγράφους. Και παρόλο που τα προβλήματα του NLP και της AI παραμένουν σε μεγάλο βαθμό άλυτα, πρέπει να παραδεχτούμε ότι έχει σημειωθεί σημαντική πρόοδος τα τελευταία χρόνια (κατά τη γνώμη μου, θα μπορούσε να σημειωθεί πρόοδοςоΘα ήταν καλύτερα αν οι άνθρωποι του κλάδου έδιναν λίγο λιγότερη προσοχή στη μηχανική μάθηση και λίγο περισσότερο σε άλλες τεχνικές - αλλά αυτό είναι ήδη εκτός θέματος).
Ας επιστρέψουμε στον κόσμο των DevOps και των microservices. Βρισκόμαστε αντιμέτωποι με ένα τεράστιο πρόβλημα, το μεταμφιεσμένο σε ελέφαντα στην Kunstkamera - γιατί αυτό που ακούω συχνά είναι "απλώς πάρτε kubernetes και τιμόνι, και όλα θα πάνε καλά!" Αλλά όχι, δεν θα πάνε όλα καλά αν μείνουν όλα ως έχουν. Επιπλέον, μια αναλυτική λύση σε αυτό το πρόβλημα δεν φαίνεται αποδεκτή λόγω της πολυπλοκότητάς του. Όπως και στο NLP, θα πρέπει πρώτα να προσεγγίσουμε αυτό το πρόβλημα περιορίζοντας το εύρος αναζήτησης — σε αυτήν την περίπτωση, εξαλείφοντας τις παρωχημένες μεταθέσεις.
Ένα από τα πράγματα που μπορεί να βοηθήσει είναι κάτι που έγραψα πέρυσι . Είναι επίσης σημαντικό να σημειωθεί ότι μια καλά σχεδιασμένη διαδικασία CI/CD βοηθά σημαντικά στη μείωση των παραλλαγών. Ωστόσο, η τρέχουσα κατάσταση με το CI/CD δεν είναι αρκετά καλή για να λύσει το πρόβλημα των μεταθέσεων χωρίς πρόσθετα εργαλεία για τη λογιστική και την παρακολούθηση στοιχείων.
Αυτό που χρειαζόμαστε είναι ένα σύστημα πειραματισμού στο στάδιο της ολοκλήρωσης, όπου μπορούμε να προσδιορίσουμε τον παράγοντα κινδύνου για κάθε εξάρτημα και επίσης να έχουμε μια αυτοματοποιημένη διαδικασία ενημέρωσης διαφόρων στοιχείων και δοκιμών χωρίς παρέμβαση χειριστή - για να δούμε τι λειτουργεί και τι όχι.
Ένα τέτοιο σύστημα πειραμάτων θα μπορούσε να μοιάζει με αυτό:
- Οι προγραμματιστές γράφουν δοκιμές (αυτό είναι ένα κρίσιμο στάδιο - γιατί διαφορετικά δεν έχουμε κριτήριο αξιολόγησης - είναι σαν να επισημαίνουμε δεδομένα στη μηχανική εκμάθηση).
- Κάθε στοιχείο (έργο) λαμβάνει το δικό του σύστημα CI - αυτή η διαδικασία είναι πλέον καλά αναπτυγμένη και το ζήτημα της δημιουργίας ενός συστήματος CI για ένα μόνο στοιχείο έχει επιλυθεί σε μεγάλο βαθμό
- Το «έξυπνο σύστημα ενοποίησης» συλλέγει τα αποτελέσματα διαφόρων συστημάτων CI και συγκεντρώνει έργα εξαρτημάτων στο τελικό προϊόν, εκτελεί δοκιμές και τελικά υπολογίζει τη συντομότερη διαδρομή για την απόκτηση της επιθυμητής λειτουργικότητας του προϊόντος με βάση τα υπάρχοντα στοιχεία και τους παράγοντες κινδύνου. Εάν δεν είναι δυνατή μια ενημέρωση, αυτό το σύστημα ειδοποιεί τους προγραμματιστές σχετικά με τα υπάρχοντα στοιχεία και ποια από αυτά προκαλεί το σφάλμα. Για άλλη μια φορά, το σύστημα δοκιμών είναι κρίσιμης σημασίας εδώ - αφού το σύστημα ολοκλήρωσης χρησιμοποιεί τεστ ως κριτήριο αξιολόγησης.
- Σύστημα CD, το οποίο στη συνέχεια λαμβάνει δεδομένα από το Smart Integration System και εκτελεί απευθείας την ενημέρωση. Αυτό το στάδιο τελειώνει τον κύκλο.
Συνοψίζοντας, για μένα ένα από τα μεγαλύτερα προβλήματα τώρα είναι η έλλειψη ενός τέτοιου «Smart Integration System» που θα συνέδεε τα διάφορα στοιχεία σε ένα προϊόν και έτσι θα σας επέτρεπε να παρακολουθείτε πώς συναρμολογείται το προϊόν στο σύνολό του. Θα με ενδιαφέρουν οι σκέψεις της κοινότητας για αυτό (σπόιλερ - αυτήν τη στιγμή εργάζομαι σε ένα έργο , που μπορεί να γίνει ένα τόσο έξυπνο σύστημα ολοκλήρωσης).
Κάτι τελευταίο που θέλω να αναφέρω είναι ότι, για μένα, ο μονόλιθος δεν είναι αποδεκτός για κανένα έργο έστω και μεσαίου μεγέθους. Για μένα, οι προσπάθειες επιτάχυνσης του χρόνου υλοποίησης και της ποιότητας ανάπτυξης επιστρέφοντας σε ένα μονόλιθο προκαλούν μεγάλο σκεπτικισμό. Πρώτον, ένας μονόλιθος έχει ένα παρόμοιο πρόβλημα διαχείρισης στοιχείων - μεταξύ των διαφόρων βιβλιοθηκών από τις οποίες αποτελείται, ωστόσο, όλα αυτά δεν είναι τόσο αισθητά και εκδηλώνονται κυρίως στον χρόνο που αφιερώνουν οι προγραμματιστές. Η συνέπεια του προβλήματος του μονόλιθου είναι η εικονική αδυναμία πραγματοποίησης αλλαγών στον κώδικα - και εξαιρετικά αργή ταχύτητα ανάπτυξης.
Οι μικροϋπηρεσίες βελτιώνουν την κατάσταση, αλλά στη συνέχεια η αρχιτεκτονική των μικροϋπηρεσιών αντιμετωπίζει το πρόβλημα της συνδυαστικής έκρηξης στο στάδιο της ολοκλήρωσης. Ναι, γενικά, μεταφέραμε το ίδιο πρόβλημα από το στάδιο ανάπτυξης στο στάδιο της ολοκλήρωσης. Ωστόσο, κατά τη γνώμη μου, η προσέγγιση των microservices εξακολουθεί να οδηγεί σε καλύτερα αποτελέσματα και οι ομάδες επιτυγχάνουν αποτελέσματα πιο γρήγορα (πιθανώς κυρίως λόγω της μείωσης του μεγέθους της μονάδας ανάπτυξης - ή μέγεθος παρτίδας). Ωστόσο, η μετάβαση από το monolith στις microservices δεν έχει φέρει ακόμη αρκετή βελτίωση στη διαδικασία - η συνδυαστική έκρηξη των εκδόσεων microservice είναι ένα τεράστιο πρόβλημα και έχουμε πολλές δυνατότητες να βελτιώσουμε την κατάσταση καθώς το λύνουμε.
Πηγή: www.habr.com