Multi-Tenancy χωρίς ορολογίες: ένας οδηγός για ιδρυτές

Κάποια στιγμή στη δημιουργία ενός προϊόντος λογισμικού, ένας προγραμματιστής θα σας πει τη λέξη «multi-tenant», θα κοιτάξει το πρόσωπό σας και θα υποθέσει ότι καταλάβατε. Πιθανότατα γνέψατε. Οι περισσότεροι ιδρυτές το κάνουν. Όμως αυτή είναι μία από εκείνες τις πρώιμες αποφάσεις που αθόρυβα καθορίζουν το ταβάνι του πόσο γρήγορα μπορείτε να μεγαλώσετε, πόσο φθηνά μπορείτε να λειτουργείτε και πόσο άσχημα μπορούν να πάνε τα πράγματα αν κάποιος πελάτης δει ποτέ δεδομένα που δεν του ανήκουν. Αξίζει δέκα λεπτά της προσοχής σας τώρα, γιατί είναι πολύ ακριβό να το ξαναδείτε αργότερα.

Έχω καθίσει απέναντι σε πολλούς μη τεχνικούς ιδρυτές — ανθρώπους με μια καλή ιδέα για ένα προϊόν SaaS και χωρίς ιδιαίτερο ενδιαφέρον για βάσεις δεδομένων. Τα καλά νέα είναι ότι δεν χρειάζεται να μάθετε προγραμματισμό για να πάρετε σωστά αυτήν την απόφαση. Χρειάζεστε ένα ξεκάθαρο νοητικό μοντέλο και μια σύντομη λίστα ερωτήσεων. Αυτό ακριβώς είναι αυτός ο οδηγός. Χωρίς buzzwords, χωρίς διαγράμματα αρχιτεκτονικής που δεν θα ξανακοιτάξετε ποτέ, μόνο αυτό που ο προγραμματιστής σας θα ήθελε να είχατε καταλάβει πριν από την πρώτη γραμμή κώδικα.

Αν κρατήσετε μία ιδέα, ας είναι αυτή: το multi-tenancy δεν είναι ένα χαρακτηριστικό που προσθέτετε αργότερα. Είναι θεμέλιο. Μπορείτε να ξαναβάψετε ένα σπίτι, αλλά δεν μπορείτε εύκολα να αλλάξετε αυτό πάνω στο οποίο στέκεται μόλις σηκωθούν οι τοίχοι.

Τι σημαίνει πραγματικά το «multi-tenant»

Φανταστείτε μια πολυκατοικία. Κάθε ένοικος έχει το δικό του διαμέρισμα — το δικό του κλειδί, τα δικά του έπιπλα, τη δική του εξώπορτα. Αλλά όλοι μοιράζονται την ίδια δομή: τα θεμέλια, τις σωληνώσεις, τη στέγη, το ασανσέρ. Ο ιδιοκτήτης συντηρεί ένα κτίριο, όχι πενήντα ξεχωριστά σπίτια, και αυτό κρατά το ενοίκιο προσιτό. Το λογισμικό multi-tenant λειτουργεί ακριβώς έτσι. Μία εφαρμογή εξυπηρετεί πολλούς πελάτες — «tenants» — και ο καθένας τη βιώνει ως τον δικό του ιδιωτικό χώρο, αν και όλοι τρέχουν στο ίδιο κοινό σύστημα από κάτω.

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

Σχεδόν κάθε προϊόν που χρησιμοποιείτε καθημερινά είναι multi-tenant. Το email σας, το λογιστικό σας εργαλείο, το σύστημα κρατήσεων, το CRM στο οποίο ζει η ομάδα πωλήσεών σας. Εσείς και χίλιες άλλες εταιρείες μοιράζεστε το ίδιο υποκείμενο λογισμικό, και καμία δεν βλέπει ποτέ την άλλη. Αυτή η αορατότητα — αυτός ο καθαρός διαχωρισμός — είναι όλη η τέχνη του multi-tenancy.

Γιατί αυτή η απόφαση αγγίζει όλη σας την επιχείρηση

