Kubernetes, Δικτύωση και Εύρεση του VMware του Cloud Native

Ο Thomas Graf είναι ο συνιδρυτής και CTO του Ισοδύναμο, και δημιουργός μιας δημοφιλής τεχνολογίας δικτύωσης ανοιχτού κώδικα (και εγγενούς cloud) που ονομάζεται Τσίλιουμ. Το Cilium είναι χτισμένο πάνω σε μια τεχνολογία Linux σε επίπεδο πυρήνα που ονομάζεται eGMP.

Σε αυτή τη συνέντευξη, ο Graf συζητά τους ρόλους που διαδραματίζουν το Cilium και το eBPF στο αναπτυσσόμενο οικοσύστημα δικτύωσης του cloud, καθώς και ορισμένες ευρύτερες τάσεις γύρω από την υιοθέτηση και την εξέλιξη του Kubernetes. Εξηγεί ποιος χρησιμοποιεί και αγοράζει το Kubernetes σε μεγάλες επιχειρήσεις, όπου η εγγενής υποδομή του cloud χρειάζεται ακόμα βελτίωση και πώς η επιθυμία για τυποποίηση οδηγεί την καινοτομία.

---

ΜΕΛΛΟΝ: Πώς πρέπει να σκεφτόμαστε για το eBPF και το Cilium στο πλαίσιο της πληροφορικής και της δικτύωσης, γενικά, και στη συνέχεια ειδικά στο πλαίσιο του σύννεφο εγγενές οικοσύστημα?

ΤΟΜΑΣ ΓΚΡΑΦ: Συνολικά, το eBPF είναι η τεχνολογία και είναι εξαιρετικά χαμηλού επιπέδου. Σχεδιάστηκε για προγραμματιστές πυρήνα και το υπόβαθρό μου είναι στην ανάπτυξη πυρήνα. Το eBPF είναι για τον πυρήνα, για το λειτουργικό σύστημα, ό,τι είναι η JavaScript για ένα πρόγραμμα περιήγησης. Κάνει το λειτουργικό σύστημα προγραμματιζόμενο ακριβώς όπως η JavaScript κάνει το πρόγραμμα περιήγησης προγραμματιζόμενο. Στο παρελθόν, έπρεπε να αναβαθμίσουμε τις εκδόσεις του προγράμματος περιήγησής μας για να χρησιμοποιήσουμε πραγματικά συγκεκριμένους ιστότοπους. Και μετά ήρθε η JavaScript, και ξαφνικά ομάδες εφαρμογών και προγραμματιστές μπόρεσαν να δημιουργήσουν τεράστιες εφαρμογές — σε σημείο που η πιο δημοφιλής εφαρμογή επεξεργασίας κειμένου αντικαταστάθηκε από μια εφαρμογή στο πρόγραμμα περιήγησης. Οδήγησε σε ένα τεράστιο κύμα καινοτομίας. 

Το ίδιο συμβαίνει και με το eBPF, αν και σε επίπεδο λειτουργικού συστήματος, γιατί ξαφνικά μπορούμε να κάνουμε πράγματα σε επίπεδο πυρήνα ή λειτουργικού συστήματος όπου βλέπουμε τα πάντα και ελέγχουμε τα πάντα — πράγμα πολύ σημαντικό για την ασφάλεια — χωρίς να χρειάζεται να αλλάξουμε πυρήνα πηγαίος κώδικας. Μπορούμε ουσιαστικά να φορτώσουμε προγράμματα στον πυρήνα για να επεκτείνουμε τη λειτουργικότητά του και να φέρουμε μαζί του νέες δυνατότητες. Αυτό έχει επίσης ξεκλειδώσει ένα τεράστιο κύμα καινοτομίας. Υπερκλιμάκωση όπως το Facebook, η Google και το Netflix το χρησιμοποιούν μόνοι τους, άμεσα, με τις δικές τους ομάδες πυρήνα. 

