Ανάθεμα στο Google, δεν ήθελα να ξαναβάλω blog. Έχω τόσα πολλά να κάνω. Το blogging απαιτεί χρόνο, ενέργεια και δημιουργικότητα, τα οποία θα μπορούσα να αξιοποιήσω σωστά: τα βιβλία μου, , το παιχνίδι μου και ούτω καθεξής. Αλλά με εξοργίσατε αρκετά που πρέπει να το γράψω.
Ας το τελειώσουμε λοιπόν.
Επιτρέψτε μου να ξεκινήσω με μια σύντομη αλλά διδακτική ιστορία από την πρώτη στιγμή που ξεκίνησα να εργάζομαι στην Google. Ξέρω ότι λέω πολλά άσχημα πράγματα για την Google τον τελευταίο καιρό, αλλά με αναστατώνει όταν η εταιρεία μου παίρνει τακτικά ανίκανες επιχειρηματικές αποφάσεις. Ταυτόχρονα, πρέπει να του δώσουμε την τιμητική του: η εσωτερική υποδομή της Google είναι πραγματικά εξαιρετική, μπορούμε να πούμε με ασφάλεια ότι δεν υπάρχει τίποτα καλύτερο σήμερα. Οι ιδρυτές της Google ήταν πολύ καλύτεροι μηχανικοί από ό,τι θα είμαι ποτέ, και αυτή η ιστορία επιβεβαιώνει μόνο αυτό το γεγονός.
Πρώτον, ένα μικρό υπόβαθρο: Η Google διαθέτει μια τεχνολογία αποθήκευσης δεδομένων που ονομάζεται . Ήταν ένα αξιοσημείωτο τεχνικό επίτευγμα, ένα από τα πρώτα (αν όχι το πρώτο) «απεριόριστα επεκτάσιμο» κατάστημα κλειδιού-τιμής (K/V): ουσιαστικά η αρχή του NoSQL. Αυτές τις μέρες το Bigtable εξακολουθεί να τα πηγαίνει καλά στον αρκετά γεμάτο χώρο αποθήκευσης K/V, αλλά εκείνη την εποχή (2005) ήταν εκπληκτικά cool.
Ένα αστείο πράγμα για το Bigtable είναι ότι είχαν αντικείμενα επιπέδου εσωτερικού ελέγχου (ως μέρος της υλοποίησης) που ονομάζονταν διακομιστές tablet, με μεγάλα ευρετήρια, και κάποια στιγμή έγιναν εμπόδιο κατά την κλιμάκωση του συστήματος. Οι μηχανικοί του Bigtable μπερδεύονταν με το πώς να εφαρμόσουν την επεκτασιμότητα και ξαφνικά συνειδητοποίησαν ότι μπορούσαν να αντικαταστήσουν τους διακομιστές tablet με άλλο χώρο αποθήκευσης Bigtable. Άρα το Bigtable είναι μέρος της υλοποίησης του Bigtable. Αυτές οι αποθηκευτικές εγκαταστάσεις υπάρχουν σε όλα τα επίπεδα.
Μια άλλη ενδιαφέρουσα λεπτομέρεια είναι ότι για λίγο το Bigtable έγινε δημοφιλές και πανταχού παρόν στο Google, με κάθε ομάδα να έχει το δικό της αποθετήριο. Έτσι, σε μια από τις συναντήσεις της Παρασκευής, ο Λάρι Πέιτζ ρώτησε περιστασιακά: «Γιατί έχουμε περισσότερα από ένα Bigtable; Γιατί όχι μόνο ένα;» Θεωρητικά, ένας αποθηκευτικός χώρος θα πρέπει να είναι αρκετός για όλες τις ανάγκες αποθήκευσης της Google. Φυσικά, ποτέ δεν πήγαν μόνο σε ένα για πρακτικούς λόγους ανάπτυξης (όπως οι συνέπειες μιας πιθανής αποτυχίας), αλλά η θεωρία ήταν ενδιαφέρουσα. Ένα αποθετήριο για ολόκληρο το Σύμπαν (Παρεμπιπτόντως, γνωρίζει κανείς αν το Amazon το έκανε αυτό με το Sable του;)
Τέλος πάντων, εδώ είναι η ιστορία μου.
Εκείνη την εποχή, εργαζόμουν στην Google για λίγο περισσότερο από δύο χρόνια και μια μέρα έλαβα ένα email από την ομάδα μηχανικών Bigtable που ήταν κάπως έτσι:
Αγαπητέ Steve,
Γεια από την ομάδα του Bigtable. Θα θέλαμε να σας ενημερώσουμε ότι στο [όνομα κέντρου δεδομένων] χρησιμοποιείτε ένα πολύ, πολύ παλιό δυαδικό αρχείο Bigtable. Αυτή η έκδοση δεν υποστηρίζεται πλέον και θέλουμε να σας βοηθήσουμε να κάνετε αναβάθμιση στην πιο πρόσφατη έκδοση.
Παρακαλώ ενημερώστε με εάν μπορείτε να προγραμματίσετε λίγο χρόνο για να συνεργαστούμε για αυτό το θέμα.
Τα καλύτερα,
Bigtable Team
Στο Google λαμβάνετε πολλά μηνύματα, οπότε με την πρώτη ματιά διάβασα κάτι σαν αυτό:
Αγαπητέ παραλήπτη,
Γεια από κάποια ομάδα. Θέλουμε να επικοινωνήσουμε αυτό το μπλα μπλα μπλα μπλα. Μπλα μπλα μπλα μπλα μπλα μπλα, και μπλα μπλα μπλα αμέσως.
Ενημερώστε μας εάν μπορείτε να προγραμματίσετε λίγο από τον πολύτιμο χρόνο σας για μπλα μπλα μπλα.
Τα καλύτερα,
Κάποιο είδος εντολής
Σχεδόν το έσβησα αμέσως, αλλά στην άκρη της συνείδησής μου ένιωσα μια οδυνηρή, γκρίνια αίσθηση ότι ΟΧΙ ακριβως μοιάζει με επίσημη επιστολή όμως προφανώς, ότι ο παραλήπτης έκανε λάθος επειδή δεν χρησιμοποίησα το Bigtable.
Αλλά ήταν περίεργο.
Πέρασα την υπόλοιπη μέρα εναλλάξ σκεπτόμενος τη δουλειά και τι είδους κρέας καρχαρία να δοκιμάσω στη μικρο-κουζίνα, από τα οποία τουλάχιστον τρία ήταν αρκετά κοντά για να χτυπήσω από το κάθισμά μου με ένα εύστοχο ρίξιμο ενός μπισκότου, αλλά Η σκέψη να γράψω ποτέ δεν με άφησε με ένα αυξανόμενο συναίσθημα ήπιου άγχους.
Είπαν ξεκάθαρα το όνομά μου. Και το email στάλθηκε στη διεύθυνση email μου, όχι σε κάποιον άλλο, και δεν είναι cc: ή bcc:. Ο τόνος είναι πολύ προσωπικός και ξεκάθαρος. Ίσως αυτό είναι κάποιου είδους λάθος;
Τελικά, η περιέργεια με κέρδισε και πήγα να κοιτάξω την κονσόλα Borg στο κέντρο δεδομένων που ανέφεραν.
Και φυσικά, είχα υπό διαχείριση χώρο αποθήκευσης BigTable. Συγγνώμη τι? Κοίταξα το περιεχόμενό του και ουάου! Ήταν από τη θερμοκοιτίδα Codelab στην οποία κάθισα την πρώτη μου εβδομάδα στη Google τον Ιούνιο του 2005. Το Codelab σας ανάγκασε να εκτελέσετε το Bigtable για να γράψετε κάποιες τιμές εκεί και προφανώς δεν έκλεισα ποτέ τον χώρο αποθήκευσης μετά από αυτό. Δούλευε ακόμα παρόλο που είχαν περάσει περισσότερα από δύο χρόνια.
Υπάρχουν αρκετές αξιοσημείωτες πτυχές αυτής της ιστορίας. Πρώτον, το έργο του Bigtable ήταν τόσο ασήμαντο στην κλίμακα της Google που μόνο δύο χρόνια αργότερα κάποιος παρατήρησε τον επιπλέον χώρο αποθήκευσης και μόνο επειδή η έκδοση του δυαδικού ήταν ξεπερασμένη. Για σύγκριση, κάποτε σκέφτηκα να χρησιμοποιήσω για το διαδικτυακό μου παιχνίδι. Εκείνη την εποχή, αυτή η υπηρεσία κόστιζε περίπου 16 $ ετησίως. αδειάζω Bigtable στο GCP. Δεν λέω ότι σε εξαπατούν, αλλά κατά την προσωπική μου άποψη, είναι πολλά τα λεφτά για μια άδεια γαμημένη βάση δεδομένων.
Μια άλλη αξιοσημείωτη πτυχή είναι ότι η αποθήκευση εξακολουθεί να λειτουργεί μετά από δύο χρόνια. WTF; Τα κέντρα δεδομένων έρχονται και παρέρχονται. παρουσιάζουν διακοπές, υποβάλλονται σε προγραμματισμένη συντήρηση, αλλάζουν συνεχώς. Το υλικό ενημερώνεται, οι διακόπτες ανταλλάσσονται, όλα βελτιώνονται συνεχώς. Πώς στο διάολο μπόρεσαν να κρατήσουν το πρόγραμμά μου σε λειτουργία για δύο χρόνια με όλες αυτές τις αλλαγές; Αυτό μπορεί να φαίνεται σαν ένα μέτριο επίτευγμα το 2020, αλλά το 2005-2007 ήταν αρκετά εντυπωσιακό.
Και η πιο υπέροχη πτυχή είναι ότι μια εξωτερική ομάδα μηχανικών σε κάποια άλλη πολιτεία με πλησιάζει, ο ιδιοκτήτης μιας μικροσκοπικής, σχεδόν άδειας παρουσίας του Bigtable, ο οποίος έχει μηδενική κίνηση τα τελευταία δύο χρόνια - και προσφέρουν βοήθεια για την ενημέρωση του.
Τους ευχαρίστησα, διέγραψα τον αποθηκευτικό χώρο και η ζωή συνεχίστηκε ως συνήθως. Αλλά δεκατρία χρόνια μετά, ακόμα σκέφτομαι αυτό το γράμμα. Επειδή μερικές φορές λαμβάνω παρόμοια email από το Google Cloud. Μοιάζουν με αυτό:
Αγαπητέ χρήστη του Google Cloud,
Ως υπενθύμιση, θα διακόψουμε την υπηρεσία [ουσιαστική υπηρεσία που χρησιμοποιείτε] από τον Αύγουστο του 2020, μετά την οποία δεν θα μπορείτε να αναβαθμίσετε τις παρουσίες σας. Συνιστούμε την αναβάθμιση στην πιο πρόσφατη έκδοση, η οποία βρίσκεται σε δοκιμή beta, δεν έχει τεκμηρίωση, δεν έχει διαδρομή μετεγκατάστασης και είναι προηγουμένως ξεπερασμένη με την ευγενική μας βοήθεια.
Δεσμευόμαστε να διασφαλίσουμε ότι αυτή η αλλαγή θα έχει ελάχιστο αντίκτυπο σε όλους τους χρήστες της πλατφόρμας Google Cloud.
Καλύτεροι φίλοι για πάντα,
Google Cloud Platform
Αλλά σχεδόν ποτέ δεν διάβασα τέτοιες επιστολές, γιατί αυτό που στην πραγματικότητα λένε είναι:
Αγαπητέ παραλήπτη,
Αντε μου στο διαολο. Γάμα σου, γάμα σου, γάμα σου. Άσε ό,τι κάνεις γιατί δεν πειράζει. Αυτό που έχει σημασία είναι ο χρόνος μας. Χάνουμε χρόνο και χρήμα για να διατηρήσουμε τα χάλια μας και τα έχουμε βαρεθεί, οπότε δεν θα τα υποστηρίζουμε πια. Οπότε εγκαταλείψτε τα γαμημένα σχέδιά σας και αρχίστε να σκάβετε τη σκοτεινή τεκμηρίωσή μας, να ζητάτε αποκόμματα στα φόρουμ, και παρεμπιπτόντως, η νέα μας σκατά είναι εντελώς διαφορετική από την παλιά σκατά, επειδή χαλάσαμε αυτό το σχέδιο πολύ άσχημα, χε, αλλά αυτό είναι δικό σας πρόβλημα, όχι δικό μας.
Συνεχίζουμε να καταβάλλουμε προσπάθειες για να διασφαλίσουμε ότι όλες οι εξελίξεις σας θα καταστούν άχρηστες εντός ενός έτους.
Σε παρακαλώ, σκάσε
Google Cloud Platform
Και το γεγονός είναι ότι λαμβάνω τέτοιες επιστολές περίπου μια φορά το μήνα. Αυτό συμβαίνει τόσο συχνά και τόσο συνεχώς που αναπόφευκτα έσπρωξε μακριά εμένα από το GCP στο στρατόπεδο κατά του νέφους. Δεν συμφωνώ πλέον να βασίζομαι στις ιδιόκτητες εξελίξεις τους, γιατί στην πραγματικότητα είναι ευκολότερο για την devop να διατηρεί ένα σύστημα ανοιχτού κώδικα σε μια γυμνή εικονική μηχανή παρά να προσπαθεί να συμβαδίσει με την Google με την πολιτική της να κλείνει «ξεπερασμένα» προϊόντα.
Πριν επιστρέψω στο Google Cloud γιατί ακόμη και κοντά Δεν έχει τελειώσει η κριτική τους, ας δούμε τις επιδόσεις της εταιρείας σε κάποιους άλλους τομείς. Οι μηχανικοί της Google υπερηφανεύονται για την πειθαρχία τους στη μηχανική λογισμικού και αυτό είναι που στην πραγματικότητα προκαλεί προβλήματα. Η υπερηφάνεια είναι μια παγίδα για τους απρόσεκτους και έχει οδηγήσει πολλούς υπαλλήλους της Google να πιστεύουν ότι οι αποφάσεις τους είναι πάντα σωστές και ότι το να είναι σωστό (με κάποιο ασαφή ασαφή ορισμό) είναι πιο σημαντικό από το να νοιάζονται για τους πελάτες.
Θα δώσω μερικά τυχαία παραδείγματα από άλλα μεγάλα έργα εκτός Google, αλλά ελπίζω να βλέπετε αυτό το μοτίβο παντού. Είναι ως εξής: Η συμβατότητα προς τα πίσω διατηρεί τα συστήματα ζωντανά και ενημερωμένα για δεκαετίες.
Η συμβατότητα προς τα πίσω είναι ο σχεδιαστικός στόχος όλων των επιτυχημένων συστημάτων για τα οποία έχουν σχεδιαστεί ανοίξτε χρήση, δηλαδή υλοποιείται με ανοιχτό κώδικα ή/και ανοιχτά πρότυπα. Νιώθω ότι λέω κάτι πολύ προφανές ότι όλοι αισθάνονται ακόμη και άβολα, αλλά όχι. Αυτό είναι ένα πολιτικό ζήτημα, άρα χρειάζονται παραδείγματα.
Το πρώτο σύστημα που θα επιλέξω είναι το παλαιότερο: το GNU Emacs, το οποίο είναι ένα υβρίδιο μεταξύ του Σημειωματάριου των Windows, του πυρήνα του λειτουργικού συστήματος και του Διεθνούς Διαστημικού Σταθμού. Είναι λίγο δύσκολο να το εξηγήσω, αλλά με λίγα λόγια, το Emacs είναι μια πλατφόρμα που δημιουργήθηκε το 1976 (ναι, σχεδόν πριν από μισό αιώνα) για προγραμματισμό για να σας κάνει πιο παραγωγικούς, αλλά να μεταμφιέζεστε ως επεξεργαστής κειμένου.
Χρησιμοποιώ το Emacs κάθε μέρα. Ναι, χρησιμοποιώ επίσης το IntelliJ κάθε μέρα, έχει εξελιχθεί σε μια ισχυρή πλατφόρμα εργαλείων από μόνη της. Αλλά η σύνταξη επεκτάσεων για το IntelliJ είναι μια πολύ πιο φιλόδοξη και πολύπλοκη εργασία από τη σύνταξη επεκτάσεων για το Emacs. Και το πιο σημαντικό, όλα όσα γράφτηκαν για το Emacs διατηρούνται για πάντα.
Εξακολουθώ να χρησιμοποιώ το λογισμικό που έγραψα για το Emacs το 1995. Και είμαι βέβαιος ότι κάποιος χρησιμοποιεί ενότητες γραμμένες για Emacs στα μέσα της δεκαετίας του '80, αν όχι νωρίτερα. Μπορεί να απαιτούν μια μικρή αλλαγή από καιρό σε καιρό, αλλά αυτό είναι πραγματικά πολύ σπάνιο. Δεν ξέρω τίποτα που να έχω γράψει ποτέ για το Emacs (και έχω γράψει πολλά) που να απαιτούσε μια εκ νέου αρχιτεκτονική.
Το Emacs έχει μια λειτουργία που ονομάζεται make-obsolete για απαρχαιωμένες οντότητες. Η ορολογία του Emacs για τις θεμελιώδεις έννοιες των υπολογιστών (όπως το τι είναι το "παράθυρο") συχνά διαφέρει από τις συμβάσεις του κλάδου, επειδή η Emacs τις παρουσίασε πριν από πολύ καιρό. Αυτός είναι ένας τυπικός κίνδυνος για όσους είναι μπροστά από την εποχή τους: όλοι οι όροι σας είναι εσφαλμένοι. Αλλά το Emacs έχει μια έννοια υποτίμησης, που στην ορολογία τους ονομάζεται απαρχαίωση.
Αλλά στον κόσμο του Emacs φαίνεται να υπάρχει ένας διαφορετικός ορισμός λειτουργίας. Μια διαφορετική υποκείμενη φιλοσοφία, αν θέλετε.
Στον κόσμο του Emacs (και σε πολλούς άλλους τομείς, τους οποίους θα καλύψουμε παρακάτω), η καταργημένη κατάσταση API βασικά σημαίνει: "Πραγματικά δεν πρέπει να χρησιμοποιήσετε αυτήν την προσέγγιση, γιατί ενώ λειτουργεί, πάσχει από διάφορες ελλείψεις που θα λίστα εδώ. Αλλά στο τέλος της ημέρας, είναι δική σου επιλογή».
Στον κόσμο της Google, το να είσαι απαρχαιωμένο σημαίνει ότι «παραβιάζουμε τη δέσμευσή μας απέναντί σου». Αυτό είναι αλήθεια. Αυτό ουσιαστικά σημαίνει. Αυτό σημαίνει ότι θα σας αναγκάσουν τακτικά κάντε κάποια δουλειά, ίσως πολλή δουλειά, ως τιμωρία για την πίστη σε αυτά : Έχουμε το καλύτερο λογισμικό. Ο πιο γρήγορος! Κάνεις τα πάντα σύμφωνα με τις οδηγίες, εκκινείς την εφαρμογή ή την υπηρεσία σου και μετά μπαμ, μετά από ένα ή δύο χρόνια χαλάει.
Είναι σαν να πουλάς ένα μεταχειρισμένο που σίγουρα θα χαλάσει μετά από 1500 χλμ.
Αυτοί είναι δύο εντελώς διαφορετικοί φιλοσοφικοί ορισμοί της «απαρχαιότητας». Ο ορισμός της οσμής της Google . Δεν το πιστεύω αυτό στην πραγματικότητα προγραμματισμένη απαξίωση με την ίδια έννοια όπως η Apple. Αλλά η Google σχεδιάζει σίγουρα να σπάσει τα προγράμματά σας, με κυκλικό τρόπο. Το ξέρω γιατί εργάστηκα εκεί ως μηχανικός λογισμικού για πάνω από 12 χρόνια. Έχουν ασαφείς εσωτερικές κατευθυντήριες γραμμές σχετικά με το πόσο θα πρέπει να ακολουθείται η συμβατότητα προς τα πίσω, αλλά τελικά εξαρτάται από κάθε μεμονωμένη ομάδα ή υπηρεσία. Δεν υπάρχουν συστάσεις σε επίπεδο επιχείρησης ή μηχανικής και η πιο τολμηρή σύσταση όσον αφορά τους κύκλους απαξίωσης είναι «προσπαθήστε να δώσετε στους πελάτες 6-12 μήνες για να αναβαθμίσουν πριν σπάσουν ολόκληρο το σύστημά τους».
Το πρόβλημα είναι πολύ μεγαλύτερο από ό,τι νομίζουν, και θα συνεχιστεί για τα επόμενα χρόνια, επειδή η φροντίδα των πελατών δεν είναι στο DNA τους. Περισσότερα για αυτό παρακάτω.
Σε αυτό το σημείο θα κάνω μια τολμηρή δήλωση ότι το Emacs είναι επιτυχημένο σε μεγάλο βαθμό και μάλιστα κυρίως επειδή παίρνουν τόσο σοβαρά τη συμβατότητα προς τα πίσω. Στην πραγματικότητα, αυτή είναι η διατριβή του άρθρου μας. Τα επιτυχημένα ανοιχτά συστήματα με μεγάλη διάρκεια ζωής οφείλουν την επιτυχία τους στις μικροκοινότητες που ζουν γύρω τους εδώ και δεκαετίες επεκτάσεις/πρόσθετα. Αυτό είναι το οικοσύστημα. Έχω ήδη μιλήσει για τη φύση των πλατφορμών και το πόσο σημαντικές είναι, και πώς η Google δεν κατάλαβε ποτέ σε ολόκληρη την εταιρική της ιστορία τι συνεπάγεται η δημιουργία μιας επιτυχημένης ανοιχτής πλατφόρμας εκτός Android ή Chrome.
Στην πραγματικότητα, θα πρέπει να αναφέρω εν συντομία το Android γιατί μάλλον το σκέφτεστε.
Πρώτον, Το Android δεν είναι Google. Δεν έχουν σχεδόν τίποτα κοινό μεταξύ τους. Το Android είναι μια εταιρεία που αγοράστηκε από την Google τον Ιούλιο του 2005, η εταιρεία είχε τη δυνατότητα να λειτουργεί περισσότερο ή λιγότερο αυτόνομα και στην πραγματικότητα παρέμεινε σε μεγάλο βαθμό ανέγγιχτη στα χρόνια που μεσολάβησαν. Το Android είναι μια διαβόητη στοίβα τεχνολογίας και ένας εξίσου διαβόητος αγκαθωτός οργανισμός. Όπως είπε ένας υπάλληλος της Google, "Δεν μπορείτε απλώς να συνδεθείτε στο Android".
Σε ένα προηγούμενο άρθρο, συζήτησα πόσο κακές ήταν μερικές από τις πρώιμες σχεδιαστικές αποφάσεις του Android. Διάολε, όταν έγραψα αυτό το άρθρο έβγαζαν χάλια που ονομάζονταν "άμεσες εφαρμογές" που είναι τώρα (έκπληξη!) , και συμπονώ αν ήσασταν αρκετά ανόητοι για να ακούσετε την Google και να μετακινήσετε το περιεχόμενό σας σε αυτές τις άμεσες εφαρμογές.
Αλλά υπάρχει μια διαφορά εδώ, μια σημαντική διαφορά, η οποία είναι ότι οι άνθρωποι του Android καταλαβαίνουν πραγματικά πόσο σημαντικές είναι οι πλατφόρμες, προσπαθούν να διατηρήσουν τις παλιές εφαρμογές Android που λειτουργούν. Στην πραγματικότητα, οι προσπάθειές τους να διατηρήσουν τη συμβατότητα προς τα πίσω είναι τόσο ακραίες που ακόμη και εγώ, κατά τη σύντομη θητεία μου στο τμήμα Android πριν από μερικά χρόνια, βρέθηκα να προσπαθώ να τους πείσω να σταματήσουν την υποστήριξη για μερικές από τις παλαιότερες συσκευές και API (έκανα λάθος , όπως και σε πολλά άλλα πράγματα στο παρελθόν και στο παρόν. Συγγνώμη παιδιά Android! Τώρα που έχω πάει στην Ινδονησία, καταλαβαίνω γιατί τα χρειαζόμαστε).
Οι άνθρωποι του Android ωθούν τη συμβατότητα προς τα πίσω σε σχεδόν αδιανόητα άκρα, συσσωρεύοντας τεράστια ποσά τεχνικού χρέους παλαιού τύπου στα συστήματα και τις αλυσίδες εργαλείων τους. Θεέ μου, θα πρέπει να δεις μερικά από τα τρελά πράγματα που πρέπει να κάνουν στο σύστημα κατασκευής τους, όλα στο όνομα της συμβατότητας.
Για αυτό, απονέμω στο Android το πολυπόθητο βραβείο "You're Not Google". Πραγματικά δεν θέλουν να γίνουν Google, που δεν ξέρει πώς να δημιουργεί ανθεκτικές πλατφόρμες, αλλά Android ξέρει, πως να το κάνεις. Και έτσι η Google είναι πολύ έξυπνη από μία άποψη: επιτρέπει στους ανθρώπους να κάνουν τα πράγματα με τον δικό τους τρόπο στο Android.
Ωστόσο, οι άμεσες εφαρμογές για Android ήταν μια αρκετά ανόητη ιδέα. Και ξέρετε γιατί; Γιατί απαιτούσαν ξαναγράψτε και επανασχεδιάστε την αίτησή σας! Λες και οι άνθρωποι απλώς θα ξαναγράψουν δύο εκατομμύρια εφαρμογές. Υποθέτω ότι οι Instant Apps ήταν ιδέα κάποιου υπαλλήλου της Google.
Υπάρχει όμως μια διαφορά. Η συμβατότητα προς τα πίσω έχει υψηλό κόστος. Το ίδιο το Android φέρει το βάρος αυτού του κόστους, ενώ η Google επιμένει να επωμιστεί το βάρος είσαι, πελάτης που πληρώνει.
Μπορείτε να δείτε τη δέσμευση του Android για συμβατότητα προς τα πίσω στα API του. Όταν έχετε τέσσερα ή πέντε διαφορετικά υποσυστήματα που κάνουν κυριολεκτικά το ίδιο πράγμα, είναι ένα σίγουρο σημάδι ότι υπάρχει δέσμευση για συμβατότητα προς τα πίσω στον πυρήνα. Που στον κόσμο των πλατφορμών είναι συνώνυμο της δέσμευσης προς τους πελάτες και την αγορά σας.
Το κύριο πρόβλημα της Google εδώ είναι η υπερηφάνειά της για την υγιεινή της μηχανικής. Δεν τους αρέσει όταν υπάρχουν πολλοί διαφορετικοί τρόποι να κάνουν το ίδιο πράγμα, με τους παλιούς, λιγότερο επιθυμητούς τρόπους να κάθονται δίπλα στους νέους, πιο φανταχτερούς τρόπους. Αυξάνει την καμπύλη εκμάθησης για όσους είναι νέοι στο σύστημα, αυξάνει το βάρος της διατήρησης παλαιού τύπου API, επιβραδύνει την ταχύτητα των νέων λειτουργιών και το βασικό αμάρτημα είναι ότι δεν είναι όμορφο. Google - όπως η Λαίδη Άσκοτ από την Αλίκη στη Χώρα των Θαυμάτων του Τιμ Μπάρτον:
Lady Ascot:
- Αλίκη, ξέρεις τι φοβάμαι περισσότερο;
- Η παρακμή της αριστοκρατίας;
- Φοβόμουν ότι θα είχα άσχημα εγγόνια.
Για να κατανοήσουμε το αντάλλαγμα μεταξύ όμορφου και πρακτικού, ας ρίξουμε μια ματιά στην τρίτη επιτυχημένη πλατφόρμα (μετά το Emacs και το Android) και ας δούμε πώς λειτουργεί: την ίδια την Java.
Η Java έχει πολλά απαρχαιωμένα API. Η κατάργηση είναι πολύ δημοφιλής μεταξύ των προγραμματιστών Java, ακόμη πιο δημοφιλής από ό,τι στις περισσότερες γλώσσες προγραμματισμού. Η ίδια η Java, η βασική γλώσσα, και οι βιβλιοθήκες καταργούν συνεχώς τα API.
Για να πάρουμε μόνο ένα από τα χιλιάδες παραδείγματα, θεωρείται απαρχαιωμένη. Έχει καταργηθεί από την κυκλοφορία της Java 1.2 τον Δεκέμβριο του 1998. Έχουν περάσει 22 χρόνια από τότε που καταργήθηκε.
Αλλά ο πραγματικός μου κώδικας στην παραγωγή εξακολουθεί να σκοτώνει τα νήματα κάθε μέρα. Πιστεύεις πραγματικά ότι είναι καλό; Απολύτως! Εννοώ, φυσικά, αν ξαναέγραφα τον κώδικα σήμερα, θα τον εφάρμοζα διαφορετικά. Αλλά ο κώδικας για το παιχνίδι μου, που έχει κάνει εκατοντάδες χιλιάδες ανθρώπους χαρούμενους τις τελευταίες δύο δεκαετίες, είναι γραμμένος με μια λειτουργία να κλείνει νήματα που μένουν πολύ μακριά, και εγώ δεν χρειάστηκε ποτέ να το αλλάξει. Ξέρω το σύστημά μου καλύτερα από οποιονδήποτε, έχω κυριολεκτικά 25 χρόνια εμπειρίας στην παραγωγή και μπορώ να πω με βεβαιότητα: στην περίπτωσή μου, το κλείσιμο αυτών των συγκεκριμένων νημάτων εργασίας είναι εντελώς άνευ αξίας. Δεν αξίζει τον κόπο και τον χρόνο για να ξαναγράψω αυτόν τον κώδικα και ευχαριστώ τον Larry Ellison (μάλλον) που η Oracle δεν με ανάγκασε να τον ξαναγράψω.
Η Oracle πιθανώς καταλαβαίνει και τις πλατφόρμες. Ποιός ξέρει.
Στοιχεία μπορούν να βρεθούν σε όλα τα βασικά API της Java, τα οποία είναι γεμάτα με κύματα απαρχαιότητας, όπως οι γραμμές ενός παγετώνα σε ένα φαράγγι. Μπορείτε εύκολα να βρείτε πέντε ή έξι διαφορετικούς διαχειριστές πλοήγησης πληκτρολογίου (KeyboardFocusManager) στη βιβλιοθήκη Java Swing. Είναι πραγματικά δύσκολο να βρείτε ένα Java API που δεν έχει καταργηθεί. Αλλά εξακολουθούν να λειτουργούν! Νομίζω ότι η ομάδα Java θα καταργήσει πραγματικά ένα API μόνο εάν η διεπαφή δημιουργεί ένα κραυγαλέο ζήτημα ασφάλειας.
Να το πράγμα, παιδιά: Εμείς οι προγραμματιστές λογισμικού είμαστε όλοι πολύ απασχολημένοι και σε κάθε τομέα του λογισμικού βρισκόμαστε αντιμέτωποι με ανταγωνιστικές εναλλακτικές λύσεις. Ανά πάσα στιγμή, οι προγραμματιστές στη γλώσσα Χ εξετάζουν τη γλώσσα Υ ως πιθανή αντικατάσταση. Α, δεν με πιστεύεις; Θέλετε να το πείτε Swift; Όπως, όλοι μεταναστεύουν στο Swift και κανείς δεν το εγκαταλείπει, σωστά; Πω πω, πόσο λίγα ξέρεις. Οι εταιρείες μετρούν το κόστος των ομάδων ανάπτυξης διπλής κινητής τηλεφωνίας (iOS και Android) - και αρχίζουν να συνειδητοποιούν ότι αυτά τα συστήματα ανάπτυξης πολλαπλών πλατφορμών με αστεία ονόματα όπως το Flutter και το React Native λειτουργούν πραγματικά και μπορούν να χρησιμοποιηθούν για να μειώσουν το μέγεθος των κινητές ομάδες δύο φορές ή, αντίθετα, τις καθιστούν δύο φορές πιο παραγωγικές. Διακυβεύονται πραγματικά χρήματα. Ναι, υπάρχουν συμβιβασμοί, αλλά, από την άλλη, χρήματα.
Ας υποθέσουμε υποθετικά ότι η Apple πήρε ανόητα ένα σύνθημα από τον Guido van Rossum και δήλωσε ότι το Swift 6.0 είναι ασυμβίβαστο με το Swift 5.0, όπως η Python 3 είναι ασυμβίβαστη με την Python 2.
Μάλλον είπα αυτήν την ιστορία πριν από περίπου δέκα χρόνια, αλλά πριν από περίπου δεκαπέντε χρόνια πήγα στο O'Reilly's Foo Camp με τον Guido, κάθισα σε μια σκηνή με τον Paul Graham και μια δέσμη μεγάλων βολών. Καθίσαμε στην απίστευτη ζέστη περιμένοντας τον Λάρι Πέιτζ να πετάξει έξω με το προσωπικό του ελικόπτερο, ενώ ο Γκουίντο έκανε drone για το «Python 3000», το οποίο ονόμασε από τον αριθμό των ετών που θα χρειαζόταν ο καθένας να μεταναστεύσει εκεί. Τον ρωτούσαμε συνέχεια γιατί έσπασε τη συμβατότητα και απάντησε: «Unicode». Και ρωτήσαμε, αν έπρεπε να ξαναγράψουμε τον κώδικά μας, ποια άλλα οφέλη θα βλέπαμε; Κι εκείνος απάντησε «Γιοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοοο.
Εάν εγκαταστήσετε το Google Cloud Platform SDK ("gcloud"), θα λάβετε την ακόλουθη ειδοποίηση:
Αγαπητέ παραλήπτη,
Θα θέλαμε να σας υπενθυμίσουμε ότι η υποστήριξη για την Python 2 έχει καταργηθεί, οπότε γαμήστε σας
… και ούτω καθεξής. Κύκλος της ζωής.
Αλλά το θέμα είναι ότι κάθε προγραμματιστής έχει μια επιλογή. Και αν τους αναγκάσετε να ξαναγράψουν τον κώδικα αρκετά συχνά, μπορεί να το σκεφτούν άλλος επιλογές. Δεν είναι όμηροι σας, όσο κι αν θέλετε να είναι. Είναι καλεσμένοι σας. Η Python εξακολουθεί να είναι μια πολύ δημοφιλής γλώσσα προγραμματισμού, αλλά η Python 3(000) δημιούργησε τέτοιο χάος από μόνη της, στις κοινότητές της και στους χρήστες των κοινοτήτων της που οι συνέπειες δεν έχουν ξεκαθαριστεί εδώ και δεκαπέντε χρόνια.
Πόσα προγράμματα Python έχουν ξαναγραφτεί στο Go (ή στο Ruby, ή σε κάποια άλλη εναλλακτική λύση) λόγω αυτής της ασυμβατότητας προς τα πίσω; Πόσο νέο λογισμικό έχει γραφτεί σε κάτι διαφορετικό από την Python, αν και αυτό θα μπορούσε γραμμένο σε Python, αν ο Guido δεν είχε κάψει όλο το χωριό; Είναι δύσκολο να πούμε, αλλά η Python έχει ξεκάθαρα υποφέρει. Είναι τεράστιο χάος και όλοι χάνουν.
Ας υποθέσουμε, λοιπόν, ότι η Apple παίρνει ένα σύνθημα από τον Guido και διακόπτει τη συμβατότητα. Τι πιστεύετε ότι θα συμβεί στη συνέχεια; Λοιπόν, ίσως το 80-90% των προγραμματιστών να ξαναγράψουν το λογισμικό τους αν είναι δυνατόν. Με άλλα λόγια, το 10-20% της βάσης χρηστών πηγαίνει αυτόματα σε κάποια ανταγωνιστική γλώσσα, όπως το Flutter.
Κάντε αυτό πολλές φορές και θα χάσετε τη μισή βάση χρηστών σας. Ακριβώς όπως στον αθλητισμό, στον κόσμο του προγραμματισμού, η τρέχουσα μορφή έχει επίσης σημασία. όλα. Όποιος χάσει τους μισούς χρήστες του σε πέντε χρόνια θα θεωρείται Big Fat Loser. Πρέπει να είσαι trendy στον κόσμο των πλατφορμών. Αλλά εδώ είναι που η μη υποστήριξη παλαιότερων εκδόσεων θα σας καταστρέψει με την πάροδο του χρόνου. Επειδή κάθε φορά που ξεφορτώνεστε ορισμένους προγραμματιστές, (α) τους χάνετε για πάντα επειδή είναι θυμωμένοι μαζί σας που αθέσατε το συμβόλαιο και (β) τους δίνετε στους ανταγωνιστές σας.
Κατά ειρωνικό τρόπο, βοήθησα επίσης την Google να γίνει μια τέτοια prima donna που αγνοεί τη συμβατότητα προς τα πίσω όταν δημιούργησα το Grok, ένα σύστημα ανάλυσης και κατανόησης πηγαίου κώδικα που διευκολύνει την αυτοματοποίηση και την οργάνωση του ίδιου του κώδικα - παρόμοιο με ένα IDE, αλλά εδώ η υπηρεσία cloud αποθηκεύει υλοποιήθηκαν αναπαραστάσεις όλων των δισεκατομμυρίων γραμμών του πηγαίου κώδικα της Google σε μια μεγάλη αποθήκη δεδομένων.
Ο Grok παρείχε στους υπαλλήλους της Google ένα ισχυρό πλαίσιο για την εκτέλεση αυτοματοποιημένων ανακατασκευών σε ολόκληρη τη βάση κώδικα τους (κυριολεκτικά σε όλη την Google). Το σύστημα υπολογίζει όχι μόνο τις ανοδικές σας εξαρτήσεις (από τις οποίες εξαρτάστε), αλλά και φθίνων (που εξαρτώνται από εσάς), οπότε όταν αλλάζετε API, ξέρετε όλους όσους παραβιάζετε! Με αυτόν τον τρόπο, όταν κάνετε αλλαγές, μπορείτε να επαληθεύσετε ότι κάθε καταναλωτής του API σας έχει ενημερωθεί στη νέα έκδοση και στην πραγματικότητα, συχνά με το εργαλείο Rosie που έγραψαν, μπορείτε να αυτοματοποιήσετε πλήρως τη διαδικασία.
Αυτό επιτρέπει στη βάση κώδικα της Google να είναι εσωτερικά σχεδόν υπερφυσικά καθαρή, καθώς έχουν αυτούς τους ρομποτικούς υπηρέτες να τρέχουν στο σπίτι και να καθαρίζουν αυτόματα τα πάντα εάν μετονομάσουν SomeDespicablyLongFunctionName σε SomeDespicablyLongMethodName επειδή κάποιος αποφάσισε ότι ήταν άσχημο εγγόνι και έπρεπε να κοιμηθεί.
Και ειλικρινά, λειτουργεί αρκετά καλά για την Google... εσωτερικά. Εννοώ, ναι, η κοινότητα Go της Google γελάει καλά με την κοινότητα Java της Google λόγω της συνήθειας της συνεχούς ανακατασκευής. Αν επανεκκινήσετε κάτι Ν φορές, αυτό σημαίνει ότι όχι μόνο το βιδώσατε N-1 φορές, αλλά μετά από λίγο γίνεται ξεκάθαρο ότι πιθανότατα το έχετε βιδώσει και στην Νη προσπάθεια. Αλλά, σε γενικές γραμμές, παραμένουν πάνω από όλα αυτή τη φασαρία και κρατούν τον κωδικό «καθαρό».
Το πρόβλημα ξεκινά όταν προσπαθούν να επιβάλουν αυτή τη στάση στους πελάτες τους στο cloud και στους χρήστες άλλων API.
Σας παρουσίασα λίγο το Emacs, το Android και την Java. Ας δούμε την τελευταία επιτυχημένη μακρόβια πλατφόρμα: τον ίδιο τον Ιστό. Μπορείτε να φανταστείτε πόσες επαναλήψεις έχει κάνει το HTTP από το 1995 όταν χρησιμοποιούσαμε ετικέτες που αναβοσβήνουν; και εικονίδια "Υπό κατασκευή" σε ιστοσελίδες.
Αλλά εξακολουθεί να λειτουργεί! Και αυτές οι σελίδες εξακολουθούν να λειτουργούν! Ναι, παιδιά, τα προγράμματα περιήγησης είναι οι παγκόσμιοι πρωταθλητές στη συμβατότητα προς τα πίσω. Το Chrome είναι ένα άλλο παράδειγμα της σπάνιας πλατφόρμας Google που έχει τα κεφάλια της σωστά βιδωμένα και όπως ίσως μαντέψατε, το Chrome λειτουργεί αποτελεσματικά ως εταιρεία sandbox ξεχωριστή από την υπόλοιπη Google.
Θέλω επίσης να ευχαριστήσω τους φίλους μας στους προγραμματιστές λειτουργικών συστημάτων: Windows, Linux, NOT APPLE FUCK YOU APPLE, FreeBSD, κ.λπ., για την εξαιρετική δουλειά της συμβατότητας προς τα πίσω στις επιτυχημένες πλατφόρμες τους (η Apple παίρνει C στην καλύτερη περίπτωση με το The Το μειονέκτημα είναι ότι σπάνε τα πάντα χωρίς καλό λόγο, αλλά κατά κάποιο τρόπο η κοινότητα το ξεπερνάει με κάθε κυκλοφορία και τα κοντέινερ OS X δεν είναι ακόμα εντελώς απαρχαιωμένα... ακόμα).
Αλλά περίμενε, λες. Δεν συγκρίνουμε τα μήλα με τα πορτοκάλια - αυτόνομα συστήματα λογισμικού σε ένα μόνο μηχάνημα όπως το Emacs/JDK/Android/Chrome έναντι συστημάτων πολλών διακομιστών και API όπως οι υπηρεσίες cloud;
Λοιπόν, έγραψα γι' αυτό χθες, αλλά με το στυλ του Larry Wall (δημιουργός της γλώσσας προγραμματισμού Perl - περ. ανά.) με βάση την αρχή του "sucks/rules" έψαξα τη λέξη αποδοκιμαστεί στους ιστότοπους προγραμματιστών Google και Amazon. Και παρόλο που το AWS έχει εκατοντάδες φορές περισσότερες προσφορές υπηρεσιών από το GCP, η τεκμηρίωση προγραμματιστών της Google αναφέρει την κατάργηση περίπου επτά φορές πιο συχνά.
Αν κάποιος στην Google το διαβάζει αυτό, είναι πιθανότατα έτοιμος να βγάλει γραφήματα τύπου Ντόναλντ Τραμπ που δείχνουν ότι στην πραγματικότητα τα κάνει όλα σωστά και ότι δεν πρέπει να κάνω άδικες συγκρίσεις όπως "αριθμός αναφορών της λέξης που καταργήθηκε έναντι αριθμός υπηρεσιών" "
Αλλά μετά από όλα αυτά τα χρόνια, το Google Cloud εξακολουθεί να είναι η Νο. 3 υπηρεσία (δεν έγραψα ποτέ άρθρο για την αποτυχημένη προσπάθεια να γίνω Νο. 2), αλλά αν πιστευτούν οι μυημένοι, υπάρχουν κάποιες ανησυχίες ότι θα μπορούσαν σύντομα να πέσουν στο Νο 4.
Δεν έχω επιτακτικά επιχειρήματα για να «αποδείξω» τη διατριβή μου. Το μόνο που έχω είναι τα πολύχρωμα παραδείγματα που έχω συγκεντρώσει εδώ και 30 χρόνια ως προγραμματιστής. Έχω ήδη αναφέρει τη βαθιά φιλοσοφική φύση αυτού του προβλήματος. κατά κάποιο τρόπο πολιτικοποιείται στις κοινότητες προγραμματιστών. Κάποιοι το πιστεύουν δημιουργοί Οι πλατφόρμες θα πρέπει να ενδιαφέρονται για τη συμβατότητα, ενώ άλλοι πιστεύουν ότι αυτό είναι ανησυχητικό χρήστες (οι ίδιοι οι προγραμματιστές). Ένας στους δύο. Πράγματι, δεν είναι πολιτικό ζήτημα όταν αποφασίζουμε ποιος πρέπει να αναλάβει το κόστος των κοινών προβλημάτων;
Αυτό είναι λοιπόν πολιτική. Και μάλλον θα υπάρξουν θυμωμένες απαντήσεις στην ομιλία μου.
πως χρήστη Google Cloud Platform, και ως χρήστης AWS για δύο χρόνια (ενώ εργάζομαι για το Grab), μπορώ να πω ότι υπάρχει τεράστια διαφορά μεταξύ της Amazon και των φιλοσοφιών της Google όσον αφορά τις προτεραιότητες. Δεν αναπτύσσω ενεργά στο AWS, επομένως δεν ξέρω πολύ καλά πόσο συχνά αφαιρούν παλιά API. Αλλά υπάρχει η υποψία ότι αυτό δεν συμβαίνει τόσο συχνά όσο στο Google. Και πραγματικά πιστεύω ότι αυτή η πηγή συνεχούς διαμάχης και απογοήτευσης στο GCP είναι ένας από τους μεγαλύτερους παράγοντες που εμποδίζουν την ανάπτυξη της πλατφόρμας.
Γνωρίζω ότι δεν κατονόμασα συγκεκριμένα παραδείγματα συστημάτων GCP που δεν υποστηρίζονται πλέον. Μπορώ να πω ότι σχεδόν ό,τι έχω χρησιμοποιήσει, από δίκτυα (από το παλαιότερο έως VPC) μέχρι αποθήκευση (Cloud SQL v1-v2), Firebase (τώρα Firestore με εντελώς διαφορετικό API), App Engine (ας μην ξεκινήσουμε καν) , τερματικά σημεία σύννεφου Cloud Endpoint και μέχρι... Δεν ξέρω - απολύτως όλα αυτά σας ανάγκασαν να ξαναγράψετε τον κώδικα μετά από 2-3 χρόνια το πολύ και ποτέ δεν αυτοματοποίησαν τη μετεγκατάσταση για εσάς και συχνά . Σαν να έπρεπε να είναι έτσι.
Και κάθε φορά που κοιτάζω το AWS, αναρωτιέμαι γιατί στο διάολο είμαι ακόμα στο GCP. Προφανώς δεν χρειάζονται πελάτες. Χρειάζονται αγοραστές. Καταλαβαίνετε τη διαφορά; ΑΣΕ με να εξηγήσω.
Το Google Cloud έχει , όπου οι άνθρωποι προτείνουν τις λύσεις λογισμικού τους και για να αποφύγουν το φαινόμενο του άδειου εστιατορίου, χρειαζόταν να το γεμίσουν με κάποιες προτάσεις, έτσι συνήψαν σύμβαση με μια εταιρεία που ονομάζεται Bitnami για να δημιουργήσουν μια δέσμη λύσεων που αναπτύσσονται με «ένα κλικ» ή θα έπρεπε Το γράφω μόνος μου «λύσεις», γιατί αυτές δεν λύνουν τίποτα. Απλώς υπάρχουν ως πλαίσια ελέγχου, ως πληρωτικά μάρκετινγκ και η Google δεν ενδιαφέρθηκε ποτέ αν κάποιο από τα εργαλεία λειτουργεί πραγματικά. Γνωρίζω υπεύθυνους προϊόντων που έχουν καθίσει στη θέση του οδηγού και μπορώ να σας διαβεβαιώσω ότι αυτοί οι άνθρωποι δεν ενδιαφέρονται.
Πάρτε, για παράδειγμα, μια υποτιθέμενη λύση ανάπτυξης "με ένα κλικ". . Ήμουν άρρωστος μέχρι θανάτου από τις γελοιότητες του Google Cloud SQL, οπότε άρχισα να ψάχνω να δημιουργήσω το δικό μου σύμπλεγμα Percona ως εναλλακτική λύση. Και αυτή τη φορά η Google φαινόταν να έχει κάνει καλή δουλειά, επρόκειτο να μου γλυτώσει λίγο χρόνο και προσπάθεια με το πάτημα ενός κουμπιού!
Τέλεια, πάμε. Ας ακολουθήσουμε τον σύνδεσμο και ας κάνουμε κλικ σε αυτό το κουμπί. Επιλέξτε "Ναι" για να συμφωνήσετε με όλες τις προεπιλεγμένες ρυθμίσεις και να αναπτύξετε το σύμπλεγμα στο έργο σας στο Google cloud. Χαχα, δεν δουλεύει. Τίποτα από αυτά τα χάλια δεν λειτουργεί. Το εργαλείο δεν δοκιμάστηκε ποτέ και άρχισε να σαπίζει από το πρώτο λεπτό και δεν θα με εξέπληξε αν περισσότερες από τις μισές "λύσεις" είναι αναπτύξεις με ένα κλικ (τώρα καταλαβαίνουμε γιατί τα εισαγωγικά) γενικά δεν δουλεύει. Αυτό είναι απολύτως απελπιστικό σκοτάδι, όπου είναι καλύτερα να μην μπείτε.
Αλλά η Google έχει δίκιο κλήσεις να τα χρησιμοποιήσετε. Σε θέλουν αγορασμένος. Για αυτούς είναι μια συναλλαγή. Δεν θέλουν τίποτα υποστήριξη. Δεν είναι μέρος του DNA της Google. Ναι, οι μηχανικοί υποστηρίζουν ο ένας τον άλλον, όπως αποδεικνύεται από την ιστορία μου με το Bigtable. Αλλά σε προϊόντα και υπηρεσίες για απλούς ανθρώπους πάντα ήταν αδίστακτοι μέσα , που δεν ανταποκρίνεται στον πήχη της κερδοφορίας ακόμα κι αν έχει εκατομμύρια χρήστες.
Και αυτό αποτελεί πραγματική πρόκληση για το GCP, επειδή αυτό είναι το DNA πίσω από όλες τις προσφορές cloud. Δεν προσπαθούν να υποστηρίξουν τίποτα. Είναι γνωστό ότι αρνούνται να φιλοξενήσουν (ως διαχειριζόμενη υπηρεσία) οποιοδήποτε λογισμικό τρίτων μέχρι, μέχρι η AWS να κάνει το ίδιο και να δημιουργήσει μια επιτυχημένη επιχείρηση γύρω από αυτήν, και όταν οι πελάτες κυριολεκτικά απαιτούν το ίδιο. Ωστόσο, χρειάζεται κάποια προσπάθεια για να πείσετε την Google να υποστηρίξει κάτι.
Αυτή η έλλειψη κουλτούρας υποστήριξης, σε συνδυασμό με τη νοοτροπία «ας το σπάσουμε για να το κάνουμε πιο όμορφο», αποξενώνει τους προγραμματιστές.
Και αυτό δεν είναι καλό αν θέλετε να δημιουργήσετε μια μακροχρόνια πλατφόρμα.
Google, ξύπνα, διάολε. Είναι 2020 τώρα. Ακόμα χάνεις. Ήρθε η ώρα να ρίξετε μια προσεκτική ματιά στον καθρέφτη και να απαντήσετε εάν θέλετε πραγματικά να παραμείνετε στην επιχείρηση cloud.
Αν θέλεις να μείνεις τότε σταματήστε να τα σπάτε όλα. Παιδιά είστε πλούσιοι. Εμείς οι προγραμματιστές όχι. Επομένως, όταν πρόκειται για το ποιος θα επωμιστεί το βάρος της συμβατότητας, πρέπει να το αναλάβετε. Όχι για εμάς.
Γιατί υπάρχουν τουλάχιστον άλλα τρία πραγματικά καλά σύννεφα. Κουνούν.
Και τώρα θα προχωρήσω για να φτιάξω όλα τα χαλασμένα μου συστήματα. Ε.
Μέχρι την επόμενη φορά!
ΥΓ Ενημέρωση αφού διαβάσετε μερικές από τις συζητήσεις σε αυτό το άρθρο (οι συζητήσεις είναι υπέροχες, btw). Η υποστήριξη Firebase δεν έχει διακοπεί και δεν υπάρχουν σχέδια που να γνωρίζω. Ωστόσο, έχουν ένα δυσάρεστο σφάλμα ροής που κάνει τον πελάτη Java να σταματήσει στο App Engine. Ένας από τους μηχανικούς τους με βοήθησε να λύσω αυτό το πρόβλημα, όταν δούλευα στην Google, αλλά στην πραγματικότητα δεν διόρθωσαν ποτέ το σφάλμα, επομένως έχω μια άθλια λύση να πρέπει να επανεκκινώ την εφαρμογή GAE κάθε μέρα. Και έτσι είναι εδώ και τέσσερα χρόνια! Τώρα έχουν Firestore. Θα χρειαστεί πολλή δουλειά για να μεταφερθείτε σε αυτό, καθώς είναι ένα εντελώς διαφορετικό σύστημα και το σφάλμα Firebase δεν θα διορθωθεί ποτέ. Τι συμπέρασμα μπορεί να εξαχθεί; Μπορείτε να λάβετε βοήθεια εάν εργάζεστε σε εταιρεία. Είμαι ίσως ο μόνος που χρησιμοποιεί το Firebase στο GAE, επειδή καταγράφω λιγότερα από 100 κλειδιά σε μια 100% εγγενή εφαρμογή και σταματά να λειτουργεί κάθε δύο μέρες λόγω ενός γνωστού σφάλματος. Τι μπορώ να πω εκτός από το να το χρησιμοποιήσετε με δική σας ευθύνη. Αλλάζω στο Redis.
Έχω δει επίσης μερικούς πιο έμπειρους χρήστες AWS να λένε ότι το AWS συνήθως δεν σταματά ποτέ να υποστηρίζει καμία υπηρεσία και το SimpleDB είναι ένα εξαιρετικό παράδειγμα. Οι υποθέσεις μου ότι το AWS δεν έχει το ίδιο τέλος ασθένειας υποστήριξης όπως η Google φαίνεται να είναι δικαιολογημένες.
Επιπλέον, παρατήρησα ότι πριν από 20 ημέρες η ομάδα του Google App Engine διέκοψε τη φιλοξενία μιας κρίσιμης βιβλιοθήκης Go, τερματίζοντας μια εφαρμογή GAE από έναν από τους βασικούς προγραμματιστές της Go. Ήταν πραγματικά ηλίθιο.
Τέλος, έχω ακούσει τους υπαλλήλους της Google να συζητούν ήδη αυτό το θέμα και γενικά να συμφωνούν μαζί μου (love you guys!). Αλλά φαίνεται να πιστεύουν ότι το πρόβλημα είναι άλυτο επειδή η κουλτούρα της Google δεν είχε ποτέ τη σωστή δομή κινήτρων. Σκέφτηκα ότι θα ήταν καλό να αφιερώσω λίγο χρόνο για να συζητήσω την απολύτως εκπληκτική εμπειρία που είχα δουλεύοντας με μηχανικούς της AWS ενώ εργαζόμουν στο Grab. Κάποια μέρα στο μέλλον, ελπίζω!
Και ναι, το 2005 είχαν διαφορετικά είδη κρέατος καρχαρία στον τεράστιο μπουφέ στο κτίριο 43, και το αγαπημένο μου ήταν το κρέας καρχαρία σφυροκέφαλου. Ωστόσο, μέχρι το 2006, ο Λάρι και ο Σεργκέι απαλλάχθηκαν από όλα τα ανθυγιεινά σνακ. Έτσι, κατά τη διάρκεια της ιστορίας του Bigtable το 2007 δεν υπήρχαν καρχαρίες και σας εξαπάτησα.
Όταν κοίταξα το cloud Bigtable πριν από τέσσερα χρόνια (δώστε ή πάρτε), εδώ ήταν το κόστος. Φαίνεται να έχει πέσει λίγο τώρα, αλλά αυτό είναι ακόμα πολύ για μια άδεια αποθήκη δεδομένων, ειδικά επειδή η πρώτη μου ιστορία δείχνει πόσο ασήμαντο είναι ένα άδειο μεγάλο τραπέζι στην κλίμακα τους.
Συγγνώμη που προσβάλατε την κοινότητα της Apple και δεν είπα τίποτα καλό για τη Microsoft κ.λπ. Έχετε εντάξει, εκτιμώ πραγματικά όλη τη συζήτηση που έχει δημιουργήσει αυτό το άρθρο! Αλλά μερικές φορές χρειάζεται να κάνετε λίγο τα νεύρα για να ξεκινήσετε μια συζήτηση, ξέρετε;
Ευχαριστώ για την ανάγνωση.
Ενημέρωση 2, 19.08.2020/XNUMX/XNUMX. Ταινία !
Ενημέρωση 3, 31.08.2020/2/2. Επικοινώνησε μαζί μου ένας μηχανικός της Google στο Cloud Marketplace, ο οποίος αποδείχθηκε ότι ήταν ένας παλιός μου φίλος. Ήθελε να καταλάβει γιατί το CXNUMXD δεν λειτουργούσε και τελικά καταλάβαμε ότι ήταν επειδή είχα δημιουργήσει το δίκτυό μου πριν από χρόνια και το CXNUMXD δεν δούλευε σε δίκτυα παλαιού τύπου επειδή η παράμετρος υποδικτύου έλειπε στα πρότυπά τους. Πιστεύω ότι είναι καλύτερο για τους πιθανούς χρήστες GCP να βεβαιωθούν ότι γνωρίζουν αρκετούς μηχανικούς στην Google...
Πηγή: www.habr.com