Το Ταξίδι της Shoprocket προς τις Μικροϋπηρεσίες: Μέρος 1

Μερικούς μήνες μετά την έναρξη της δουλειάς μου στο Shoprocket, άρχισα να απογοητεύομαι. Είχαμε μια εφαρμογή PHP που δουλεύαμε με την μικρή ομάδα λαμπρών προγραμματιστών μας, που ήταν διασκορπισμένοι σε όλο τον κόσμο. Γιατί απογοητευόμουν; Για μένα, φαινόταν ότι οι διορθώσεις σφαλμάτων προκαλούσαν περισσότερα σφάλματα, η ενσωμάτωση νέων χαρακτηριστικών δεν ήταν τόσο απλή όσο θα μπορούσε να είναι, και οι αναπτύξεις ήταν σπάνιες και αγχωτικές. Ο λόγος για αυτά τα προβλήματα: πολύ συνδεδεμένος κώδικας.

Είχαμε μια μονολιθική εφαρμογή και σχεδόν όλος ο κώδικας μας βρισκόταν σε ένα αποθετήριο Github. Οι ενημερώσεις ή οι διορθώσεις για ένα χαρακτηριστικό συνήθως συνέβαιναν σε πολλά μέρη. Για τη δοκιμή, είχαμε μια διαδικασία αναθεώρησης από ομότιμους, όπου τουλάχιστον δύο άλλοι προγραμματιστές έπρεπε να εγκρίνουν ένα κλάδο πριν συγχωνευτεί στο master και αναπτυχθεί. Όλα αυτά σήμαιναν ότι όταν τα σφάλματα κατάφερναν να περάσουν κάτω από την επιφάνεια, ήταν συχνά δύσκολο να εντοπιστούν οι διαταραχές. Και μόλις το κάναμε, οι διορθώσεις θα περνούσαν από την ίδια διαδικασία και ολόκληρη η εφαρμογή έπρεπε να αναπτυχθεί ξανά.

Ως ένας ενθουσιώδης νέος προγραμματιστής πάντα ψάχνοντας για το νέο, όταν βρήκα τα μικροservίce σκέφτηκα ότι αυτό το αρχιτεκτονικό στυλ θα λυνόταν όλα μας τα προβλήματα. Δεν υπάρχει μια επίσημη ορισμός για τα μικροservίce, αλλά από την έρευνά μου έμαθα ότι η αρχιτεκτονική μικροservίce είναι ένας τρόπος σχεδιασμού εφαρμογών λογισμικού ως κατανεμημένα συστήματα ανεξάρτητων υπηρεσιών, καθεμιά με υψηλή εξειδίκευση και με τον δικό της κύκλο ζωής. Για τους αναγνώστες που θέλουν μια πιο λεπτομερή εισαγωγή στο εννοιολογικό σκεπτικό, προτείνω το εξαιρετικό άρθρο του Martin Fowler άρθρο.

Υπήρχαν πολλοί τομείς των μικροservίce που με ενδιέφεραν, αλλά δύο συγκεκριμένα: Πρώτον, η ιδέα του διαχωρισμού της εφαρμογής σε υπηρεσίες με πολύ αυστηρά όρια. Αυτό μειώνει τις πιθανότητες λογικής που σχετίζεται με μια επιχειρηματική κατάσταση να διαρρεύσει μεταξύ των στοιχείων επειδή οι διεπαφές μεταξύ των ορίων πρέπει να προγραμματισθούν προσεκτικά. Δεν είναι τόσο απλό όσο το να κάνεις τοπικές κλήσεις λειτουργιών; Δεύτερον, κάθε στοιχείο μπορεί να έχει τον δικό του ανεξάρτητο κύκλο ζωής. Αυτό επιτρέπει στις ομάδες να αναλάβουν την ιδιοκτησία του κώδικά τους και να χρησιμοποιήσουν μια τεχνολογική στοίβα που ταιριάζει καλύτερα στην ατομική υπηρεσία. Επίσης, επιτρέπει περισσότερη λεπτομερή έλεγχο της εφαρμογής καθώς οι αλλαγές μπορούν να αναπτυχθούν σε μια υπηρεσία κάθε φορά και να αναιρεθούν χωρίς να επηρεάζουν την υπόλοιπη εφαρμογή αν κάτι πάει στραβά.

Έτσι, ήμουν πωλημένος. Το Shoprocket θα χώριζε τον μονολιθικό! Αυτό είναι το πρώτο σε μια μικρή σειρά από αναρτήσεις blog που ακολουθούν αυτό το ταξίδι. Ελπίζω ότι οι αναγνώστες που σχεδιάζουν ή περνούν από μια παρόμοια μετάβαση θα μάθουν από τις επιτυχίες και τις αποτυχίες μας και θα νιώσουν καλύτερα προετοιμασμένοι για να αντιμετωπίσουν αυτή την πρόκληση στα δικά τους έργα.

Η πρώτη μου πρόκληση δεν ήταν τεχνική, αλλά ανθρώπινη. Έπρεπε να πουλήσω την ιδέα στη υπόλοιπη ομάδα. Φαινόταν περίεργοι, αλλά δεν μοιράζονταν τον ίδιο ενθουσιασμό και ήταν απρόθυμοι να εγκαταλείψουν τις ώρες ανάπτυξης σε αυτό το πρώιμο στάδιο της ζωής του προϊόντος μας. Ευτυχώς, ο CTO ήθελε να εξετάσω τη διαχείριση των συνεδριών μας και εκμεταλλεύτηκα την ευκαιρία πείθοντάς τον ότι μπορούσα να χωρίσω μια υπηρεσία συνεδρίας.