Αυτό που φέρνει το Cilium στο τραπέζι είναι ότι χρησιμοποιεί αυτήν την τεχνολογία χαμηλού επιπέδου eBPF για να παρέχει ουσιαστικά ένα νέο κύμα υποδομής λογισμικού, ιδιαίτερα για το εγγενές κύμα cloud. Σκεφτείτε αυτό όπως η δικτύωση που ορίζεται από λογισμικό και τι έκανε η Nicira, η οποία έγινε VMware NSX, για τη βιομηχανία εικονικοποίησης. Κάνουμε το ίδιο για το cloud native, όπου είναι ένας συνδυασμός παρόχου cloud ή δημόσιας υποδομής cloud, καθώς και υποδομής εσωτερικής εγκατάστασης. Και επιλύουμε περιπτώσεις χρήσης δικτύωσης, ασφάλειας και παρατηρησιμότητας με αυτό στο επίπεδο υποδομής.

Και το Cilium Service Mesh, που μόλις κυκλοφόρησε, είναι μια εξέλιξη αυτών των δυνατοτήτων;

Αυτό που συμβαίνει αυτή τη στιγμή, από πριν από περίπου ένα χρόνο, είναι ότι οι δύο χώροι συγκρούονται. Αυτό που έχει κάνει μέχρι στιγμής η Cilium επικεντρώνεται στη δικτύωση, στην εικονική δικτύωση και, στη συνέχεια, στην εγγενή δικτύωση στο cloud — αλλά ακόμα στη δικτύωση. Στη συνέχεια, όμως, από την κορυφή προς τα κάτω, έκαναν οι ομάδες εφαρμογών στο Twitter και την Google υπηρεσία πλέγματος πράγματα — στην εφαρμογή πρώτα, και μετά το μοντέλο που βασίζεται σε sidecar, το μοντέλο που βασίζεται σε διακομιστή μεσολάβησης, όπως τα έργα Ίστιο παραδίδω. Και τώρα αυτά τα δύο στρώματα έρχονται πιο κοντά γιατί Οι παραδοσιακές επιχειρήσεις έρχονται στον εγγενή κόσμο του cloud και έχουν απαιτήσεις εταιρικής δικτύωσης, αλλά οι ομάδες εφαρμογών τους θέλουν επίσης ένα πλέγμα υπηρεσιών. 

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

Γιατί δίνεται τόση έμφαση στο επίπεδο δικτύωσης και πλέγματος εξυπηρέτησης της στοίβας Kubernetes;

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

Και συγκεκριμένα στο cloud native, Το multi-cloud γίνεται απολύτως απαραίτητο. Όλοι οι πάροχοι cloud έχουν τα δικά τους επίπεδα δικτύωσης, αλλά, φυσικά, προσαρμοσμένα στα δικά τους σύννεφα. Έχουν προσφορές on-prem, αλλά δεν είναι πραγματικά multi-cloud. Το Ciliium και το eBPF φέρνουν στο τραπέζι αυτό το πολυσύννεφο, αγνωστικό στρώμα. Συμπεριφέρεται ακριβώς στις εγκαταστάσεις όπως και στο δημόσιο νέφος. Αρκετοί από τους δημόσιους παρόχους cloud χρησιμοποιούν το Cilium under the hood για τις διαχειριζόμενες προσφορές Kubernetes τους και οι τηλεπικοινωνίες το χρησιμοποιούν για on-prem υποδομή 5G. Έχει να κάνει με το να μιλάς και τις δύο γλώσσες και να συνδέεις αυτούς τους κόσμους μαζί.

Γι' αυτό υπάρχει τόση εστίαση σε αυτό: επειδή ένας από τους ευκολότερους τρόπους για τους παρόχους cloud να κλειδώσουν τους πελάτες είναι να κατέχουν αυτό το επίπεδο συνδεσιμότητας. Νομίζω ότι από την άποψη της στρατηγικής υποδομής, όπως το επίπεδο εικονικοποίησης ήταν το κλειδί, τώρα το επίπεδο συνδεσιμότητας και δικτύου είναι απολύτως βασικό.

