Πολλές ελληνικές εταιρείες τρέχουν ακόμα το production σε ένα VPS, σε έναν τοπικό πάροχο hosting ή σε servers μέσα στο γραφείο. Δουλεύει μια χαρά, μέχρι τη μέρα που δεν δουλεύει: ο server γέμισε, ο άνθρωπος που τον έστησε έφυγε, ή ένας μεγάλος πελάτης ρωτάει πού είναι τα backups και τι γίνεται αν πέσει το data center.
Αν η σκέψη να μεταφέρετε το production σας γεμίζει άγχος, είναι απολύτως λογικό. Η μετάβαση στο cloud λύνει αυτά τα προβλήματα, αλλά μόνο αν είναι σχεδιασμένη. Αυτό είναι το checklist που χρησιμοποιούμε, με τη σειρά που το ακολουθούμε.
1. Αποφασίστε αν αξίζει
Πριν από οποιαδήποτε τεχνική δουλειά, γράψτε γιατί μεταφέρεστε και πόσο πρέπει να κοστίζει μετά. Καλοί λόγοι: χρειάζεστε redundancy που δεν μπορείτε να στήσετε μόνοι σας, μεγαλώνετε πιο γρήγορα από τους servers σας, το ζητάει ένας πελάτης ή ένας κανονισμός, ή φεύγουν οι άνθρωποι που ξέρουν το παλιό setup. Αδύναμος λόγος: «όλοι είναι στο cloud». Ένα καλοστημένο VPS μπορεί να βγαίνει φθηνότερο από ένα κακοστημένο cloud setup, και μια μετάβαση που διπλασιάζει τον λογαριασμό χωρίς να βελτιώνει την αξιοπιστία είναι βήμα προς τα πίσω.
Κάντε μια χοντρική εκτίμηση του μηνιαίου κόστους πριν ξεκινήσετε, και αποφασίστε ποιος θα έχει την ευθύνη αυτού του νούμερου μετά το go-live.
2. Καταγράψτε τα πάντα
Αυτό είναι το βήμα που καθορίζει αν η ημέρα της μεταφοράς θα είναι ήρεμη. Καταγράψτε κάθε κομμάτι, με έναν υπεύθυνο δίπλα:
- Servers και τι τρέχει πάνω τους, μαζί με όσα κανείς δεν θεωρεί «την εφαρμογή»: cron jobs, queue workers, scripts για αναφορές, τον FTP server που ακόμα χρησιμοποιεί ένας συνεργάτης.
- Βάσεις δεδομένων, το μέγεθός τους, πόσο γρήγορα αλλάζουν και ποιος διαβάζει απευθείας από αυτές.
- DNS records, πιστοποιητικά TLS και πού ανανεώνονται.
- Εξερχόμενα integrations: πάροχοι πληρωμών, APIs τραπεζών και δημοσίου, πάροχοι SMS και email. Αρκετοί από αυτούς έχουν whitelist την τωρινή σας IP, και η αλλαγή μπορεί να πάρει μέρες.
- Εισερχόμενες εξαρτήσεις: συνεργάτες, mobile εφαρμογές ή συσκευές που σας καλούν σε σταθερή IP ή hostname.
- Backups, πού πηγαίνουν, και πότε έγινε τελευταία φορά πραγματικό restore.
Τα IP whitelists είναι η πιο συνηθισμένη παγίδα για τις ελληνικές εταιρείες. Ξεκινήστε αυτά τα αιτήματα νωρίς.
3. Διαλέξτε region
Στο AWS, οι συνήθεις επιλογές για ελληνικά workloads είναι η Φρανκφούρτη (eu-central-1) και το Μιλάνο (eu-south-1). Και τα δύο κρατούν τα δεδομένα στην ΕΕ και απέχουν λίγες δεκάδες milliseconds από την Αθήνα, που αρκούν για σχεδόν κάθε web εφαρμογή. Η Φρανκφούρτη έχει τον μεγαλύτερο κατάλογο υπηρεσιών και συνήθως παίρνει πρώτη τα νέα features.
Η AWS έχει επίσης ανακοινώσει Local Zone στην Αθήνα. Ένα Local Zone επεκτείνει ένα parent region με compute και storage κοντά στους χρήστες σας, αλλά προσφέρει μόνο μέρος των υπηρεσιών. Έχει νόημα για κομμάτια του συστήματος που θέλουν πολύ χαμηλό latency ή δεδομένα που πρέπει να μείνουν στη χώρα, ενώ η υπόλοιπη πλατφόρμα τρέχει στο parent region. Ελέγξτε ποιες υπηρεσίες είναι διαθέσιμες πριν το βάλετε στο σχέδιό σας.
Σε GCP και Azure η λογική είναι ίδια: το κοντινότερο EU region με τις υπηρεσίες που χρειάζεστε, και όλα, μαζί με logs και backups, μέσα στην ΕΕ. Η σύγκριση AWS, GCP και Azure καλύπτει την ίδια την επιλογή παρόχου.
4. Στήστε τα θεμέλια πριν μετακινηθεί οτιδήποτε
- Λογαριασμοί. Χωρίστε το production από όλα τα υπόλοιπα από την αρχή. Στο AWS αυτό σημαίνει AWS Organizations με SSO και χωρίς κοινά root credentials.
- Δίκτυο. Private subnets για βάσεις και services, VPN προς ό,τι μένει on-prem, και gateway endpoints για S3 ώστε να μην πληρώνετε NAT για κίνηση που δεν χρειαζόταν να βγει.
- Infrastructure as code. Όλα σε Terraform από την πρώτη μέρα, με λογικά χωρισμένο state. Ό,τι στηθεί με κλικ στο console κατά τη μετάβαση, του χρόνου θα είναι η υποδομή που κανείς δεν ξέρει πώς δουλεύει.
- Logging και monitoring. Κεντρικά logs και βασικά alerts πριν φτάσει το πρώτο request του production, για να μπορείτε να συγκρίνετε παλιό και νέο.
5. Διαλέξτε compute: VMs, ECS ή Kubernetes
Εδώ πολλές μεταβάσεις ξοδεύουν περισσότερα απ' όσο πρέπει. Η ειλικρινής συμβουλή:
- Virtual machines (EC2): ο πιο γρήγορος δρόμος «lift and shift» για παλιό λογισμικό που θέλει να τρέχει σε server. Μια χαρά ως πρώτο βήμα· σχεδιάστε containers αργότερα, αν αξίζει.
- Managed containers (ECS με Fargate, Cloud Run): ταιριάζουν στα περισσότερα startups και ΜμΕ με λίγα services. Δεν υπάρχει cluster να συντηρείτε ούτε χρέωση control plane.
- Kubernetes (EKS, GKE, AKS): αξίζει με πολλά services, αρκετές ομάδες που κάνουν deploy ανεξάρτητα, ή ανάγκη για την ίδια πλατφόρμα σε πολλά cloud. Το EKS χρεώνει control plane ανά cluster, και η συντήρησή του θέλει πραγματική δουλειά.
Αν μεταφέρετε πέντε services, μάλλον δεν χρειάζεστε ακόμα Kubernetes. Αν μεταφέρετε πενήντα, μάλλον ναι.
6. Σχεδιάστε τη μεταφορά της βάσης
Η βάση καθορίζει πόσο downtime θα έχετε. Ένα dump σε maintenance window είναι απλό και αρκεί για μικρές βάσεις. Για οτιδήποτε μεγαλύτερο ή με περισσότερη κίνηση, κάντε συνεχές replication στη νέα managed βάση (με native replication ή AWS Database Migration Service), αφήστε τη να συγχρονιστεί, και αλλάξτε με πάγωμα εγγραφών μόνο για δευτερόλεπτα ή λίγα λεπτά.
- Δοκιμάστε restore ενός πλήρους backup στη νέα βάση πριν από τη μεταφορά, και χρονομετρήστε το.
- Ελέγξτε character sets, collations και time zones. Τα ελληνικά και οι ημερομηνίες είναι εκεί που εμφανίζονται τα «σιωπηλά» bugs στα δεδομένα.
- Αποφασίστε από πριν πώς γίνεται rollback αφού οι εγγραφές έχουν αρχίσει να πηγαίνουν στη νέα βάση.
7. Κάντε πρόβα, μετά τη μεταφορά
- Κατεβάστε τα DNS TTL σε ένα-δύο λεπτά τουλάχιστον μία μέρα πριν.
- Κάντε ολόκληρη δοκιμή σε staging, με χρονόμετρο και το πραγματικό runbook.
- Τη μέρα της μεταφοράς: πάγωμα εγγραφών, αναμονή μέχρι να συγχρονιστεί το replication, αλλαγή DNS ή load balancer, και έλεγχος με πραγματικά requests.
- Κρατήστε το παλιό περιβάλλον όρθιο και ανέγγιχτο για λίγες μέρες, σε περίπτωση που χρειαστεί rollback.
Διαλέξτε ώρα ήσυχη για την επιχείρησή σας, όχι για τους μηχανικούς. Για πολλά ελληνικά καταναλωτικά προϊόντα αυτό είναι πρωί καθημερινής, όχι Παρασκευή βράδυ.
8. Οι πρώτες 30 μέρες
- Ορίστε budgets και billing alerts από την πρώτη μέρα, και κοιτάξτε τον λογαριασμό κάθε εβδομάδα τον πρώτο μήνα.
- Μικρύνετε τους πόρους όταν η πραγματική κίνηση δείξει τι χρειάζεστε· οι πρώτες εκτιμήσεις είναι συνήθως μεγάλες.
- Αγοράστε Savings Plans ή committed-use discounts μόνο αφού σταθεροποιηθεί η χρήση.
- Κλείστε το παλιό περιβάλλον και ακυρώστε τα παλιά συμβόλαια. Είναι απίστευτα εύκολο να πληρώνετε και τα δύο για έναν ολόκληρο χρόνο χωρίς να το πάρετε είδηση.
- Κάντε έναν σύντομο απολογισμό: τι σας ξάφνιασε, και τι μπαίνει στο runbook για την επόμενη φορά.
Πόσο διαρκεί
Μια εφαρμογή με μία βάση συνήθως μεταφέρεται σε λίγες εβδομάδες. Μια εταιρεία με αρκετά services, περιβάλλοντα και εξωτερικά integrations θέλει συνήθως δύο έως έξι μήνες, με τον περισσότερο χρόνο σε απογραφή, θεμέλια και δοκιμές και όχι στην ίδια τη μεταφορά. Η απογραφή του βήματος 2 είναι αυτή που σας δίνει ρεαλιστική εκτίμηση, και την ησυχία ότι ξέρετε τι κάνετε.
Συχνές ερωτήσεις
Πόσο διαρκεί η μετάβαση στο cloud;
Μια εφαρμογή με μία βάση συνήθως θέλει λίγες εβδομάδες. Εταιρείες με αρκετά services, περιβάλλοντα και integrations χρειάζονται συνήθως δύο έως έξι μήνες, κυρίως για απογραφή, θεμέλια και δοκιμές.
ECS ή Kubernetes για ένα startup;
Με λίγα services, managed containers όπως ECS σε Fargate ή Cloud Run είναι συνήθως φθηνότερα και απλούστερα. Το Kubernetes αξίζει με πολλά services και αρκετές ομάδες που κάνουν deploy ανεξάρτητα.
Ποιο AWS region είναι καλύτερο για την Ελλάδα;
Η Φρανκφούρτη (eu-central-1) και το Μιλάνο (eu-south-1) είναι οι συνήθεις επιλογές, και τα δύο στην ΕΕ και λίγες δεκάδες milliseconds από την Αθήνα. Το Athens Local Zone μπορεί να φιλοξενήσει κομμάτια που θέλουν πολύ χαμηλό latency, δίπλα σε ένα parent region.