Bulud köçü: necə başlamaq, qərar vermək və kömək almaq

Dennis Harvey, 1/10/2020, Cadence80Studios.com

Şirkətinizin İT hesablama mənbələrini buludlara köçürmək qərarı kifayət qədər sadə ola bilər, lakin taktiki qərarlar alınmır və səhvlər baha başa gəlir. Bəzi şirkətlər tək satıcı həll yollarını izləyirlər. Bəziləri bulud aqnostik strategiyaları aparır. Bəziləri hibrid-bulud yanaşmaları izləyirlər. Bu yazı Google Cloud Platformasını (GCP) vurğulayır, baxmayaraq ki, məqalənin mahiyyəti digər bulud satıcılarına da aiddir.

Xidmət provayderlərinin geniş bir sıra bazarı, misli görünməmiş bulud miqrasiyasına kömək etmək üçün geniş konsaltinq firmalarını, butik texnologiya firmalarını, müqavilə ilə işləyən şirkətləri, İT infrastruktur təminatçılarını, idarə olunan xidmət təminatçılarını daxil etdi və siyahı davam edir.

Bulud miqrasiyasına başlamağınıza, öyrənmə əyriliyinizi qısaltmağınıza, bəzi bahalı səhvlərdən qaçınmağınıza və kömək mənbələrini müəyyənləşdirməyə kömək edəcək bir məqalə vermək bu məqalənin məqsədi.

Qərarlar: Şirkətiniz bu qərarlar daimi bir başlanğıcdan bir bulud köçü ilə qarşılaşır:

  1. Bulud strategiyanıza qərar verin: tək bulud satıcısı, bulud aqnostik və ya hibrid bulud.
  2. Buludda hansı tətbiqlər hərəkət edir: mövcud korporativ və ya köhnə tətbiqlər və ya yeni tətbiqlər?
  3. Başlanğıcdan təməl əsasları əldə edin.
  4. Lazım olan köməyi müəyyənləşdirin.

Gəlin dörd mövzu sahəsinə baxaq.

Tək bulud satıcısı, bulud aqnostik və ya hibrid bulud

Bu mövzu yəqin ki, öz məqaləsinə layiqdir, amma burada bir neçə giriş düşüncəsi var. Bir çox şirkət bir bulud satıcısı kilidləmə ssenarisinə girməkdən çəkinir; buna görə bir bulud aqnostik yanaşması səthdəki tək bulud satıcısından daha yaxşı səslənir. Əslində, bulud aqnostikasını satıcıya bağlanmadan həqiqi praktiki müdafiəni təmin etmək üçün kifayət qədər böyük fayda gətirəcək mürəkkəblik əlavə etmədən həyata keçirmək çətindir.

Konteyner texnologiyası, Docker, Kubernetes və Terraform hamısı bəzi bulud aqnostik hədəflərinə çatmaq üçün istifadə edilə bilər. Konteynerlər, Docker və Kubernetes hamısı bulud doğma tətbiqləri olaraq adlandırılan çətir altına düşür. Kubernetes, hər bir bulud satıcısının öz idarə olunan K8s xidmətinə malik olduğundan Kubernetes böyük ölçüdə aqnostik güc təmin edir: GCP üçün GKE, AWS-də EKS və Azure-də AKS. Elliot Forbesin Cloud Agnostic Architecture adlı bir məqaləsində söylədiyi bir çox məqamı bəyənirəm.

Terraform, bulud qaynağı təminatını avtomatlaşdıran liderdir və yüklü provayder memarlığına görə bulud aqnostik super gücləri təmin edir. Bu, Terraform-a düzgün provayderdən istifadə edərək əsas bulud platformalarından hər hansı birində bulud mənbələrini təmin etməyə imkan verir. Tutmaq, hər bir bulud provayderinin fərqli mənbələr şəklində öz sintaksisinə sahib olması və bu mənbələrin özünəməxsus dəyişən tərifləri olmasıdır. Terraform ilə bulud mənbələrini təmin etmək, buna görə də tamamilə bulud aqnostik deyildir, çünki Terraform kodunun özü hər bir bulud provayderi üçün fərqlidir: GCP, AWS və Azure. Bulud mənbələrinizi yaratmaq üçün hər bir bulud Terraform təminatçınıza uyğun "terraform kodu" "port" edə bildiyiniz halda doğru istiqamətdə bir addım təmin edir.

