Ξεχωριστή βάση για κάθε πελάτη: τι κερδίζεις και τι πληρώνεις

Τι σημαίνει «ξεχωριστή βάση για κάθε πελάτη»;

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

Υπάρχουν τρεις τρόποι να οργανώσεις τα στοιχεία των πελατών. Ο πρώτος είναι ένας κοινός φωριαμός. Όλοι οι φάκελοι είναι μαζί και κάθε φάκελος γράφει πάνω το όνομα του πελάτη. Ο δεύτερος είναι ένας φωριαμός με χωριστά συρτάρια. Ο τρίτος είναι ένας ολόκληρος φωριαμός για κάθε πελάτη.

Η AWS, η υπηρεσία υποδομής της Amazon, το περιγράφει με δύο λέξεις. Το «χωριστό» μοντέλο (στα αγγλικά silo) δίνει σε κάθε πελάτη δικό του χώρο, και τα στοιχεία δεν αναμειγνύονται ποτέ. Το «κοινό» μοντέλο (στα αγγλικά pool) βάζει τα πάντα μαζί και ξεχωρίζει τους πελάτες από ένα αναγνωριστικό. Υπάρχει και η ενδιάμεση λύση, με κοινή βάση και ξεχωριστό συρτάρι για τον καθένα.

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

Πρώτα όμως μια διευκρίνιση που μπερδεύει πολλούς. Άλλο είναι να χωρίσεις τα στοιχεία και άλλο να τα προστατέψεις. Η AWS το τονίζει: αν έβαλες τα στοιχεία σε χωριστά μέρη, δεν σημαίνει ότι ένας πελάτης δεν μπορεί να φτάσει στα στοιχεία του άλλου. Χρειάζεται και κλειδαριά, δηλαδή δικαιώματα, έλεγχος ταυτότητας και έλεγχοι.

Τι κερδίζεις με ξεχωριστή βάση για κάθε πελάτη;

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

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

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

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

Τι πληρώνεις όταν αλλάζεις τη δομή της βάσης;

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

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

Το δεύτερο πρόβλημα είναι ότι πρέπει να βλέπεις τι συμβαίνει. Χρειάζεσαι έναν πίνακα που δείχνει σε ποια έκδοση βρίσκεται κάθε βάση. Αλλιώς δεν ξέρεις ποιος πελάτης έμεινε πίσω.

Το τρίτο πρόβλημα είναι ο χρόνος. Μια αλλαγή που σε μια μικρή βάση τελειώνει σε δευτερόλεπτα, σε μια μεγάλη μπορεί να κρατήσει πολύ. Γι' αυτό δοκιμάζεις πάντα πρώτα σε μια βάση που μοιάζει με τις μεγαλύτερες.

Ένας απλός κανόνας για αλλαγές σε πολλές βάσεις

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

Τι αλλάζει στα αντίγραφα ασφαλείας;

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

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

Το κόστος είναι η επιτήρηση. Με πολλές βάσεις, ένα αντίγραφο που δεν έγινε δεν φαίνεται από μόνο του. Στην υποδομή που έστησα στην AWS, η υπηρεσία AWS Backup έκανε τα αντίγραφα και η υπηρεσία CloudWatch παρακολουθούσε καθημερινά αν όλα πήγαν καλά. Το ζητούμενο είναι να φαίνεται νωρίς μια παράλειψη. Όχι την ώρα που χρειάζεσαι το αντίγραφο.

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

Πώς βγάζεις συνολικά νούμερα από εκατό βάσεις;

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

Αυτό είναι το κόστος που οι ομάδες το υποτιμούν. Φαντάσου ότι ρωτάς: «πόσοι χρήστες συνδέθηκαν συνολικά αυτόν τον μήνα;». Δεν έχει εύκολη απάντηση. Αν ανοίξεις εκατό φωριαμούς έναν έναν και προσθέσεις τα αποτελέσματα, θα πάρει πολλή ώρα. Θα σπάσει εύκολα. Και θα φορτώσει τις βάσεις των πελατών.

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

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

Πώς αλλάζει η καθημερινή δουλειά με μία βάση για κάθε πελάτη;

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

Η δημιουργία ενός νέου πελάτη

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

Η εύρεση της σωστής βάσης σε κάθε αίτημα

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

Η αποχώρηση ενός πελάτη

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

Τι δοκιμάζεις πριν από κάθε αλλαγή

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

Πότε αξίζει η ξεχωριστή βάση για κάθε πελάτη και πότε όχι;

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

Η AWS αναφέρει ότι πολλά προϊόντα καταλήγουν σε μικτή λύση. Οι μεγάλοι ή απαιτητικοί πελάτες παίρνουν δική τους υποδομή, και οι υπόλοιποι μοιράζονται μία κοινή.

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

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

Βήματα για να αποφασίσεις:

1. Γράψε τι απαιτεί ο χώρος σου για τον διαχωρισμό των στοιχείων: νόμος, συμβόλαια, πελάτες που θα ρωτήσουν.
2. Υπολόγισε πόσοι πελάτες θα έχεις σε τρία χρόνια και πόσο μεγάλοι θα είναι.
3. Αποφάσισε πώς θα γίνονται οι αλλαγές σε όλες τις βάσεις και πώς θα βλέπεις σε ποια έκδοση είναι η καθεμία.
4. Αποφάσισε πώς θα γίνονται και θα ελέγχονται τα αντίγραφα ασφαλείας για κάθε πελάτη.
5. Σχεδίασε το ξεχωριστό μέρος για τα συνολικά νούμερα πριν το χρειαστείς.