Μπαίνετε στον πειρασμό να το κατατάξετε στο «τεχνική λεπτομέρεια που χειρίζεται ο προγραμματιστής μου». Όμως το μοντέλο που επιλέγετε επηρεάζει άμεσα τα μέρη της επιχείρησης που όντως σας ενδιαφέρουν: τον μηνιαίο λογαριασμό φιλοξενίας, πόσο γρήγορα μπορείτε να βγάλετε ένα νέο χαρακτηριστικό σε όλους, τι μπορείτε να υποσχεθείτε σε έναν επιφυλακτικό εταιρικό αγοραστή και πόση ζημιά μπορεί να κάνει ένα μόνο bug.

Όταν διορθώνετε ένα bug ή κυκλοφορείτε ένα χαρακτηριστικό σε ένα καλοφτιαγμένο προϊόν multi-tenant, κάθε πελάτης το λαμβάνει ταυτόχρονα, από μία ενημέρωση. Σε έναν κόσμο single-tenant, θα έπρεπε να εφαρμόσετε αυτήν την αλλαγή σε πενήντα ξεχωριστές εγκαταστάσεις, καθεμία από τις οποίες μπορεί να είναι λίγο διαφορετική πλέον. Το ένα είναι ένα απόγευμα Τρίτης. Το άλλο είναι ένα έργο. Πολλαπλασιάστε το σε χρόνια ενημερώσεων και καταλαβαίνετε γιατί η βιομηχανία SaaS βασίζεται στο multi-tenancy.

Η άλλη όψη είναι ότι η κοινή χρήση υποδομής ανεβάζει τον πήχη στον διαχωρισμό. Σε μια πολυκατοικία, μια βλάβη στις σωληνώσεις μπορεί να επηρεάσει πάνω από ένα διαμέρισμα. Στο λογισμικό multi-tenant, ένα λάθος στον τρόπο που κρατάτε τους tenants χωριστά δεν ενοχλεί απλώς έναν πελάτη — μπορεί να εκθέσει τα δεδομένα όλων ταυτόχρονα. Αυτό δεν είναι λόγος να αποφύγετε το multi-tenancy. Είναι ο λόγος να το χτίσετε σωστά, με κάποιον που το έχει ξανακάνει.

Οι τρεις τρόποι να κρατήσετε τους tenants χωριστά

Όταν οι προγραμματιστές διαφωνούν για το multi-tenancy, συνήθως διαφωνούν για το πόσο χωριστά πρέπει να είναι τα δεδομένα κάθε tenant. Υπάρχουν τρεις συνηθισμένες προσεγγίσεις, και κάθονται σε μια κλίμακα από το «μέγιστη κοινή χρήση, χαμηλότερο κόστος» μέχρι το «μέγιστος διαχωρισμός, υψηλότερο κόστος». Δεν χρειάζεται να επιλέξετε εσείς — αλλά πρέπει να κατανοήσετε το trade-off που κάνει ο προγραμματιστής σας εκ μέρους σας.

1. Κοινή βάση, κοινοί πίνακες

Τα δεδομένα όλων βρίσκονται στην ίδια βάση, στους ίδιους πίνακες, με μια κρυφή ετικέτα — ένα «tenant ID» — που σημειώνει σε ποιον ανήκει κάθε γραμμή. Το λογισμικό είναι υπεύθυνο να φιλτράρει πάντα με βάση αυτήν την ετικέτα, ώστε ο πελάτης A να βλέπει μόνο τις γραμμές του πελάτη A. Αυτό είναι το φθηνότερο και πιο κλιμακούμενο μοντέλο, αυτό που χρησιμοποιούν τα περισσότερα πρώιμα προϊόντα SaaS. Η παγίδα: ο διαχωρισμός ζει μέσα στον κώδικα, οπότε ένα μόνο ξεχασμένο φίλτρο είναι αρκετό για να διαρρεύσουν δεδομένα. Απαιτεί προσεκτική, πειθαρχημένη μηχανική.

2. Κοινή βάση, ξεχωριστά διαμερίσματα

Μία βάση δεδομένων, αλλά κάθε tenant παίρνει το δικό του απομονωμένο τμήμα μέσα της (οι προγραμματιστές τα ονομάζουν «schemas»). Ισχυρότερος διαχωρισμός από το πρώτο μοντέλο, ακόμη αρκετά αποδοτικό, και ευκολότερο, ας πούμε, να εξαγάγετε ή να διαγράψετε καθαρά τα δεδομένα ενός πελάτη. Το trade-off είναι περισσότερα κινούμενα μέρη να διαχειριστείτε καθώς μεγαλώνετε σε εκατοντάδες και χιλιάδες tenants.