Bulud aqnostik aləmində başqa bir mülahizələr dəsti bunlardır: idarə olunan xidmətlər və mülkiyyət bulud satıcı xidmətləri. İdarə olunan xidmətlər ya əməliyyatları adətən əhəmiyyətli dərəcədə asanlaşdırır və ya standart alternativlərə nisbətən "tələb olunmayan əməliyyatlar" və ya "NoOps" faydaları verir. GCP nümunələrinə aşağıdakılar daxildir:

  • GCE (VM) instansiyalarında öz MySQL və ya Postgresql yerinə CloudSQL
  • Sizə məxsus Hadoop qrupları və xidmətləri əvəzinə DataProc

GCP CloudSQL, nümunə olaraq bu vacib əməliyyat üstünlüklərini təmin edir.

Ciddi bir bulud aqnostik yanaşması hər bir bulud satıcısı tərəfindən təklif olunan idarə olunan xidmətlərin əksəriyyətindən yayınmağı diktə edərdi. Yenə də, idarə olunan xidmətlər sadələşdirilmiş istifadə, avtomatlaşdırılmış xüsusiyyətlər və ekvivalent, standart, öz-özünə xidmətlərə nisbətən əməliyyatları asanlaşdırmaqla yanaşı bir çox üstünlük verir. Beləliklə, idarə olunan xidmətlərdən ciddi şəkildə qaçınmaq üçün daha çox əməliyyat mənbəyi, daha mürəkkəblik və qrupunuzun devopsoz olduğunu ehtimal etmək üçün bazara daha uzun müddət tələb olunur.

Mülkiyyət xidmətləri idarəedilən xidmətlərə bənzər mülahizələrə malikdir, çünki açıq-aydın buludlu agnostik deyillər. Qlobal mesajlaşma xidmətləri təqdim edən GCP-də Pub / Sub xidmətlərini nəzərdən keçirin. Pub / Sub, məsələn, Kafka tərəfindən geniş yayılmış, açıq mesajlaşma platforması alternativi olaraq GCP daxilində mesajlaşma üçün istifadə etmək daha asandır. Yenə də bu mülkiyyət xidmətlərindən ciddi şəkildə qaçınmaq daha çox əməliyyat mənbəyi, daha mürəkkəb və daha uzun bazar tələb edir.

Hibrid bulud ümumiyyətlə yerli, özəl bulud və ictimai bulud hesablama mənbələrini birləşdirən bir mühitə aiddir. Bir çox şirkət, ictimai buludda hərəkət etməyən və ya edə bilməyən hesablama xidmətlərinə görə hibrid-buludlu bir yanaşma seçəcək və ya seçməyə məcbur olacaq. Bunlardan bir misal, mainframe kompüterlərində işləyən bank xidmətləri. Digər hallarda, təhlükəsizlik səbəbiylə və ya xüsusi əqli mülkiyyəti qorumaq üçün tətbiqlər yerli və ya xüsusi buludlarda saxlanıla bilər.

Şirkətiniz bir neçə bulud platformasında işləyən bir məhsul / xidmət qurarsa, o zaman iş tələbləri bir bulud aqnostik yanaşmanı təmin edəcəkdir. Şirkətiniz buludlu aqnostik bir yanaşmanı qeyri-müəyyən bir sığorta siyasəti kimi qiymətləndirirsə, əlaqəli mürəkkəbliyi və dəyəri yenidən qiymətləndirmək istəyə bilərsiniz.

Buludda hansı tətbiqlər hərəkət edir: mövcud korporativ və ya köhnə tətbiqlər və ya yeni tətbiqlər?

Mövcud tətbiqlər və köhnə tətbiqlər bəzən qaldırma və sürüşmə yanaşması istifadə edərək buludlara köçürülür ki, bu da əsasən hesablama mənbələrini yerli hesablama və şəbəkə mənbələrinə mümkün qədər bənzətmək deməkdir. Tez-tez bu yanaşma bulud miqrasiyasını sürətləndirmək və asanlaşdırmaq üçün qəbul edilir.

