vrypan|net|weblog (αρχείο)

Μέσα στις διακοπές του Πάσχα δούλεψα πολύ προσπαθώντας να μεταφέρω[1] το urlBorg στο Google AppEngine και νομίζω ότι πλέον έχω μία αρκετά καλή αντίληψη για το συγκεκριμένο περιβάλλον. Διαβάζοντας τα σχετικά άρθρα που έγραψα στο vrypan|net|log κάποιοι με ρώτησαν “γιατί μπαίνεις σε όλο αυτό τον κόπο και δεν χρησιμοποιείς το Amazon EC2“; Ορίστε λοιπόν μία σύγκριση των δύο.

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

Το Amazon EC2 είναι ουσιαστικά virtual hardware. Αυτό σημαίνει ότι μπορεί κανείς να το χρησιμοποιήσει όπως ακριβώς θα έκανε με ένα (ή περισσότερους) dedicated servers. Μπορείς να ξεκινήσεις χρησιμοποιώντας ένα virtual server με χαμηλές προδιαγραφές ταχύτητας και πολύ εύκολα αν η εφαρμογή σου έχει επιτυχία να αναβαθμίσεις σε ένα μεγαλύτερο -και επειδή ακριβώς το hardware είναι virtual, η μετάβαση αυτή γίνεται απλά πληρώνοντας για περισσότερα resources. Μπορείς ακόμη πολύ εύκολα να “σηκώσεις” νέους servers, π.χ. να βάλεις την database να τρέχει σε ένα ξεχωριστό “μηχάνημα” κ.λ. Και αν μιλάμε για web sites, μπορείς καθώς μεγαλώνει η κίνηση στο site σου να προσθέτεις επιπλέον web servers, να έχεις 2 ή και περισσότερα μηχανήματα με db replication κ.λ. Όπως ακριβώς θα έκανε κανείς με dedicated servers, αλλά πολύ πιο εύκολα, σχετικά πιο φθηνά (έως πολύ πιο φθηνά) και με την σιγουριά που προσφέρει η υποδομή της Amazon.

Από την άλλη, το Google AppEngine είναι ένα εντελώς διαφορετικό περιβάλλον. Έχει πάρα πολλούς και σημαντικούς περιορισμούς. Η γλώσσα προγραμματισμού αυτή την στιγμή είναι αποκλειστικά Python (αν και λέγεται ότι θα ακολουθήσουν και άλλες στο μέλλον). Οι βιβλιοθήκες που είναι διαθέσιμες είναι περιορισμένες και δεν επιτρέπουν πράγματα όπως image manipulation και γενικά οποιαδήποτε library της python είναι compiled (π.χ. γραμμένη σε C). Επίσης, δεν μπορεί κανείς να έχει background processes. Το μεγαλύτερο όμως πρόβλημα είναι ότι για την αποθήκευση δεδομένων δεν χρησιμοποιείται μία RDBMS άλλα το “Google Datastore” που για όποιον έχει συνηθίσει να δουλεύει με RDBMS μοιάζει να είναι ανίκανο να κάνει ακόμη και τα πιο βασικά (π.χ. ένα SELECT SUM() ή ένα unique auto increment ID).

Η προσέγγιση του Google AppEngine είναι “ορίστε το περιβάλλον στο οποίο αναπτύσσουμε σαν Google τις εφαρμογές μας, αν θέλετε και μπορείτε, χρησιμοποιήστε το”. Οι περιορισμοί που βάζει προφανώς έχουν κάποιο λόγο: να μπορεί μία εφαρμογή να κάνει “άπειρο”[2] scale [3]. Η προσέγγιση αυτή έχει τα καλά της και τα κακά της. Το κακό είναι ότι μεταφέρει τα διάφορα προβλήματα κλίμακας στον developer (προβλήματα για τα οποία σε άλλες περιπτώσεις φροντίζει η “υποδομή”, όπως το OS, ο web server, η RDBMS). Από την άλλη, μία καλογραμμένη εφαρμογή δεν έχει τα προβλήματα κλίμακας που ακριβώς αυτή η “υποδομή” βάζει από κάποιο σημείο και μετά (π.χ. με ένα καλύτερο server και με λίγη προσοχή μπορεί όντως ένα τυπικό website να αντέξει την κίνηση όταν οι επισκέπτες από 1000/ημέρα γίνουν 100.000 την ημέρα, αλλά δεν θα βρείτε server που να μπορέσει να αντιμετωπίσει με τίποτα 1.000.000 επισκέπτες το δευτερόλεπτο, για αυτό και όσοι αντιμετωπίζουν τέτοια προβλήματα έχουν server farms, clusters κ.λ.)

