cloud

Cloud: ποιο μοντέλο υπηρεσιών ταιριάζει στην επιχείρηση

Το cloud, δηλαδή η παροχή υπολογιστικών πόρων μέσω δικτύου ανάλογα με τη ζήτηση, μπορεί να προσφέρει ταχύτητα ανάπτυξης και ευελιξία. Δεν είναι όμως μία ενιαία λύση για όλες τις ανάγκες. Μια μικρή ομάδα που χρειάζεται έτοιμη εφαρμογή, μια εταιρεία που αναπτύσσει δικό της λογισμικό και ένας οργανισμός με αυστηρούς κανόνες ελέγχου υποδομής αντιμετωπίζουν διαφορετικές επιλογές. Το σωστό ερώτημα δεν είναι αν «πρέπει να πάμε στο νέφος», αλλά ποιες ευθύνες θέλουμε να διαχειριζόμαστε, ποια δεδομένα επηρεάζονται και πόσο μεταβάλλεται ο φόρτος. Η σύγκριση αρχίζει από τις ανάγκες και τελειώνει σε δοκιμή πραγματικής χρήσης.

Τι αγοράζουμε όταν επιλέγουμε υπηρεσίες νέφους

Το αμερικανικό Εθνικό Ινστιτούτο Προτύπων και Τεχνολογίας, γνωστό ως NIST (National Institute of Standards and Technology), ορίζει το υπολογιστικό νέφος ως πρόσβαση κατά ζήτηση σε κοινόχρηστους παραμετροποιήσιμους πόρους. Περιγράφει διακριτά μοντέλα όπου ο πελάτης χρησιμοποιεί έτοιμο λογισμικό, πλατφόρμα εφαρμογών ή υποκείμενη υποδομή. Αυτό σημαίνει ότι δεν αγοράζουμε υποχρεωτικά μηχανήματα· εξασφαλίζουμε συγκεκριμένες δυνατότητες και όρους χρήσης. Σε κάθε μοντέλο, όμως, εξακολουθεί να απαιτείται διαχείριση χρηστών, δεδομένων και κατάλληλων ρυθμίσεων. Οι συμβατικές υποχρεώσεις πρέπει να διαβάζονται μαζί με τις τεχνικές δυνατότητες και όχι ανεξάρτητα.

Έτοιμο λογισμικό, πλατφόρμα ή υποδομή;

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

Δημόσιο, ιδιωτικό και υβριδικό περιβάλλον

Σε δημόσιο νέφος οι πόροι παρέχονται από εξωτερικό οργανισμό σε πολλούς πελάτες με λογική απομόνωση. Ένα ιδιωτικό περιβάλλον σχεδιάζεται για έναν οργανισμό, χωρίς αυτό να σημαίνει ότι βρίσκεται υποχρεωτικά στα δικά του γραφεία. Η υβριδική προσέγγιση συνδέει διαφορετικά περιβάλλοντα, προσθέτοντας όμως ανάγκη για ενιαίες πολιτικές, δικτυακή επικοινωνία και παρακολούθηση. Πριν αποφασίσουμε, εξετάζουμε ποια συστήματα πρέπει να επικοινωνούν μεταξύ τους και πού επιτρέπεται να μεταφέρονται δεδομένα. Η ύπαρξη πολλών περιβαλλόντων δεν είναι από μόνη της στρατηγική αν δεν γνωρίζουμε ποιος τα λειτουργεί και πώς αντιμετωπίζονται οι αστοχίες.

Δέντρο απόφασης ανά εφαρμογή

Ξεκινάμε από το επίπεδο ελέγχου: αν αρκεί μια έτοιμη λειτουργία, εξετάζουμε εφαρμογή ως υπηρεσία. Αν χρειαζόμαστε δικό μας κώδικα αλλά όχι διαχείριση λειτουργικών συστημάτων, εξετάζουμε πλατφόρμα. Αν απαιτούνται ειδικές ρυθμίσεις δικτύου ή συστήματος, εξετάζουμε υποδομή ως υπηρεσία. Σε δεύτερο βήμα ελέγχουμε αν η εφαρμογή εξαρτάται από τοπικά μηχανήματα ή συνδέσεις που δυσκολεύουν τη μεταφορά. Τέλος αξιολογούμε τόπο δεδομένων, δικαιώματα διαχειριστών, σχέδιο ανάκτησης και κόστος αποχώρησης. Η επιλογή γίνεται για το συγκεκριμένο φορτίο, όχι απαραίτητα για ολόκληρο τον οργανισμό.