Bu nöqtədə qaldırma və dəyişdirmə yanaşmasının mənfi cəhətləri haqqında çox şey yazıldı və GCP layihələrimdə ilk məhdudiyyətləri yaşamışam. Dezavantajları hədəf bulud platforması üçün optimallaşdırılmaması kimi geniş təsnif edilə bilər və bunlara daxildir:

  • Elastik, avtomatik miqyaslama və GCP kontekstində idarə olunan nümunə qrupları və GKE kimi yüksək səviyyədə idarə olunan xidmətlərdən istifadə edilməməsi.
  • Məlumat bazası xidmətlərini daha güclü alternativlərə köçürə bilməməyiniz, məsələn CloudSQL istifadə GCE misallarında öz MySQL yerinə və ya Spanner kimi daha genişlənən SQL platformaya köçürülmə.
  • Bulud üçün uyğun olmayan tipologiyaları izləyərək proqram təyin olunan şəbəkəni (GCP kontekstində SDN) optimallaşdıra bilməmək.
  • Bulud satıcısı tərəfindən təmin edilən tamamilə yeni təhlükəsizlik xidmətləri və konsepsiyalardan tam istifadə edilməməsi. Misal olaraq genişlənən firewall qaydalarının ənənəvi aparat firewall cihazlarından tamamilə fərqli GCP-də tətbiq olunduğunu göstərmək olar.

Bir çoxunuz, bir layihənin növbəti mərhələsində əsas memarlıq qüsurlarını düzəltmək fikrini yaşamısınız və bu mərhələ heç vaxt baş tutmur. Giriş yerindən düzgün arxitekturanı əldə etmək üçün qabaqcadan dizayn üçün heç bir yer yoxdur və bu da bulud miqrasiyasına aiddir.

Səyahətlərimdə qaldırma və növbələşmə yanaşması yalnız sadə tətbiqetmə və ətraf mühitdən istifadə halları üçün uyğundur və GCP layihəmdə yalnız bir dəfə uyğun istifadə vəziyyətinə rast gəldim.

Bulud üçün yeni tətbiqlər hazırlamaq tamamilə fərqli bir işdir. Bir çox hallarda şirkətlər qablar, Docker, Kubernetes və mikro servislərdən istifadə edərək buludlu yerli yanaşma tətbiq edəcəklər. Vaxt keçdikcə Kubernetes (aka K8s) haqqında oxumağınıza və ya özünüzlə işlədiyinizə şübhə yoxdur, çünki bu bizim hesablama / devops / bulud dünyamızdakı ən isti texnologiyalardan biridir. Konteynerlərin virtual maşınlara nisbətən tanınmış üstünlüklərini bərpa etmək üçün çox az səbəb var. Hər bir əsas bulud satıcısının K8s xidmət tətbiqi var: GCP üçün GKE, AWS-də EKS və Azure-də AKS.

K8s-in isti bir mal olduğuna görə GCP dünyasında digər xidmətlərə daha uyğun olan bir çox xidmət və tətbiqetmənin olduğunu etiraf etmək lazımdır.

  • Virtual maşınlar üçün Google hesablama mühərriki (GCE)
  • İdarə olunan bir tətbiq platforması üçün Google tətbiqi mühərriki (GAE)
  • Hadisə idarə serverless funksiyaları üçün Cloud funksiyaları
  • Serversiz konteynerli tətbiqləri işə salmaq üçün Cloud Run

Təməlləri başlanğıcda alın

Vəqflər: Buludda təməl əsaslarını düzgün şəkildə düzəltmədən böyük fayda əldə edəcəksiniz. Tətbiq arxitekturanızı tətbiqi inkişaf dünyasında əvvəlcədən müəyyənləşdirmək üçün oxşar bir şeydir.