3. Ξεχωριστή βάση ανά tenant

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

Το μέρος που δεν επιτρέπεται να κάνετε λάθος: η απομόνωση

Αν υπάρχει ένα σημείο για να ξοδέψετε την ανησυχία σας, είναι εδώ. Η απομόνωση tenant είναι η εγγύηση ότι ο πελάτης A δεν μπορεί ποτέ, σε καμία περίπτωση, να δει, να επεξεργαστεί ή ακόμη και να αντιληφθεί την ύπαρξη των δεδομένων του πελάτη B. Ακούγεται προφανές. Είναι επίσης η πιο συνηθισμένη πηγή σοβαρών bugs στα προϊόντα multi-tenant, γιατί η αποτυχία είναι σιωπηλή — όλα φαίνονται εντάξει μέχρι την ημέρα που κάποιος ανοίγει μια αναφορά και βλέπει μέσα τους πελάτες ενός αγνώστου.

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

Υπάρχει και ένα πιο ήσυχο ξαδερφάκι αυτού του προβλήματος: ο «θορυβώδης γείτονας». Επειδή οι tenants μοιράζονται υποδομή, ένας πελάτης που κάνει κάτι βαρύ — μια τεράστια εισαγωγή, μια ανεξέλεγκτη αναφορά — μπορεί να επιβραδύνει το σύστημα για όλους τους άλλους, όπως ένα διαμέρισμα με όλες τις βρύσες ανοιχτές μπορεί να ρίξει την πίεση του νερού σε όλο το κτίριο. Ο καλός σχεδιασμός multi-tenant το προβλέπει με όρια και δίκαιη κατανομή. Αξίζει να ρωτήσετε, ειδικά αν περιμένετε λίγους πολύ μεγάλους πελάτες.

Πότε το single-tenant είναι όντως η σωστή επιλογή

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

• Έναν πελάτη σε ρυθμιζόμενο κλάδο — υγεία, χρηματοοικονομικά, δημόσιο — του οποίου οι κανόνες συμμόρφωσης ουσιαστικά απαιτούν τα δεδομένα του να βρίσκονται κάπου αποδεδειγμένα χωριστά.
• Έναν μεγάλο πελάτη που πληρώνει αρκετά ώστε μια αποκλειστική εγκατάσταση να αξίζει, και που θέλει βαθιά προσαρμογή που δεν θέλετε να διαρρεύσει στην εμπειρία όλων των άλλων.
• Δεδομένα τόσο ευαίσθητα που το κόστος μιας διαρροής μεταξύ tenants θα τελείωνε την επιχείρηση, κάνοντας τη μέγιστη απομόνωση να αξίζει το επιπλέον έξοδο.
• Μια απαίτηση on-premise, όπου το λογισμικό πρέπει να τρέχει μέσα στους ίδιους τους τοίχους του πελάτη αντί στο δικό σας cloud.

Παρατηρήστε το μοτίβο: το single-tenant είναι η εξαίρεση στην οποία καταφεύγετε σκόπιμα, συνήθως για έναν συγκεκριμένο πελάτη υψηλής αξίας, όχι η προεπιλογή πάνω στην οποία χτίζετε ολόκληρη την επιχείρηση. Αν ένας προγραμματιστής προτείνει single-tenant για το τυπικό σας προϊόν από την πρώτη μέρα, ζητήστε του να σας εξηγήσει γιατί — συνήθως σημαίνει πολύ υψηλότερο κόστος λειτουργίας και πιο αργές ενημερώσεις, και θέλετε αυτό να είναι επιλογή, όχι ατύχημα.

Οι ερωτήσεις που πρέπει να κάνετε πριν γράψει κανείς κώδικα

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

1. 1
   Πώς θα κρατήσετε τα δεδομένα των tenants χωριστά;

   Ακούτε για μια δομική απάντηση — το σύστημα το επιβάλλει — όχι «θα είμαστε προσεκτικοί». Αυτή είναι η μη διαπραγματεύσιμη.
