Υπάρχουν δύο τρόποι να αφήσετε κάποιον άλλο να λειτουργεί την υποδομή σας. Στον πρώτο, αγοράζετε cloud από αυτόν: αυτός κρατά τους λογαριασμούς παρόχου, αυτός παίρνει το τιμολόγιο, εσείς παίρνετε έναν λογαριασμό με προσαύξηση και μια διεύθυνση υποστήριξης. Στον δεύτερο - bring your own cloud, συνήθως συντομευμένο σε BYOC - κρατάτε τους δικούς σας λογαριασμούς με Hetzner ή AWS ή OVHcloud, τη δική σας σύμβαση, το δικό σας τιμολόγιο, και παραχωρείτε σε μια πλατφόρμα διαχείρισης οριοθετημένα credentials για να τους λειτουργεί για λογαριασμό σας. Τα δύο μοντέλα μοιάζουν παρόμοια σε μια επίδειξη και δεν συμπεριφέρονται καθόλου το ίδιο τη μέρα που θέλετε να φύγετε.

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

Τι κρατάτε όταν κρατάτε τη σύμβαση

Στο BYOC η σχέση με τον πάροχο παραμένει εκεί που θα την περίμενε ένας δικηγόρος. Τα instances είναι στον λογαριασμό σας. Τα tickets υποστήριξης είναι δικά σας να τα ανοίξετε. Το τιμολόγιο φτάνει στη μορφή που η οικονομική σας ομάδα ήδη συμφωνεί, από μια εταιρεία που ήδη ελέγξατε, υπό μια δικαιοδοσία που ήδη έχετε σκεφτεί. Αν η στάση συμμόρφωσής σας εξαρτάται από το ποιος λειτουργεί νομικά μια υπηρεσία - που, μετά το Schrems II, είναι το ενδιαφέρον ερώτημα αντί για το πού φυσικά βρίσκονται οι διακομιστές - δεν έχετε προσθέσει κρίκο σε αυτή την αλυσίδα υιοθετώντας ένα control plane.

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

Τι απαιτεί το BYOC από την πλατφόρμα

Το τίμημα του μοντέλου είναι ότι η πλατφόρμα τώρα κρατά πραγματικά credentials παραγωγής για λογαριασμούς που δεν κατέχει. Αυτή η υποχρέωση πρέπει να ληφθεί κυριολεκτικά. Τα credentials κρυπτογραφούνται at rest με AES-256-GCM, οριοθετημένα σε έναν μόνο οργανισμό, ποτέ δεν μοιράζονται μεταξύ tenants, και ποτέ δεν επιστρέφονται σε απάντηση API - τα πεδία είναι private τόσο κατά την έξοδο όσο και κρυπτογραφημένα κατά την είσοδο. Καθένα από αυτά είναι μια βαρετή απαίτηση που γίνεται ενδιαφέρουσα την πρώτη φορά που ένα απλό endpoint λίστας του ζητείται να σειριοποιήσει μια εγγραφή credential.

Έπειτα υπάρχει ο τρόπος αποτυχίας που κανείς δεν προγραμματίζει. Μια εργασία provisioning φτάνει χωρίς κανένα συνδεδεμένο credential: ένα bug, μια συνθήκη ανταγωνισμού, ένα μήνυμα από παλαιότερη έκδοση μιας υπηρεσίας. Η δελεαστική συμπεριφορά είναι να πέσετε πίσω στο δικό token παρόχου της πλατφόρμας ώστε η εργασία να πετύχει. Το κάναμε αυτό μια φορά και έκανε ακριβώς αυτό που θα έκανε πάντα - δημιούργησε ένα πραγματικό μηχάνημα στον δικό λογαριασμό της πλατφόρμας, χρεωμένο στο λάθος μέρος, αόρατο στην απογραφή του πελάτη. Η προεπιλογή τώρα είναι fail-closed. Μια εργασία χωρίς credential απορρίπτεται, και η ενεργοποίηση του fallback απαιτεί ρητή σημαία περιβάλλοντος.

Πού γίνεται δύσκολο το multi-provider BYOC