Αναδρομικά, ίσως αυτό ήταν μια κακή επιλογή στοιχείου για πρώτη υπηρεσία. Το προϊόν μας περιλαμβάνει ένα πρόσθετο javascript που επιτρέπει το ηλεκτρονικό εμπόριο σε οποιαδήποτε ιστοσελίδα. Θεωρούμε τις συνεδρίες ως μια πηγή, διατηρώντας τις πληροφορίες της συνεδρίας στη βάση δεδομένων για λεπτομερή ανάλυση KPIs όπως τα ποσοστά εγκατάλειψης καλαθιού. Ωστόσο, αυτή η πηγή δεν είναι τόσο απτή όσο κάτι όπως οι παραγγελίες ή οι γραμμές στοιχείων. Επιπλέον, χρησιμοποιούσαμε την πηγή της συνεδρίας με σχεδόν κάθε αλλαγή στην κατάσταση της εφαρμογής. Αυτό σήμαινε ότι η υπηρεσία θα ήταν αναπόφευκτα συνομιλητική με την υπόλοιπη εφαρμογή, κάτι που δεν προέβλεπα, αλλά έκανε τη δουλειά μου δύσκολη.

Αφού πείσαμε τον προϊστάμενό μου, αύξησα την έρευνά μου για τα μικροservίce. Εκτός από το ήδη αναφερόμενο άρθρο, βρήκα και το «Building Microservices» του Sam Newman να είναι μια ανεκτίμητη πηγή. Θα αναφερθώ και στους δύο συχνά στις αναρτήσεις μου.

Στο βιβλίο του, ο Newman προτείνει αρχικά να αναδομηθεί μια υπάρχουσα εφαρμογή σε ενότητες που αντικατοπτρίζουν τα περιορισμένα πλαίσια του τομέα. Στη συνέχεια, μόλις οι προγραμματιστές είναι ικανοποιημένοι, οι ενότητες μπορούν να διαχωριστούν σε δικές τους υπηρεσίες. Ο λόγος γι' αυτό είναι ότι είναι πολύ πιο εύκολο να σπάσεις και να ξαναγράψεις ενότητες αν τα όριά τους έχουν κακώς επιλεγεί από το να σπάσεις και να ξαναγράψεις ολόκληρες υπηρεσίες, με όλο τον επιπλέον κώδικα και τις διαρκείς πηγές τους. Παρόλα αυτά, λόγω περιορισμών χρόνου και του ενθουσιασμού μου να κατασκευάσω ένα στοιχείο δικό μου, προχώρησα στην πρώτη υπηρεσία.

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

Έπρεπε να κάνω την υπηρεσία να μιλήσει με τον μονολίθιο. Ήταν τη στιγμή αυτή που έμαθα πόσο στενά συνδεδεμένη ήταν η διαχείριση συνεδρίων με τον υπόλοιπο κώδικα. Χρειάστηκα λίγο χρόνο για να αναλύσω τις υπάρχουσες κλήσεις λειτουργιών και να τις μεταφράσω σε κλήσεις API. Αυτό ήταν δύσκολο. Καθώς η υπηρεσία συνεδριών και ο μονολίθιος είχαν τα δικά τους σχήματα βάσεων δεδομένων, έπρεπε να ξαναγράψω οποιαδήποτε λογική στον μονολίθιο που χρησιμοποιούσε πόρους συνεδριών από την παλιά βάση δεδομένων, αναδομώντας τα δεδομένα στα όρια της εφαρμογής για να διατηρήσουμε τη συμβατότητα με πελάτες όπως το πρόσθετο javascript.

Η ενσωμάτωση της υπηρεσίας με την υπάρχουσα εφαρμογή μας διήρκεσε περισσότερο από ό,τι χρειάστηκε για να γράψω την υπηρεσία αυτή καθαυτή και αυτό δεν περιλάμβανε πολλά από τα επιπλέον έξοδα που συνήθως φέρνουν τα μικροservίce, όπως η ανακάλυψη υπηρεσιών, η καταγραφή και η παρακολούθηση. Επιπλέον, λόγω της στενής σύνδεσης, έγιναν αλλαγές σε πολλές περιοχές του κώδικα. Καθώς η ομάδα είχε δουλέψει σε διάφορες περιοχές του κώδικα παράλληλα, θα απαιτούσε πολύ περισσότερη δουλειά για να συγχωνευτούν οι αλλαγές και να μπει η υπηρεσία συνεδρίας σε παραγωγή.

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

Είμαι ακόμα πωλημένος στην ιδέα των μικροservίce και θεωρώ ότι η απόπειρά μου να χωρίσω μια υπηρεσία ήταν ένα επιτυχές πείραμα. Έμαθα πολλά σχετικά με την αρχιτεκτονική εφαρμογών και τη μοντελοποίηση τομέων κατά τη διαδικασία και βελτίωσα την κατανόησή μου για τις αρχές REST, μεταξύ άλλων. Αυτά είχαν άμεσο αντίκτυπο σε άλλες περιοχές του κώδικά μας.

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

Το Shoprocket θα συνεχίσει στην πορεία του προς τα μικροservίce. Ανυπομονούμε να σας πούμε περισσότερα στο δεύτερο μέρος!