Οι χρεώσεις που συχνά ξεχνά η πρώτη εκτίμηση

Στο μηνιαίο κόστος περιλαμβάνονται περισσότεροι παράγοντες από την κεντρική υπολογιστική ισχύ: αποθήκευση, αντίγραφα, εξερχόμενη κίνηση δεδομένων, εργαλεία παρακολούθησης, πρόσθετες υπηρεσίες και ανθρώπινη διαχείριση. Ένα σύστημα με σταθερή χρήση μπορεί να έχει διαφορετική οικονομική εικόνα από ένα που λειτουργεί περιστασιακά. Ελέγχουμε τι συμβαίνει όταν αυξάνεται η επισκεψιμότητα, όταν αλλάζει ο όγκος δεδομένων και όταν απαιτείται γρήγορη ανάκτηση. Δεν βασιζόμαστε σε τιμοκατάλογο χωρίς ρεαλιστικό σενάριο λειτουργίας. Η οικονομική σύγκριση χρειάζεται κοινό ορίζοντα, ίδιες λειτουργίες και επαρκή πρόβλεψη για μεταφορά ή τερματισμό συνεργασίας.

Η περιοχή λειτουργίας και οι κανόνες δεδομένων

Μια περιοχή νέφους είναι γεωγραφική επιλογή ανάπτυξης υπηρεσιών και δεν πρέπει να συγχέεται με το όνομα μιας συγκεκριμένης εγκατάστασης. Η θέση της επηρεάζει τις διαδρομές επικοινωνίας, τις διαθέσιμες υπηρεσίες και τις επιλογές ανθεκτικότητας. Αν χρειαζόμαστε αποθήκευση ή επεξεργασία σε συγκεκριμένη γεωγραφική ζώνη, εξετάζουμε και τα αντίγραφα, τα αρχεία καταγραφής και την υποστήριξη. Δεν θεωρούμε δεδομένο ότι κάθε υπηρεσία διατίθεται σε όλες τις περιοχές. Το αναλυτικό θέμα cloud region βοηθά να καταγράψουμε απαιτήσεις πριν από την υλοποίηση. Για περιβάλλοντα δημόσιας διοίκησης χρειάζεται επιπλέον ειδικός θεσμικός έλεγχος.

Η ασφάλεια παραμένει κοινή υποχρέωση

Η χρήση υπηρεσίας δεν καταργεί την ευθύνη του πελάτη για την ασφαλή διαμόρφωση λογαριασμών, τον περιορισμό δικαιωμάτων και την προστασία των δεδομένων που διαχειρίζεται. Ρωτούμε τι προστατεύει ο πάροχος, τι ορίζουμε εμείς και ποιος αντιδρά σε συμβάν. Αν χρησιμοποιούμε έτοιμο λογισμικό, ο έλεγχος μπορεί να εστιάζει σε χρήστες και ρυθμίσεις διαμοιρασμού. Σε υποδομή ως υπηρεσία μεγαλώνει το πεδίο συντήρησης και παρακολούθησης που αναλαμβάνει η ομάδα. Χρειάζεται πολιτική αντιγράφων, έλεγχος ταυτοποίησης και διαδικασία ανάκτησης. Καμία γενική αναφορά σε «ασφαλές νέφος» δεν αντικαθιστά τεχνικό και συμβατικό έλεγχο.

Πότε το νέφος μπορεί να μην είναι η κατάλληλη απάντηση

Μια παλιά εφαρμογή μπορεί να εξαρτάται από ειδικό υλικό, άδειες χρήσης ή τοπικές συνδέσεις που καθιστούν τη μεταφορά δυσανάλογα περίπλοκη. Σε άλλες περιπτώσεις, ένα ιδιαίτερα προβλέψιμο φορτίο ίσως ωφελείται από εναλλακτικό μοντέλο κόστους. Το ουσιαστικό είναι να συγκρίνουμε λειτουργικά ισοδύναμα σενάρια αντί να αντιμετωπίζουμε την τεχνολογία ως υποχρεωτικό προορισμό. Μπορεί επίσης να προκύψει μικτή λύση, όπου μεταφέρονται πρώτα συστήματα χαμηλού κινδύνου και παραμένουν προσωρινά τοπικές υπηρεσίες. Η αποδοχή πρέπει να βασίζεται σε δοκιμή συμβατότητας, πραγματική απόδοση και σαφείς όρους προστασίας δεδομένων.