Ένας πάροχος είναι μια ενσωμάτωση· έντεκα είναι πρόβλημα ταξινομίας. Το Sencai σήμερα λειτουργεί με Hetzner, OVHcloud, Scaleway, UpCloud, AWS, Azure, Google Cloud, DigitalOcean, Vultr, Akamai/Linode και Oracle Cloud, συν on-premise και bare-metal διακομιστές μέσω ενός host agent. Καθένας από αυτούς έχει το δικό του μοντέλο ελέγχου ταυτότητας, το δικό του σύστημα ποσοστώσεων, το δικό του λεξιλόγιο, και τη δική του άποψη για το αν ένα firewall ανήκει σε ένα μηχάνημα, ένα δίκτυο, ή ένα project. Το να τα κανονικοποιήσετε αυτά χωρίς να πείτε ψέματα γι' αυτά είναι το μεγαλύτερο μέρος της μηχανικής.

Η γραμμή που προσπαθούμε να κρατήσουμε είναι ότι το control plane λειτουργεί τον πάροχο αντί για ένα αντίγραφό του. Όταν δημιουργείτε ένα δίκτυο, έναν κανόνα firewall ή μια ζώνη DNS στο Sencai, η κλήση πηγαίνει στο API του παρόχου και το αντικείμενο υπάρχει εκεί - ορατό στη δική του κονσόλα, διαγράψιμο με το δικό του CLI, πραγματικό για όποιον δεν έχει ξανακούσει για εμάς. Μια πλατφόρμα που απλά καταγράφει πρόθεση στη δική της βάση δεδομένων παράγει μια πολύ πειστική απογραφή πραγμάτων που μπορεί να μην υπάρχουν.

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

Για ποιον είναι το bring your own cloud

Το BYOC ταιριάζει σε ομάδες με μια υποδομή που ήδη υπάρχει και περιορισμούς που είναι ήδη πραγματικοί: μερικές εκατοντάδες μηχανήματα συσσωρευμένα σε τρία χρόνια, μια απαίτηση δικαιοδοσίας από την ομάδα προμηθειών ενός πελάτη, ένα μείγμα παρόχων που απλά συνέβη αντί να σχεδιαστεί. Ταιριάζει χειρότερα αν ξεκινάτε από το μηδέν, θέλετε ακριβώς ένα τιμολόγιο, και δεν έχετε καμία άποψη για το πού τρέχει οτιδήποτε. Ένας μεταπωλητής ή ένας μεμονωμένος hyperscaler θα είναι απλούστεροι, και θα πρέπει να διαλέξετε το απλούστερο. Κανείς δεν χρειάζεται ένα multi-cloud control plane για έναν λογαριασμό και έντεκα διακομιστές.

Δύο πράγματα γίνονται πιο κρίσιμα κάτω από το BYOC και αξίζουν σκόπιμο σχεδιασμό αντί για καλές προθέσεις. Το πρώτο είναι η απομόνωση: τα credentials ανήκουν σε έναν οργανισμό, η ιδιότητα μέλους γίνεται με πρόσκληση, και οι ρόλοι αποφασίζουν ποιος μπορεί να ξοδέψει χρήματα ή να αγγίξει ένα firewall - γιατί η ακτίνα καταστροφής εδώ είναι ένας πραγματικός λογαριασμός παραγωγής, όχι ένα sandbox. Το δεύτερο είναι το ίχνος ελέγχου. Κάθε ενέργεια που κάνει η πλατφόρμα για λογαριασμό σας θα έπρεπε να καταγράφεται μόνο-για-προσθήκη, με τον δράστη, τον πόρο και ένα correlation ID, σε μορφή που μπορείτε να εξάγετε. Αναθέτετε λειτουργίες, οπότε η καταγραφή αυτών των λειτουργιών είναι αυτό που έχετε αντί να τις έχετε κάνει μόνοι σας.

Λοιπόν, οι ερωτήσεις που αξίζει να κάνετε σε όποιον σας πουλά bring your own cloud. Ποιανού το όνομα είναι στη σύμβαση με τον πάροχο; Τι ακριβώς μπορεί να κάνει το credential που παραδώσατε, και μπορείτε να το περιορίσετε; Τι συμβαίνει στην τρέχουσα υποδομή αν σταματήσετε να τους πληρώνετε αύριο; Μπορείτε να εξάγετε το log όλων όσων έκαναν μέσα στους λογαριασμούς σας, και να το ελέγξετε ανεξάρτητα; Καλές απαντήσεις σε αυτά τα τέσσερα είναι αυτό που ξεχωρίζει την ανάθεση των λειτουργιών σας από την ανάθεση της υποδομής σας - και μόνο ένα από αυτά τα δύο είναι αναστρέψιμο μια Τρίτη.