Η πηγή της [μελλοντικής] καινοτομίας θα είναι ο ανοιχτός κώδικας και οι πελάτες και οι χρήστες που θα οδηγούν τη ζήτηση θα είναι εταιρείες ένα επίπεδο πιο κάτω από τις υπερκλιμακωτές — ήδη μεγάλες εταιρείες που εξακολουθούν να προκαλούν μεγάλη αναστάτωση.

Το Kubernetes είναι αρκετά ευρέως αποδεκτό και υιοθετείται σε αυτό το σημείο, αλλά εξακολουθεί να γίνεται λόγος σε ορισμένους κύκλους ότι είναι υπερβολικό. Σε ποιον πιστεύετε ότι απευθύνεται το Kubernetes και το εγγενές οικοσύστημα του cloud συνολικά;

Είναι για σύγχρονες ομάδες εφαρμογών. Νομίζω ότι η συνειδητοποίηση έχει ξεκινήσει στο ότι αν θέλετε να προσελκύσετε σύγχρονες ομάδες εφαρμογών και να μπορείτε να έχετε γρήγορους χρόνους κυκλοφορίας στην αγορά, πρέπει να τους παρέχετε εγγενή υποδομή cloud. Συχνά βλέπουμε πρωτότυπα — αρχικό, pre-MVP, ακόμη και απόδειξη της ιδέας ή πώληση εσωτερικά — σε serverless, κάτι σαν το Lambda. Και μετά στο Kubernetes, επειδή οι ομάδες εφαρμογών μπορούν να κατέχουν απευθείας την υποδομή. Και μετά, καθώς προχωρά στην παραγωγή, πηγαίνουν σε επιχειρηματικές, on-prem διανομές Kubernetes. Αλλά αυτό είναι στην πραγματικότητα ένα σχετικά μικρό μέρος της συνολικής υποδομής, ίσως ένα μονοψήφιο ή χαμηλό διψήφιο ποσοστό. 

Σαφώς, όμως, θα είναι το νέο πρότυπο. Ακριβώς όπως η υιοθέτηση της εικονικοποίησης ήταν πολύ αργή αρχικά και οι άνθρωποι είπαν ότι ήταν υπερβολική — αλλά με την πάροδο του χρόνου, φυσικά, άρχισε να αντικαθιστά τα περισσότερα πράγματα — θα δούμε το ίδιο και εδώ. Ή όπως ακριβώς συμβαίνει με τις σύγχρονες γλώσσες. Οι άνθρωποι είπαν ότι η Java ήταν υπερβολική, και πιθανότατα εξακολουθεί να ισχύει για πολλές εφαρμογές, αλλά υπήρξε μια εποχή που έγινε πολύ δύσκολο να γίνει οποιαδήποτε ανάπτυξη εφαρμογών εκτός Java, επειδή αυτό θα μπορούσε να γράψει η πλειοψηφία των προγραμματιστών εφαρμογών. Το ίδιο θα ισχύει για τις σύγχρονες ομάδες εφαρμογών: θα περιμένουν να έχουν την Kubernetes για να αναπτυχθούν πιο ευέλικτα και να φέρουν το προϊόν γρήγορα στην αγορά.

Από την πλευρά της υποδομής, μπορεί να είναι λίγο υπερβολικό, αλλά αν η εναλλακτική είναι να ξαναγράψετε μια εφαρμογή από serverless σε on-prem, αυτό είναι ένα τεράστιο έργο. Οπότε η Kubernetes είναι η μέση λύση εκεί, η οποία είναι πολύ ελκυστική. 

Τι γίνεται με την ιδέα ότι η Kubernetes χρειάζεται ακόμα μια καλύτερη εμπειρία προγραμματιστή;