Πιλοτική εφαρμογή πριν δεσμεύσουμε όλο το έργο

Επιλέγουμε μία αντιπροσωπευτική εφαρμογή, ορίζουμε αναμενόμενο φόρτο και δοκιμάζουμε πρόσβαση, εξαρτήσεις, αντίγραφα και αντιμετώπιση περιστατικού. Καταγράφουμε πραγματική κατανάλωση πόρων, δυσκολίες διαχείρισης και χρόνο αποκατάστασης από γνωστό σενάριο βλάβης. Οι δοκιμές περιλαμβάνουν και την έξοδο: μπορούμε να εξαγάγουμε αρχεία, ρυθμίσεις και δεδομένα σε αξιοποιήσιμη μορφή; Αν οι απαντήσεις δεν είναι ικανοποιητικές, προσαρμόζουμε την αρχιτεκτονική πριν γενικεύσουμε τη μετάβαση. Για συγκριτική θεώρηση μεταξύ επιλεγμένων μοντέλων χρήσης, δείτε το θέμα νέφος στον ιδιωτικό τομέα.

Τι γράφουμε στο τελικό φύλλο επιλογής

Η απόφαση περιλαμβάνει μοντέλο υπηρεσίας, επιθυμητό έλεγχο, ορισμό υπευθύνων, ανεκτή διακοπή, επιτρεπόμενες τοποθεσίες δεδομένων, αναμενόμενο κόστος και διαδικασία εξόδου. Οι επιλογές κατατάσσονται ως «καλύπτει», «καλύπτει υπό προϋποθέσεις» ή «δεν καλύπτει», με σύντομη αιτιολόγηση. Δεν αθροίζουμε μη συγκρίσιμα πλεονεκτήματα για να βγει τεχνητά νικητής. Αν ένα υποχρεωτικό κριτήριο ασφάλειας ή συμμόρφωσης αποτύχει, απαιτείται αλλαγή σχεδίου. Το κατάλληλο cloud δεν είναι γενική ετικέτα ποιότητας αλλά μια τεκμηριωμένη σχέση συγκεκριμένης υπηρεσίας με συγκεκριμένες ανάγκες.

Κίνδυνος εξάρτησης από έναν πάροχο

Οι εξειδικευμένες υπηρεσίες μπορούν να επιταχύνουν την ανάπτυξη, αλλά ενδέχεται να δυσκολεύουν την αλλαγή παρόχου. Πριν τις χρησιμοποιήσουμε, αξιολογούμε πόσο εύκολα εξάγονται δεδομένα, ποιες ρυθμίσεις μεταφέρονται και πόσο εξαρτάται ο κώδικας από μοναδικές λειτουργίες. Δεν απορρίπτουμε κάθε εξειδίκευση, επειδή μπορεί να προσφέρει πραγματική αξία. Τεκμηριώνουμε όμως το κόστος μετάβασης και την επιχειρησιακή συνέπεια της εξάρτησης. Για κρίσιμες εφαρμογές αξίζει μια μικρή δοκιμή εξαγωγής και επαναφοράς σε εναλλακτικό περιβάλλον. Η δυνατότητα εξόδου πρέπει να υπάρχει στο σχέδιο πριν παρουσιαστεί ανάγκη αναγκαστικής αλλαγής.

Χρονοδιάγραμμα μετάβασης με ελεγχόμενα βήματα

Η μετάβαση μπορεί να ξεκινήσει με απογραφή συστημάτων και χαρτογράφηση εξαρτήσεων. Έπειτα επιλέγεται υπηρεσία χαμηλού κινδύνου για δοκιμή, με σαφές αποτέλεσμα αποδοχής. Προχωρούμε σε μεταφορά δεδομένων, ελέγχουμε δικαιώματα, διασυνδέσεις και επιδόσεις και προβλέπουμε δυνατότητα επιστροφής. Η ομάδα καταγράφει τι έμαθε και τι θα αλλάξει στο επόμενο στάδιο. Με αυτό τον τρόπο η υιοθέτηση δεν στηρίζεται σε γενική προσδοκία μείωσης κόστους ή αυτόματης ασφάλειας. Κάθε νέα εφαρμογή περνά από δική της αξιολόγηση, με διαφορετικό επίπεδο προσοχής ανάλογα με τα δεδομένα και τη σημασία της.