Μέσα στις διακοπές του Πάσχα δούλεψα πολύ προσπαθώντας να μεταφέρω[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 κ.λ.) χρειάζεται.

Έπαιξα λίγο με το amazon ec2. Εντυπωσιακό και θα με έψηνε η ιδέα να μεταφέρω εκεί τον “server” μου (ένα vps) σε αυτό[1]. Το κόστος υπολογίζω ότι θα μου έβγαινε γύρω στα $100/μήνα, σε σχέση με τα $60/μήνα που πληρώνω τώρα, αλλά θα είχα πολύ καλύτερο virtual μηχάνημα και πιο αξιόπιστη υποδομή. Το βασικό μου πρόβλημα όμως είναι ότι όταν “σβήσει” (shutdown, reboot) το μηχάνημα, όλα τα data εξαφανίζονται και αρχίζεις πάλι με ένα “καθαρό” installation (ή έστω με το δικό σου custom image). Δεν υπάρχει τρόπος π.χ. να κάνεις mount ένα filesystem από το S3 στο οποίο να σώζεις τα data. Η μόνη λύση είναι backup στο S3, αλλά, OK, δεν είναι το ίδιο.

Από την άλλη, θα μου πεις, ένα hosting environment δεν το κάνεις reboot εκτός και αν υπάρχει hardware failure και “κολλήσει” -κάτι που δείχνει πραγματικά απίθανο στο ec2. Αλλά και πάλι, δεν αισθάνομαι άνετα με την ιδέα.

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

Για αυτό που είναι σίγουρα ιδανικό το ec2, είναι αν κάνεις πράγματα που απαιτούν ώρες number crunching ή compiling ή κάτι τέτοιο. Σε αυτή την περίπτωση, δημιουργείς ένα image με το περιβάλλον που χρησιμοποιείς συνήθως (π.χ. τα compilation tools) και όταν χρειάζεται να κάνεις rebuild όλο το project, σηκώνεις ένα “extra large instance” [2] και κάνεις την δουλειά σου, με $0.80/ώρα, όταν τελειώσεις το σβήνεις και τελείωσες. Αν μάλιστα θέλεις π.χ. να κάνεις compile και για διαφορετικές πλατφόρμες ή με διαφορετικά options, σηκώνεις και άλλα παρόμοια instances και κάνεις την δουλειά σου παράλληλα. Εργασίες που θα χρειαζόντουσαν πολλές ώρες ή PC μερικών χιλιάδων ευρώ, γίνονται γρήγορα και με αστείο κόστος.

–
[1] η όλη διαδικασία δεν είναι δύσκολη, αλλά σε καμία περίπτωση δεν απευθύνεται στον “απλό χρήστη”. Η πρώτη φορά, ακολουθώντας τις οδηγίες του Amazon βήμα-βήμα, θα απαιτήσει 1-2 ώρες από ένα τυπικό admin και αρκετό command line, εξοικείωση με ssh κ.λ. για να φτάσει στο επιθυμητό αποτέλεσμα. Η δεύτερη σημαντικά λιγότερο χρόνο και φαντάζομαι ότι από ένα σημείο και μετά το να “σηκώσεις” ένα νέο instance μπορεί να είναι υπόθεση 1-2 λεπτών.
[2] “extra large instance” = virtual machine με 15 GB of memory, 8 EC2 Compute Units (4 virtual cores with 2 EC2 Compute Units each), 1690 GB of instance storage, 64-bit platform