Αν κοιτάξουμε το αρχικό OpenShift, πριν επαναβασιστεί στο Kubernetes, ήταν αυτό. Ήταν ακόμα πιο κοντά στην ομάδα εφαρμογών και ήταν μια ακόμα καλύτερη εμπειρία προγραμματιστή εφαρμογών. Θα μπορούσατε να πιέσετε στο Git και θα αναπτυχθεί αυτόματα. Ο Heroku το δοκίμασε επίσης αυτό, αλλά βασισμένο στο SaaS. 

Ο Kubernetes έκανε ένα βήμα προς τα πίσω και είπε: «Πρέπει να διατηρήσουμε ορισμένες λειτουργικές πτυχές σε αυτό και να το κάνουμε λίγο πιο κοντά σε αυτό που θα περίμενε ένας sysadmin. Δεν μπορούμε να είμαστε προσαρμοσμένοι μόνο στις εφαρμογές». Είναι η μέση λύση: Πρέπει να έχει αρκετή ελκυστικότητα για τις ομάδες εφαρμογών, αλλά πρέπει να είναι δυνατή η εκτέλεση αυτής της εφαρμογής εκτός ενός συγκεκριμένου περιβάλλοντος και η διαχείρισή της από άτομα εκτός από προγραμματιστές εφαρμογών.

Θα έλεγα ότι το μεγαλύτερο βήμα μεταξύ Docker και Kubernetes ήταν ότι το Docker αφορούσε την εμπειρία προγραμματιστή. Έλυσε αυτό το κομμάτι, αλλά δεν έλυσε το κομμάτι του οικοσυστήματος του δημόσιου νέφους.

Πώς φτάσαμε σε αυτό το σημείο; Ήταν αυτή η φυσική εξέλιξη από τα δοχεία πλατφόρμας ως υπηρεσίας (PaaS) και εφαρμογών;

Ήταν οι εικόνες Docker και η πτυχή της συσκευασίας του Docker. Το παλιό σχολείο ήταν πώς να αναπτυχθεί σε εικονικές μηχανές, και υπήρχαν όλα τα είδη αυτοματισμού γύρω από αυτό. Και μετά ήταν αυτό που έκανε το Facebook με την Tupperware — πολύ προσαρμοσμένη και για πραγματικά μεγάλη κλίμακα. Και μετά ήρθε ο Docker και ουσιαστικά έδωσε αυτήν την εικόνα κοντέινερ και όλοι θα μπορούσαν να την αντιμετωπίσουν σαν μια μινιατούρα VM. Μπορώ πλέον να διανείμω την εφαρμογή μου και αντί για εικονική εικόνα 600 MB, είναι πλέον ένα κοντέινερ 10 MB. Μπορείς όμως να το αντιμετωπίσεις το ίδιο, έχει όλα όσα χρειάζεται. 

Αυτό ξεκλείδωσε τη δυνατότητα να φέρεις έναν ενορχηστρωτή όπως ο Kubernetes που εξακολουθεί να σου επιτρέπει να χειρίζεσαι εφαρμογές όπως τα mini VM, αλλά στη συνέχεια να κάνεις ένα βήμα παραπέρα και να τις αντιμετωπίζεις πραγματικά ως μικροϋπηρεσίες. Σας επιτρέπει να κάνετε και τα δύο.

Θα έλεγα ότι το μεγαλύτερο βήμα μεταξύ Docker και Kubernetes ήταν ότι το Docker αφορούσε την εμπειρία προγραμματιστή. Έλυσε αυτό το κομμάτι, αλλά δεν έλυσε το κομμάτι του οικοσυστήματος δημόσιου νέφους. Δεν είχε, ή δεν ήθελε απαραίτητα, στενή ενοποίηση με τους παρόχους cloud. Η Kubernetes το έλυσε. 

Ποιον βλέπετε να τρέχει την Kubernetes μέσα σε εταιρείες; Είναι μεμονωμένες ομάδες εφαρμογής;

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

