- Pag-aampon ng isang kaisipang produkto na nakatuon sa paglutas ng mga totoong problema ng gumagamit sa halip na pagpapatupad lamang ng mga teknikal na solusyon.
- Pagpapatupad ng mga cloud-native na arkitektura batay sa mga microservice, container, at pamantayan ng Twelve-Factor App upang makakuha ng liksi at scalability.
- Komprehensibong automation sa pamamagitan ng Infrastructure as Code (IaC) at CI/CD flows upang mabawasan ang mga error at mapabilis ang paghahatid ng value.
Kung nagtatrabaho ka sa imprastraktura, malamang na napagtanto mo na ang simpleng pag-set up ng mga cluster at pag-deploy ng mga serbisyo ay hindi sapat upang garantiyahan ang tagumpay ng isang sistema. Madalas tayong masyadong nakatuon sa makabagong teknolohiya kaya nakakalimutan natin kung sino talaga ang gagamit ng platform at kung anong mga totoong problema sa mundo ang sinusubukan nating lutasin araw-araw.
Upang matigil ang pagkapa sa dilim, isang pamamaraan na tinatawag na Product Thinking ang lumitaw, na karaniwang binubuo ng pagtigil sa pag-iisip sa imprastraktura bilang isang proyekto na may petsa ng pagtatapos at simulang makita ito bilang isang buhay at umuunlad na produkto . Hindi lamang ito tungkol sa pag-install ng mga tool, kundi tungkol sa pagbabago ng mindset upang madama ng mga inhinyero na gumagamit ng aming platform na pinapadali namin ang kanilang buhay, hindi mas kumplikado.
Ang konsepto ng Product Thinking ay inilapat sa inhenyeriya
Ang Product Thinking ay, sa esensya, ang proseso ng pagtukoy at pagbibigay-priyoridad sa mga problema ng customer upang makabuo ng halaga sa pamamagitan ng paglutas sa mga ito. Narito ang isang mahalagang punto: ang pokus ay hindi dapat nasa functionality o teknikal na katangian, kundi sa mismong problema. Kapag ang isang inhinyero ay direktang nagdidisenyo ng solusyon nang hindi nauunawaan ang mga pinagbabatayan na dahilan, nanganganib silang mag-aksaya ng oras at pera sa isang bagay na sa huli ay walang gagamit o hindi tutugon sa tunay na pangangailangan.
Para maiwasan ito, mahalagang umibig sa problema, hindi sa solusyon. Kung tayo ay nahuhumaling sa tool, isinasara natin ang pinto sa paggalugad. Sa halip, kung makikipag-usap tayo sa mga gumagamit at magkakaroon ng empatiya , maaari nating patunayan ang mga hypotheses bago magsulat ng kahit isang linya ng code, na lubos na binabawasan ang panganib ng paglikha ng isang sistema na nagiging isang pasanin sa pagpapatakbo o nagtataguyod ng paglitaw ng shadow IT kung saan ang mga gumagamit ay naghahanap ng mga alternatibo sa kanilang sarili.
Hindi tulad ng tradisyonal na pamamahala batay sa proyekto—na kinabibilangan ng pangangalap, pagpapatupad, at pag-deploy ng mga kinakailangan—ang pamamaraan ng produkto ay tuluy-tuloy at paikot . Nakatuon ito sa pagpapanatili ng isang bukas na channel ng komunikasyon sa gumagamit upang patuloy na makapaghatid ng halaga. Ang siklong ito ay nagtataguyod ng isang relasyon ng tiwala na nagpapahintulot sa platform na lumago nang organiko at maging isang multiplier ng pagiging epektibo para sa buong organisasyon.
Pag-unawa sa ecosystem ng Cloud Native
Para mailapat ang kaisipang ito, kailangan muna nating maunawaan kung ano ang ibig sabihin ng pagiging cloud-native. Hindi lamang ito basta pag-upload ng virtual machine sa cloud, kundi pagdidisenyo ng mga application na lubos na sinasamantala ang elastic computing model . Kabilang dito ang paglikha ng mga resilient, scalable, at observable system na nagbibigay-daan para sa mga madalas na pagbabago na may kaunting panganib, gamit ang mga elemento tulad ng mga container, service mesh, at declarative API.
Ang liksi ng modelong ito ay nakasalalay sa ilang haligi. Ang una ay ang mismong cloud, kung saan tayo ay lilipat mula sa konsepto ng "mga alagang hayop" (mga pinangalanang server na may indibidwal na pangangalaga) patungo sa konsepto ng "mga alagang hayop" o mga kalakal (magkapareho at disposable na mga halimbawa). Sa ilalim ng pamamaraang ito, kung ang isang server ay masira, hindi ito maaayos: ito ay sisirain at ang isang bago ay awtomatikong ise-set up gamit ang immutable infrastructure.
Mga prinsipyo ng modernong disenyo at arkitektura
Para maging tunay na cloud-native ang isang application, karaniwang ginagamit ang metodolohiyang Twelve-Factor App . Nilalayon ng hanay ng mga patakarang ito na i-optimize ang portability at automation. Kabilang sa mga pangunahing punto ang bawat microservice ay dapat may sarili nitong codebase at mga nakahiwalay na dependency, at ang configuration ay dapat na i-externalize upang ang parehong binary ay maaaring ilipat sa pagitan ng QA at mga production environment nang walang pagbabago.
- Mga proseso at sabay-sabay na pagkakasunod-sunod: Ang bawat serbisyo ay dapat tumakbo sa sarili nitong proseso at masukat nang pahalang, na iniiwasan ang napakalaking patayong pag-scale.
- Pagtatapon: Kailangang mabilis na magsimula at magsara nang maayos ang mga instance, isang bagay na kayang hawakan nang maayos ng mga container.
- Pagkakapantay-pantay ng kapaligiran: Ang kapaligiran ng pag-unlad ay dapat na katulad hangga't maaari sa kapaligiran ng produksyon upang maiwasan ang mga hindi kanais-nais na sorpresa habang inilulunsad.
- Telemetrya at mga API: Mahalagang magdisenyo muna gamit ang API at mangolekta ng datos ng kalusugan at pagganap mula sa simula.
Bukod pa rito, ang mga balangkas tulad ng Well-Architected Framework ng Microsoft ay nakakatulong na matiyak ang kalidad batay sa limang haligi: pamamahala ng gastos (pagbabayad lamang para sa iyong ginagamit), kahusayan sa pagpapatakbo (pag-automate ng lahat), bisa ng pagganap, pagiging maaasahan (kakayahang makabawi mula sa mga error), at, siyempre, seguridad na isinama sa buong lifecycle.
Mga microservice at pamamahala ng pagiging kumplikado
Ang puso ng mga solusyong cloud-native ay nasa mga microservice. Sa pamamagitan ng paghahati-hati ng isang monolitikong aplikasyon sa maliliit at independiyenteng mga serbisyo, nagkakaroon tayo ng hindi kapani-paniwalang liksi . Maaari nating i-update ang mga partikular na functionality nang hindi kinakailangang i-restart ang buong sistema at i-scale lamang ang mga bahaging pinakamataas ang demand, sa gayon ay ma-optimize ang mga gastos sa pagpapatakbo.
Gayunpaman, nagdudulot ito ng mga hamon. Ang komunikasyon sa pagitan ng mga serbisyo ay nagiging kumplikado, at lumilitaw ang pangangailangang pamahalaan ang katatagan (ano ang mangyayari kung ang serbisyo B ay maging hindi tumutugon?) at ang ipinamahaging datos. Ang mga tool tulad ng Dapr ay nakakatulong na gawing simple ito sa pamamagitan ng pagbibigay ng mga pre-built building block na nagsisilbing dynamic glue, na nagpapahintulot sa mga developer na tumuon sa business logic sa halip na sa mga detalye ng imprastraktura.
Mga Serbisyo ng Container, Orchestration at Backup
Ang mga container ang mga pangunahing tagapagtaguyod ng modelong ito. Sa pamamagitan ng pag-empake ng code at mga dependency nito sa isang imahe, tinitiyak namin na ang application ay gumagana nang pareho sa laptop ng developer tulad ng sa production server. Upang mapamahalaan ang libu-libong container na ito, kailangan namin ng isang orchestrator; at dito itinatag ng Kubernetes ang sarili bilang de facto standard, na humahawak sa scheduling, health monitoring, at automatic scaling.
Upang maiwasan ang mga komplikasyon, ang mainam na solusyon ay ang pagtatalaga ng pamamahala ng mga pantulong na mapagkukunan (mga database, pila ng mensahe, mga log) sa mga pinamamahalaang serbisyo ng backup mula sa mga cloud provider. Sa ganitong paraan, inaalis namin ang pasanin ng mga lisensya at pagpapanatili, tinatrato ang mga serbisyong ito bilang mga nauugnay na mapagkukunan na naka-link sa pamamagitan ng mga URL at panlabas na kredensyal, pinapanatili ang code na nakahiwalay at nababaluktot.
Ganap na Awtomasyon: Ang Landas Tungo sa CI/CD
Hindi gagana ang alinman sa mga ito nang walang matatag na automation. Ang Infrastructure as Code (IaC) ay nagbibigay-daan sa iyong tukuyin ang network at mga server gamit ang mga declarative script (tulad ng Terraform o Bicep), na ginagawang paulit-ulit ang deployment at walang pagkakamali ng tao. Ito ay kinukumpleto ng Continuous Integration and Continuous Delivery (CI/CD) workflow.
Sa isang modernong daloy ng trabaho, ina-upload ng developer ang kanilang code sa isang repository, na nagti-trigger ng isang awtomatikong yugto ng pagbuo at pagsubok. Pagkatapos ay isang hindi nababagong bersyon ang nabubuo at naide-deploy sa target na kapaligiran. Ginagawang transparent ng mga tool tulad ng Google Cloud Build o GitHub Actions ang prosesong ito, na nagpapadali pa nga sa pag-aampon ng GitOps , kung saan ang nais na estado ng cluster ay direktang inilalarawan sa isang Git file.
Ang paglipat sa modelong ito ay nangangailangan ng higit pa sa mga kagamitan lamang; nangangailangan ito ng pagbabago sa kultura . Ang mga pangkat ay dapat maging cross-functional, sinisira ang mga silo sa pagitan ng pag-unlad at operasyon upang magkaroon ng isang nakabahaging responsibilidad na pag-iisip. Sa pamamagitan ng pagsasama-sama ng teknikal na kapangyarihan ng Kubernetes at ng cloud na may diskarteng nakasentro sa gumagamit , maaaring baguhin ng mga organisasyon ang kanilang imprastraktura tungo sa isang business engine na nagtutulak ng patuloy na inobasyon at kahusayan sa pagpapatakbo.
Talatuntunan
- 1 Ang konsepto ng Product Thinking ay inilapat sa inhenyeriya
- 2 Pag-unawa sa ecosystem ng Cloud Native
- 3 Mga prinsipyo ng modernong disenyo at arkitektura
- 4 Mga microservice at pamamahala ng pagiging kumplikado
- 5 Mga Serbisyo ng Container, Orchestration at Backup
- 6 Ganap na Awtomasyon: Ang Landas Tungo sa CI/CD