AWS Service Health Dashboard - Amazon S3 Availability Event: July 20, 2008.
Όπως πολύ σωστά παρατηρεί ο Dave Winer, μία τόσο λεπτομερής εξήγηση από την Amazon, για τα προβλήματα που αντιμετώπισε το S3, θέτει τον πήχη της εταιρικής επικοινωνίας πολύ ψηλά.
Μέσα στις διακοπές του Πάσχα δούλεψα πολύ προσπαθώντας να μεταφέρω[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 κ.λ.) χρειάζεται.
Το EC2 του Amazon, αποκτάει Persistent Storage, ένα από τα features που ζητούσαν πολλοί developers. Το storage αυτό είναι με την μορφή “raw” devices από 1GB ώς 1TB που το instance σας μπορεί να κάνει mount, format με το επιθυμητό filesystem κ.λ.
Η Google ξεκίνησε σήμερα το πρωί (για ώρα Ελλάδας) την δοκιμαστική λειτουργία του Google App Engine. Το Google App Engine είναι ένα web hosting environment που αξιοποιεί την τεχνογνωσία της Google στο θέμα των “scalable applications” -ποιος μπορεί να αμφισβητήσει ότι ξέρουν τί χρειάζεται να γίνει για να μπορέσει μία web εφαρμογή να εξυπηρετεί εκατομμύρια χρήστες ταυτόχρονα;
Πιο αναλυτικά:
Η ανακοίνωση αυτή αποτελεί πολύ σημαντικό γεγονός. Όσοι έχουμε κατά καιρούς αναπτύξει μια web app που να έχει γίνει δημοφιλής, ακόμη και στην πολύ μικρή ελληνική κλίμακα, ξέρουμε ότι από κάποιο κάποιο σημείο αρχίζουν διάφορα προβλήματα που δεν είχε βάλει με το μυαλό του ο developer. Εϊναι η στιγμή που ο αριθμός χρηστών αλλάζει μερικές τάξεις μεγέθους, που τα δεδομένα γίνονται πολύ περισσότερα στην βάση, που τα requests μετριούνται σε hits/sec και όχι σε hits/hour.
Με το Google App Engine η Google παρέχει ένα περιβάλλον στο οποίο ο developer μπορεί να δημιουργήσει (δωρεάν) την εφαρμογή του, να την δοκιμάσει και αν πετύχει να έχει μεγάλη κίνηση αυτό να μην τον απασχολήσει αφού θεωρητικά η ίδια η πλατφόρμα παρέχει το scalability. Αυτά είναι καλά νέα και για όσους σκέφτονται να ξεκινήσουν μία web startup και δίσταζαν μπροστά στον “φόβο της επιτυχίας”: τί κάνεις αν η υπηρεσία που ανέπτυξες γίνει ξαφνικά πολύ δημοφιλής με αποτέλεσμα να καταρρεύσει και από την άλλη, πώς να επενδύσεις σε hosting, managed services κ.λ. όταν είσαι ακόμη στην αρχή και δεν ξέρεις αν αξίζει ή όχι; Πλέον, μπορούν να κάνουν host την υπηρεσία τους δωρεάν και θα χρειαστεί να πληρώσουν μόνο αν μεγαλώσει αρκετά -απόλυτα λογικό.
Κάποιοι βλέπουν το Google App Engine ως ανταγωνιστή των διάφορων Amazon Web Services. Σε μερικές περιπτώσεις είναι. Αλλά νομίζω ότι οι δύο προσεγγίσεις είναι αρκετά διαφορετικές. Θα έλεγα ότι το AWS είναι απείρως πιο ευέλικτο και δεν στοχεύει μόνο σε web εφαρμογές. Από την άλλη το Google App Engine είναι προσανατολισμένο στο να λύσει ένα και μοναδικό πρόβλημα, αυτό της ανάπτυξης και του hosting web app που χρειάζονται scalability και για να το λύσει βάζει όλους τους περιορισμούς που θεωρεί λογικούς. Θα χρειαστεί να περιμένουμε για να δούμε αν οι δύο να συγκλίνουν ή θα αποκλίνουν. Πάντως, δεν θα μου έμοιαζε περίεργο η Amazon να παρουσιάσει ένα πιο “high level” περιβάλλον, ανάλογο με αυτό της Google, στοχεύοντας να καλύψει όλο το φάσμα.
Διαβάστε επίσης:
- Dave Winer: Early notes on GoogleApps
- TechCrunch Labs: Our Experience Building And Launching App On Google App Engine
- TechCrunch: Google Jumps Head First Into Web Services With Google App Engine
Virtual Hosting of S3 Buckets. Χρήσιμο για όποιον θέλει να κάνει host αρχεία για το site του στο Amazon S3.
Έπαιξα λίγο με το 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