Οι ομάδες πλατφόρμας είναι αυτές που αγοράζουν το Kubernetes και τις σχετικές τεχνολογίες, τις οποίες χρησιμοποιούν επειδή έχουν ως αποστολή να παρέχουν αυτήν την υποδομή επόμενης γενιάς για να κάνουν χαρούμενες τις σύγχρονες ομάδες εφαρμογών.

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

Είναι ένας καθαρός νέος αγοραστής ή μια καθαρά νέα ομάδα; Ή μήπως οι ομάδες πλατφόρμας είναι σαν κάτι που υπάρχει σε μέρη όπως το Google ή το Facebook και τώρα γίνονται mainstream;

Είναι κυρίως μια νέα ομάδα. Νομίζω ότι είναι, σε κάποιο βαθμό, σαν τις ομάδες SRE στη Google και στο Facebook. Ωστόσο, οι ομάδες εφαρμογών πιθανότατα κατέχουν περισσότερο από την ανάπτυξη εφαρμογών σε επιχειρήσεις, επειδή οι επιχειρήσεις δεν έχουν αυτή την πολύ σαφή διάκριση μεταξύ μηχανικών λογισμικού και SRE όπως η Google και το Facebook. Θα έλεγα ότι αυτή η εξέλιξη μοιάζει πολύ με τον τρόπο που είχατε ομάδες εικονικοποίησης και στη συνέχεια πολλές λειτουργίες δικτύου μετεγκαταστάθηκαν από — ή εξελίχθηκαν ή προχώρησαν — από το δίκτυο υλικού για το δίκτυο virtualization. Και αυτές οι ομάδες, για παράδειγμα, άρχισαν να λειτουργούν το VMware NSX. Το ίδιο συμβαίνει και εδώ. 

Αν και, δεν είναι απαραίτητα νέος προϋπολογισμός. Βλέπουμε ότι οι προϋπολογισμοί μετατοπίζονται από την ασφάλεια και τη δικτύωση σε αυτήν την ομάδα πλατφόρμας, για παράδειγμα, καθώς οι δαπάνες στο cloud αυξάνονται και δαπανώνται λιγότερα σε υλικό δικτύου. Συχνά συνεργάζονται με την ομάδα ασφαλείας και με την ομάδα λειτουργιών δικτύου για να λάβουν buy-in, αλλά στην πραγματικότητα κατέχουν ένα αρκετά σημαντικό μέγεθος του προϋπολογισμού.

Πώς βλέπετε το Ίδρυμα Cloud Native Computing εξελίσσεται και το Kubernetes θα είναι πάντα στο επίκεντρό του — ή του κινήματος εγγενών νέφους συνολικά;

Το Kubernetes είναι αυτό που πυροδότησε το CNCF και τα πρώτα δύο χρόνια αφορούσε το Kubernetes και το δημόσιο cloud. Αυτό που έχουμε δει πριν από περίπου ένα χρόνο είναι ότι πλέον δεν αφορά μόνο το Kubernetes, είναι στην πραγματικότητα περισσότερο για το cloud native αρχές. Αυτό στην πραγματικότητα σημαίνει ότι δεν είναι απαραίτητα πλέον σύννεφο, ούτε καν ιδιωτικό cloud. Συχνά είναι ακόμη και η παραδοσιακή δικτύωση επιχειρήσεων, η βαρετή on-prem υποδομή, οι γυμνοί μεταλλικοί διακομιστές και όλα αυτά, αλλά με ενσωματωμένες τις εγγενείς αρχές του cloud. 

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

Βλέπουμε μια πολύ μεγάλη απαίτηση να συνεχίσουμε να συνδέουμε τον παλιό κόσμο και να μιλάμε για MPLS, VLAN, sFlow και NetFlow — ολόκληρο το υπάρχον σύνολο επιχειρηματικών απαιτήσεων. Κανένας τους δεν έχει φύγει.