Κατά την γνώμη μου η επιλογή μεταξύ των δύο ξεκινάει με το ερώτημα “πόσο μεγάλη θα μπορούσε να γίνει η εφαρμογή μου στην ιδανική περίπτωση”. Π.χ. ένα site που απευθύνεται αποκλειστικά σε Έλληνες είναι δεδομένο ότι δεν μπορεί να ξεπεράσει κάποιο μέγεθος. Αντίθετα, αν φτιάχνετε το επόμενο twitter ή Google Analytics, η κίνηση σε περίπτωση επιτυχίας θα είναι πολλές τάξεις μεγέθους μεγαλύτερη από όσο θα μπορούσαν να σηκώσουν 1 ή 2 servers.

Μετά είναι το ερώτημα αν θέλει κανείς να “δεθεί” με την υποδομή της Google ή θα προτιμούσε να αντιμετωπίσει τα πιθανά προβλήματα κλίμακας μόνος του. Τα προβλήματα αυτά προφανώς και λύνονται (δεν περίμενε την Google το CNN ή το BBC για να μπορέσουν να εξυπηρετούν πολλά εκατομμύρια pageviews την μέρα), αλλά θα πρέπει να αντιμετωπίσει κανείς μόνος του (ή προσλαμβάνοντας ειδικούς) τις τεχνικές δυσκολίες. Ναι, μπορείτε να “σηκώσετε” όσους DB servers χρειάζεστε και να κάνετε replication και να έχετε άλλους τόσους η περισσότερους clustered web servers στο EC2, αλλά κάποιος θα πρέπει να ασχολείται με το πώς γίνεται αυτό το πράγμα, να κάνει maintenence, monitoring, optimization κ.λ. στην υποδομή -ένας ή περισσότεροι system admins, db admins κ.λ. Μία καλογραμμένη εφαρμογή που τρέχει στο AppEngine απλά ίσως να χρειαστεί optimization από τον developer.

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

Ελπίζω να έδωσα μία πιο πλήρη εικόνα από αυτή που κυκλοφορεί με απλοποιήσεις όπως “η Google παρουσιάζει τον αντίπαλο του Amazon EC2″.

Για εμένα η επιλογή να ασχοληθώ με το AppEngine πέρα από τα παραπάνω (και καλά το urlBorg θα έχει δισεκατομμύρια hits/sec… και μετά ξύπνησες!) είναι ότι αποτελεί μία (από άποψη development) σπαζοκεφαλιά που μετατρέπει σε προκλήσεις πράγματα που θεωρούσα βαρετά -ΟΚ, προγραμματιστική διαστροφή, το δέχομαι :-)

–
[1] όχι, δεν το έχω μεταφέρει ακόμη και θα χρειαστεί αρκετή δουλειά.
[2] όπου “άπειρο” ας θεωρήσουμε κάτι συγκρινόμενο ίσως με την κλίμακα που έχουν οι υπηρεσίες που προσφέρει η ίδια η Google.
[3] το περιβάλλον που προσφέρεται αυτή την στιγμή είναι περιορισμένο σε resources λέγοντας ότι είναι μόνο για development, αλλά ας δεχθούμε ότι (όπως λέει η Google) στο μέλλον θα μπορεί κάποιος να πληρώνει ανάλογα με το πόσα resources (bandwidth, cpu cycles, DB access κ.λ.) χρειάζεται.