2. 2
   Ποιο μοντέλο χρησιμοποιούμε, και γιατί;

   Κοινοί πίνακες, ξεχωριστά διαμερίσματα ή βάση ανά tenant. Δεν υπάρχει λάθος απάντηση, αλλά πρέπει να υπάρχει λόγος που ταιριάζει στους πελάτες και τον προϋπολογισμό σας.
3. 3
   Μπορούμε να προσφέρουμε αποκλειστική απομόνωση σε έναν μεγάλο πελάτη αργότερα;

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

   Πώς εμποδίζει το σύστημα έναν βαρύ tenant να επιβραδύνει όλους τους άλλους; Θέλετε να ακούσετε ότι τα σενάρια θορυβώδους γείτονα λήφθηκαν υπόψη.
5. 5
   Πώς εξάγουμε ή διαγράφουμε καθαρά τα δεδομένα ενός πελάτη;

   Οι πελάτες φεύγουν, και ο νόμος περί απορρήτου απαιτεί να αφαιρείτε τα δεδομένα τους κατόπιν αιτήματος. Αυτό πρέπει να είναι μια απλή, κατανοητή λειτουργία, όχι πανικός.

Δεν βαθμολογείτε την τεχνική λεπτομέρεια των απαντήσεων. Ελέγχετε ότι καμία από αυτές τις ερωτήσεις δεν πέφτει ως έκπληξη. Μια ομάδα που έχει ξαναχτίσει λογισμικό multi-tenant θα έχει σαφείς, σχεδόν βαρετές απαντήσεις και στις πέντε. Ο δισταγμός στην πρώτη ή την τρίτη είναι το σήμα να επιβραδύνετε και να σκάψετε.

Ένα σύντομο, ρεαλιστικό παράδειγμα

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

Δούλευε υπέροχα στους τρεις. Ο εφιάλτης του ιδρυτή ήταν η σκέψη των τριάντα. Κάθε διόρθωση bug σήμαινε σύνδεση σε τρία μέρη. Κάθε νέο χαρακτηριστικό σήμαινε τρεις αναπτύξεις και τρία πράγματα να ελεγχθούν. Μια νέα κλινική χρειαζόταν σχεδόν μια ολόκληρη εβδομάδα για να στηθεί στο χέρι. Το μοντέλο που τους έφερε στην εκκίνηση ήταν τώρα αυτό που περιόριζε την ανάπτυξή τους — ακριβώς το πρόβλημα θεμελίου για το οποίο μιλά όλο αυτό το άρθρο.

Δεν τα πετάξαμε όλα έξω σε μια δραματική επανεγγραφή. Ξαναχτίσαμε τον πυρήνα πάνω σε ένα κοινό θεμέλιο multi-tenant με την απομόνωση να επιβάλλεται σε επίπεδο συστήματος, κρατήσαμε τις προσαρμογές ανά κλινική ως ρυθμιζόμενες επιλογές αντί για ξεχωριστά codebases, και μεταφέραμε τις τρεις υπάρχουσες κλινικές μία-μία, παράλληλα, ώστε κανείς να μην έχει μια τρομακτική μέρα μετάβασης. Η ενσωμάτωση μιας νέας κλινικής πέρασε από μια εβδομάδα χειρωνακτικής δουλειάς σε μια self-serve εγγραφή. Τα νέα χαρακτηριστικά τώρα φτάνουν σε κάθε πελάτη από μία μόνο κυκλοφορία.

Οι αριθμοί εδώ είναι ενδεικτικοί, όχι υπόσχεση — κάθε προϊόν είναι διαφορετικό — αλλά το σχήμα είναι τυπικό: η ανακατασκευή κόστισε πραγματικά χρήματα και μερικούς μήνες, και αποπληρώθηκε μέσα στους πρώτους λίγους νέους πελάτες που μπορούσαν ξαφνικά να ενσωματώσουν χωρίς να κουνήσουν το δαχτυλάκι τους. Το μάθημα που πήρε ο ιδρυτής ήταν το φθηνότερο: αν είχαν κάνει τις πέντε ερωτήσεις στην αρχή, δεν θα υπήρχε τίποτα να ξαναχτιστεί.

Συχνές ερωτήσεις