GCP sahəsində, bu cür şeyləri get-go-dən düzgün müəyyənləşdirmək deməkdir:

  • Resurs iyerarxiyası: təşkilat, qovluqlar, layihələr
  • Şəxsiyyət və Giriş İdarəçiliyi (İAM): şəxsiyyət qruplarını və xidmət hesablarını müəyyənləşdirin
  • Şəbəkə: VPC (virtual özəl bulud), paylaşılan VPClər, alt şəbəkələr, firewall qaydaları və yerli şəbəkələrə qoşulma
  • Perimetrinizi, şəbəkələrinizi və tətbiqlərinizi qorumaq üçün müvafiq təhlükəsizlik xidmətlərini həyata keçirməklə yanaşı, yuxarıda göstərilənlərin hamısı ilə kəsişən təhlükəsizlik.

Bu GCP arayışı, Müəssisə təşkilatları üçün ən yaxşı təcrübələr, daha çox məlumat ilə yaxşı bir xülasə təmin edir.

Xidmətlər: Yuxarıda idarə olunan və mülkiyyət xidmətləri ilə bağlı bəzi mülahizələrə qısa toxunduq. Xidmət seçimi ilə əlaqəli qərarlarınız təsir edəcək: bulud miqrasiya mürəkkəbliyi və xərcləri, devops və gələcək texniki xidmət, ölçülmə qabiliyyəti və yüksək mövcudluq və davamlılıqda gələcək bulud əməliyyat xərcləri.

Xidmət seçimi xüsusi bir geniş məqaləyə layiqdir, amma burada bir neçə fikir təqdim edəcəyəm.

Bulud, məlumat mərkəzindəki yerli avadanlıqdan bir çox üstünlük təklif edir:

  • Tələb ilə otoskale edən elastika xidmətləri
  • Yüksək mövcudluq daha əlçatandır
  • Şəxsiyyət və giriş idarəetmə üçün vahid və mərkəzləşdirilmiş xidmətlər (İAM)
  • Qitələr, bölgələr və zonaları əhatə edən qlobal şəbəkə
  • Təhlükəsizlik üçün vahid və hərtərəfli xidmətlər
  • Mərkəzləşdirilmiş giriş və monitorinq
  • Avtomatlaşdırma (növbəti hissədə müraciət olunur)

Yerli serverlərdən istifadə edərək pərakəndə e-ticarət günlərimdə avtomatik miqyaslama imkanlarına həsrət olduğumu xatırlayıram.

GCP bulud servislərindəki avtomatik miqyaslama imkanlarını gözardı etmək çox yaxşıdır. Bəzi nümunələrə aşağıdakılar daxildir:

  • GKE / K8s-də klaster otoskallaşdırılması
  • GCE-də idarə olunan nümunə qruplarında autoscaling (əsasən VM-lərin avtomatik miqyaslı hovuzları)
  • Məlumat anbarı analitikası üçün Bigquery, təbii olaraq avtomatik ölçülüdür və hər hansı bir çoxluq məlumatını göstərməyə ehtiyac olmadan saniyədə minlərlə nüvəni əhatə edə bilər.
  • Google'un idarə etdiyi Hadoop və Spark xidməti olan Dataproc, otoskale etmir, ancaq istənilən ölçüdə çoxluqları bir neçə dəqiqə içində bükə bilərsiniz.
  • Spanner GCP-nin əməliyyat, üfüqi ölçülən, əlaqəli (aka SQL) məlumat bazasıdır. Otoskale deyil, ancaq bir nümunəyə daha çox qovşaq əlavə etməklə asanlıqla ölçülə bilər.

Avtomatlaşdırma: Bulud, proqram təminatını proqram təminatı ilə əvəz etməkdən ibarətdir: proqram təminatı ilə müəyyən edilmiş ehtiyat tədarükü, proqram təminatı ilə təyin olunan şəbəkə (SDN) və əsasən hər şey müəyyənləşdirilmiş proqram. Yerli hardware dünyasında siz hardware sahəsinə sahibsiniz. Yeni bulud dünyasında mənbə kodunuz var və ya heç olmasa qısa müddətdə vurğulayacağım qədər olmalıdır.