Περίπου μια δεκαετία μετά, ο εγγενής χώρος του cloud δεν φαίνεται να είναι μόδα. Πόσο περιθώριο υπάρχει για να συνεχίσει να εξελίσσεται;

Υπήρχε σίγουρα μια εποχή που ήταν σαν, "Ω, το Kubernetes είναι πιθανότατα βραχύβιο και χωρίς διακομιστή θα είναι το επόμενο επίπεδο". Ή, "Το Kubernetes είναι παρόμοιο με το OpenStack. Ή, "Θα εξαφανιστεί και θα είναι μια λεπτομέρεια υλοποίησης." Και αυτό δεν έχει συμβεί. 

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

Ποια μεγάλα προβλήματα πρέπει ακόμη να επιλυθούν σε επίπεδο υποδομής;

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

Αυτή είναι λοιπόν η επόμενη μεγάλη πρόκληση: Ποιος θα είναι αυτό το αγνωστικό επίπεδο για multi-cloud και cloud native, όπως αυτό που έγινε το VMware; Ποιος θα είναι το VMware για το cloud native;

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

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

Το δύσκολο μέρος είναι ότι οι σύγχρονες ομάδες εφαρμογών έχουν συνηθίσει να έχουν το επίπεδο υποδομής να εξελίσσεται τόσο γρήγορα όσο αυτές. Και αυτό ανάγκασε το επίπεδο υποδομής να είναι ακόμα πιο προγραμματιζόμενο, πιο ρυθμιζόμενο. Γι' αυτό βλέπουμε στην πραγματικότητα ένα επίπεδο δικτύωσης και ένα επίπεδο ασφάλειας πάνω από το επίπεδο δικτύωσης cloud. Αλλά τώρα έχουμε επιχειρήσεις που έρχονται και βλέπουμε μια πολύ μεγάλη ζήτηση να συνεχίσουμε να συνδεόμαστε με τον παλιό κόσμο και να μιλάμε για MPLS, VLAN, sFlow και NetFlow — ολόκληρο το υπάρχον σύνολο επιχειρηματικών απαιτήσεων. Κανένα από αυτά δεν έχει εξαφανιστεί, όλοι οι κανόνες συμμόρφωσης παραμένουν οι ίδιοι. Και ακόμη και μερικές από τις σύγχρονες εταιρείες SaaS αντιμετωπίζουν τώρα αυτές τις προκλήσεις καθώς μεγαλώνουν και ενδιαφέρονται για τη συμμόρφωση και ούτω καθεξής. 

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

Από πού βλέπετε να προέρχεται το επόμενο κύμα εγγενούς καινοτομίας στο cloud; Εξακολουθεί να προέρχεται από μια εταιρεία όπως η Google ή υπάρχει ένας νέος τύπος εταιρείας που ηγείται της χρέωσης;

Ειναι πολυ ενδιαφερον. Θα έλεγα ότι μάλλον δεν προέρχεται από τα Google και τα Facebook. Η πηγή της καινοτομίας θα είναι ανοιχτού κώδικα και οι πελάτες και οι χρήστες που θα οδηγήσουν τη ζήτηση θα είναι εταιρείες ένα επίπεδο χαμηλότερα από τις υπερκλιμακωτές — ήδη μεγάλες εταιρείες που εξακολουθούν να προκαλούν μεγάλη αναστάτωση, όπως η Adobe, το Shopify ή το GitHub. Αλλά και εταιρείες που κινδυνεύουν να διαταραχθούν από την τεχνολογία, όπως οι χρηματοπιστωτικές υπηρεσίες, οι ασφαλιστικοί πάροχοι και οι τηλεπικοινωνίες. Όλες αυτές οι εταιρείες έχουν κοινό συμφέρον στην τυποποίηση της υποδομής με επαναλαμβανόμενα μοντέλα ανάπτυξης και υποδομής.

Δημοσιεύτηκε στις 26 Ιουλίου 2022