GCP-də və digər bulud satıcılarında da bütün qaynaqlar etibarlı REST API-lərinə zəng etməklə yaradılır, sadalanır və başqa şəkildə idarə olunur. Bu API-lər müxtəlif mexanizmlər, alətlər və proqramlar tərəfindən istifadə edilə bilər, o cümlədən:

  • GCP konsolu: konsol.cloud.google.com
  • Gcloud SDK
  • Terraform və ya Google Cloud Deployment Manager kimi qaynaq təminetmə vasitələri
  • Bulud REST API-lərini çağıran Homegrown proqramları və qabıq skriptləri

Yuxarıda göstərilənlərin hər biri müxtəlif istifadə halları üçün istifadə edilə bilər. Hər şey deyildikdə və edildikdə, bu vacib imkanları təmin edən bir dildə bəzi vasitələrdən istifadə edərək tam mənbə koduna sahib olmalısınız:

  1. Bulud mənbələrinizi kod şəklində sənədləşdirin
  2. Bulud mühitlərinizi (inkişaf, quruluş, QA, istehsal) istəyinizlə yenidən yaradın
  3. Zamanla bulud ehtiyatlarınızı artırın / genişləndirin
  4. Yüksək mövcudluğu və fəlakət bərpa

Yuxarıda göstərilənlərin əhəmiyyətini qeyd etmək olmaz. Bulud ehtiyatlarının heç bir kod və ya avtomatlaşdırma olmadan konsoldan istifadə edildiyi istehsalda bir neçə əsas ticarət mühiti ilə qarşılaşdım. Bulud ümumiyyətlə yerli avadanlıq üçün mövcud olmayan avtomatlaşdırma imkanlarını təmin edir, buna görə də bu imkanlardan əvvəldən istifadə edin. Bu təkrar etməməli olduğunuz bir səhvdir və düzgün bir yanaşma və tərəfdaşın köməyi ilə asanlıqla qarşılanır.

Lazım olan köməyi müəyyənləşdirin

Yardım: Yuxarıda göstərilən bəzi vacib qərarlar qəbul etdiniz və bulud miqrasiyasını reallaşdırmaq üçün lazım olan köməyi müəyyənləşdirməyin vaxtı gəldi.

Satıcılar və texnoloji tərəfdaşlar strategiya tövsiyələri, texnoloji məsləhətlər, həyata keçirmə (dizayn, qurulma, yerləşdirmə və nəzərdən keçirmə metodologiyası ilə) və təlim daxil olmaqla bir sıra xidmətlər təklif edirlər. GCP vəziyyətində sadalanan tərəfdaş ixtisaslarına daxildir: tətbiqetmənin inkişafı, bulud miqrasiyası, məlumat analitikası, infrastruktur, IoT, məkan mərkəzli xidmətlər, maşın öyrənmə, marketinq analitikası, təhlükəsizlik, iş çevrilməsi və təlim (məlumat analitikası, infrastruktur, təhlükəsizlik ).

Hansı növ köməyə ehtiyacınız var: strateji və ya memarlıq məsləhəti və ya taktiki həyata keçirməyə kömək?

Bir çox hallarda, taktiki həyata keçirmək üçün tələb olunan bulud bacarıqlarına yiyələnmək üçün onsuz da texniki heyətinizdə olan insanları yetişdirə bilərsiniz. İnternet təlim resursları linuxacademy, coursera və udemy ilə lazımlı bilik əldə etmək və müxtəlif səviyyəli bulud satıcılarının sertifikatlarına sahib olmaq üçün onlayn kurslar verən heyrətamizdir. Mən bir neçə GCP sertifikatımı əldə etmək üçün istifadə etdiyim linuxacademy'yə qismən baxıram.

Bir çox hallarda, bahalı səhvlərə yol verməmək üçün əvvəldən strateji və memarlıq seçimlərini aydınlaşdırmaq üçün düzgün tərəfdaş işə götürmək istəyəcəksiniz.

Dennis Harvey, proqram inkişafı, müəssisələrin hesablanması, genişmiqyaslı e-ticarət və özünüzün adı olan bir karyera quraraq, https://cadence80studios.com/ adlı bir nəfərlik GCP konsaltinq təcrübəsinin banisidir.